emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Daniele Pizzolli <dan@toel.it>
To: "Charles C. Berry" <ccberry@ucsd.edu>,
	Aaron Ecay <aaronecay@gmail.com>,
	Andreas Leha <andreas.leha@med.uni-goettingen.de>,
	emacs-orgmode@gnu.org, Ista Zahn <istazahn@gmail.com>,
	mcg <giepen.m@googlemail.com>
Subject: Re: [PATCH] inline src block results can be removed
Date: Mon, 24 Nov 2014 10:48:40 +0100	[thread overview]
Message-ID: <b52cbe2d2cc2963024c59a80c8c721e0@toel.it> (raw)
In-Reply-To: <87zjbqrapy.fsf@nicolasgoaziou.fr>

On 2014-11-17 00:23, Nicolas Goaziou wrote:
> "Charles C. Berry" writes:
> 
>> For now, I'd be willing to make patches that will allow removal of the
>> inline src block results that do *not* involve these header args:

[]

> IMO, we're too much focused on the implementation details. We ought to
> agree on what should be done first. For example, considering
> `org-babel-insert-result' and its RESULT-PARAMS argument, I think the
> following makes sense:
> 
>   | Param   | Example output                    |
>   |---------+-----------------------------------|
>   | default | {{{results(42)}}}                 |
>   | file    | {{{results(file:something.pdf)}}} |
>   | list    |                                   |
>   | raw     | 42                                |
>   | drawer  |                                   |
>   | org     | {{{results(src_org{...})}}}       |
>   | html    | {{{results(@@html:...@@)}}}       |
>   | latex   | {{{results(@@latex:...@@)}}}      |
>   | code    | {{{results(src_xxx{...})}}}       |
> 
> Basically, it should be possible to remove any kind of result using
> "results" macro, with the exception of "raw".  "list" and "drawer" can
> be ignored since there is no inline equivalent.

[]

> There's no rush, however. Non-removable results from inline source
> blocks have been there for a long time.

Hello all,

I jump into this conversation because in the next months I will try to
write a supplementary information annex using org-mode with Gnu R, so
my idea on what should be done follows...

I guess I will start my project using those patches.  Thanks!

A brief review on how how results are presented (or usually
anticipated) inline led me to the following wish list:

* provide some facilities to keep track of the 'unit of measurement'

Few numbers are pure numbers.  There is a little value added to the
correctness of the work as a whole if I get the correct number from
babel but I have hard coded the wrong unit of measure in the text.

Please follow the examples.

# Load used languages
#+BEGIN_SRC emacs-lisp
(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . nil)
(octave . t)
(R . t)))
#+END_SRC

Ideally, I think that reasonable solution would take table like the
following:

#+TBLNAME:speed-1
| speed | speed_unit |
|-------+------------|
|    12 | km/s       |

and output by default or through an easy to call syntax:

#+BEGIN_EXAMPLE
12 km/s
#+END_EXAMPLE

I am not aware of any facilities provided by languages like R or
octave to keep track of the unit of measure, If you have some please
share.

A more space wise representation, that add another layer of
indirection would be to have a look-up table like the following:

#+TBLNAME:speed-1-units-lookup
| name   | unit |
|--------+------|
| speed  | km/s |
| length | km   |
| time   | s    |

But I am not sure that it's worth it, at least for those that are
working with small data sets.

* support for inline rendering of tables

The most complex inline output I think I will need at some point
follows:

#+TBLNAME:data-set-1
#+NAME:data-set-1
| position | item1 | author1 | item2 | author2 | correlation |
|----------+-------+---------+-------+---------+-------------|
|        1 | i1    | a1      | j1    | b1      | c1          |
|        2 | i2    | a2      | j2    | b2      | c2          |
|        3 | i3    | a3      | j3    | b3      | c3          |

#+NAME: block-1
#+BEGIN_SRC R :session :colnames yes :exports none :var 
data_set_1=data-set-1
# Just to show that we use R
data_set_2 <- data_set_1
#+END_SRC

#+RESULTS: block-1
| position | item1 | author1 | item2 | author2 | correlation |
|----------+-------+---------+-------+---------+-------------|
|        1 | i1    | a1      | j1    | b1      | c1          |
|        2 | i2    | a2      | j2    | b2      | c2          |
|        3 | i3    | a3      | j3    | b3      | c3          |


And I really like to be easily rendered as an inline string through
some formatting specs e.g.:

#+BEGIN_EXAMPLE
#+PROPERTY: header-args: R :fmt '(%(position)i) “%(item1)s” by 
/%(author1)s/ correlate to “%(item2)s” by /%(author2)s/  with a 
correlation coefficient of %(correlation).2f'
#+PROPERTY: header-args: R :rowsep (', ', ' and ')

The preliminary results show that: src_R[:session :results 
replace]{data_set_2}.
#+END_EXAMPLE

Will be rendered as:

#+BEGIN_org
The preliminary results show that:
(1) “i1” by /a1/ correlate to “j1” by /b1/ with a correlation 
coefficient of c1,
(2) “i2” by /a2/ correlate to “j2” by /b2/ with a correlation 
coefficient of c2 and
(3) “i3” by /a3/ correlate to “j3” by /b3/ with a correlation 
coefficient of c3.
#+END_org

For languages that does not support tables with headers we can stick
with the positional formatting:

#+NAME: block-2
#+BEGIN_SRC octave :session :colnames yes :exports none :var 
data_set_1=data-set-1
ans = data_set_1;
#+END_SRC

# TODO: figure out why this does not work
#+RESULTS: block-2
: iii123aaa123jjj123bbb123ccc123

#+BEGIN_EXAMPLE
#+PROPERTY: header-args: octave :fmt '(%i) “%s” by /%s/ correlate to 
“%s” by /%s/  with a correlation coefficient of %.2f'
#+PROPERTY: header-args: octave :rowsep (', ', ' and ')
The preliminary results show that: src_octave[:session :results 
replace)]{ans}.
#+END_EXAMPLE

#+BEGIN_org
The preliminary results show that:
(1) “i1” by /a1/ correlate to “j1” by /b1/ with a correlation 
coefficient of c1,
(2) “i2” by /a2/ correlate to “j2” by /b2/ with a correlation 
coefficient of c2 and
(3) “i3” by /a3/ correlate to “j3” by /b3/ with a correlation 
coefficient of c3.
#+END_org

* support for humanization

A minor point would be supporting some humanization of the numbers
using extended format placeholder to support:

- number-as-word or number-as-cardinal :: 1 -> one
- number-as-ordinal :: 2 -> second
- number-as-pretty-fraction :: 2.3333 -> 2 + 1/3
- number-as-word-fraction :: 2.3333 -> two and one third
- number-as-natural-size :: 1000000 -> 1.0 MB
- number-as-natural-size-binary :: 1000000 -> 976.6 KiB

* auto formatting standard test result

It would be nice to simplify the insertion of the result of standard
test like Chi-square by taking the =R= result and rewrite in a
sentence form:

#+BEGIN_org
\Chi-squared = 0.214, d.f. = 1, p-value < 0.05
#+END_org

But this is really lower priority because it will need a lot work to
keep track of language and test specific parameters.

* Conclusion

I really like to hear your feedback on those points.  Maybe am I
taking the avoidance of cute and paste point of the reproducible
research too far?

Best,
Daniele

  reply	other threads:[~2014-11-24  9:49 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12  0:49 [PATCH] inline src block results can be removed Charles C. Berry
2014-11-12  1:10 ` Andreas Leha
2014-11-12  6:58   ` Charles C. Berry
2014-11-12 19:34 ` Aaron Ecay
2014-11-12 23:47   ` Charles C. Berry
2014-11-13 17:48     ` Nicolas Goaziou
2014-11-13 19:06       ` Andreas Leha
2014-11-14 17:43       ` Charles C. Berry
2014-11-14 20:39         ` Nicolas Goaziou
2014-11-14 23:04           ` Aaron Ecay
2014-11-16  0:10             ` Nicolas Goaziou
2014-11-15 20:22           ` Charles C. Berry
2014-11-16 23:23             ` Nicolas Goaziou
2014-11-24  9:48               ` Daniele Pizzolli [this message]
2014-11-24 10:18                 ` Andreas Leha
2015-01-13  0:48               ` New patches WAS " Charles C. Berry
2015-01-16 22:41                 ` Nicolas Goaziou
2015-01-19  3:22                   ` Charles C. Berry
2015-01-19 17:53                     ` Nicolas Goaziou
2015-01-19 19:31                       ` Charles C. Berry
2015-01-20 23:30                         ` Nicolas Goaziou
2015-01-22  3:07                           ` Charles C. Berry
2015-01-22 23:08                             ` Nicolas Goaziou
2015-01-24 22:47                               ` Charles C. Berry
2015-01-25  1:14                                 ` Aaron Ecay
2015-01-25  5:01                                   ` Charles C. Berry
2015-01-29 20:31                               ` Charles C. Berry
2015-01-17  3:22                 ` Aaron Ecay
2015-01-17 22:20                   ` Nicolas Goaziou
2015-01-18 19:13                     ` Aaron Ecay
2015-01-18 22:34                       ` Nicolas Goaziou
2015-01-18 22:55                         ` Aaron Ecay
  -- strict thread matches above, loose matches on Subject: below --
2014-11-24 11:12 Daniele Pizzolli
2014-11-25  8:04 ` Daniele Pizzolli
2014-11-25  9:52   ` Andreas Leha

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=b52cbe2d2cc2963024c59a80c8c721e0@toel.it \
    --to=dan@toel.it \
    --cc=aaronecay@gmail.com \
    --cc=andreas.leha@med.uni-goettingen.de \
    --cc=ccberry@ucsd.edu \
    --cc=emacs-orgmode@gnu.org \
    --cc=giepen.m@googlemail.com \
    --cc=istazahn@gmail.com \
    /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).