Menu
▾
▴
gnuplot-beta
|
From: <pen...@in...> - 2005-09-22 18:04:55
|
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... |
|
From: Robert H. <en...@no...> - 2005-09-23 09:14:34
|
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. |
|
From: Pentek I. G. <pen...@in...> - 2005-09-23 11:16:17
|
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... |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-09-23 09:50:55
|
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". |
|
From: Pentek I. G. <pen...@in...> - 2005-09-23 11:18:37
|
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... |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-09-23 12:55:29
|
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? |
|
From: Robert H. <en...@no...> - 2005-09-23 13:12:51
|
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. |
|
From: Robert H. <en...@no...> - 2005-09-23 14:20:16
|
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. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-09-23 18:34:46
|
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 |
|
From: Juergen W. <wie...@fr...> - 2005-09-23 19:04:29
|
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 |
|
From: Robert H. <en...@no...> - 2005-09-24 12:57:09
|
On Fri, 2005-09-23 at 11:34 -0700, Ethan Merritt wrote: > 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. Firstly gnuplot is not a programming language, it is a scientific plotting utility. I think that is an important distinction in itself. Secondly, the typical user is neither a programmer or "experienced", they are simply somebody who wants to create plots with the minimum fuss. If they are experienced in something, it may well be spreadsheets - in fact a spreadsheet may be the last application they used before switching to gnuplot. I realise at the end of a day this is a issue of background, and that people like me who are used to basic, perl and excel think differently to the FORTRAN, C, and bash people in the world, but if the situation were reversed I don't think you'd get people reporting it as a bug that 1/2=0.5, because they'd just say "oh uh, I meant int(1/2) then" Just my $0.02. -- 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. |
|
From: Petr M. <mi...@ph...> - 2005-09-23 14:34:16
|
> 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 |
|
From: Robert H. <en...@no...> - 2005-09-23 14:59:35
|
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. |
|
From: Aapo L. <aap...@gm...> - 2005-09-23 15:39:11
|
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 |
|
From: Juergen W. <wie...@fr...> - 2005-09-23 16:31:29
|
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 |
|
From: V. <gae...@no...> - 2005-09-24 13:02:59
|
So far I haven't expressed my opinion on that subject, and I don't
what to add wood to the flame, but I must say that I am strongly opposed
to 1/2 !=3D 1/2.0 . This just make gnuplot hermetic to non coders. It als=
o
makes it behave differently then octave and matlab, and most scientific
programs.
--
Ga=EBl
|
|
From: Harald H. <h.h...@tu...> - 2005-09-24 13:29:34
|
On Sat, 24 Sep 2005, Ga=EBl Varoquaux wrote: > So far I haven't expressed my opinion on that subject, and I don't > what to add wood to the flame, but I must say that I am strongly opposed > to 1/2 !=3D 1/2.0 . This just make gnuplot hermetic to non coders. It als= o > makes it behave differently then octave and matlab, and most scientific > programs. I am a coder, but I also think that 1/2 should be equal to 1/2.0. Since gnuplot does not provide explicit variable types you always have to use hacks to make sure that you use floats, e.g. f(a,b)=3Da/(1.0*b). This often leads to bugs in gnuplot scripts. What about Pascal syntax: float =3D a/b int =3D a div b Best regards Harald --=20 Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: BBands <bb...@ya...> - 2005-09-27 14:45:31
|
Dear Plotters,
One factor you might want to consider in this regard
is the increasing use of gnuplot driven by scripts of
dynamically-typed languages--Python, Perl, Tcl, Ruby,
PHP... In such cases unexpected results can arise as a
result of integer division being the default. Perhaps
adopting a Python-like approach (// for integer
division) initially driven by a switch (set division
true|integer) and eventually defaulting to true might
help.
Best regards,
jab
John Bollinger, CFA, CMT
www.BollingerBands.com
If you advance far enough, you arrive at the beginning.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
|
|
From: Petr M. <mi...@ph...> - 2005-09-27 14:50:18
|
> One factor you might want to consider in this regard > is the increasing use of gnuplot driven by scripts of > dynamically-typed languages--Python, Perl, Tcl, Ruby, > PHP... In such cases unexpected results can arise as a > result of integer division being the default. Perhaps > adopting a Python-like approach (// for integer > division) initially driven by a switch (set division > true|integer) and eventually defaulting to true might > help. Python works like gnuplot: Python 2.3.4 (#1, Feb 7 2005, 15:50:45) [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print 5/2 2 >>> print 5//2 2 --- PM |
|
From: Juergen W. <wie...@fr...> - 2005-09-27 14:56:57
|
Petr Mikulik wrote: > Python works like gnuplot: > > Python 2.3.4 (#1, Feb 7 2005, 15:50:45) > [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > > >>> print 5/2 > > 2 > > >>> print 5//2 > > 2 Yes, but AFAIK this behaviour will change with 3.0. Try: >>> from __future__ import division >>> print 5/2 2.5 Juergen |
|
From: BBands <bb...@ya...> - 2005-09-27 15:05:57
|
--- Petr Mikulik <mi...@ph...> wrote:
> Python works like gnuplot:
>
> Python 2.3.4 (#1, Feb 7 2005, 15:50:45)
> [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
> Type "help", "copyright", "credits" or "license" for
> more information.
> >>> print 5/2
> 2
> >>> print 5//2
> 2
It does now, but look at this:
C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> 5/2
2
>>> 5//2
2
>>> from __future__ import division
>>> 5/2
2.5
>>> 5//2
2
>>>
This behavior will become the default with 3.0.
jab
John Bollinger, CFA, CMT
www.BollingerBands.com
If you advance far enough, you arrive at the beginning.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
|
