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

Re: Plans for gnuplot version 5 [integer division]

[<pl...@pi...>]

On 04/18/14 08:19, sfeam wrote:
> - Most people don't have their keyboard set up to type ➗ easily.
>
> 	Ethan

Any my default character set does not even display it ! Looks like a 
rectangle of grey spots.

While I too would prefer a Pascal like 'div' as a separate operator ( in 
fact Pascal's strong variable typing makes it one of the fastest 
languages to write and debug reliable code , but I digress ),  changing 
the usual fp division to anything other than slash is likely to cause 
more confusion than anything else.


 > - The same people who didn't understand why 10/4 == 2 won't
 >   understand when/why they need to use a different operator.

The people who do not understand *don't need* a new operator. ;)

I really don't see the need for anything more complex than the use of 
slash as always f.p. division  and int() where int.div. is required.

Someone may like to scratch their head about byte counting how 
inefficient it is to do an fp div then a fn call but, as I said before, 
in the sea of f.p. needed by 'plot' I'm not sure there is a strong 
argument for a separate operator. (Not that I see any objection to a new 
op for integer. div.).


Peter.

Re: Plans for gnuplot version 5 [integer division]

[Hans-Bernhard B. <HBB...@t-...>]

On 18.04.2014 03:25, Philipp K. Janert wrote:

> 1) how much of a problem is this (really)?

> Regarding 1), I can offer this as "hard" data: on my
> public gnuplot forum (over at Manning), there have
> been 166 user questions over the last few years, and
> as far as I recall, this issue has NOT come up. (Not
> a huge data set to be sure, but it does not support
> an urgent need for action.)

I've been following the gnuplot newsgroup / mailing list, the
SourceForge issue trackers and forums over a much longer time than that.
  The issue does come up once in a blue moon, but not really very often.
  E.g. since 2003 there were about 5 threads on the user mailing list, 4
entries to the bug tracker, and one entry as a feature request.  That's
not really a lot, given the mailing list alone had about 7600 messages
over that time.  In other words, this issue appears to cause on the
order of 0.1 percent of the traffic.

OTOH, the surprise caused by integers dividing like integers _is_
covered by the FAQ.  So people who actually look at documentation before
complaining about purportedly buggy programs will find it there, and
we'll never hear about their being surprised.

But overall, I'd call that enough of a non-issue that it really isn't
worth breaking compatibility for it.

> Personally, it does bite me occasionally, and like
> Peter, by habit I always append a dot to denominators,
> and I'd be happy if I didn't have to do that anymore.

Division isn't all there is to this.  We do make the distinction between
ints, strings, and complex-floats, and we do so in
a good deal more places than just division: the '%' operator being the
most obvious other one.  Then there's binary and boolean operators,
shifts and alls that.  Even '**' special-cases for integer arguments.

With all that happening, looking at integer division as if it were an
isolated decision for us to make, doesn't do it justice, because it's
not.  IMHO, as long as we support integers as a separate data type,
there _has_ to be proper integer division, too.  gnuplot's arithmetic is
entirely based on that of C, and it's said so on the tin since basically
day 1.  If we dropped integer division, that promise would fly out the
window, too.

Actually, I'd even say that having to think about integer division is a
useful way of reminding users (including ourselves) that integers do,
indeed, exist in this language.

And FWIW I completely reject that notion that just because Python or
some other language do something, we ought to do so, too.  If all
languages were compelled to behave the same way, what could possibly be
the point of having more than one in the first place?

Re: [integer division]

[Karl-Friedrich R. <mai...@gm...>]

As gnuplot is not a programming language, i think changing the
integer division behaviour is well permissible for a major version.
And for those who, like myself, misuse gp for general data
evaluation and programming, i´d just say "Suck it up!" ;-)

One should however set up a few extra warnings (probably in the gp
startup messages?), so everybody will catch up on it.


I would like to have an explicit integer division symbol, like e.g.
pascal "div". It´d be faster, could be overloaded to also accept a
real divided/divisor, and just be syntactically clear.

(btw., would it be possible to overload modulo "%" to also accept
reals?)


>>> I wonder if it is worth putting in special
>>> code to detect division of two integer constants, and warn once per
>>> session. (every evaluation would obviously be too often)
> 
> I like this idea if we choose not to auto-promote.
> 
> For those already aware, the warning would get annoying. There should
> be a way to suppress the warning (by using int()?), and for that matter
> probably a way to suppress all warnings.
> 

The problem then persist: Most everybody sometimes forgets the dot
after a number that is supposed to be a real, and then spends half
an hour searching for the bug.


  Karl

Re: Plans for gnuplot version 5 [integer division]

[<pl...@pi...>]

