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

Re: Re: gnuplot cvs source bug

[<ds...@ch...>]

> 
> From: Juergen Wieferink <wie...@fr...>
> Date: 2005/09/23 Fri PM 03:02:15 EDT
> To: gnu...@li...
> Subject: Re: gnuplot cvs source bug
> 
> On Friday 23 September 2005 20:34 Ethan Merritt wrote:
> > I happen to disagree.  Integer arithmetic is quite useful in many
> > contexts, and it is a standard part of programming languages and
> > natural languages.  Adding peculiar arithmetic operators to indicate
> > that a number is an integer strikes me as being an obfuscation, not
> > a clarification.  Sure, sometimes even an experienced user will
> > forget, and mistype  (n/2) where it should have been (n/2.0).
> > But also people type "if (a = b)" where it should have been
> > "if (a == b)" or "if (a eq b)". Hiding this useful distinction
> > in a choice of operators is not likely to reduce the number of
> > mistakes.
> 
> I would agree if variables in gnuplot had explicit types.  But the
> type is part of the value.  In a script it can be hard or even
> impossible to say if an expression "a/b" is integer or floating
> point division.  So an additional operator would make the code more
> readable.
> 
> I just wanted to make my point clear.  I'm aware that this is
> unlikly to be included.

Nothing Ethan said seems to rule out the "treat all numbers as floats"/"treat non-decimal point numbers as ints" variable that someone else suggested.  It is something that could be put in the gnuplot startup file for those who want gnuplot always to treat numbers as floats even immediately after launch.

But yeah, int(...) of this and float(...) of that scatter about the scripts is nasty and unnecessary.

Dan

Re: gnuplot cvs source bug

[Juergen W. <wie...@fr...>]

On Friday 23 September 2005 20:34 Ethan Merritt wrote:
> I happen to disagree.  Integer arithmetic is quite useful in many
> contexts, and it is a standard part of programming languages and
> natural languages.  Adding peculiar arithmetic operators to indicate
> that a number is an integer strikes me as being an obfuscation, not
> a clarification.  Sure, sometimes even an experienced user will
> forget, and mistype  (n/2) where it should have been (n/2.0).
> But also people type "if (a = b)" where it should have been
> "if (a == b)" or "if (a eq b)". Hiding this useful distinction
> in a choice of operators is not likely to reduce the number of
> mistakes.

I would agree if variables in gnuplot had explicit types.  But the
type is part of the value.  In a script it can be hard or even
impossible to say if an expression "a/b" is integer or floating
point division.  So an additional operator would make the code more
readable.

I just wanted to make my point clear.  I'm aware that this is
unlikly to be included.

Juergen

Re: gnuplot cvs source bug

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

On Friday 23 September 2005 07:19 am, Robert Hart wrote:
> 
> Yes, but we are talking about a situation where floats *do* apply.
> Surely it is more logical to treat numbers as floats *unless* they are
> used in a context where only integers apply. For any ambiguous case
> (division and exponentiation), anybody who wants the integer math
> *knows* they want it and can use int()

I happen to disagree.  Integer arithmetic is quite useful in many
contexts, and it is a standard part of programming languages and
natural languages.  Adding peculiar arithmetic operators to indicate
that a number is an integer strikes me as being an obfuscation, not
a clarification.  Sure, sometimes even an experienced user will 
forget, and mistype  (n/2) where it should have been (n/2.0).
But also people type "if (a = b)" where it should have been
"if (a == b)" or "if (a eq b)". Hiding this useful distinction
in a choice of operators is not likely to reduce the number of
mistakes.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: gnuplot cvs source bug

[Juergen W. <wie...@fr...>]

On Friday 23 September 2005 17:38 Aapo Lankinen wrote:
> Gnuplot could even warn every time you try to use integers in
> interactive interpreted mode:
> ----
> gnuplot> print 1/2
> Warning: Numeric input interpreted as integers.  Consider using "set
> numbermode floating" or "set numbermode integer".
> ----
> And of course, scripts would just silently do what they are directed to
> do even if "numbermode interpreted" would be used.

