gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Bug #1503114

[<br...@ph...>]

Daniel J Sebald wrote:

> That is what I'm suggesting.  Below is an example of something for the 
> longest time I couldn't understand, i.e., why the yrang here is as it 
> is.  The y range could be forced to make it look better.

Well, guess what: I just tried that example myself (OpenWatcom build for 
MS Windows, terminal windows), and got nothing like what you got in
that PNG.  The yrange I got was [1:2], exactly as expected.

> What is happening there?

Whatever it is --- it's not happening here where I sit and type this ;-)

You'll have to debug that yourself, I think.

Re: Please confirm whether or not image.dem works on Windows

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
>=20
>>"Mojca Miklavec" <moj...@gm...>
>>has reported that the "with image" demo produces very strange
>>output on his Windows system.
>>
>>On Wednesday 21 June 2006 08:29 am, Daniel J Sebald wrote:
>>
>>>I'm fairly certain that this bug has to do with the fact that in Windo=
ws,=20
>>>with the CR/LF, the following may be dogdy in some way:=20
>>>
>>>    if (!i_line) {i_line =3D ASCII_PER_LINE; *encoded_image_ptr++ =3D =
'\n';}
>=20
>=20
> Only if the file was opened in the wrong mode.  I'm reasonably sure=20
> gnuplot doesn't get this so spectactularly wrong.
>=20
> The most likely explanation is that the binary data files got mangled o=
n=20
> the way from CVS to Mojca's Windows box, because some tool though it ha=
d=20
> to convert Unix to Microsoft style linebreaks (cygwin CVS to a text-mod=
e=20
> mounted file system, or similar).

Ahead of you, but good assessment!  (I won't say "guess".)  About 10 minu=
tes ago I emailed:

> Does the attached PNG look familiar?
>=20
> The size of the file is incorrect:
>=20
> -rw-r--r--  1 sebald users 49225 Sep  1  2004 blutux.rgb
>=20
> The image is supposed to be 128 x 128 x 3 =3D 49152.=20

Re: Please confirm whether or not image.dem works on Windows

[<br...@ph...>]

Ethan A Merritt wrote:
> "Mojca Miklavec" <moj...@gm...>
> has reported that the "with image" demo produces very strange
> output on his Windows system.
> 
> On Wednesday 21 June 2006 08:29 am, Daniel J Sebald wrote:
>> I'm fairly certain that this bug has to do with the fact that in Windows, 
>> with the CR/LF, the following may be dogdy in some way: 
>>
>>     if (!i_line) {i_line = ASCII_PER_LINE; *encoded_image_ptr++ = '\n';}

Only if the file was opened in the wrong mode.  I'm reasonably sure 
gnuplot doesn't get this so spectactularly wrong.

The most likely explanation is that the binary data files got mangled on 
the way from CVS to Mojca's Windows box, because some tool though it had 
to convert Unix to Microsoft style linebreaks (cygwin CVS to a text-mode 
mounted file system, or similar).

Re: Bug #1503114

[<br...@ph...>]

Ethan Merritt wrote:
> Why should it be a path relative to the executable?
> Can't it go in  C:\Applications\gnuplot\
> or something to that effect?  

No.  It has to be in some place chosen by the user, at installation time.

> I was under the impression that all Windows systems had a
> conventional set of directory trees under C:

Yes.  But that's all they are: "conventional".  There's exactly nothing 
special about them.

> Failing that, isn't the point of the registry file that you can
> register where individual programs keep their data files? 

Yes, but automatically writing into that is what Windows programs need 
those pesky "installers" for.  gnuplot never had any so far.

> Is there not a "register <prog-name> <directory-tree>" command of
> some sort that enters this information in the registry?

No.  The minimum you need is a .reg file, and the contents of that file 
have to be edited before it can be merged into the main registry.

Re: Bug #1503114

[<br...@ph...>]

Ethan A Merritt wrote:
> On Tuesday 20 June 2006 07:21 pm, Timoth=E9e Lecomte wrote:

>> With the current code, 99% of chance of getting the error "Can't f=
ind=20
>> PostScript prologue file" out-of-the-box when using the postscript=
=20
>> terminal on Windows=20

I wouldn't put the number as high as 99%, but yes, it's high.

> Is that because there is not an appropriate README file?

Not really.  We do have one, and the information and techniques=20
described in it should suffice, if people actually used it (and gnupl=
ot=20
was extended to use it in the relevant places).

The key problem is a design decision made for wgnuplot ages ago, whic=
h=20
is rather unusual for the Windows world: that we don't have a setup=
=20
program.  There has never been much of a need for such a thing before=
,=20
because gnuplot consisted of only two files (.exe and .hlp), and the =
OS=20
provides the necessary link between those for us.

But as soon as there are many files, it has to be ensured that the=
=20
executable can find all the others.  So far, gnuplot made do with=
=20
environment variables, and it didn't strictly need any of them.

> How about if we change the message to:
>=20
> "Please copy your PostScript prolog files to <somewhere Windowish>"

The problem is not that the files aren't in that <somewhere Windowish=
>=20
place --- the problem is such a place to store files in doesn't exist=
.
The only central, truly "Windowsish" place to store anything is the=
=20
Registry, and it can't hold files.  It only contains strings, like th=
e=20
Unix environment does, but it hides them in a file-system like hierar=
chy=20
(the master copy of the environment itself is stored in the registry,=
=20
too, these days)

Windows program installations differ fundamentally from Unix in sever=
al=20
ways.  There is no "Windowish" place to install extra files private t=
o a=20
program.  Packages have to pick all such places themselves, and they=
=20
have to store the information needed to find those places in the=20
registry.  The usual layout is to put all files (including the=20
executable) below a single directory that is in a place choosable by =
the=20
user at install time (defaulting to "c:\program files\[program name]"=
).

Re: Bug #1503114

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Hans-Bernhard Br=F6ker wrote:
>>
>>> Daniel J Sebald wrote:
>=20
>=20
>> My point here is that I think there is an inherent amount of visual=20
>> plotting information that a person can view.  I'm confortable with the=
=20
>> idea of limits on resolution.
>=20
>=20
> The idea of such limits is obviously correct.  The problems start when=20
> you try to fix those limits to an actual value, and use it.  The choice=
=20
> is so hard because there is no single such limit --- its choice is=20
> arbitrary.

I suppose.  There is a typical visual resolution, but nothing to cover al=
l resolutions.


>> The idea would be to reasonably catch the situation where the tic=20
>> interval is computed as 1/3 =3D 0.33333333333 and then the round outwa=
rd=20
>> test does something (after arithmetic) like deciding  0.999999999999 <=
=20
>> 1.0 because of rounding.
>=20
>=20
> That is a non-issue, because autoscaling never picks a tick interval of=
=20
> 1/3.  It picks power-of-ten multiples of 1, 2 or 5.
>=20
>> OK.  Did you want to change the demos and set the ranges in a few case=
s? =20
>=20
>=20
> I'm not even convinced that any change is necessary for this at all.
> A few tweaks to the demos would be about the maximum I would see as=20
> useful here.

That is what I'm suggesting.  Below is an example of something for the lo=
ngest time I couldn't understand, i.e., why the yrang here is as it is.  =
The y range could be forced to make it look better.

However, if what you say above is true, something seems odd.  This should=
 be a clear case where autoranging on y comes out as [1:2].  The tic inte=
rvals are 0.2.  (I would think, anyway, given that (2-1)/5 =3D 0.2.  No a=
rithmetic problems there.)  And the data in the file is exactly on (0,1) =
(1,1) and (2,1).

What is happening there?



PM3D.DEM CODE

reset

set title "Demo for clipping of 2 rectangles comes now. The xrange is [0:=
2]..."
set pm3d; set palette
set pm3d map

