emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Spreadsheet calculations (24.3/8.0-pre)


From: Bastien
Subject: Re: [O] Spreadsheet calculations (24.3/8.0-pre)
Date: Thu, 18 Apr 2013 16:13:11 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

Hi Oliver,

Oliver Večerník <address@hidden> writes:

> Hi Ippei,
>
>> | Product   |    g | kJ/100g |   kJ | kcal |
>> |-----------+------+---------+------+------|
>> | Bread     | 50.6 |    1372 |  694 |  166 |
>> | Butter    | 11.5 |    3054 |  351 |   84 |
>> | Marmalade | 19.7 |     926 |  182 |   44 |
>> |-----------+------+---------+------+------|
>> |           |      |         | 1227 |  294 |
>> #+TBLFM: $3='(org-lookup-first $1 '(remote(nf,@address@hidden))
>> (remote(nf,@address@hidden)))
>> #+TBLFM: $4='(* $2 (/ $3 $b));N%.0f
>> #+TBLFM: $5=$4/$j;%.0f
>> #+TBLFM: @>$4..$5=vsum(@I..II)
>> (Each TBLFM line has no linebreak.)
>
> thanks for your suggestion, but I didn't want an extra column.  I played
> with `N' and `L' options and found following solution leaving them
> out entirely:
>
> #+TITLE: Nutrition Facts
> #+CONSTANTS: b=100.0 j=4.184
> #+TBLNAME: nf
> | Product     |   kJ | kcal |
> |-------------+------+------|
> | Bread white | 1372 |  328 |
> | Butter      | 3054 |  730 |
> | Marmalade   |  926 |  221 |
> #+TBLFM: $3=$2/$j;%.0f
>
> | Product     |    g |   kJ | kcal |
> |-------------+------+------+------|
> | Bread white | 50.6 |  694 |  166 |
> | Butter      | 11.5 |  351 |   84 |
> | Marmalade   | 19.7 |  182 |   43 |
> | nonexistent |      |    0 |    0 |
> |-------------+------+------+------|
> |             |      | 1227 |  293 |
> #+TBLFM: $3='(* (string-to-number $2) (/ (string-to-number (org-lookup-last 
> $1 '(remote(nf,@address@hidden)) '(remote(nf,@address@hidden)))) 
> $b));%.0f::$4=$3/$j;%.0f::@>$3..$4=vsum(@I..II)
>
> $1 has to be a string, because the lookup column can have more than one
> word.  For the math I have to convert the strings to numbers.  Maybe
> someone has an idea for a more elegant solution, but this works for
> me now.

I confirm there is no other elegant solution that either using an
additional column or using the internal conversion you used.  

-- 
 Bastien



reply via email to

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