On 04/17/14 22:29, Tait wrote:
> * It's not even true that gnuplot's mannerisms mirror C. C is a
> statically-typed language. Variables and arguments have a known and
> unchanging type at the time of their declaration. Gnuplot has no such
> facilities; types are undeclared and inferred dynamically, which is
> all the more reason to expect dynamic, rather than static, typing
> behaviors throughout.


Indeed, I was going to reply in a similar vein yesterday but did not 
have time.

The problem is that gnuplot us a fuzzy typed language, so it's 
inappropriate to say it follows C conventions.

Clearly having functions that can deliver different results *depending 
on the data* is a serious flaw.

The need for integer division is fairly marginal and is better treated 
with int() when required. There is an efficiency gain to int. dev. and 
in a language like C that is intended for writing operating systems 
every bit counts, but in the sea of fp calcs needed to plot a graph this 
is a bit irrelevant. (Even in the case of non FPU hardware like earlier 
ARM platforms.)


It seems it should either go one way or the other. Statically typed or 
full automatic promotion.

An unholy mix of the two leads to unacceptable ambiguities, like 
function results depending on the data.

Peter.

Re: Plans for gnuplot version 5 [integer division]

[sfeam <sf...@us...>]

On Thursday, 17 April 2014 09:50:14 PM Jonathan Thornburg wrote:
> 
> A different point:
> 
> I suggested reviving an old suggestion of Dave Denholm:
> 
> : Date: Thu, 05 Aug 2004 17:50:43 +0100
> : From: Dave Denholm <dde...@es...>
> : Reply-To: gnu...@li...
> : To: gnu...@li...
> : Subject: Re: [Gnuplot-bugs] Interpretation of commandline numbers
> :
> : I wonder if it is worth putting in special
> : code to detect division of two integer constants, and warn once per
> : session. (every evaluation would obviously be too often)
> 
> Ethan Merritt pointed out a difficulty with this:
> 
> > Limiting this to integer constants would be tricky.
> > By the time the evaluation code sees the division operation,
> > the two operands have already been evaluated. I don't think there
> > is any way to tell at that point whether these were "constants" or
> > "result of integer expression" or "extracted from a user variable".
> 
> Dave Denholm's original message went on to say:
> 
> : Just a quick scan over the action table after parsing, to detect the
> : sequence  (puchc int), (pushc int), div
> : 
> : gnuplot> show at x/3.0 + 10/3 
> : 
> :         push x
> :         pushc 3.0
> :         div
> :         pushc 10
> :         pushc 3
> :         div
> :         plus
> : 
> : 
> : Or even - when appending the 'div' action, peek back at the previous
> : two entries.

Ugh.  Seriously?   That amounts to examining every partial expression 
in the stack on the off chance that one of them matches a known pattern.
And it would still fail on the logically equivalent case
gnuplot> show at 10/(1+2) 
        pushc 10
        pushc 1
        pushc 2
        plus
        div

> : This isn't going to catch the sequence
> : 
> : x=13
> : print x/3
> : 
> : but it might stop the user scratching their head for too long if they
> : then resort to typing in things like print 13/3

Heh.  It would probably just add to any confusion.
"Given A=10; B=3;  Why does A/B  not equal 10/3?"

> Another alternative would be to warn the first time an integer division
> yields a result which
> (a) is not an integer or very close to an integer,
> 	[We could use the "set zero" value as a tolerance to
> 	define "very close to an integer", i.e.,
>   	  very_close_to_integer(x)
> 	      := ( abs(x-nearest_integer_to_x) <= tolerance*max(1,abs(x)) )
> 	(This definition is borrowed from APL; the "max(1,"
> 	is to properly handle values close to zero.)]
>     AND
> (b) is *not* immediately passed to floor(), ceil(), or int()
> 	[these seem to be the only builtin functions which
> 	convert a real number to an integer.]
> 
> Implementing (b) would require the division operator to look back down
> in the evaluation stack.  This is a kludge.  But it would warn on
>   x = 4
>   y = 5
>   print x/y
> 
> If we did such a warning then probably the warning should mention that
> taking int(), floor(), or ceil() of the integer-division-result would
> silence the warning.  And having a separate control to disable the
> warning altogether might also be useful.
> 
> 
> 
> But having said all this, my preference is to either
> (a) leave the current behavior unchanged, or
> (b) introduce a new global mode
>       set integer_division [ truncates | promotes ]

>From the perspective of designing a well-behaved syntax,
I'd rather introduce a new operator:
	10 / 4 = 2
    10 ➗ 4 = 2.5

Of course that has several serious downsides.
- The same people who didn't understand why 10/4 == 2 won't
  understand when/why they need to use a different operator.