set xrange [0:2]
splot 'clip14in.dat'

CLIP14IN.DAT

# demo for set pm3d [clip1in | clip4in]

0 1 1
1 1 2
2 1 3

0 2 1
1 2 2
2 2 3

Re: Bug #1503114

[<br...@ph...>]

Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
>> Daniel J Sebald wrote:

> My point here is that I think there is an inherent amount of visual=
=20
> plotting information that a person can view.  I'm confortable with =
the=20
> idea of limits on resolution.

The idea of such limits is obviously correct.  The problems start whe=
n=20
you try to fix those limits to an actual value, and use it.  The choi=
ce=20
is so hard because there is no single such limit --- its choice is=
=20
arbitrary.

> The idea would be to reasonably catch the situation where the tic=
=20
> interval is computed as 1/3 =3D 0.33333333333 and then the round ou=
tward=20
> test does something (after arithmetic) like deciding  0.99999999999=
9 <=20
> 1.0 because of rounding.

That is a non-issue, because autoscaling never picks a tick interval =
of=20
1/3.  It picks power-of-ten multiples of 1, 2 or 5.

> OK.  Did you want to change the demos and set the ranges in a few=
=20
> cases? =20

I'm not even convinced that any change is necessary for this at all.
A few tweaks to the demos would be about the maximum I would see as=
=20
useful here.

Re: Should NaN be reported as "UNDEFINED" ?

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> I think that is good for 4.2.  But I would like to see eventually flexibility with defining both "missing" and "undefined", with possibly the ability to have more than one definition.  For example,
> 
> set missing "Inf" "+Inf" "-Inf" "inf" "+inf" "-inf"
> set undefined "N/A" "outdated"

I have updated the patch in [ 1508316 ] for this (just for "datafile missing").  I think users will be happy to have multiple strings.

There are some string linked-list helper routines I added in gadgets.c and gadgets.h.  This may not be the best location for those.  In fact, if someone already knows of some simple character string linked-lists definitions inside gnuplot, they should be reused instead.

Here is some example behavior (I put an Inf and -Inf in the data file):

gnuplot> set pm3d map
gnuplot> set dgrid3d 100,100,1
gnuplot> splot 'example.dat' u 1:2:3
         Axis range undefined due to improper data values. NaN? Inf?

gnuplot> set datafile missing "NaN"
gnuplot> splot 'example.dat' u 1:2:3
         Axis range undefined due to improper data values. NaN? Inf?

