Blocchi di codice che producono tabelle organizzative per essere successivamente consumati da altri blocchi di codice


9

Sto riscontrando un po 'di problemi con i blocchi di codice che producono tabelle org da consumare in seguito da altri blocchi di codice. Per esempio:

#+NAME: upper_air
#+BEGIN_SRC clojure :results output raw
  (clojure.pprint/print-table table)
#+END_SRC 

produrrà

#+RESULTS: upper_air
|      :m | :degree | :meter/second |      :degC | :millibar |
|---------+---------+---------------+------------+-----------|
|  1545.0 |   175.0 |         12.36 |  15.400001 |     850.0 |
|  3162.0 |   265.0 |          6.69 |        4.8 |     700.0 |

ma quello che vorrei davvero è

#+TBLNAME: upper_air
|      :m | :degree | :meter/second |      :degC | :millibar |
|---------+---------+---------------+------------+-----------|
|  1545.0 |   175.0 |         12.36 |  15.400001 |     850.0 |
|  3162.0 |   265.0 |          6.69 |        4.8 |     700.0 |

(nota #+RESULTSvs. #+TBLNAME) in modo che successivamente possa fare qualcosa di simile

#+BEGIN_SRC ipython :session  :var data=upper_air
import numpy as np

arr = np.array(data)
p = arr[:,4]
#+END_SRC

Con il #+RESULTSrisultato, il secondo blocco di codice interpreterà l' data argomento come una stringa anziché una tabella di dati e non sarò in grado di estrarre i dati in modo semplice. Potrei convertire i dati ASCII in una struttura di dati Python 'manualmente', ma preferirei che org li gestisca per me :-) Esiste un modo per l'output di un primo blocco di codice #+TBLNAMEanziché #+RESULTS? In alternativa, il secondo blocco di codice può forzare l'argomento come tabella organizzativa anziché come stringa?


2
Normalmente, se un blocco sorgente Babel è pensato per produrre una tabella, genera un vettore bidimensionale. Se il codice Clojure lo facesse invece di generare una stringa, non dovresti cambiare nulla nel tuo codice. Forse provare a cercare un modo per produrre un vettore in Clojure?
wvxvw,

@wvxvw Grazie del commento. Immagino di essere un po 'confuso qui. Pensavo che l'intera modalità org punto fosse un testo semplice. Quello che vedi è quello che ottieni. Ma sembra che tu stia suggerendo che il blocco # + RISULTATI abbia una sorta di struttura di dati dietro che può essere una stringa o una struttura di dati nidificata.
Julien Chastang,

2
No, non è quello che sto dicendo. Credo che clojure.pprint/print-tableritorni una stringa formattata come tabella Org e, poiché imposti l'argomento header in modo che outputsia raw, ottieni ciò che ottieni. Tuttavia, quando lo si utilizza per la seconda volta, Org non legge la tabella risultante, invece, rivaluta il blocco Clojure e trasmette il suo risultato al blocco Python. Tuttavia, se il blocco Clojure ha prodotto un array 2D, è possibile modificare il risultato in modo valueche non sia rawOrg per formattare il risultato come tabella e lo si otterrebbe come un array 2D nel blocco Python.
wvxvw,

@wvxvw Grazie ancora per avermi aiutato a capire gli argomenti dell'intestazione org-babel. Dopo un po 'di sperimentazione, vedo che ciò che descrivi sembra davvero essere il caso, e dovrei essere in grado di gestirlo. Tuttavia, sembra che non riesca a non poter utilizzare tabelle organizzative di tipo "più ricco" con hline in particolare come formato intermedio poiché si tratta di stringhe e non di rappresentazioni di dati (ad es. Clojure nested vector). Ad ogni modo, sono stato molto contento di org-babel e lo considero un'alternativa superiore a Jupyter (se sei un utente emacs, ovviamente :-)) Grazie ancora per il tuo aiuto.
Julien Chastang,

Risposte:


6

È necessario che il blocco tabella restituisca un array (o un vettore o un elenco, ecc.) Come questo. Puoi ottenere linee orizzontali con Nessuno, o zero o qualunque tipo equivalente di clojure.

#+NAME: upper_air
#+BEGIN_SRC python :results value
return [[":m", ":degree",":meter/second", ":degC", ":millibar"],
        None,
        [1545.0, 175.0, 12.36, 15.40001, 850.0],
        [3162.0, 265.0, 6.69, 4.8, 700.0]]

#+END_SRC

#+RESULTS: upper_air
|     :m | :degree | :meter/second |    :degC | :millibar |
|--------+---------+---------------+----------+-----------|
| 1545.0 |   175.0 |         12.36 | 15.40001 |     850.0 |
| 3162.0 |   265.0 |          6.69 |      4.8 |     700.0 | 


#+BEGIN_SRC python :results value  :var data=upper_air
import numpy as np

arr = np.array(data)
p = arr[:,4]
return p
#+END_SRC  

#+RESULTS:
| 850 | 700 |
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.