- It would be more conventional to flip the meanings,
  since ➗ is normally taught in the context of integer arithmetic.
- Most people don't have their keyboard set up to type ➗ easily.

	Ethan

Re: Plans for gnuplot version 5 [integer division]

[Jonathan T. <jt...@as...>]

Tait wrote:
> I don't think most gnuplot users ...

I replied:
| The problem is that we don't have any *data* on what "most gnuplot
| users" expect, nor on "all the other tools they are familiar with".
| We only have conjecture.

Tait then asked:
> Indeed; I speak from my experience. Is your experience different?

Yes, my experience is different: all the gnuplot users I know come
from C/C++/Fortran backgrounds, where integer division truncates.
But I don't know the background of the "median gnuplot user".



A different point:

I suggested reviving an old suggestion of Dave Denholm:

: Date: Thu, 05 Aug 2004 17:50:43 +0100
: From: Dave Denholm <dde...@es...>
: Reply-To: gnu...@li...
: To: gnu...@li...
: Subject: Re: [Gnuplot-bugs] Interpretation of commandline numbers
:
: I wonder if it is worth putting in special
: code to detect division of two integer constants, and warn once per
: session. (every evaluation would obviously be too often)

Ethan Merritt pointed out a difficulty with this:

> Limiting this to integer constants would be tricky.
> By the time the evaluation code sees the division operation,
> the two operands have already been evaluated. I don't think there
> is any way to tell at that point whether these were "constants" or
> "result of integer expression" or "extracted from a user variable".

Dave Denholm's original message went on to say:

: Just a quick scan over the action table after parsing, to detect the
: sequence  (puchc int), (pushc int), div
: 
: gnuplot> show at x/3.0 + 10/3 
: 
:         push x
:         pushc 3.0
:         div
:         pushc 10
:         pushc 3
:         div
:         plus
: 
: 
: Or even - when appending the 'div' action, peek back at the previous
: two entries.
: 
: This isn't going to catch the sequence
: 
: x=13
: print x/3
: 
: but it might stop the user scratching their head for too long if they
: then resort to typing in things like
: 
:   print 13/3


Another alternative would be to warn the first time an integer division
yields a result which
(a) is not an integer or very close to an integer,
	[We could use the "set zero" value as a tolerance to
	define "very close to an integer", i.e.,
  	  very_close_to_integer(x)
	      := ( abs(x-nearest_integer_to_x) <= tolerance*max(1,abs(x)) )
	(This definition is borrowed from APL; the "max(1,"
	is to properly handle values close to zero.)]
    AND
(b) is *not* immediately passed to floor(), ceil(), or int()
	[these seem to be the only builtin functions which
	convert a real number to an integer.]

Implementing (b) would require the division operator to look back down
in the evaluation stack.  This is a kludge.  But it would warn on
  x = 4
  y = 5
  print x/y

If we did such a warning then probably the warning should mention that
taking int(), floor(), or ceil() of the integer-division-result would
silence the warning.  And having a separate control to disable the
warning altogether might also be useful.



But having said all this, my preference is to either
(a) leave the current behavior unchanged, or
(b) introduce a new global mode
      set integer_division [ truncates | promotes ]

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

Re: Plans for gnuplot version 5

[Philipp K. J. <ja...@ie...>]

> [shrug]
> Most of gnuplot's math syntax follows C, and the distinction between
> (int) and (float) also follows C. 
> I don't think that pulling in examples from python is relevant;
> languages all have their quirks and even a kitchen-sink tool like
> perl cannot simultaneous mimic all of them.
> 

I think this is the point: gnuplot does what C does.
10, even 5 years ago, this reasonably represented
users expectations.

I am willing to acknowledge that times have moved on.

Which brings us to two questions:
1) how much of a problem is this (really)?
2) how difficult would it be to change it (and what
   weird, unexpected fall-out might it cause)?

Regarding 1), I can offer this as "hard" data: on my 
public gnuplot forum (over at Manning), there have 
been 166 user questions over the last few years, and 
as far as I recall, this issue has NOT come up. (Not
a huge data set to be sure, but it does not support
an urgent need for action.)

Personally, it does bite me occasionally, and like
Peter, by habit I always append a dot to denominators,
and I'd be happy if I didn't have to do that anymore.
At the same time, I can think of far fewer situations, 
where I actually WANTED the integer arithmetic.

I have no way of assessing the effort (item 2). However,
speaking of Python again, I find it unsettling if a 
mature program changes some of its fundamental behavior
(as Python did/does). I am not convinced this issues is
urgent enough.

Best,

  Ph.

Re: Plans for gnuplot version 5 [integer division]

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

On Thursday, 17 April, 2014 23:36:13 Tait wrote:
 