gnuplot> set datafile missing "NaN" "Inf" "-Inf"
gnuplot> show datafile missing

        The following in datafile are interpreted as missing values

          NaN
          Inf
          -Inf

gnuplot> splot 'example.dat' u 1:2:3

Dan

Re: Bug #1503114

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 21 June 2006 02:01 am, Timoth=E9e Lecomte wrote:
> Ethan A Merritt wrote:
> > How about if we change the message to:
> >
> > "Please copy your PostScript prolog files to <somewhere Windowish>"
>
> The problem is this "somewhere". What would it be ? On Windows, it
> should be a path relatively to the executable, and the code to
> retrieve the absolute path from the path of the executable has yet to
> be written.

(Please forgive my total inexperience with Windows. I'm working off
what I know from running MSOffice under Wine)

Why should it be a path relative to the executable?
Can't it go in  C:\Applications\gnuplot\
or something to that effect? =20

I was under the impression that all Windows systems had a
conventional set of directory trees under C:
=46ailing that, isn't the point of the registry file that you can
register where individual programs keep their data files?=20
Is there not a "register <prog-name> <directory-tree>" command of
some sort that enters this information in the registry?
=46or instance, in the dummied-up Windows registry file that Wine
uses, I see these entries for Acrobat:

  [Software\\Adobe\\CommonFiles] 1080673271
  "AdobeHome"=3D"C:;"

I have no idea what the magic number means, but it seems clear that
the "AdobeHome" entry tells the Adobe programs where to base their
data files.  Can't we add an entry something like:=20

 [Software\\Gnuplot\\CommonFiles] <magic-number-foo>
 "PS_DIRECTORY"=3D"C:Gnuplot\;"

I would imagine that this is basically what an installer does,
but we might not need the whole installer. =20

> I think it is probably the first place in gnuplot where external
> files are needed _on all platforms_.
> This issue has never happened on Windows (some needed files are just
> placed in the directory of the .
> On OS/2, pm.trm looks for gnupmdrv.exe
> Where the X11 terminal is available, x11.trm looks for gnuplot_x11.
> Nowhere we have a code that has been written for all platforms.

I hate to use it as an example, since I've been complaining about it
for other reasons (need to install at least part of TeX), but....

It seems from the code that the "kpsextend" path searching is used
by all platforms to find the location of fonts. =20
Could it also be used for this purpose?
That is, put the prolog files in the same directory as the PostScript
fonts (since we're going to need them anyhow) and use "kpsextend" to
find them? That puts us right back in the midst of the argument about
whether it is reasonable to require TeX in order to install gnuplot,
but it does seem to be a platform-independent solution.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Please confirm whether or not image.dem works on Windows

[<tim...@en...>]

Ethan A Merritt wrote:
> "Mojca Miklavec" <moj...@gm...>
> has reported that the "with image" demo produces very strange
> output on his Windows system.
>
> On Wednesday 21 June 2006 08:29 am, Daniel J Sebald wrote:
>  =20
>> I'm fairly certain that this bug has to do with the fact that in Windo=
ws,=20
>> with the CR/LF, the following may be dogdy in some way:=20
>>
>>     if (!i_line) {i_line =3D ASCII_PER_LINE; *encoded_image_ptr++ =3D =
'\n';}
>>    =20
>
> Except that we haven't heard of this problem from anyone else.
> It's part of the standard "all.dem" check in the build process.
> Surely *someone* would have noticed if the demos fail under Windows.
>
> Petr? Bastian?  Anyone running Windows?
>  =20
I don't remember if I tried for the 'win' terminal, but I am sure the=20
wxWidgets one works with image.dem under Windows.

By the way, the quoted line above belongs to post.trm, so in case it is=20
relevant, it would appear for the postscript terminal, which doesn't=20
work for other reasons ;-)

Timoth=E9e

Please confirm whether or not image.dem works on Windows

[Ethan A M. <merritt@u.washington.edu>]

"Mojca Miklavec" <moj...@gm...>
has reported that the "with image" demo produces very strange
output on his Windows system.

On Wednesday 21 June 2006 08:29 am, Daniel J Sebald wrote:
> I'm fairly certain that this bug has to do with the fact that in Windows, 
> with the CR/LF, the following may be dogdy in some way: 
> 
>     if (!i_line) {i_line = ASCII_PER_LINE; *encoded_image_ptr++ = '\n';}

Except that we haven't heard of this problem from anyone else.
It's part of the standard "all.dem" check in the build process.
Surely *someone* would have noticed if the demos fail under Windows.

Petr? Bastian?  Anyone running Windows?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Bug #1503114

[<tim...@en...>]

Ethan A Merritt wrote:
> On Tuesday 20 June 2006 07:21 pm, Timoth=E9e Lecomte wrote:
>  =20
>>>  =20
>>>      =20
>> With the current code, 99% of chance of getting the error "Can't find=20
>> PostScript prologue file" out-of-the-box when using the postscript=20
>> terminal on Windows=20
>>    =20
>
> Is that because there is not an appropriate README file?
> How about if we change the message to:
>
> "Please copy your PostScript prolog files to <somewhere Windowish>"
>  =20
The problem is this "somewhere". What would it be ? On Windows, it=20
should be a path relatively to the executable, and the code to retrieve=20
the absolute path from the path of the executable has yet to be written.
> After all, it doesn't work "out of the box" on unix either.=20
> You still have to set up your font paths and add  environmental
> variables to your locally customized initialization files.
>  =20
Well, you do './configure - make - make install' and it works, "out of=20
the box", in my opinion. Then, you can customize, but that's optional.
>> and other non-Unix platforms.=20
>>    =20
>
> Do you mean because of the trailing '/' on the directory name?
> Other than that I don't see much difference.  But yes, I should
> add conditional code for VMS that adds ':' rather than '/'.
> Does windows or os2 need it changed to '\'?
>  =20
I have not even thought about that. I just wanted to distinguish=20
platforms where absolute paths can be determined at compile time, and=20
platforms where it is not possible, such as Windows. I just assume there=20
are others of this type.
>> Two alternatives :
>> 1- Move them back to the source file (the GNUPLOT_PS_DIR environment=20
>> variable can be conserved for flexibility)
>>    =20
>
> Huh?  What does the environmental variable do, if the prolog
> is in the driver?
>  =20
Maybe to use custom prologs that you have modified from the originals=20
and installed by hand (so that you know where they are). What was your=20
first intention ? Reduce executable size ? Make post.trm easier to read ?
>>     * others : include them in the source file at compile time
>>    =20
> I think you are over-generalizing. Why assume that it is an=20
> issue for all non-unix systems?  I'll report back on VMS, but
> I don't see why there should be a problem.  And I doubt we=20
> support anything less unix-like than VMS
Maybe I am.
I think it is probably the first place in gnuplot where external files=20
are needed _on all platforms_.
This issue has never happened on Windows (some needed files are just=20
placed in the directory of the .
On OS/2, pm.trm looks for gnupmdrv.exe
Where the X11 terminal is available, x11.trm looks for gnuplot_x11.
Nowhere we have a code that has been written for all platforms.

Timoth=E9e

Re: Bug #1503114

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 20 June 2006 07:21 pm, Timoth=E9e Lecomte wrote:
> >  =20
> With the current code, 99% of chance of getting the error "Can't find=20
> PostScript prologue file" out-of-the-box when using the postscript=20
> terminal on Windows=20

Is that because there is not an appropriate README file?
How about if we change the message to:

"Please copy your PostScript prolog files to <somewhere Windowish>"

After all, it doesn't work "out of the box" on unix either.=20
You still have to set up your font paths and add  environmental
variables to your locally customized initialization files.

> and other non-Unix platforms.=20

Do you mean because of the trailing '/' on the directory name?
Other than that I don't see much difference.  But yes, I should
add conditional code for VMS that adds ':' rather than '/'.
Does windows or os2 need it changed to '\'?

> Two alternatives :
> 1- Move them back to the source file (the GNUPLOT_PS_DIR environment=20
> variable can be conserved for flexibility)

Huh?  What does the environmental variable do, if the prolog
is in the driver?

>     * others : include them in the source file at compile time

I think you are over-generalizing. Why assume that it is an=20
issue for all non-unix systems?  I'll report back on VMS, but
I don't see why there should be a problem.  And I doubt we=20
support anything less unix-like than VMS.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Bug #1503114

[<tim...@en...>]

Daniel J Sebald wrote:
> Ethan Merritt wrote:
>  =20
>
>>   - Does Windows truly require the PostScript prolog files to
>>     be moved back into the driver source?
>>    =20
>
> Well, maybe not.  But if there is any chance of too much confusion with=
 the patch because of something we haven't tested much yet, perhaps move =
the code back into post.trm and immediately move it back out after 4.2.
>
> What is the amount of confidence at this point regarding the possibilit=
y of a lot of bug reports "postscript not viewable"?
>  =20
With the current code, 99% of chance of getting the error "Can't find=20
PostScript prologue file" out-of-the-box when using the postscript=20
terminal on Windows and other non-Unix platforms.

Two alternatives :
1- Move them back to the source file (the GNUPLOT_PS_DIR environment=20
variable can be conserved for flexibility)
2- Use a platform-specific strategy :
    * UNIX : let the code as it is now
    * Windows : look for those files in share/Postscript/  relatively to=20
the executable path using getModuleFilename()
    * others : include them in the source file at compile time

Timoth=E9e

Re: Bug #1503114

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> May I propose that we just drop this patch [*], and put the
> effort into discussion of more serious issues?
> 
> At a minimum, we need to resolve:
> 
>   - Reconciling the docs and the code with regard to the various
>     flavors of missing/undefined data points

It sounds as though we're willing to redefine behavior slightly on this, right?

There is a more straightforward way of doing this and fairly easy fix.  In fact, I'd propose that so long as we are going to fix this, go with multiple definitions

set undefined "Inf" "-Inf"
set missing "N/A"
?? set notnumber "NaN"

right away.  I think there is some utility to that.

Controllable behavior of plotting based upon point class could be for the future.


>   - Does Windows truly require the PostScript prolog files to
>     be moved back into the driver source?

Well, maybe not.  But if there is any chance of too much confusion with the patch because of something we haven't tested much yet, perhaps move the code back into post.trm and immediately move it back out after 4.2.

What is the amount of confidence at this point regarding the possibility of a lot of bug reports "postscript not viewable"?

...

And how about bug [ 1488168 ]?  Hans, I think that one is ready to go.  Ethan and I can discuss and change mouse behavior after that (probably a simple change), or just leave it as is for 4.2.

Dan

Re: Bug #1503114

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>=20
>>There are only two valid concepts in my mind.
>>
>>1)  What I just described, which is ignore anything within (or beyond,=20
>>whatever your viewpoint) a small fraction of the total range.  Likely=20
>>something so small it can't be resolved.
>=20
>=20
> And the trouble with that is that "can't be resolved" is a criterion=20
> that by its very definition depends on information that the autoscaling=
=20
> algorithm can't have.  The actual resolution of the eventual output=20
> device of a plot may not even be known at 'plot' time, much less can=20
> autoscaling be allowed to depend on it.

Well, I'm not sure on that.  Set the resolution to 20000 by 20000.  Then =
a ticmark will be 1/20000?  If so, that is not viewable.  You'd have to f=
orce a tic mark to be five or more pixels.  I mean, sure perhaps there is=
 a reason for such a high resolution, say a person wants to create a conf=
erence poster and be able to resolve something in a little corner of the =
plot.

My point here is that I think there is an inherent amount of visual plott=
ing information that a person can view.  I'm confortable with the idea of=
 limits on resolution.


> BTW: gnuplot has a parameter like your proposed "tolerance":  set zero.
> But it's being used less and less in the actual code, and I think that'=
s=20
> a good thing.
>=20
>=20
>>2)  Ignore anything within the machine resolution (i.e., epsilon) or=20
>>some small multiple of machine resolution, what Petr pointed out.
>=20
>=20
> Machine resolution is quite certainly the wrong way of doing this.=20
> That's the smallest value for your "TOL" parameter that's=20
> distinguishable from zero at all, effectively --- the only useful=20
> application of it would be sanity-check a 'set tolerance'.

