Re: [PATCH] Add support for tables in Calc src block :var

[Visuwesh <visuweshm@gmail.com>]

[வெள்ளி டிசம்பர் 13, 2024] Fraga, Eric wrote:

> Response below/inline for email Visuwesh wrote:
>> (original email sent 13 Dec 2024 at 14:32)
>> 
>> Update x := 3 and y first.  Then update `a' and `z'.  `z' will be 10.6.
>> Now update x := 2, and update `z' and `a'.  `z' updates to 5.4 as shown
>> above but `a' remains 9!  
>
> Yes, this is expected behaviour.  Calc assumes a sequential evaluation,
> especially when the same variable is given a value more than once.  It's
> not like most modelling languages which look at the ensemble of
> equations simultaneously.

I assumed this was the case.  It does make sense when you take the whole
picture together.  You are likely to use the same variable name (such as
T for temperature) everywhere so it would be best to use the nearest
one.

> [...]
>
>> Which begs the question: what should be `x'?
>
> Ideally, it would follow the Calc convention and would be the value last
> given (before point, where the table is), I guess.

When we have

    x := 3

    | 1 | 3 |
    #+TBLFM:$2=$x

    x := 6

    | 1 | 6 |
    #+TBLFM:$2=$x

value of `x' for the first table should be 3, and for the second 6.
However, when we have something like

    x := 3
    a := 2 * x
    x := 2
    z := 0.5 * x

    | 1 | |
    #+TBLFM:$2=$x*$z

what should $2 evaluate to?  $z is straight-forward: $z=1.  But what
about $x?  Should it be 2 or 3?  If we go by Calc's convention, it
should be 3.  Do you agree?

> But, at least, for simple cases where variables are not overwritten,
> what you have done would be sufficient (and a really nice addition to
> the Calc package!).
>
> I intend to use it for sure.

I am glad to be of help, and hope the quick hack actually works
reliably.