> > This topic has been argued for a long time.  I think it might be useful
> > to revive an old suggestion from Dave Denholm:
> > 
> > > Date: Thu, 05 Aug 2004 17:50:43 +0100
> > > From: Dave Denholm <dde...@es...>
> > > 
> > > I wonder if it is worth putting in special
> > > code to detect division of two integer constants, and warn once per
> > > session. (every evaluation would obviously be too often)

Limiting this to integer constants would be tricky.
By the time the evaluation code sees the division operation,
the two operands have already been evaluated. I don't think there
is any way to tell at that point whether these were "constants" or
"result of integer expression" or "extracted from a user variable".

 
> I like this idea if we choose not to auto-promote.
> 
> For those already aware, the warning would get annoying. There should
> be a way to suppress the warning (by using int()?), and for that matter
> probably a way to suppress all warnings.

Re: Plans for gnuplot version 5 [integer division]

[Tait <gnu...@t4...>]

> > I don't think most gnuplot users ...
> 
> The problem is that we don't have any *data* on what "most gnuplot
> users" expect, nor on "all the other tools they are familiar with".
> We only have conjecture.

Indeed; I speak from my experience. Is your experience different?

> For some people "all the other tools" are software environments
> (e.g., C, C++, Java, Perl, Python, Fortran, Pascal, PL/I, ...) where
> integer division truncates.

C, C++, Java, Fortran, and Pascal are statically-typed languages where
the types of variables and inputs are fixed. I think it is natural in
such languages for operations on integers to produce integers, because
it's well-established whether an input is an integer or not, and what
type is the output.

Perl and Python are dynamic (like gnuplot) and do auto-promote.

PL/I, I'll have to plead ignorance about.

> This topic has been argued for a long time.  I think it might be useful
> to revive an old suggestion from Dave Denholm:
> 
> > Date: Thu, 05 Aug 2004 17:50:43 +0100
> > From: Dave Denholm <dde...@es...>
> > 
> > I wonder if it is worth putting in special
> > code to detect division of two integer constants, and warn once per
> > session. (every evaluation would obviously be too often)

I like this idea if we choose not to auto-promote.

For those already aware, the warning would get annoying. There should
be a way to suppress the warning (by using int()?), and for that matter
probably a way to suppress all warnings.

Re: Plans for gnuplot version 5 [integer division]

[Jonathan T. <jt...@as...>]

On Thu, Apr 17, 2014 at 08:29:56PM +0000, Tait wrote:
> The root question is, what do gnuplot's users expect?
[[...]]
> I don't think most gnuplot users are familiar with C, so while
> gnuplot's mannerisms mirror C*, that's meaningless to many users.
> Users expect division to promote-to-float as necessary because all the
> other tools they are familiar with do it that way, from their paper
> and pencil to their calculator to WolframAlpha to R.

The problem is that we don't have any *data* on what "most gnuplot
users" expect, nor on "all the other tools they are familiar with".
We only have conjecture.

For some people "all the other tools" are software environments
(e.g., C, C++, Java, Perl, Python, Fortran, Pascal, PL/I, ...) where
integer division truncates.  For some (other) people "all the other
tools" are software environments (e.g., APL, R, pocket calculators,
spreadsheets) where integer division promotes the arguments to float.
The problem is that we don't know the relative sizes of these different
sets of gnuplot users.  Nor do we know what fraction of them have
existing scripts which would break if we changed the default.



This topic has been argued for a long time.  I think it might be useful
to revive an old suggestion from Dave Denholm:

> Date: Thu, 05 Aug 2004 17:50:43 +0100
> From: Dave Denholm <dde...@es...>
> Reply-To: gnu...@li...
> To: gnu...@li...
> Subject: Re: [Gnuplot-bugs] Interpretation of commandline numbers
> 
> I wonder if it is worth putting in special
> code to detect division of two integer constants, and warn once per
> session. (every evaluation would obviously be too often)

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"

Re: Plans for gnuplot version 5 [integer division]

[Tait <gnu...@t4...>]

The root question is, what do gnuplot's users expect?

The example of Python just illustrates one point in the landscape of
tools that are used for data analysis, graphing, and numerical
computation. My sense is that Python is one of gnuplot's "peers" in
this respect, and probably among the most-frequently-used alternatives
to gnuplot.

I don't think most gnuplot users are familiar with C, so while
gnuplot's mannerisms mirror C*, that's meaningless to many users.
Users expect division to promote-to-float as necessary because all the
other tools they are familiar with do it that way, from their paper
and pencil to their calculator to WolframAlpha to R. If gnuplot were
were not an anomaly, there would be no surprise and confusion at its
current behavior, but there is.

If you don't agree with the users-expect argument, consider
consistency. Imagine you have:
  f(x) = (x/2)**2 - x + 3