The idea would be to reasonably catch the situation where the tic interva=
l is computed as 1/3 =3D 0.33333333333 and then the round outward test do=
es something (after arithmetic) like deciding  0.999999999999 < 1.0 becau=
se of rounding.


> I still hold that
>=20
> 3) zero tolerance --- keep it small and simple
>=20
> is the right way to go.
>=20
>=20
>>Going back to your original point.  The jump tells someone their data=20
>>extends beyond a tic, but in a perhaps imperceptable way.  (We could do=
=20
>>some examples to test this.)
>=20
>=20
> ... and if that really bothers some user, he can always easily fix that=
=20
> range manually (or, if he dislikes this jumpiness altogether, put 'set=20
> autoscale xfix' in his ~/.gnuplot).

I know.


>>I don't know what the preference would be, honestly. =20
>=20
>=20
> Let me put it this way: that behaviour, and those demos, have been=20
> around for years, some of them decades.  IIRC, we've had a total of=20
> about one complaint about that, in all that time.

OK.  Did you want to change the demos and set the ranges in a few cases? =
 I mean, I have wondered in the past why some of the pm3d demos have a wh=
ite area near the bottom of them.  They do look better without the gap in=
 this case.

Dan

Re: Build problem

[James R. V. Z. <jr...@co...>]

Juergen Wieferink <wie...@fr...> wrote:
>   > I suggest you check for extra copies of autoconf or automake, which
>   > may be hiding the versions you mention.  E.g.
>   >
>   >   type -a autoconf
>   >   type -a automake
>
>   Good idea.  But I've checked them using
>
>     autoconf --version
>     automake --version
>
>   so I should be save.

That will show you the first versions found in PATH.  But the
configure/build scripts might not respect the PATH.  I think it's
easiest to check for multiple versions directly.  If there are none,
then there is nothing to worry about.  

             - Jim Van Zandt

Re: Should NaN be reported as "UNDEFINED" ?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On a machine with IEEE-compliant floating point interpretations,
> the string "NaN"  (not case sensitive) is a legal floating point
> value.  Thus if NaN occurs in an input data file, the point is 
> not flagged as DF_UNDEFINED.
> 
> Should it be?  
> 
> DF_UNDEFINED usually means some random non-parsable
> junk appears in the field, or perhaps the field is empty.
> 
> I've uploaded a trivial patch that marks input NaN values as
> UNDEFINED, attached to Bug #1490699
> 
> But I'd like to hear whether everyone agrees that this is
> correct behaviour.
> 
> What about infinities ("Inf")?  
> I am inclined to pass those through, since the sign information
> is still present and conceivably a plotting function would want
> to handle +/- Inf explicitly.

I'm inclined to agree with you.  NaN is undefined.  Unless the user wants to flag it as missing.

+/-Inf is part of the extended real number system and part of the IEEE float definition.  It likely is something handled legitimately by most hardware and software these days.  Generally, let it pass on through, I would think.  Especially given the fact that I think there is both a plus and minus infinity in the IEEE definition.  So that would mean you'd need multiple strings to declare that as "missing".

NaN is in the IEEE definition as well, but has no conceptual connection to the real or extended real number system.

I think that is good for 4.2.  But I would like to see eventually flexibility with defining both "missing" and "undefined", with possibly the ability to have more than one definition.  For example,

set missing "Inf" "+Inf" "-Inf" "inf" "+inf" "-inf"
set undefined "N/A" "outdated"

Dan

Re: Bug #1503114

[<br...@ph...>]

Daniel J Sebald wrote:

> There are only two valid concepts in my mind.
> 
> 1)  What I just described, which is ignore anything within (or beyond, 
> whatever your viewpoint) a small fraction of the total range.  Likely 
> something so small it can't be resolved.

