From: <pentek_i@in...>  20050922 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 EMail: pentek_i@... 
From: Robert Hart <enxrah@no...>  20050923 09:14:34

On Thu, 20050922 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 <enxrah@...> 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 Imre Geza <pentek_i@in...>  20050923 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 computerexecuted math, but instead I think about mathematical operation, and should work anyways.  Üdvözlettel: Ifj. Péntek Imre EMail: pentek_i@... 
From: HansBernhard Broeker <broeker@ph...>  20050923 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 Imre Geza <pentek_i@in...>  20050923 11:18:37

On Fri, 23 Sep 2005 11:53:24 +0200, HansBernhard 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 computerexecuted mathematical computations, but thinking about mathematical operation. the two of the above ones should be equivalent.  Üdvözlettel: Ifj. Péntek Imre EMail: pentek_i@... 
From: HansBernhard Broeker <broeker@ph...>  20050923 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 computerexecuted > mathematical computations, but thinking about mathematical operation. Well, you don't have a computer with a mindreading 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 Hart <enxrah@no...>  20050923 13:12:51

On Fri, 20050923 at 14:57 +0200, HansBernhard Broeker wrote: > Well, you don't have a computer with a mindreading 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 reallife case where integer maths is the "correct" way of doing a calculation *and* explicitly using the int() function would not be appropriate?  Robert Hart <enxrah@...> 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 Hart <enxrah@no...>  20050923 14:20:16

On Fri, 20050923 at 15:48 +0200, HansBernhard Broeker wrote: > Yes, and I will until the day the first DIWM (for "dowhatImean") > 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 reallife 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 counterintuitive 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 <enxrah@...> 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 Merritt <merritt@u.washington.edu>  20050923 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@... Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 
From: Juergen Wieferink <wieferink@fr...>  20050923 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 Hart <enxrah@no...>  20050924 12:57:09

On Fri, 20050923 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 <enxrah@...> 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 Mikulik <mikulik@ph...>  20050923 14:34:16

> Other counterintuitive 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 Hart <enxrah@no...>  20050923 14:59:35

On Fri, 20050923 at 16:33 +0200, Petr Mikulik wrote: > > Other counterintuitive 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 <enxrah@...> 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 Lankinen <aapo.lankinen@gm...>  20050923 15:39:11

On Fri, 20050923 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 Wieferink <wieferink@fr...>  20050923 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: Varoquaux <gael.varoquaux@no...>  20050924 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 Harders <h.harders@tu...>  20050924 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.harders@... http://www.haraldharders.de 
From: BBands <bbands@ya...>  20050927 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 dynamicallytyped languagesPython, Perl, Tcl, Ruby, PHP... In such cases unexpected results can arise as a result of integer division being the default. Perhaps adopting a Pythonlike approach (// for integer division) initially driven by a switch (set division trueinteger) and eventually defaulting to true might help. Best regards, jab John Bollinger, CFA, CMT http://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 Mikulik <mikulik@ph...>  20050927 14:50:18

> One factor you might want to consider in this regard > is the increasing use of gnuplot driven by scripts of > dynamicallytyped languagesPython, Perl, Tcl, Ruby, > PHP... In such cases unexpected results can arise as a > result of integer division being the default. Perhaps > adopting a Pythonlike approach (// for integer > division) initially driven by a switch (set division > trueinteger) 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 Wieferink <wieferink@fr...>  20050927 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 <bbands@ya...>  20050927 15:05:57

 Petr Mikulik <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 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 http://www.BollingerBands.com If you advance far enough, you arrive at the beginning. __________________________________ Yahoo! Mail  PC Magazine Editors' Choice 2005 http://mail.yahoo.com 