Hmm.  I'd vote for the introduction of some explicit integer
division operator like "//" (as in python).  So at the end it would
be

gnuplot> print 1/2
0.5
gnuplot> print 1//2
0

I'm aware of the compatibility issues.  The use of "/" as integer
division would have to be depricated for at least one release [=>
about five years ;-)].  It should lead to some warning message as
you suggested.


Juergen

Re: Re: gnuplot cvs source bug

[<ds...@ch...>]

> Gnuplot could even warn every time you try to use integers in
> interactive interpreted mode:
> ----
> gnuplot> print 1/2
> Warning: Numeric input interpreted as integers.  Consider using "set
> numbermode floating" or "set numbermode integer".

But only the first time integer math is used.  Otherwise it would be too, um, annoying.

Dan

Re: gnuplot cvs source bug

[Aapo L. <aap...@gm...>]

On Fri, 2005-09-23 at 16:33 +0200, Petr Mikulik wrote:
> > gnuplot> print 1/(5**1)
> > 0
> > gnuplot> print (5**-1)
> > 0.2
> 
> Whether we like it or not, changing it now would break scripts, so we have 
> to accept this behaviour. (Well, it is a FAQ for a long long time.)

Could it be like
  gnuplot> set numbermode floating
or
  gnuplot> set numbermode integer
or
  gnuplot> set numbermode interpreted
where the default would be "interpreted", which would have the current
behaviour.  That way the old scripts wouldn't be broken, and the new
users could be directed to always use numbermode floating.

Gnuplot could even warn every time you try to use integers in
interactive interpreted mode:
----
gnuplot> print 1/2
Warning: Numeric input interpreted as integers.  Consider using "set
numbermode floating" or "set numbermode integer".
----
And of course, scripts would just silently do what they are directed to
do even if "numbermode interpreted" would be used.

						Aapo Lankinen

Re: gnuplot cvs source bug

[Robert H. <en...@no...>]

On Fri, 2005-09-23 at 16:33 +0200, Petr Mikulik wrote:
> > Other counter-intuitive behaviour:
> >
> > gnuplot> print 1/(5**1)
> > 0
> > gnuplot> print (5**-1)
> > 0.2
> 
> Whether we like it or not, changing it now would break scripts, so we have 
> to accept this behaviour. (Well, it is a FAQ for a long long time.)

No, we just have to bear in mind that there would be a cost to changing
it and weigh that up against the cost of not changing it. In fact in
this case, it wouldn't surprise me if we ended up fixing currently
broken scripts.


-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: gnuplot cvs source bug

[Petr M. <mi...@ph...>]

> Other counter-intuitive behaviour:
>
> gnuplot> print 1/(5**1)
> 0
> gnuplot> print (5**-1)
> 0.2

Whether we like it or not, changing it now would break scripts, so we have 
to accept this behaviour. (Well, it is a FAQ for a long long time.)

---
PM

Re: gnuplot cvs source bug

[Robert H. <en...@no...>]

On Fri, 2005-09-23 at 15:48 +0200, Hans-Bernhard Broeker wrote:

> Yes, and I will until the day the first DIWM (for "do-what-I-mean") 
> interfaced computer becomes available --- it's been elusive for so long 
> that I seriously doubt it will ever happen, though.

Until then we have the "principle of least surprise" - in other words a
computer can be made to "DWIM" as much of the time as possible by doing
what you would expect most likely it to do. Thus in the context of a
scientific plotting package that primarily plots continuous functions
and arbitrary discrete data, the mathematical (and human) definition of
division would be expected.

> > Can you actually think of a real-life case where integer maths is the
> > "correct" way of doing a calculation *and* explicitly using the int()
> > function would not be appropriate?
> 
> Yes.  It's quite obvious, too: integer maths has applications where 
> floats simply don't apply.  gnuplot has binary operators like '%', '|', 
> '&' and '^' which are applicable only to integers.

