Re: [Orgmode] org-babel: Meta-LaTeX-Python-Environment

[Dan Davison]

Torsten Wagner <address@hidden> writes:

<...>

> Within a LaTeX-file (org-file) I like to use python snippets to perform 
> calculus 
> and other tasks which are otherwise extremely difficult or time consuming to 
> perform directly in LaTeX. E.g. on-the-fly-generation of graphs or calculus 
> of 
> statistical values (e.g., (very simple) the mean value of n numbers). 
>
> I guess org-mode together with org-babel can do most of this already. I 
> played 
> around with it and it is very nice, many thanks to the developers. However, I 
> found the following point which I wasn't able to figure out yet.

Hi Torsten,

>
> 1. Hiding of the source code blocks for export
> I like to export the results of the source code block to LaTeX only. However, 

Using ':exports results' specifies that only the results should appear
in the exported document. This

#+begin_src python :exports results
  6 + 6
#+end_src

is exported to latex as this:

\begin{verbatim}
 12
\end{verbatim}

Is that working for you?

> I tried different options all resulting in embedding the source-code itself 
> inside the final LaTeX file. I guess this is more due to the org-export 
> function 
> rather then org-babel
>
> 2. Inline source code blocks
> I guess this was discussed once already. Instead of a verbose source code 
> block a single short command to elaborate a python variable or a one line 
> calculus would be nice e.g., "#:session_name a#" to replace this command by 
> the results of variable a of the session session_name during the export to 
> LaTeX.

Yes, you can do that (and it is now doumented on worg). The syntax for
that is src_lang[optional header args]{code}

See below for examples.

>
> I like to combine this with a little python module specialised in creating 
> proper LaTeX export for all kind of python data types.
> E.g.  tab_export([1,2,3,4,5]) could generate the string "1 & 2 & 3 & 4 & 5 \\"
>
> The idea is to use this as a form of reproducible research allowing the data 
> evaluation together with the textual and graphical representation. 
> Furthermore, I would like to use org as a publication system with meta-
> description capabilities. This would allow to commentary what someone is 
> doing 
> "between the lines". By this one could merge somehow the lab-book, data 
> analysis and the final paper into one org-file (or org-project) and keep 
> always 
> all infos and data close together
>
> Something like (pseudo code):

>
> /---------------------------------------------------------------------------------/
>
> 12.03.2148: Scotty
> I'm going to create a better warp drive system: 
> ...
> First measurements should show the better efficiency. The old set-up is moved 
> to 
> the lab downstairs .... the old measurement files back-up is at ....
> First lets load the values and calculate the performance:
>
> #+srcname: measurement 
> #+begin_src python 
> data=load(measurement.csv)
> perf = calculate_performance(data.values)
> #+end_src
>
> This was the final measurement performed with the new set-up. It shows 
> already 
> the nice improvements... 
> Just some infos of the measurement
> Measurement date: #:measurement data.date#
> Measurement parameter: #:measurement data.param1#

You can use inline blocks as follows. Note that the source block needs
to be evaluated to ensure that the variables exist in the session (hence
the :exports results header)

--8<---------------cut here---------------start------------->8---
#+srcname: measurement 
#+begin_src python :session :exports results
  date = "12.03.2148"
  param1 = 19.7
  perf = 77
#+end_src

Measurement date: src_python[:session]{date}
Measurement parameter: src_python[:session]{param1}
--8<---------------cut here---------------end--------------->8---

>
> 13.3.2148: Scotty
> Spoke told me it could be better by performing a new warp-core calibration... 
> However, I could write the abstract already:
>
> #+srcname: paper_for_star_fleet_physics_journal
> #+begin_src LaTeX 
> \begin{abstract}
> .... the new set-up shows a $#:measurement perf#,/%$ better perfomance then 
> the old warp drive...
> \end{abstract}
> #+end_src

The inline code blocks will not be processed inside source blocks. I'm
not sure how to achieve what you want with the current machinery, but
have you read the recent posts by Thomas Dye describing how he uses
latex blocks with org-babel?  In particular you should look at the noweb
reference expansions. These are also documented on the Worg page. In
general of course, the more you can write in org rather than latex, the
more functionality you'll get out of org-babel. Is it possible write the
abstract in org and defer export to latex?

<...>
> I hope this gives an idea of what I like to do. :)
>
> Export should allow selections like "export all" (including comment texts and 
> source code blocks), "export without source code blocks" and "export results 
> only". The last one would produce the native LaTeX code ready for submission. 
> This would allow to process the file with any standard LaTeX environment.

The Worg page says

,----
| exports
|     exports arguments specify what should be included in html or latex 
exports of the org-mode file
| 
|     code
|         the body of code is included into the exported file 
|     results
|         the results of evaluating the code is included in the exported file 
|     both
|         both the code and results are included in the exported file 
|     none
|         nothing is included in the exported file 
| 
`----

could you clarify how you would like it to be different?

>
> I know there is the tangle function. However, it would require a LaTeX-source 
> block for org-babel. Creating one would result in the problem that I have to 
> replace spaceholders within the LaTeX-code blocks  with the results of python-
> blocks (as shown in the example). 
>
> It would be nice to hear if someone is doing something similar or if somebody 
> has some ideas how to accomplish this with org-mode and org-babel

Hope I've helped a bit. Have another look at our Worg page and let us
know if it can be improved, and also check out the threads involving
Eric Thomas Dye[1]. And let us know how your approach evolves.

Thanks,
Dan

Footnotes:

[1] 
http://search.gmane.org/search.php?group=gmane.emacs.orgmode&query=Thomas+Dye


>
> Best regards,
>
> Torsten
>
>
> CC. Sorry for the long mail
>
>  
>
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode