Re: NaNs not propagating

[<pl...@pi...>]

On 11/04/14 05:14, sfeam wrote:
> On Monday, 03 November 2014 06:45:48 PM pl...@pi... wrote:
>
>  > Hi,
>
>  >
>
>  > I seem have a problem with NaN not propagating to function calls.
>
>  >
>
>  >
>
>  > gnuplot>
>
>  >
>
>  > integ(x)=(int_last==0)?(NaN,int_last=x):(int_last=int_last+x)
>
>  >
>
>  > plot int_last=0, "-" u 1:(integ($2-44)) w l
>
>  > input data ('e' ends) > 1 1
>
>  > input data ('e' ends) > 2 2
>
>  > input data ('e' ends) > 3 NaN
>
>  > input data ('e' ends) > 4 4
>
>  > input data ('e' ends) > 5 5
>
>  > input data ('e' ends) > e
>
>  >
>
>  > gnuplot> print int_last+NaN
>
>  > NaN
>
>  >
>
>  >
>
>  > This gives a straight line with a break which means that the third line
>
>  > is evaluating NaN as zero and passing -44 to the function.
>
>  >
>
>  > I was expecting the argument (NaN-44) to pass NaN to the function which
>
>  > would in turn return and assign a NaN leaving all further points
>
>  > unplotted.
>
>  >
>
>  > Bug or feature ?
>
> I think it rates as a bug.
>
> When the data is read in, a using spec that evaluates to NaN is
>
> flagged as "undefined". This is sufficient for the purpose of
>
> plotting that one point, but as you have discovered it doesn't
>
> address side-effects of the evaluation. Arguably if the point
>
> itself is undefined then it is reasonable to say that any
>
> side-effects are also undefined, but it's less of a surprise
>
> if this makes the side-effect expressions evaluate to NaN also.
>
> I'll whip up a fix for 5.0 and 5.1.

Thanks.  I wonder what is the best way to fix this.
1. data point in undefined so fn is never called.
2. NaN propagates to fn call.

My gut feel is for 2 but I have not given it a lot of thought.


>
> By the way, in the definition you show for function integ()
>
> integ(x)=(int_last==0)?(NaN,int_last=x):(int_last=int_last+x)
>
> the NaN has no effect whatsover because it is on the left
>
> side of a comma. That means the function reduces to
>
> integ(x) = (int_last = int_last+x)
>
> Ethan
>

Thanks for pointing that out. I just lashed that up as an example but 
clearly it should be other way around  with the NaN after the assignment.

Peter.