emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [BUG][babel] ":result output table" doesn't work for python code


From: Eric Schulte
Subject: Re: [O] [BUG][babel] ":result output table" doesn't work for python code blocks
Date: Tue, 26 Apr 2011 13:31:26 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Eric S Fraga <address@hidden> writes:

> "Eric Schulte" <address@hidden> writes:
>
>> Eric S Fraga <address@hidden> writes:
>>
>>> "Eric Schulte" <address@hidden> 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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]