The return value f(x) will be different depending on x's type. That
is not C-like (where functions can have only a single return type) and
it makes it difficult to work with f(x), because f(1) is different
from f(1.0). (To make f(x) predictable, one must use: f(x) =
(1.0*x/2)**2 - 1.0*x + 3.)

Currently, function inputs tend to be floats because $1,$2,... return
a float, but if gnuplot gains array support it will less commonly true
that inputs are already float and so predictability of function output
will become more important.

Further, gnuplot built-in functions don't exhibit this same ambiguity.
For example log10() returns a float, even when it could return an int:
log10(100) => 2.0; real() always returns float, even with int
arguments: real(1) => 1.0. Users might be misled into expecting the
same consistency from user-defined functions.



* It's not even true that gnuplot's mannerisms mirror C. C is a
statically-typed language. Variables and arguments have a known and
unchanging type at the time of their declaration. Gnuplot has no such
facilities; types are undeclared and inferred dynamically, which is
all the more reason to expect dynamic, rather than static, typing
behaviors throughout.

> [shrug]
> Most of gnuplot's math syntax follows C, and the distinction between
> (int) and (float) also follows C. 
> I don't think that pulling in examples from python is relevant;
> languages all have their quirks and even a kitchen-sink tool like
> perl cannot simultaneous mimic all of them.

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

On Thursday, 17 April, 2014 20:18:44 pl...@pi... wrote:
> On 04/17/14 19:40, Ethan A Merritt wrote:
> >
> > On Thursday, 17 April, 2014 18:39:50 pl...@pi... wrote:
> >> On 04/17/14 17:48, Philipp K. Janert wrote:
> >>> Fair enough.
> >>>
> >>> And I will admit that the 1/2==0 problem bites
> >>> me as well, occasionally.;-)
> >>>
> >>
> >> I too find this a pain. Sometimes I forget , especially when it is a
> >> variable that later is in denominator, since it's not immediately obvious.
> >>
> >> df=30
> >> ....
> >>
> >> fit f(x) datafile using 1:($2/df) via m,c
> >
> > Huh?
> >
> > $2 is always a float, so $2/df is also always a float.
> >
> > 	Ethan
> >
> >
> >
> 
> OK , so now I'm putting dots where I don't need to in order to try to 
> avoid writing integer divisions when I don't intend.
> 
> Underlines that this is confusing and a PITA.

[shrug]
Most of gnuplot's math syntax follows C, and the distinction between
(int) and (float) also follows C. 
I don't think that pulling in examples from python is relevant;
languages all have their quirks and even a kitchen-sink tool like
perl cannot simultaneous mimic all of them.

	Ethan

Re: Plans for gnuplot version 5

[<pl...@pi...>]

On 04/17/14 19:40, Ethan A Merritt wrote:
>
> On Thursday, 17 April, 2014 18:39:50 pl...@pi... wrote:
>> On 04/17/14 17:48, Philipp K. Janert wrote:
>>> Fair enough.
>>>
>>> And I will admit that the 1/2==0 problem bites
>>> me as well, occasionally.;-)
>>>
>>
>> I too find this a pain. Sometimes I forget , especially when it is a
>> variable that later is in denominator, since it's not immediately obvious.
>>
>> df=30
>> ....
>>
>> fit f(x) datafile using 1:($2/df) via m,c
>
> Huh?
>
> $2 is always a float, so $2/df is also always a float.
>
> 	Ethan
>
>
>

OK , so now I'm putting dots where I don't need to in order to try to 
avoid writing integer divisions when I don't intend.

Underlines that this is confusing and a PITA.

regard, Peter.

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

On Thursday, 17 April, 2014 18:39:50 pl...@pi... wrote:
> On 04/17/14 17:48, Philipp K. Janert wrote:
> > Fair enough.
> >
> > And I will admit that the 1/2==0 problem bites
> > me as well, occasionally.;-)
> >
> 
> I too find this a pain. Sometimes I forget , especially when it is a 
> variable that later is in denominator, since it's not immediately obvious.
> 
> df=30
> ....
> 
> fit f(x) datafile using 1:($2/df) via m,c

Huh?

$2 is always a float, so $2/df is also always a float.

	Ethan

Re: Plans for gnuplot version 5

[<pl...@pi...>]

On 04/17/14 17:48, Philipp K. Janert wrote:
> Fair enough.
>
> And I will admit that the 1/2==0 problem bites
> me as well, occasionally.;-)
>

I too find this a pain. Sometimes I forget , especially when it is a 
variable that later is in denominator, since it's not immediately obvious.

df=30
....

fit f(x) datafile using 1:($2/df) via m,c