Yes, but we are talking about a situation where floats *do* apply.
Surely it is more logical to treat numbers as floats *unless* they are
used in a context where only integers apply. For any ambiguous case
(division and exponentiation), anybody who wants the integer math
*knows* they want it and can use int()

Other counter-intuitive behaviour:

gnuplot> print 1/(5**1)
0
gnuplot> print (5**-1) 
0.2

gnuplot> x=1000000000000000000                                 
gnuplot> print x              
2147483647
gnuplot> x=1000000000000000000.0
gnuplot> print x                
1e+18
gnuplot> x=1*10**18
gnuplot> print x
-1486618624


-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: gnuplot cvs source bug

[Robert H. <en...@no...>]

On Fri, 2005-09-23 at 14:57 +0200, Hans-Bernhard Broeker wrote:

> Well, you don't have a computer with a mind-reading interface, do you? 
> So how do you expect it to be able to know what you *think*, 
> particularly in a case like this where what you think openly disagrees 
> with what you actually told it via keyboard?

Do you actually believe that? Even if you are a C programmer, and you
understand why there is a distinction between 2/3 and 2.0/3.0 this must
still catch you out time and time again?

Thankfully in this case the symptoms are strong enough that the error is
easily noticed, and therefor fixed, but it's also easy to get caught out
in more subtle ways too. i.e. with larger integers.

It's even worse that although we use the C convention of integer
division but also have implicitly typed variables, something like this
is wrong too:

f(x) = 1/a*x
a = 5
plot f(x)
a = 5.0
plot f(x)

Can you actually think of a real-life case where integer maths is the
"correct" way of doing a calculation *and* explicitly using the int()
function would not be appropriate?



-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: gnuplot cvs source bug

[Hans-Bernhard B. <br...@ph...>]

Pentek Imre Geza wrote:

> this is not a feature, its a very annoying malfunction. 

Following this same style of argument, what you wrote is not a bug 
report, but an very annoying complaint.

> when I write 2/3 I'm not thinking about computer-executed
> mathematical computations, but thinking about mathematical operation.

Well, you don't have a computer with a mind-reading interface, do you? 
So how do you expect it to be able to know what you *think*, 
particularly in a case like this where what you think openly disagrees 
with what you actually told it via keyboard?

Re: gnuplot cvs source bug

[Pentek I. G. <pen...@in...>]

On Fri, 23 Sep 2005 11:53:24 +0200, Hans-Bernhard Broeker wrote
> Péntek Imre wrote:
> > Hello,
> > 
> > I use gnuplot compiled by me from cvs source, I found this bug:
> > Terminal type set to 'x11'
> > gnuplot> plot exp(2/3*x);
> > Warning: empty y range [1:1], adjusting to [0.99:1.01]
> 
> That's not a bug.  That's just integer arithmetic.  Try the 
> following two commands in a gnuplot prompt, and you'll see it:
> 
> 	print 2/3
> 	print 2.0/3
> 
> And before you ask: yes, this documented behaviour.  See "help expressions".
this is not a feature, its a very annoying malfunction. when I write 2/3 I'm 
not thinking about computer-executed mathematical computations, but thinking 
about mathematical operation. the two of the above ones should be equivalent.
--
Üdvözlettel: Ifj. Péntek Imre
E-Mail: pen...@in...

Re: gnuplot cvs source bug

[Pentek I. G. <pen...@in...>]

On Fri, 23 Sep 2005 10:14:10 +0100, Robert Hart wrote
> plot exp(2.0/3.0*x) ?
not yet, thanks I will try that.
> I really don't see why a scientific plotting program is doing integer
> math. urgh.
When I write 2/3*x I don't thinking about computer-executed math, but instead 
I think about mathematical operation, and should work anyways.
--
Üdvözlettel: Ifj. Péntek Imre
E-Mail: pen...@in...

