On 20/10/2020 16:32, Daniele Nicolodi wrote: > 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).
There are other funny Calc behaviors: if an expression results in a number with an unit where the numerical part is exactly 1, the printed result looses the numerical part and only the units are printed. Cheers, Dan
