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
