From: "Eric Schulte" <schulte.eric@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [BUG][babel] ":result output table" doesn't work for python code blocks
Date: Tue, 26 Apr 2011 13:31:26 -0600 [thread overview]
Message-ID: <87zkncolm9.fsf@gmail.com> (raw)
In-Reply-To: <87aafksm4y.fsf@ucl.ac.uk> (Eric S. Fraga's message of "Wed, 20 Apr 2011 21:28:29 +0100")
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>
>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>
>>> [...]
>>>
>>>> That said, I agree that in examples like yours above the returned value
>>>> should be a table given that the ":results table" is explicitly stated.
>>>> I've just pushed up a patch after which the following is possible.
>>>
>>> Eric,
>>>
>>> It would appear that this change you've made is only for python)? Is
>>> there any chance of having the same for octave, please? But only if it
>>> is easy to do as =:results output raw= with carefully formatted output
>>> does the job for me for the moment!
>>>
>>
>> Hi Eric,
>>
>> I do not have a local copy of octave, so I'm less confident making
>> changes to that file, but the attached patch attempts to make the same
>> changes in ob-octave which were made in ob-python.
>>
>> Could you please test this patch for both external and session based
>> evaluation and let me know if it works (I'm more hopeful that the
>> external evaluation will work as expected than the session
>> evaluation).
>
> Eric,
>
> thanks for this.
>
> I haven't tried the session based evaluation but the external one,
> unfortunately, doesn't work as I would expect. In the following, I
> would expect both source code blocks to give me the same output with the
> first, value based, being the correct output.
>
Hi Eric,
Does the matlab/octave `disp' function display tabular data in the same
manner as it is written literally in source code?
This is part of the issue with the "output table" :results combination,
namely what constitutes a table for printed output. In source code the
answer is obvious, namely whatever the language's interpreter would read
as a literal table, however with printed output there are many possible
ways to represent tabular data, but none *is* tabular in the way that
source code can *be* tabular.
If the printed output is exactly the same as how a table would be
written in matlab/octave source code, then does my patched version work?
If not, then rather than writing another table parser, perhaps the data
could be printed as an Org-mode table, and then the "output raw"
:results combination could be used, or the output could be sent through
another code block to convert the string to a table.
Hope this helps, Best -- Eric
>
>
> #+srcname: valueresult
> #+begin_src octave :results value table :cache yes
> values = [];
> for i=1:15
> values(end+1,:) = [i, i^3];
> endfor
> ans = values
> #+end_src
>
> #+results[7a87a711b7814ecf23ec5d3741a5fec3ffff3e44]: valueresult
> | 1 | 1 |
> | 2 | 8 |
> | 3 | 27 |
> | 4 | 64 |
> | 5 | 125 |
> | 6 | 216 |
> | 7 | 343 |
> | 8 | 512 |
> | 9 | 729 |
> | 10 | 1000 |
> | 11 | 1331 |
> | 12 | 1728 |
> | 13 | 2197 |
> | 14 | 2744 |
> | 15 | 3375 |
>
>
> #+srcname: outputresult
> #+begin_src octave :results output table :cache yes
> values = [];
> for i=1:15
> values(end+1,:) = [i, i^3];
> endfor
> disp(values)
> #+end_src
>
> #+results[3104573dcf8ec30de1a26aae7051a9e8fce6a92a]: outputresult
> | 1 1 |
> | 2 8 |
> | 3 27 |
> | 4 64 |
> | 5 125 |
> | 6 216 |
> | 7 343 |
> | 8 512 |
> | 9 729 |
> | 10 1000 |
> | 11 1331 |
> | 12 1728 |
> | 13 2197 |
> | 14 2744 |
> | 15 3375 |
>
> Thanks,
> eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
next prev parent reply other threads:[~2011-04-26 19:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 0:46 [BUG][babel] ":result output table" doesn't work for python code blocks Ethan Ligon
2011-04-15 2:26 ` Eric Schulte
2011-04-15 10:35 ` Eric S Fraga
2011-04-15 16:13 ` Eric Schulte
2011-04-20 20:28 ` Eric S Fraga
2011-04-26 19:31 ` Eric Schulte [this message]
2011-04-27 10:09 ` Eric S Fraga
2011-04-27 13:16 ` Eric Schulte
2011-04-27 15:28 ` Eric S Fraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zkncolm9.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).