Re: gnuplot cvs source bug

[Hans-Bernhard B. <br...@ph...>]

P=E9ntek Imre wrote:
> Hello,
>=20
> I use gnuplot compiled by me from cvs source, I found this bug:
> Terminal type set to 'x11'
> gnuplot> plot exp(2/3*x);
> Warning: empty y range [1:1], adjusting to [0.99:1.01]

That's not a bug.  That's just integer arithmetic.  Try the following=20
two commands in a gnuplot prompt, and you'll see it:

	print 2/3
	print 2.0/3

And before you ask: yes, this documented behaviour.  See "help expression=
s".

Re: gnuplot cvs source bug

[Robert H. <en...@no...>]

On Thu, 2005-09-22 at 20:04 +0200, P=E9ntek Imre wrote:
> Hello,
>=20
> I use gnuplot compiled by me from cvs source, I found this bug:
> Terminal type set to 'x11'
> gnuplot> plot exp(2/3*x);
> Warning: empty y range [1:1], adjusting to [0.99:1.01]
> gnuplot> plot [-3:3] exp(2/3*x);
> Warning: empty y range [1:1], adjusting to [0.99:1.01]
> gnuplot> plot [-3:3][0:3] exp(2/3*x);
> gnuplot>
> And in this version (cvs2005091) exp(2/3*x) is interpreted as a constant =
1=20
> function, however it should be exp(x):=3De**x:=3Dsum n=3D0 to +infinity (=
x**n)/(n!)

Have you tried=20

plot exp(2.0/3.0*x) ?

I really don't see why a scientific plotting program is doing integer
math. urgh.

Rob

--=20
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

gnuplot cvs source bug

[<pen...@in...>]

Hello,

I use gnuplot compiled by me from cvs source, I found this bug:
Terminal type set to 'x11'
gnuplot> plot exp(2/3*x);
Warning: empty y range [1:1], adjusting to [0.99:1.01]
gnuplot> plot [-3:3] exp(2/3*x);
Warning: empty y range [1:1], adjusting to [0.99:1.01]
gnuplot> plot [-3:3][0:3] exp(2/3*x);
gnuplot>
And in this version (cvs2005091) exp(2/3*x) is interpreted as a constant 1=
=20
function, however it should be exp(x):=3De**x:=3Dsum n=3D0 to +infinity (x*=
*n)/(n!)
=2D-=20
=DCdv=F6zlettel: Ifj. P=E9ntek Imre
E-Mail: pen...@in...

Re: Fwd: pslatex terminal output--Problem identified.

[Dmitri A. S. <das...@gm...>]

Hans-Bernhard Broeker wrote:

> 
> RTFM ('help postscript'):
> 
> Syntax:
>       set terminal postscript {<mode>} {enhanced | noenhanced}
> [...]
> where <mode> is landscape, portrait, eps or default
> 
> Select one of the others, and 'eps' will be turned off.  The "default" 
> setting may only actually work in the CVS version, not in 4.0
> 

Thanks, this works.

I do not know which FM you are referring to, mine says the following
(from 1 hour ago CVS):

gnuplot> help postscript
  Several options may be set in the `postscript` driver.

  Syntax:
        set terminal postscript {landscape | portrait | eps}
                                {enhanced | noenhanced}
                                {defaultplex | simplex | duplex}
                                {fontfile [add | delete] "<filename>"
                                 | nofontfiles}
                                {default}
                                {level1 | leveldefault}
                                {color | colour | monochrome}
                                {solid | dashed}
                                {dashlength | dl <DL>}
                                {linewidth | lw <LW>}
                                {rounded | butt}
                                {palfuncparam <samples>{,<maxdeviation>}}
                                {blacktext | colortext | colourtext}
                                {"<fontname>"} {<fontsize>}

...

Though, perhaps, one can deduce that "default" option reverses
"eps" it is not that obvious to me.

