Menu
▾
▴
gnuplot-beta
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-03-31 16:39:39
|
Bug #3513138 reports a problem when NaN appears in a data column
where gnuplot is expecting to find an extra property.
The example given is
plot 'foo' using 1:2:3 with points lc palette
The same problem would happen for
plot 'foo' using 1:2:3 with points pointsize variable
If NaN appears in the x, y, or z coordinate then the point
is rejected on input. But what should we do for these
cases where the point is in range on x/y/z but a separate
field is missing or NaN?
1) Ignore the point (same as a NaN coordinate).
2) Accept the point but assign the property some default value.
3) Use the coordinates for auto-scaling but do not draw it.
4) Something else
The current handling of "with image" data provides some precedent.
A NaN image pixel is either not drawn at all or is rendered
in the background color. But the issue of auto-scaling does not
arise for image plots because omitting a single pixel would not
change the range.
Should an "invisible" point (i.e. one with NaN for pointsize or
color) contribute to auto-scaling?
There are probably more obscure cases also, like "with circles"
where the radius is NaN. Can you think of any others?
Ethan
|
|
From: <pl...@pi...> - 2012-03-31 19:11:06
|
On 03/31/12 18:39, sfeam (Ethan Merritt) wrote: > Bug #3513138 reports a problem when NaN appears in a data column > where gnuplot is expecting to find an extra property. > The example given is > plot 'foo' using 1:2:3 with points lc palette > The same problem would happen for > plot 'foo' using 1:2:3 with points pointsize variable > > If NaN appears in the x, y, or z coordinate then the point > is rejected on input. But what should we do for these > cases where the point is in range on x/y/z but a separate > field is missing or NaN? > > 1) Ignore the point (same as a NaN coordinate). > > 2) Accept the point but assign the property some default value. > > 3) Use the coordinates for auto-scaling but do not draw it. > > 4) Something else > > The current handling of "with image" data provides some precedent. > A NaN image pixel is either not drawn at all or is rendered > in the background color. But the issue of auto-scaling does not > arise for image plots because omitting a single pixel would not > change the range. > > Should an "invisible" point (i.e. one with NaN for pointsize or > color) contribute to auto-scaling? > > There are probably more obscure cases also, like "with circles" > where the radius is NaN. Can you think of any others? > > > Ethan > > ---------------- Hi Ethan, I would have thought that any NaN anywhere was basically :"this is not valid data ignore it". A circle with rad="not a number" is "not a circle". A point of colour index "not a number" is not a point. Why should it be part of scaling or anything? I can see a limited number or reasons for finding a NaN. 1. divide by zero type error, data is bad don't use it. Using a default is almost certainly not the correct result otherwise no one would be trying to calculate whatever it was to start with. 2. data file has missing data intentionally marked at non existent: it should not be used in any way , that's why it was flagged as non existent. 3. programatically creating a NaN to control output: I require a result , I explicitly try to exclude it, don't do something (anything) with it . plot ...... using ($1<1945)?NaN:$1 :2 ... > If NaN appears in the x, y, or z coordinate then the point > is rejected on input. I thought when I brought this up a couple of months back the point I raised was that this was NOT happening when NaN was in first column. It was not being parsed as NaN but "NaN". I presume whatever action you decide upon, this will now get corrected. So if anyone sees a problem with such a change (like this is a feature not a bug) please shout now. Peter. |
|
From: Juhász P. <pet...@gm...> - 2012-03-31 19:30:01
|
On Sat, 2012-03-31 at 09:39 -0700, sfeam (Ethan Merritt) wrote: > Bug #3513138 reports a problem when NaN appears in a data column > where gnuplot is expecting to find an extra property. > The example given is > plot 'foo' using 1:2:3 with points lc palette > The same problem would happen for > plot 'foo' using 1:2:3 with points pointsize variable > > If NaN appears in the x, y, or z coordinate then the point > is rejected on input. But what should we do for these > cases where the point is in range on x/y/z but a separate > field is missing or NaN? > > 1) Ignore the point (same as a NaN coordinate). > > 2) Accept the point but assign the property some default value. > > 3) Use the coordinates for auto-scaling but do not draw it. > > 4) Something else > > The current handling of "with image" data provides some precedent. > A NaN image pixel is either not drawn at all or is rendered > in the background color. But the issue of auto-scaling does not > arise for image plots because omitting a single pixel would not > change the range. > > Should an "invisible" point (i.e. one with NaN for pointsize or > color) contribute to auto-scaling? > > There are probably more obscure cases also, like "with circles" > where the radius is NaN. Can you think of any others? > > > Ethan > I'd say the cleanest and most consistent solution would be ignoring the point completely. At least for circles, radius is an essential property, a circle with a NaN radius is not a circle at all (NaC). Same for ellipses. A counterargument could be made for point colors, sizes (and perhaps some other attributes), because those are optional properties. Still, if the using specification says "1:2:3 with points lc palette" and column(3) is NaN for a certain point, then the specification is incomplete for that point, and thus it is best if it doesn't influence the plot in any way. Péter Juhász |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-03-31 19:31:24
|
On Saturday, 31 March 2012, pl...@pi... wrote: > > If NaN appears in the x, y, or z coordinate then the point > > is rejected on input. > > I thought when I brought this up a couple of months back the point I > raised was that this was NOT happening when NaN was in first column. It > was not being parsed as NaN but "NaN". Please refresh my memory. I thought the issue there was that some runtime C libraries accept the string NaN as a valid numerical input (gcc for one) but others do not (MSVC for example). That is unfortunate, but so far as I can see is outside the range of things we can fix in gnuplot. > I presume whatever action you decide upon, this will now get corrected. > So if anyone sees a problem with such a change (like this is a feature > not a bug) please shout now. I think it's a bug, but the bug is outside of gnuplot. But maybe I am mis-remembering the details of the problem you encountered. Ethan |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-04-01 04:22:55
|
On Saturday, 31 March 2012, sfeam (Ethan Merritt) wrote: > On Saturday, 31 March 2012, pl...@pi... wrote: > > > If NaN appears in the x, y, or z coordinate then the point > > > is rejected on input. > > > > I thought when I brought this up a couple of months back the point I > > raised was that this was NOT happening when NaN was in first column. It > > was not being parsed as NaN but "NaN". > > Please refresh my memory. > I thought the issue there was that some runtime C libraries accept > the string NaN as a valid numerical input (gcc for one) but others do > not (MSVC for example). Ah, I found the earlier mail. It all comes back to me now. That was the start of my list of "Things to break in Gnuplot version 5". The list so far: 1) Do not reassign column meanings in the middle of reading data from a file. If whatever worked for the first records fails later, that's an error. 2) Change the behavior of "set range [...] reverse to affect only autoscaling. This change is already in CVS since it fixes a bug and matches the suggested use given in the docs, although it doesn't match what the program was actually doing up until now. 3) Rationalize the matrix options for ascii and binary modes. Right now the defaults and keywords conflict in the two modes. 4) Distinguish between "splot with lines" and "splot with surface". I'm not sure what's the best way to do this, but at a minimum it should fix the bug that "unset surface" prevents plotting lines and points also. E.g. splot 'silver.dat' using 1:2:1 with points pt 5 ps 6 lc pal z unset surface replot # Where's my plot??? 5) The X11 terminal should work in true pixel coordinates rather than running from [0:4096] regardless of the window aspect ratio. 6) Change the interpretation of the alpha channel component in RGBA colors so that any existing 24-bit RGB triple works also if interpreted as a 32-bit Alpha+RGB with leading component A=0. That would allow use of RGBA colors everywhere, but breaks all the existing RGB image code and "set style fill solid <alpha>". I don't like this much, but I haven't come up with a better way. I'm still hoping that inspiration strikes. The idea is that these all fix long-standing problems or limitations, but will change the behavior of existing scripts. Since the project policy is that we try to guarantee backwards compatibility within a major version series, this script breakage would only be acceptable in connection with release of the next major version - 5.0 == But none of the above has much to do with Bug #3513138. We don't the program crashing on binary input, so we've got to fix that one already for 4.6. Ethan |