Of course, as soon as you debug down to the line where it occurs you 
spot it. But it does waste time in debugging.


regards, Peter.

Re: Plans for gnuplot version 5

[Philipp K. J. <ja...@ie...>]

On Thu, 17 Apr 2014 05:49:05 +0000
Tait <gnu...@t4...> wrote:

> 
> Funny you should mention Python, because that was in fact going to be
> _my_ example. Python continues to grow in popularity, and despite
> earlier missteps, Python now treats "1/2" as 0.5, too. Python is also
> an example of a language that does infinite-precision math (and is
> surprisingly fast at it). The one remaining counter-example is that
> ruby still treats "1/2" as 0, which surprised me.

Fair enough.

And I will admit that the 1/2==0 problem bites
me as well, occasionally. ;-)

> 
> As for my inspiration for the suggestion, users wander in and ask for
> help with gnuplot several times a week. Of those, probably 40% are new
> users. Of those, probably 30% are confused by the integer division
> behavior. So the question gets asked -- usually in the form of why
> some polynomial function gives the wrong answer -- once or twice a
> week. That's obviously just anecdotal data, but if it's that
> confusing to that many people, even despite prominent documentation
> and FAQ on that exact issue, then it seemed like something worth
> changing. (For what it's worth, the other FAQ asked frequently enough
> to deserve such prominent display is the "x^2 isn't x squared" one.)
> 
> 
> > I would like to question the general statement
> > that "today's users don't understand integer
> > arithmetic no more". Can you support that claim?
> > 
> > As counter-example, consider Python (as a contemporary,
> > dynamically-typed language, popular with the current 
> > "data" crowd), which is similarly finicky about integers 
> > as gnuplot.
> 
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Plans for gnuplot version 5

[Tait <gnu...@t4...>]

Funny you should mention Python, because that was in fact going to be
_my_ example. Python continues to grow in popularity, and despite
earlier missteps, Python now treats "1/2" as 0.5, too. Python is also
an example of a language that does infinite-precision math (and is
surprisingly fast at it). The one remaining counter-example is that
ruby still treats "1/2" as 0, which surprised me.

As for my inspiration for the suggestion, users wander in and ask for
help with gnuplot several times a week. Of those, probably 40% are new
users. Of those, probably 30% are confused by the integer division
behavior. So the question gets asked -- usually in the form of why
some polynomial function gives the wrong answer -- once or twice a
week. That's obviously just anecdotal data, but if it's that
confusing to that many people, even despite prominent documentation
and FAQ on that exact issue, then it seemed like something worth
changing. (For what it's worth, the other FAQ asked frequently enough
to deserve such prominent display is the "x^2 isn't x squared" one.)


> I would like to question the general statement
> that "today's users don't understand integer
> arithmetic no more". Can you support that claim?
> 
> As counter-example, consider Python (as a contemporary,
> dynamically-typed language, popular with the current 
> "data" crowd), which is similarly finicky about integers 
> as gnuplot.

Re: Plans for gnuplot version 5

[Philipp K. J. <ja...@ie...>]

On Tue, 15 Apr 2014 20:20:27 +0000
Tait <gnu...@t4...> wrote:

> 
> This just occurred to me. One thing that hangs up more new users than
> anything else is that these days everyone assumes automatic promotion
> of numeric types. And to a lesser degree, on-demand infinite-precision
> math, but that's another topic. The question of why "1/2" is zero
> instead of a half misleads more than a few users into believing that
> gnuplot is fundamentally broken. They don't know or understand the
> underlying data types or their limitations, so these seem like arcane
> gotchas when everything else they've ever used does the promotion
> transparently.

I would like to question the general statement
that "today's users don't understand integer
arithmetic no more". Can you support that claim?

As counter-example, consider Python (as a contemporary,
dynamically-typed language, popular with the current 
"data" crowd), which is similarly finicky about integers 
as gnuplot.

I am not (at this point) arguing for or against making
a change (in fact, I frequently find gnuplot's 1/2 == 0 
behavior rather annoying), but I want to make sure that
there is good reason/evidence that would demand such a
fundamental change.

> 
> I don't think we're supporting any systems or OSes without an FPU
> anymore, right? And memory or CPU are not nearly the limitations they
> once were (at that level). Maybe v5 is the time gnuplot should stop
> treating integer-looking numbers like integers unless requested
> explicitly via int()?
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Plans for gnuplot version 5

[<pl...@pi...>]