Sincerely,

Dmitri.

Re: Fwd: pslatex terminal output--Problem identified.

[Hans-Bernhard B. <br...@ph...>]

Dmitri A. Sergatskov wrote:
> Hans-Bernhard Broeker wrote:

>> This is not really a bug, but intended behaviour.  gnuplot terminal 
>> drivers save settings internally, so going to some other driver and 
>> then back will give you the previously used driver in the same state 
>> is was in before.  Users can't seem to make up their mind whether they 
>> like this or not...

> Ok, in that case how do I undo "eps" setting for the file foo.ps in
> the following script?

RTFM ('help postscript'):

Syntax:
       set terminal postscript {<mode>} {enhanced | noenhanced}
[...]
where <mode> is landscape, portrait, eps or default

Select one of the others, and 'eps' will be turned off.  The "default" 
setting may only actually work in the CVS version, not in 4.0

Re: Fwd: pslatex terminal output--Problem identified.

[Dmitri A. S. <das...@gm...>]

Hans-Bernhard Broeker wrote:
> From: John W. Eaton <jw...@be...>
> 
>> OK, I think this might be a bug in gnuplot.  You can reproduce it with
>> the following commands (these are essentially the commands that Octave
>> is sending to gnuplot, but plotting a function instead of a data file
>> to simplify things a bit)):
> 
> 
> [...]
> 
>  > I have not looked at the code, so I am only guessing here, but it
>  > seems that the problem might be that gnuplot is hanging on to some
>  > postscript terminal options even after the set terminal pop statement
>  > is executed.  If you insert something like
> 
> This is not really a bug, but intended behaviour.  gnuplot terminal 
> drivers save settings internally, so going to some other driver and then 
> back will give you the previously used driver in the same state is was 
> in before.  Users can't seem to make up their mind whether they like 
> this or not...
> 

Ok, in that case how do I undo "eps" setting for the file foo.ps in
the following script?


  plot sin(x) title "line 1"
  set terminal push
  set term postscript eps enhanced color solid
  set output "foo.eps"
  replot
  set terminal pop
  set output
  replot
  set term postscript
  set output "foo.ps"
  replot
  quit


There are enhanced|noenhanced, color|monochrome, but there is no eps|noeps
switch, which in my mind imply that "eps" should not be a sticky option.

Sincerely,

Dmitri.

Re: epslatex problems

[Hans-Bernhard B. <br...@ph...>]

Valentina Beato wrote:

> Why? I am using the "input" mode, so I should not have to specify any 
> package for latex.

What makes you think that?  gnuplot's pslatex output is LaTeX code using 
commands from certain packages.  Those packages *cannot* be loaded by 
the gnuplot code itself --- that has to be done in the preamble of your 
document.  It says so quite clearly, too, both in the error messages you 
quoted, and in the documentation they tell you to read.

Fwd: pslatex terminal output--Problem identified.

[Dmitri A. S. <das...@gm...>]

FYI
From the octave list:

Sincerely,

Dmitri.

---------- Forwarded message ----------
From: John W. Eaton <jw...@be...>
Date: Sep 21, 2005 8:24 PM
Subject: Re: pslatex terminal output--Problem identified.
To: Pete Gustafson <wat...@ya...>
Cc: he...@oc...



OK, I think this might be a bug in gnuplot.  You can reproduce it with
the following commands (these are essentially the commands that Octave
is sending to gnuplot, but plotting a function instead of a data file
to simplify things a bit)):

  plot sin(x) title "line 1"
  set terminal push
  set term postscript eps enhanced color solid
  set output "foo.eps"
  replot
  set terminal pop
  set output
  replot
  set term pslatex
  set output "foo.tex"
  replot
  quit

I have not looked at the code, so I am only guessing here, but it
seems that the problem might be that gnuplot is hanging on to some
postscript terminal options even after the set terminal pop statement
is executed.  If you insert something like

  set term postscript landscape

