emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [PATCH] org-table: Add mode flag to enable Calc units simplification


From: Daniele Nicolodi
Subject: Re: [PATCH] org-table: Add mode flag to enable Calc units simplification mode
Date: Tue, 20 Oct 2020 16:32:16 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.1

On 20/10/2020 16:19, Eric S Fraga wrote:
> Hello again,
> 
> Following up on myself.  I'm seeing some strange behaviour although unit
> calculations are working nicely.  For instance, this table:
> 
> #+begin_src org
>   | stream   | a            | b            | c            | total        |   
> x_a |   x_b |   x_c |
>   |          | <l>          | <l>          | <l>          | <l>          |   
> <r> |   <r> |   <r> |
>   
> |----------+--------------+--------------+--------------+--------------+-------+-------+-------|
>   | feed     | 1.05 mol/s   | 1.05 mol/s   |              | 2.10 mol / s | 
> 0.500 | 0.500 |     0 |
>   | effluent | 0.74 mol / s | 0.74 mol / s | 0.32 mol / s | 1.80 mol / s | 
> 0.411 | 0.411 | 0.178 |
>   ,#+TBLFM: 
> $5=vsum($2..$4);uf2::$6=$2/$5;uf3::$7=$3/$5;uf3::$8=$4/$5;uf3::@4$2=(1-0.3)*@-1;uf2::@4$3=(1-0.3)*@-1;uf2::@4$4=@-1+0.3*@-1$-1;uf2
> #+end_src
> 
> does not seem to pay attention to the f3 mode in the last column, first
> data row.

It is something related to how Calc computes the result. The f2 mode
specifies the formatting for floating point values, however it seems
that Calc treats the zero (from the missing value in the fourth column)
divided by a float (from the value in the fifth column) as an integer
and not as a float. This may be because the org substitutes a "0" for
the missing value, thus an integer. Still, I am not sure dividing an
integer by a float should result in an integer (I guess zero is special
cased here).

If you change the formula for that field to:

  #+TBLFM: $8=$4*1.0/$5;uf3

to force the $4 field to be evaluated as a float (there are other ways
to get the same effect) you get the expected result (I think).

> I've also seen some (difficult to replicate) problem with column widths
> where the columns are much wider than the expected.  I'll keep playing
> to see if I can isolate the column width behaviour.

I haven't touched any code dealing with columns width (I believe).

Cheers,
Dan



reply via email to

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