And the trouble with that is that "can't be resolved" is a criterion 
that by its very definition depends on information that the autoscaling 
algorithm can't have.  The actual resolution of the eventual output 
device of a plot may not even be known at 'plot' time, much less can 
autoscaling be allowed to depend on it.

BTW: gnuplot has a parameter like your proposed "tolerance":  set zero.
But it's being used less and less in the actual code, and I think that's 
a good thing.

> 2)  Ignore anything within the machine resolution (i.e., epsilon) or 
> some small multiple of machine resolution, what Petr pointed out.

Machine resolution is quite certainly the wrong way of doing this. 
That's the smallest value for your "TOL" parameter that's 
distinguishable from zero at all, effectively --- the only useful 
application of it would be sanity-check a 'set tolerance'.

I still hold that

3) zero tolerance --- keep it small and simple

is the right way to go.

> Going back to your original point.  The jump tells someone their data 
> extends beyond a tic, but in a perhaps imperceptable way.  (We could do 
> some examples to test this.)

... and if that really bothers some user, he can always easily fix that 
range manually (or, if he dislikes this jumpiness altogether, put 'set 
autoscale xfix' in his ~/.gnuplot).

> I don't know what the preference would be, honestly.  

Let me put it this way: that behaviour, and those demos, have been 
around for years, some of them decades.  IIRC, we've had a total of 
about one complaint about that, in all that time.

Re: Bug #1503114

[Ethan M. <merritt@u.washington.edu>]

May I propose that we just drop this patch [*], and put the
effort into discussion of more serious issues?

At a minimum, we need to resolve:

  - Reconciling the docs and the code with regard to the various
    flavors of missing/undefined data points

  - Does Windows truly require the PostScript prolog files to
    be moved back into the driver source?

  - Finalize and include the "user-available GPVAL_*" patch,
    #1488448, which I think is waiting on Hans-Bernhard's offer
    to identify the appropriate variables for export from=20
    fitting.

  - The Makefiles and config files for the non-autobuild
    platforms need to be checked for correctness and inclusion
    of the newer configuration options.

And then there's the nuts-and-bolts requirement to go over the
full manual and make sure it is up to date in referring to=20
version numbers, available features, syntax examples, and so on.

It would also be nice if someone familiar with the fitting code
would comment on  #1445064 "Gnuplot fitting improvements".
The description sounds reasonable, but I have not looked at
the patch itself, and I am not at all familiar with that part
of the code base.


	Ethan

[*] The truth is, I already dropped it last week on the basis of=20
unfavorable comments on the mailing list.

	Ethan


On Tuesday 20 June 2006 03:45 pm, Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
> > Daniel J Sebald wrote:
> >>> Not really.  You just hid it in a spot where it's harder to
> >>> trigger.
> >>
> >> I'm still debating with myself if this is the case.
> >
> > Just think of it this way: at some point, the actual endpoint of
> > the range *will* jump from 2.0 to, e.g., 2.5.  With the existing
> > code this happens exactly if the end of the data range is larger
> > than 2.0.  That's by far the clearest and most simple way of doing
> > it.  With the proposed modifications the jump would be elsewhere
> > --- and with all the different suggestions being made, it's by now
> > entirely unclear where that is.
> >
> > So the jump won't magically go away --- it just moves to a
> > different position on the input axis.  I refuse to see that as an
> > improvement. Especially not if we can't even explain it clearly to
> > each other, much less to unsuspecting users, where that new
> > position is actually supposed to be, and why it should be exactly
> > there.
> >
> >>> Floating-point rounding is tricky stuff.  It's completely
> >>> inevitable that sometimes, results will surprise people.  All
> >>> this patch does is move the surprise from a seemingly obvious
> >>> place to a less obvious one.  An axis ending at 2.0000001 has no
> >>> more business being artificially cut down to 2.0 than one ending
> >>> at 2.001.
> >>
> >> I think it does in some cases, and depends on the range.
> >
> > It depends on entirely too much, IMHO.
> >
> >> 1) [1.9999999 : 2.0000001]
> >>
> >> 2) [-2.0 : 2.0000001]
> >>
> >> In the first case, yes definitely, the limits have no business
> >> being artificially shrunk.
> >>
> >> However, in the second case I'm saying that cutting the upper
> >> limit inward to 2.0 rather than rounding outward to 2.5 is not
> >> egregious because its effect is beyond the resolution of the plot.
> >
> > Maybe.  But as I said, that just moves the problem elsewhere.=20
> > There *will* be some threshold for which a data range of
> >
> >     [-2.0: 2.0+delta]
> >
> > jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5].=20
> > You say that delta=3D1e-7 should be below the threshold --- but that
> > wilfully turns a perfectly valid data point into an out-of-bounds
> > one.   And at some point between delta=3D1e-7 and, say, delta=3D1e-2,
> > the output range *will* jump to 2.5.  Maybe that jump is at
> > delta=3D1e-3 or at 1e-5, it doesn't really matter.   It's still a
> > jump, and somebody will have to explain to himself or a puzzled
> > user why that range endpoint made such a huge jump.  As is, that
> > explanation is simple: the actual range was larger than 2.0, so
> > gnuplot made room for that.  Now you explain why your threshold is
> > exactly where it ends up to be --- and why the same data, with the
> > same settings, yield a different range endpoint on different
> > terminal drivers.
>
> You are making a good point.  Currently, the user sees the big jump
> and knows right away that his or her data goes beyond the range they
> may have thought.  Even thought they may not be able to see it.  Very
> predictable behavior.
>
> Just to clarify, I'm saying that delta is not chosen as a fixed
> value.  I'm trying to relate that delta to the range.  For example,
> let's choose TOL to be tolerance and set that at 1/1000.  Now, the
> formula would be
>
> delta =3D TOL * abs(xmax - xmin)
>
> and in this case would be delta =3D abs(2 - (-2)) * 1/500 =3D 0.004.  So
> if the value to be rounded outward is within -2.004 but not above the
> next highest tic mark, the value is rounded to -2.  Likewise, the
> same thing that within 2.004 is rounded down to 2.0.
>
> Now, pick a range like [-1.9999:2.0001].  From the formula above,
> epsilon now is 2e-7.
>
> There are only two valid concepts in my mind.
>
> 1)  What I just described, which is ignore anything within (or
> beyond, whatever your viewpoint) a small fraction of the total range.
>  Likely something so small it can't be resolved.
>
> 2)  Ignore anything within the machine resolution (i.e., epsilon) or
> some small multiple of machine resolution, what Petr pointed out.
>
> I'm fairly certain case 1 will catch any machine arithmetic rounding
> problems.  Case 2?  Probably, but not as assured for some reason.
>
> Case 2 is predictable in the sense all it will catch is some rounding
> issues.  Case 1 *is* less predictable, but I think the concept is
> understandable.
>
> Going back to your original point.  The jump tells someone their data
> extends beyond a tic, but in a perhaps imperceptable way.  (We could
> do some examples to test this.)
>
> I don't know what the preference would be, honestly.  But there is a
> concept or two there that seems not so confusing.
>
> Dan
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Bug #1503114

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>>> Not really.  You just hid it in a spot where it's harder to trigger.
>>
>>
>> I'm still debating with myself if this is the case.
>=20
>=20
> Just think of it this way: at some point, the actual endpoint of the=20
> range *will* jump from 2.0 to, e.g., 2.5.  With the existing code this=20
> happens exactly if the end of the data range is larger than 2.0.  That'=
s=20
> by far the clearest and most simple way of doing it.  With the proposed=
=20
> modifications the jump would be elsewhere --- and with all the differen=
t=20
> suggestions being made, it's by now entirely unclear where that is.
>=20
> So the jump won't magically go away --- it just moves to a different=20
> position on the input axis.  I refuse to see that as an improvement.=20
> Especially not if we can't even explain it clearly to each other, much=20
> less to unsuspecting users, where that new position is actually suppose=
d=20
> to be, and why it should be exactly there.
>=20
>>> Floating-point rounding is tricky stuff.  It's completely inevitable=20
>>> that sometimes, results will surprise people.  All this patch does is=
=20
>>> move the surprise from a seemingly obvious place to a less obvious=20
>>> one.  An axis ending at 2.0000001 has no more business being=20
>>> artificially cut down to 2.0 than one ending at 2.001.
>>
>>
>> I think it does in some cases, and depends on the range. =20
>=20
>=20
> It depends on entirely too much, IMHO.
>=20
>> 1) [1.9999999 : 2.0000001]
>>
>> 2) [-2.0 : 2.0000001]
>>
>> In the first case, yes definitely, the limits have no business being=20
>> artificially shrunk.
>>
>> However, in the second case I'm saying that cutting the upper limit=20
>> inward to 2.0 rather than rounding outward to 2.5 is not egregious=20
>> because its effect is beyond the resolution of the plot. =20
>=20
>=20
> Maybe.  But as I said, that just moves the problem elsewhere.  There=20
> *will* be some threshold for which a data range of
>=20
>     [-2.0: 2.0+delta]
>=20
> jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5].  You sa=
y=20
> that delta=3D1e-7 should be below the threshold --- but that wilfully=20
> turns a perfectly valid data point into an out-of-bounds one.   And at=20
> some point between delta=3D1e-7 and, say, delta=3D1e-2, the output rang=
e=20
> *will* jump to 2.5.  Maybe that jump is at delta=3D1e-3 or at 1e-5, it=20
> doesn't really matter.   It's still a jump, and somebody will have to=20
> explain to himself or a puzzled user why that range endpoint made such =
a=20
>  huge jump.  As is, that explanation is simple: the actual range was=20
> larger than 2.0, so gnuplot made room for that.  Now you explain why=20
> your threshold is exactly where it ends up to be --- and why the same=20
> data, with the same settings, yield a different range endpoint on=20
> different terminal drivers.