just after the set terminal pop statement, the problem goes away.  But
how can Octave know that it should do that?  It seems it would be
better for "set term pop" to restore the state of the terminal driver
to whatever it was when "set term push" was executed.

Here is a simpler example.  Compare foo.eps vs. foo.ps from the
following two scripts.

1:
  plot sin(x) title "line 1"
  set terminal push
  set term postscript
  set output "foo.ps"
  replot
  set terminal pop
  set output
  replot
  set term postscript eps enhanced color solid
  set output "foo.eps"
  replot
  quit

2:
  plot sin(x) title "line 1"
  set terminal push
  set term postscript eps enhanced color solid
  set output "foo.eps"
  replot
  set terminal pop
  set output
  replot
  set term postscript
  set output "foo.ps"
  replot
  quit

Looking at these I would expect foo.ps in both cases to be the simple
full page postscript plot.  But in the second case, both plots are
small eps style plots.

I just checked the latest CVS gnuplot and it seems the behavior is the
same.  Would someone like to report this problem and find out if it is
intentional behavior or a bug?

Thanks,

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

epslatex problems

[Valentina B. <val...@da...>]

With the following settings:

set term epslatex input blacktext colour

I get the following error messages:

    \GenericError{(gnuplot) \space\space\space\@spaces}{%
      Package color not loaded in conjunction with
      terminal option `colourtext'%
    }{See the gnuplot documentation for explanation.%
    }{Either use 'blacktext' in gnuplot or load the package
      color.sty in LaTeX.}%

and

    \GenericError{(gnuplot) \space\space\space\@spaces}{%
      Package graphicx or graphics not loaded%
    }{See the gnuplot documentation for explanation.%
    }{The gnuplot epslatex terminal needs graphicx.sty or graphics.sty.}%

Why? I am using the "input" mode, so I should not have to specify any 
package for latex....I am surely missing something....

Ciao
Valentina

Incorrent conditional code for X11_BINARY_POLYGON

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

Daniel:

The #ifdef / #else / #endif blocks in gplt_x11.c are
horribly unreadable.  So much so that they have hidden
some serious mis-ordering of the statements.


Try
  ./configure --with-image --disable-binary-x11-polygon
  cd src
  make gnuplot_x11

and watch everything fall apart.

The nested #ifdef/#endif code blocks that end just before
line 3050 of gplt_x11.c are clearly incorrect, but I cannot
see what the original intent was.

Can you please try to clean up this code?
I suggest that no #ifdef/#endif pair should leave unbalanced
curly brackets in the code.  This sort of thing:

if (A) {
#ifdef FOO
    if (B)
	{
	blah; blah;
#else
   yadda; yadda;
#endif


is just asking for trouble.
 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: wxWidgets terminal : locale "C" ?

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

On Saturday 17 September 2005 10:48 am, you wrote:
>
> I finally found that the original bug was *my* problem. In fact, current
> cvs is not broken and in particular x11 terminal works properly on my
> "french box". 

Actually, it is broken, and in exactly the way you pointed out.
But it does not enter the broken state by default; only if you
explicitly say
	set decimalsign locale
where the current locale is, say, fr_FR.

So we still need to fix it.
I'm working on a patchset that forces LC_NUMERIC back to C
during command line parsing and during "save" commands, as well
as for the mouse zoom and the "test palette" command.
There may be other places that need it as well, but those are
the ones I have found so far.

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

new patch for wxwidgets terminal

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

Hi all !

You'll find a new version of my wxwidgets terminal on the gnuplot
developpement pages :

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1267434&grou=
p_id=3D2055&atid=3D302055

Thanks to our discussion in the mailing list, I corrected a problem
about the locale "C". Moreover, there's now an option to disable the
compilation of the wxwidgets' stuff. To do so, use : "./configure
--disable-wxwidgets". Finally, there are some simplifications, mostly
cosmetic.

Greetings,

Timoth=E9e Lecomte