On 04/15/14 22:24, Marek Peca wrote:
>
>> I don't think we're supporting any systems or OSes without an FPU
>> anymore, right? And memory or CPU are not nearly the limitations they
>> once were (at that level). Maybe v5 is the time gnuplot should stop
>> treating integer-looking numbers like integers unless requested
>> explicitly via int()?
>
> Well, have you just offered breaking the behaviour for all the existing
> scripts, which may rely on the default integer treatment?
>
> Maybe it could be changed, but in this case, I'd strongly vote for
> at least maintaining a compatibility flag (cmdline arg, setting variable).
> Still, I am afraid it can make some harm.
>
> Regards,
> Marek
>

Hi

Clearly this will be a major compatibility issue , which is why it is 
being brought up in relation to v5 when this requirement is being 
relaxed to allow worthwhile changes that would otherwise be forbidden by 
the usual strict compatibility policy.

Coming from a background of strong typed languages I do find this rather 
fuzzy typing particularly infuriating.

I can't really think of a context in which there is a use for integer 
arithmetic other than the integer division which would be much clearer 
if it was coded with int() , anyway.

There must be a lot of users who don't even know what integer arithmetic 
is about these days. Should they really have to learn to be able to use 
gnuplot ?

It does seem rather arcane and of no real benefit. Maybe this is a good 
to get rid of it.

I use gnuplot on embedded ARM platforms that do not have an FPU and have 
to use inefficient software emulation of floating point. In view of the 
volume of fp involved in producing a plot, i don't think the odd int 
division would matter. However, it could conceivable be an argument for 
some of these platforms in other cases than my own.

Obviously a compiler compatibility switch would be a good idea for those 
who have considerable investment in gnuplot scripts that they do not 
wish to rewrite and re-debug.

Generally, I think removing integer division is a good proposition.

regards, Peter.

Re: Plans for gnuplot version 5

[Marek P. <ma...@du...>]

> I don't think we're supporting any systems or OSes without an FPU
> anymore, right? And memory or CPU are not nearly the limitations they
> once were (at that level). Maybe v5 is the time gnuplot should stop
> treating integer-looking numbers like integers unless requested
> explicitly via int()?

Well, have you just offered breaking the behaviour for all the existing 
scripts, which may rely on the default integer treatment?

Maybe it could be changed, but in this case, I'd strongly vote for
at least maintaining a compatibility flag (cmdline arg, setting variable). 
Still, I am afraid it can make some harm.

Regards,
Marek

Re: Plans for gnuplot version 5

[Tait <gnu...@t4...>]

This just occurred to me. One thing that hangs up more new users than
anything else is that these days everyone assumes automatic promotion
of numeric types. And to a lesser degree, on-demand infinite-precision
math, but that's another topic. The question of why "1/2" is zero
instead of a half misleads more than a few users into believing that
gnuplot is fundamentally broken. They don't know or understand the
underlying data types or their limitations, so these seem like arcane
gotchas when everything else they've ever used does the promotion
transparently.

I don't think we're supporting any systems or OSes without an FPU
anymore, right? And memory or CPU are not nearly the limitations they
once were (at that level). Maybe v5 is the time gnuplot should stop
treating integer-looking numbers like integers unless requested
explicitly via int()?

execute gnuplot from install directory for MinGW 64 bit build

[Tatsuro M. <tma...@ya...>]

I have tried to build gnuplot of vs source using gcc 4.8.2 from MinGW-w64 (64bit SEH).

Help file problem is overcome according the information by 
http://gnuplot.10905.n7.nabble.com/gnuplot-on-64-bit-Windows-again-td17580.html 

Here I write in more detail

1.Seaech hhctrl.ocx from the computer.
2.Using pexports (available from MinGW site), make def file,
 pexports hhctrl.ocx > hhctrl.def
3. Generate dll.a using dlltool
 dlltool -l hhctrl.dll.a -d hhctrl.def hhctrl.ocx
4. Change LDLIBS  in config/mingw/Makefile for example
 LDLIBS += /c/PROGRA~2/HELPWO~1/lib/hhctrl.dll.a 

*******************************************
I could execute gnuplot and wgnuplot on build directory ( config/mingw)
However, I cannot execute them because of Application Error. (0xc000007b).

If somebody knows the way to overcome this issue, please let me know.

Regards

Tatsuro

Re: Qt window placement

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

