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