You are making a good point.  Currently, the user sees the big jump and k=
nows right away that his or her data goes beyond the range they may have =
thought.  Even thought they may not be able to see it.  Very predictable =
behavior.

Just to clarify, I'm saying that delta is not chosen as a fixed value.  I=
'm trying to relate that delta to the range.  For example, let's choose T=
OL to be tolerance and set that at 1/1000.  Now, the formula would be

delta =3D TOL * abs(xmax - xmin)

and in this case would be delta =3D abs(2 - (-2)) * 1/500 =3D 0.004.  So =
if the value to be rounded outward is within -2.004 but not above the nex=
t highest tic mark, the value is rounded to -2.  Likewise, the same thing=
 that within 2.004 is rounded down to 2.0.

Now, pick a range like [-1.9999:2.0001].  From the formula above, epsilon=
 now is 2e-7.

There are only two valid concepts in my mind.

1)  What I just described, which is ignore anything within (or beyond, wh=
atever your viewpoint) a small fraction of the total range.  Likely somet=
hing so small it can't be resolved.

2)  Ignore anything within the machine resolution (i.e., epsilon) or some=
 small multiple of machine resolution, what Petr pointed out.

I'm fairly certain case 1 will catch any machine arithmetic rounding prob=
lems.  Case 2?  Probably, but not as assured for some reason.