On 04/03/2014 04:37 PM, Ethan A Merritt wrote:
> On Thursday, 03 April, 2014 22:00:37 Allin Cottrell wrote:
>> On Thu, 3 Apr 2014, Ethan A Merritt wrote:
>>
>>> At some point between 4.6 and current CVS, the initial placement of
>>> Qt plot windows has changed.
>>>
>>> It used to be that the Qt plot window would open nicely in some unoccupied
>>> part of the screen, probably because that is how I set the window manager
>>> policy.
>>>
>>> Now it always opens in the center of the screen, which is probably the
>>> worst possible place.  Changing the window manager placement policy
>>> has no effect.
>>>
>>> How can we restore the previous behaviour?
>>
>> For the few months I've been running Arch linux, using whichever gnuplot
>> 4.6 variant was current in the Arch repositories (right now, 4.6.5). The
>> Qt terminal is apparently the default on Arch (maybe not unconditionally,
>> but seems to be the case if the Qt libraries are installed; I have Qt
>> 4.8.5).
>>
>> On that basis I'm afraid I can't agree that the gnuplot 4.6 behavior is to
>> "open [Qt windows] nicely in some unoccupied part of the screen". On my
>> system the Qt gnuplot windows open partially off-screen: I have to move
>> them inboard to see the whole plot. I'm not sure whether opening in the
>> center of the screen would be better or worse!
>
> Somewhat tangential since I'd still like to know what changed...
>
> Mojca has requested, and I very much agree, that when you manually
> adjust the plot window size it should be saved and reused when you next
> open a plot window.  Alternatively there could be an explicit
> "save current window geometry" in the tools widget.
>
> I am told this is unreasonably hard in Qt, but even so that is what I would like
> to have.

I put a patch that retains size and location here:

https://sourceforge.net/p/gnuplot/patches/663/

and Jérôme has upgraded the patch.  There are still some inconsistencies 
in the patch that need to be resolved (see comments...probably needs to 
be raised on discussion list), but I think both of us might be too busy 
at the moment.  Feedback is welcome though.

As for placement, if there is something in the code that is forcing the 
QWindow to be centered, then that could be removed.  Otherwise, it seems 
inherent in desktop management that the Window not have much control 
over position.  The only way would be to get information from the 
desktop somehow about what is occupying the screen... actually, I just 
found this:

https://qt-project.org/doc/qt-4.7/qdesktopwidget.html

so maybe there is more access to info than we believe.

Dan

Re: Qt window placement

[Ethan A M. <sf...@us...>]

On Thursday, 03 April, 2014 22:00:37 Allin Cottrell wrote:
> On Thu, 3 Apr 2014, Ethan A Merritt wrote:
> 
> > At some point between 4.6 and current CVS, the initial placement of
> > Qt plot windows has changed.
> >
> > It used to be that the Qt plot window would open nicely in some unoccupied
> > part of the screen, probably because that is how I set the window manager
> > policy.
> >
> > Now it always opens in the center of the screen, which is probably the
> > worst possible place.  Changing the window manager placement policy
> > has no effect.
> >
> > How can we restore the previous behaviour?
> 
> For the few months I've been running Arch linux, using whichever gnuplot 
> 4.6 variant was current in the Arch repositories (right now, 4.6.5). The 
> Qt terminal is apparently the default on Arch (maybe not unconditionally, 
> but seems to be the case if the Qt libraries are installed; I have Qt 
> 4.8.5).
> 
> On that basis I'm afraid I can't agree that the gnuplot 4.6 behavior is to 
> "open [Qt windows] nicely in some unoccupied part of the screen". On my 
> system the Qt gnuplot windows open partially off-screen: I have to move 
> them inboard to see the whole plot. I'm not sure whether opening in the 
> center of the screen would be better or worse!

Somewhat tangential since I'd still like to know what changed...

Mojca has requested, and I very much agree, that when you manually
adjust the plot window size it should be saved and reused when you next
open a plot window.  Alternatively there could be an explicit
"save current window geometry" in the tools widget.

I am told this is unreasonably hard in Qt, but even so that is what I would like
to have.

	Ethan

Re: Qt window placement

[Allin C. <cot...@wf...>]

On Thu, 3 Apr 2014, Ethan A Merritt wrote:

> At some point between 4.6 and current CVS, the initial placement of
> Qt plot windows has changed.
>
> It used to be that the Qt plot window would open nicely in some unoccupied
> part of the screen, probably because that is how I set the window manager
> policy.
>
> Now it always opens in the center of the screen, which is probably the
> worst possible place.  Changing the window manager placement policy
> has no effect.
>
> How can we restore the previous behaviour?

For the few months I've been running Arch linux, using whichever gnuplot 
4.6 variant was current in the Arch repositories (right now, 4.6.5). The 
Qt terminal is apparently the default on Arch (maybe not unconditionally, 
but seems to be the case if the Qt libraries are installed; I have Qt 
4.8.5).

On that basis I'm afraid I can't agree that the gnuplot 4.6 behavior is to 
"open [Qt windows] nicely in some unoccupied part of the screen". On my 
system the Qt gnuplot windows open partially off-screen: I have to move 
them inboard to see the whole plot. I'm not sure whether opening in the 
center of the screen would be better or worse!

--
Allin Cottrell
Department of Economics
Wake Forest University, NC