gnuplot-beta

NaNs not propagating

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

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 ?

Regards, Peter.

Re: NaNs not propagating

[sfeam <sf...@us...>]

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.



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

Re: NaNs not propagating

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

On 11/04/14 05:14, sfeam wrote:
> 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
>

Since this is a public archived list, I thought I ought to provide a 
more functionally correct version, just in case anyone uses it as an 
example.

integ(x)=(!istarted)?(istarted=1,int_last=x):(int_last=int_last+x)
  plot istarted=0,  datafile  using 1:(integ($2-44)) with lines


Now what I really need to do is skip the fn call if there is invalid 
data, so I try to trap the NaN in column 2:

  plot istarted=0,  datafile  using 1:(($2==NaN)?NaN:(integ($2-44))) 
with lines

This produces the same unexpected results as before and the test is 
never true. Another consequence of NaNs not propagating.

What is the correct way to trap this condition?

(isNaN($2))   undefined function: isNaN
($2==NaN)   never true
($2==0)   not true for NaN in col 2
(exists($2) always true, even for NaN

Is there currently a test condition that will trap NaN in the datafile ?

Peter.

List slow

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

Hi,

usually I find I get my own posts back within a few minutes. In the last 
few days it's been taking many hours.

Others see this, or is it local?

Peter.

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.

Re: NaNs not propagating

[Allin C. <cot...@wf...>]

On Tue, 4 Nov 2014, pl...@pi... wrote:

[...]
>
> What is the correct way to trap this condition?
>
> (isNaN($2))   undefined function: isNaN
> ($2==NaN)   never true
> ($2==0)   not true for NaN in col 2
> (exists($2) always true, even for NaN
>
> Is there currently a test condition that will trap NaN in the datafile ?

If it works like C, the test $2!=$2 should do it. A NaN tests as not 
equal to itself!

Allin Cottrell

Re: NaNs not propagating

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

On 11/04/14 17:26, Allin Cottrell wrote:
> On Tue, 4 Nov 2014, pl...@pi... wrote:
>
> [...]
>>
>> What is the correct way to trap this condition?
>>
>> (isNaN($2))   undefined function: isNaN
>> ($2==NaN)   never true
>> ($2==0)   not true for NaN in col 2
>> (exists($2) always true, even for NaN
>>
>> Is there currently a test condition that will trap NaN in the datafile ?
>
> If it works like C, the test $2!=$2 should do it. A NaN tests as not
> equal to itself!
>
> Allin Cottrell
>

Thanks.

In principal you are correct

gnuplot >  print NaN==NaN
0


But it does not work inside plot, it's another  "not true for NaN in col 
2" case. So it seems that there is currently no way to trap this 
condition. Clearly not good.

I'll have to wait until Ethan comes up with something and update my CVS.

Peter.