Case 2 is predictable in the sense all it will catch is some rounding iss=
ues.  Case 1 *is* less predictable, but I think the concept is understand=
able.

Going back to your original point.  The jump tells someone their data ext=
ends beyond a tic, but in a perhaps imperceptable way.  (We could do some=
 examples to test this.)

I don't know what the preference would be, honestly.  But there is a conc=
ept or two there that seems not so confusing.

Dan

Re: MISSING and UNDEFINED

[<br...@ph...>]

Ethan A Merritt wrote:

> Version 4.0 does not behave as the docs state.
> Is this a bug in the code, or in the docs?

Could be both.

In case of doubt, it could be that we have to pick between the last 
version of gnuplot where code and docs still agreed to some sensible 
level, on one hand, and plain common sense on the other.

> Disregarding what the docs say, is the handling of
> missing/undefined/garbage data consistent in all code paths?

I would be surprised if it were.  The code's internal consistency has 
degraded substantially over time.

Re: btw.: did you (the wxterminal developers) compile with gcc -Wall ?

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 20 June 2006 04:46 pm, Timoth=C3=A9e Lecomte wrote:
> By the way, I don't see the warnings Ethan has just reported in
> wxt.trm and gp_cairo.c . Why ? Is -Wall dependant on the compiler
> (mine is gcc 4.0.3) ? Do you use other -Wsomething, Ethan ?

gcc (GCC) 4.0.1
No special options.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Rotate plot in Gnuplot

[<br...@ph...>]

L=F8v=E5s Olvar wrote:

> It is possible to rotate a plot 90 degrees before plotting on scree=
n?

Depends.   What type of "on screen" is that?  I.e. what platform, wha=
t=20
choice of 'set terminal' in gnuplot?

Re: btw.: did you (the wxterminal developers) compile with gcc -Wall ?

[<tim...@en...>]

Dr. Johannes Zellner wrote:
> On Wed, Jun 21, 2006 at 01:08:16AM +0200, Timoth=C3=A9e Lecomte wrote:
>  =20
>> Dr. Johannes Zellner wrote:
>>    =20
>>> I get some warnings and just wanted to report this ...
>>>
>>> =20
>>>      =20
>> Good remark. I don't because I would like it to be done automatically,=
=20
>> and I don't know to do that.
>>
>> (I know export CFLAGS=3D"-Wall" but it has to be done on each terminal=
=20
>> session, it's annoying)
>>    =20
>
> I'd really, really recommend setting this by default (in your
> ~/.profile), not just for gnuplot, but for any project development usin=
g
> gcc. In the last years I found again and again that (collegues) could
> have saved a lot of time (and trouble) if they would have used -Wall.
> Just a very strong recommendation. As I've it by default, I see also
> warnings as it was just the case for gnuplot.
>  =20
Ok, thanks for your advice.

By the way, I don't see the warnings Ethan has just reported in wxt.trm=20
and gp_cairo.c . Why ? Is -Wall dependant on the compiler (mine is gcc=20
4.0.3) ? Do you use other -Wsomething, Ethan ?

Timoth=C3=A9e