Menu
▾
▴
gnuplot-beta
|
From: Juhász P. <pet...@gm...> - 2014-03-07 19:29:03
|
On Thu, 2014-03-06 at 13:52 -0800, Ethan A Merritt wrote: > On Thursday, 06 March, 2014 21:31:00 Juhász Péter wrote: > > On Wed, 2014-03-05 at 15:02 -0800, Ethan A Merritt wrote: > > > > > Also, may ask what is your proposed timeline for 5.0? > > > > > > That's what I'm trying to determine. > > > > OK, I rephrase the question: what's your latest preferred date for the > > final release? End of this year perhaps? > > I think it would be beneficial if you set a tentative date because then > > potential contributors would be able to gauge whether their proposed new > > features are plausible within that timeframe. > > > > Peter > > Remember that new features per se do not have to go in before version 5, > only features that would be incompatible with past syntax or data formats. > > If the list of "must change" items is empty, then I propose to put out > an rc1 snapshot by the end of March. > > If the list is non-empty, the rc1 snapshot would go out as soon as the > list is clear again. > > I expect there will be an rc2 either very soon after that if some major > but fixable defect is spotted (this has happened before) otherwise > after 3 months or so of testing and hopefully feedback. > > My crystal ball is hazy about where that puts the final release. > I hope well before the end of the year. > [...snip explanation about translation of strings...] > > Ethan > Thanks for the detailed and clear answer. There is one more point I'd like to raise: there have been much talk about new features and small, incompatible changes, but perhaps a new major release would be a good time to look at the state of the program from a different perspective: find and fix longstanding bugs, go through the featureset and check for inconsistencies and irregularities, check code quality and refactor where needed. Of course I'm aware that you and others have been doing such work, and it is much appreciated. But perhaps in anticipation of the new release, it would be better to focus effort on tasks of these nature, even at the expense of new features. One might argue that gnuplot has enough features as it is. Peter |
|
From: Ethan A M. <sf...@us...> - 2014-03-07 19:42:06
|
On Friday, 07 March, 2014 20:28:53 Juhász Péter wrote: > There is one more point I'd like to raise: > there have been much talk about new features and small, incompatible > changes, but perhaps a new major release would be a good time to look at > the state of the program from a different perspective: find and fix > longstanding bugs, go through the featureset and check for > inconsistencies and irregularities, check code quality and refactor > where needed. That's pretty vague. Do you have specific things in mind? I would love to rip out and replace all the log-scaling code, but that's more work than I have time for in the forseeable future. Unless someone wants to tackle it, I don't see a feasible way to do this for version 5. Ethan |
|
From: Juhász P. <pet...@gm...> - 2014-03-07 21:53:28
|
On Fri, 2014-03-07 at 11:40 -0800, Ethan A Merritt wrote: > On Friday, 07 March, 2014 20:28:53 Juhász Péter wrote: > > There is one more point I'd like to raise: > > there have been much talk about new features and small, incompatible > > changes, but perhaps a new major release would be a good time to look at > > the state of the program from a different perspective: find and fix > > longstanding bugs, go through the featureset and check for > > inconsistencies and irregularities, check code quality and refactor > > where needed. > > That's pretty vague. Do you have specific things in mind? > The patch for translated messages offers a good case study. The functionality would be good to have, but the changes associated with it look like unfeasibly large because the code is not organized right for it. Strings that are part of user messages are all over the place, spread over several files, embedded in ad-hoc parsing code. If they were already concentrated, it would be easier to localize them. As for areas for refactoring: there is datafile.c with its convoluted code paths that nobody dares to touch in fear of breaking it; much of the axis-related code, too complicated and full of hard-coded special cases like the log-scaling you've mentioned; then there is some duplicate code in the 2d and 3d plotting code paths... There are too many terminal types, many of them ancient, not really used and tested anymore, each supporting different features, having different defaults. Against all these there is the time-honored principle of not trying to fix that ain't broken. That and the fact that all contributors to the project are volunteers, sacrificing their own free time. I can accept a decision that attacking any of the problems outlined above is not feasible given the constraints of time and manpower, I just wanted to start a discussion on them, to get these issues out in the open. Peter |
|
From: Jon G. <jo...@th...> - 2014-03-07 22:44:07
|
> As for areas for refactoring: Not sure how much has changed in the image mode handling code recently, but I keep running into issues with image mode. In particular: - Visible pixel grid has a scan line longer than previous scan lines. - Number of pixels cannot be factored into integers matching grid. N = ... K = ... Improving the robustness of the image handling code would certainly be a welcome change, even if the input syntax for images would have to change (not sure that it would need to though, as "failsafe" is usually enough fix the problem). |
|
From: Daniel J S. <dan...@ie...> - 2014-03-08 08:26:53
|
On 03/07/2014 04:43 PM, Jon Gjengset wrote: >> As for areas for refactoring: > > Not sure how much has changed in the image mode handling code recently, > but I keep running into issues with image mode. In particular: > > - Visible pixel grid has a scan line longer than previous scan lines. > - Number of pixels cannot be factored into integers matching grid. N = ... K = ... > > Improving the robustness of the image handling code would certainly be a > welcome change, even if the input syntax for images would have to change > (not sure that it would need to though, as "failsafe" is usually enough > fix the problem). I'm open to the idea. Ethan and I agreed on a message in the configure indicating that image scripts were experimental. Not sure why it is no longer robust...used to be, albeit finicky syntax. The big challenge was compatibility with the existing gnuplot binary and the df_readline() routine. That really put things in a bind, partly because the gnuplot binary was so basic that it became restrictive to work around it. Someone mentioned reviewing code quality. There are many things that could be done better. Organization of the main plotting routines for more clarity would be a good start. A way to re-read data for individual plots. Remove all global variables (almost had all of them at one point, but more keep finding their way in). The date code, but that one's not for mortals. Many more. But I think before embarking on this, it takes some good planning. Dan |
|
From: Tait <gnu...@t4...> - 2014-03-07 11:06:18
|
> > Currently (version 4) you can plot with RGB colors by saying, for instance
> > plot ... using 1:2:3 linecolor rgb variable
> > where input column 3 contains 24-bit RGB values.
> > Bits 25-32 are ignored, and the lines are all solid color.
>
> Ah, I see, I was thinking of literal RGB values (#AARRGGBB), not their
> binary representation. Hence also my reference to what seems to be
> "common".
>
> > Are you suggesting that any command using the keyword "rgb" should
> > ignore the high bits?
> > I.e. that a new keyword rgba or argb should be introduced everywhere?
> > And than what - the program would invert the high byte during input?
>
> Yes, that seems like a sensible approach to me. Particularly so because
> it will never surprise a user who is expecting RGB, but suddenly gets
> RGBA. In fact, even if you don't invert the high bytes, I think the
> choice to use an alpha channel should be explicit.
There does seem to be a problem with any approach involving using the
alpha channel:
gnuplot> rgba(a,r,g,b)=(a*2**24) | (r*2**16) | (g*2**8) | b
# having << and >> operators here would be nice
gnuplot> print rgba(0,0,0,0)
0
gnuplot> print rgba(0x88,0,0,0)
non-integer passed to boolean operator
gnuplot> print rgba(0x78,0,0,0)
2025521152
The problem, of course, is that gnuplot doesn't have an unsigned
integer data type. The "non-integer" error can be avoided by using +
instead of |, but then the number is promoted to float and it cannot
be used as intended in the plot command like
gnuplot> plot x lw 5 lc rgbcolor rgba(0x88,0x22,0x55,0x88), -x lw 5 lc rgbcolor rgba(0x88,0xBB,0x77,0x33)
Even defining the function as
gnuplot> rgba(a,r,g,b)=int((a*2**24) + (r*2**16) + (g*2**8) + b)
doesnt seem to work right when it comes to the plot command.
(And if I may toss in my 2p, my intuitive expectation is that 0 means transparent, and 1 or 255 or however it ends up means opaque. I think this means a new keyword like rgbacolor or argbcolor makes the most sense.)
|
|
From: <pl...@pi...> - 2014-03-07 12:53:41
|
On 03/07/14 12:06, Tait wrote: > a new keyword like rgbacolor or argbcolor makes the most sense.) That seems a very good idea but I suspect there are situations where colours are defined outside of an explicit declaration, like that. /Peter |
|
From: Ethan A M. <sf...@us...> - 2014-03-07 20:08:45
|
On Friday, 07 March, 2014 11:06:10 Tait wrote:
> There does seem to be a problem with any approach involving using the
> alpha channel:
> gnuplot> rgba(a,r,g,b)=(a*2**24) | (r*2**16) | (g*2**8) | b
> # having << and >> operators here would be nice
I have wanted that myself more than once.
Please file a Feature Request.
I'm not sure whether the current SourceForge infrastructure allows it,
but if possibleI will attach a "Version 5 target" flag to the relevant
Bugs, Feature Requests, and Patches on the tracker.
> gnuplot> print rgba(0,0,0,0)
> 0
> gnuplot> print rgba(0x88,0,0,0)
> non-integer passed to boolean operator
> gnuplot> print rgba(0x78,0,0,0)
> 2025521152
>
> The problem, of course, is that gnuplot doesn't have an unsigned
> integer data type. The "non-integer" error can be avoided by using +
> instead of |, but then the number is promoted to float and it cannot
> be used as intended in the plot command like
> gnuplot> plot x lw 5 lc rgbcolor rgba(0x88,0x22,0x55,0x88), -x lw 5 lc rgbcolor rgba(0x88,0xBB,0x77,0x33)
>
> Even defining the function as
> gnuplot> rgba(a,r,g,b)=int((a*2**24) + (r*2**16) + (g*2**8) + b)
> doesnt seem to work right when it comes to the plot command.
Here is one way to do it. This may not cover all the desired cases:
gnuplot> argb(a,r,g,b) = sprintf("0x%.2x%.2x%.2x%.2x",a,r,g,b)
gnuplot> print argb(0x78,0,0,0)
0x78000000
gnuplot> print argb(0xff, 0, 255, 127.0)
0xff00ff7f
Yes that produces a string rather than an integer, but the plotting commands
are happy to take the string.
Although the string can evaluate to a negative value when converted by int(),
the color handling code knows to treat it as unsigned.
Using it for arithmetic might fail, but any numeric operation that is sensitive to
the signed/unsigned distinction is probably a dubious thing to apply to colors.
Ethan
|
|
From: Ethan A M. <sf...@us...> - 2014-03-07 20:24:41
|
On Friday, 07 March, 2014 12:05:27 Ethan A Merritt wrote:
> ere is one way to do it. This may not cover all the desired cases:
>
> gnuplot> argb(a,r,g,b) = sprintf("0x%.2x%.2x%.2x%.2x",a,r,g,b)
> gnuplot> print argb(0x78,0,0,0)
> 0x78000000
> gnuplot> print argb(0xff, 0, 255, 127.0)
> 0xff00ff7f
>
> Yes that produces a string rather than an integer, but the plotting commands
> are happy to take the string.
Correction. If you want to pass that directly to a plot command you
currently need to modify it to
gnuplot> argb(a,r,g,b) = sprintf("#%.2x%.2x%.2x%.2x",a,r,g,b)
The first form generates a valid hexadecimal constant but the
color code will only parse it that way if passed as a bare integer,
not in a string constant. So this works:
plot x lc rgb 0xff00ff7f
But this doesn't
plot x lc rgb "0xff00ff7f"
That's fixable.
Ethan
|
|
From: <pl...@pi...> - 2014-03-08 08:58:35
|
On 03/07/14 21:23, Ethan A Merritt wrote:
> On Friday, 07 March, 2014 12:05:27 Ethan A Merritt wrote:
>> ere is one way to do it. This may not cover all the desired cases:
>>
>> gnuplot> argb(a,r,g,b) = sprintf("0x%.2x%.2x%.2x%.2x",a,r,g,b)
>> gnuplot> print argb(0x78,0,0,0)
>> 0x78000000
>> gnuplot> print argb(0xff, 0, 255, 127.0)
>> 0xff00ff7f
>>
>> Yes that produces a string rather than an integer, but the plotting commands
>> are happy to take the string.
>
>
> Correction. If you want to pass that directly to a plot command you
> currently need to modify it to
>
> gnuplot> argb(a,r,g,b) = sprintf("#%.2x%.2x%.2x%.2x",a,r,g,b)
>
> The first form generates a valid hexadecimal constant but the
> color code will only parse it that way if passed as a bare integer,
> not in a string constant. So this works:
> plot x lc rgb 0xff00ff7f
> But this doesn't
> plot x lc rgb "0xff00ff7f"
>
> That's fixable.
>
> Ethan
>
>
Ethan, this touches on something that I often get hit with when trying
to generalise to plot some kind of iteration. The problem is how to
compose a filename, line type specifier, label id or some such element
composed from the an iteration variable and/or gnuplot constants.
Often it will involve string concatenation or a sprintf() result but as
we see here, a string result may not be acceptable to the parser.
Now you could tweak the code to accept both integer and string , which
seems to be what you mean by "That's fixable." However, wouldn't it be
a much more far reaching fix to have some kind of typecasting ability?
The fundamental problem here is automatic type magic does not always
give the desired or required variable type and the parser spits it out.
Indeed it's often pretty difficult for someone to does not have a
detailed knowledge of the code to determine what the type of the result
is going to be.
Type-casting is the classic solution to that kind of problem and
presumably would not be that difficult of disruptive to introduce.
In that context this may not be v5 issue, but I'll let you judge the
implications.
/Peter.
|
|
From: Jonathan T. <jt...@as...> - 2014-03-07 20:50:47
|
On Tue, Mar 04, 2014 at 08:51:32PM -0800, sfeam wrote:
> This is a reminder that a first release candidate for gnuplot version 5
> is planned for later this year. In preparation for that I will bump the
> version information in the current development source tree to 5.0.alpha.
[[...]]
>
> Important note: If there is some behaviour or syntax in gnuplot
> that has been annoying you for the last 20 years, please speak up.
> This is the best chance you will have to get it changed!
Ok, here's my candidate for #1 gnuplot annoyance:
Suppose I have a gnuplot script which sets up a bunch of functions,
computes some stuff, and eventually does a plot. For nontrivial plots
this means that I have many continuation lines ("backslash at the end
of the line") in the 'plot' command. The problem is, if I have a
syntax error anywhere in the plot command, the error will be reported
with the line number of the *last* continuation line.
For example, what happens if I put an extra comma into this plot command:
plot sigmoid(A,B,C,D, P) \
title 'sigmoid fit' \
with lines linetype 1 linecolor -1, \
\
0.327 \
title 'Zero OD 0.327 & 0.309' \
axis x1y2 \
with lines linetype 2 linecolor 3, \
0.309 \
notitle \
axis x1y2 \
with lines linetype 2 linecolor 3, \
\
range20 \
title '20% & 80% yrange of sigmoid' \
axis x1y1 \
with lines linetype 1 linecolor 4, \
range80 \
notitle \
axis x1y1 \
with lines linetype 1 linecolor 4, \
\
range10 \
title '10% & 90% yrange of sigmoid' \
axis x1y1 \
with lines linetype 1 linecolor 5, \
range90 \
notitle \
axis x1y1 \
with lines linetype 1 linecolor 5, \
\
\
'plate-G25-standards.dat' \
title 'standards' \
axis x1y2 \
with points pointtype 7 pointsize 0.5 linecolor -1,, \
\
'plate-G25-QC-high.dat' \
title 'QC high (100)' \
axis x1y2 \
with points pointtype 1 pointsize 0.750 linecolor rgb "#00A000",\
\
'plate-G25-QC-low.dat' \
title 'QC low (12.5)' \
axis x1y2 \
with points pointtype 1 pointsize 0.750 linecolor 1
I get an echoed line (which is several screenfills line-wrapped),
with an "^" cursor which I can't interpret (because the "line" in
question is many physical lines wrapped together with line continuation),
followed by
^
"bad.gnuplot", line 159: invalid expression
where line 159 is the last of the continuation lines.
It would be wonderful if error reports could refer to the actual physical
line of the error instead. (I realise this might be messy to implement
if we've already processed the line continuations before the error is
found.)
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"
|
|
From: Tait <gnu...@t4...> - 2014-03-07 22:18:55
|
Support for an arbitrary number of axes would be a nice feature, and one that several people have requested. To get an idea of what they mean, in 3D look for "spider plot" or sometimes "star plot" or "radar chart", and in 2D see "parallel coordinates chart". This would be a new feature, but I think it would imply some fundamental changes to the syntax for describing axes and axis settings, since it would not be feasible to hard-code a finite list of x, x2, x3, x4, x... etc. |
|
From: <pl...@pi...> - 2014-03-08 08:50:19
|
On 03/07/14 21:37, Jonathan Thornburg wrote:
> On Tue, Mar 04, 2014 at 08:51:32PM -0800, sfeam wrote:
>> This is a reminder that a first release candidate for gnuplot version 5
>> is planned for later this year. In preparation for that I will bump the
>> version information in the current development source tree to 5.0.alpha.
> [[...]]
>>
>> Important note: If there is some behaviour or syntax in gnuplot
>> that has been annoying you for the last 20 years, please speak up.
>> This is the best chance you will have to get it changed!
>
> Ok, here's my candidate for #1 gnuplot annoyance:
>
> Suppose I have a gnuplot script which sets up a bunch of functions,
> computes some stuff, and eventually does a plot. For nontrivial plots
> this means that I have many continuation lines ("backslash at the end
> of the line") in the 'plot' command. The problem is, if I have a
> syntax error anywhere in the plot command, the error will be reported
> with the line number of the *last* continuation line.
>
> For example, what happens if I put an extra comma into this plot command:
>
> plot sigmoid(A,B,C,D, P) \
> title 'sigmoid fit' \
> with lines linetype 1 linecolor -1, \
> \
> 0.327 \
> title 'Zero OD 0.327 & 0.309' \
> axis x1y2 \
> with lines linetype 2 linecolor 3, \
> 0.309 \
> notitle \
> axis x1y2 \
> with lines linetype 2 linecolor 3, \
> \
> range20 \
> title '20% & 80% yrange of sigmoid' \
> axis x1y1 \
> with lines linetype 1 linecolor 4, \
> range80 \
> notitle \
> axis x1y1 \
> with lines linetype 1 linecolor 4, \
> \
> range10 \
> title '10% & 90% yrange of sigmoid' \
> axis x1y1 \
> with lines linetype 1 linecolor 5, \
> range90 \
> notitle \
> axis x1y1 \
> with lines linetype 1 linecolor 5, \
> \
> \
> 'plate-G25-standards.dat' \
> title 'standards' \
> axis x1y2 \
> with points pointtype 7 pointsize 0.5 linecolor -1,, \
> \
> 'plate-G25-QC-high.dat' \
> title 'QC high (100)' \
> axis x1y2 \
> with points pointtype 1 pointsize 0.750 linecolor rgb "#00A000",\
> \
> 'plate-G25-QC-low.dat' \
> title 'QC low (12.5)' \
> axis x1y2 \
> with points pointtype 1 pointsize 0.750 linecolor 1
>
> I get an echoed line (which is several screenfills line-wrapped),
> with an "^" cursor which I can't interpret (because the "line" in
> question is many physical lines wrapped together with line continuation),
> followed by
>
> ^
> "bad.gnuplot", line 159: invalid expression
>
> where line 159 is the last of the continuation lines.
>
> It would be wonderful if error reports could refer to the actual physical
> line of the error instead. (I realise this might be messy to implement
> if we've already processed the line continuations before the error is
> found.)
>
> ciao,
>
That's a good point . I often have a long , slash separated, line by the
time I've got all the titles and line styles into the plot command. The
error messages are of very little help other than just indicating
something was wrong with the syntax. Digging out where the problem is,
is usually rather a lengthy debugging process.
Now since the caret symbol is there there must be some character
position that it is trying to indicate. So one simply improvement would
be to add that information to the error message
eg
"bad.gnuplot", line 159 CHARACTER 78: invalid expression
That would at least give a clue as to where in the multiple split lines
the error was detected.
While on the subject of split lines it would be really handy if the
history re-united split lines, that may also help with the above.
If I have a plot command in three lines with back-slash continuation,
when I want to repeat it I have do the up arrow three times to get the
first bit, three times to get the second bit, three times to get the
last bit, then hit the return key.
Unless there's a down side it would be great to the get the last
_command_ with one up arrow, rather then the last text line in the
buffer, which is pretty much useless on its own.
/m2c
regards, Peter.
|
|
From: Bastian M. <bma...@we...> - 2014-03-08 08:57:42
|
Am 08.03.2014 09:43, schrieb pl...@pi...: > While on the subject of split lines it would be really handy if the > history re-united split lines, that may also help with the above. > > If I have a plot command in three lines with back-slash continuation, > when I want to repeat it I have do the up arrow three times to get the > first bit, three times to get the second bit, three times to get the > last bit, then hit the return key. > > Unless there's a down side it would be great to the get the last > _command_ with one up arrow, rather then the last text line in the > buffer, which is pretty much useless on its own. > Please have a look at Shigeharu Takeno's patch on SF: "#634 save multiline input to a single line in the history" https://sourceforge.net/p/gnuplot/patches/634/ Bastian |
|
From: sfeam <sf...@us...> - 2014-03-08 18:00:13
|
On Saturday, 08 March 2014 09:57:31 AM Bastian Märkisch wrote: > Am 08.03.2014 09:43, schrieb pl...@pi...: > > > While on the subject of split lines it would be really handy if the > > history re-united split lines, that may also help with the above. > > > > If I have a plot command in three lines with back-slash continuation, > > when I want to repeat it I have do the up arrow three times to get the > > first bit, three times to get the second bit, three times to get the > > last bit, then hit the return key. > > > > Unless there's a down side it would be great to the get the last > > _command_ with one up arrow, rather then the last text line in the > > buffer, which is pretty much useless on its own. > > > > Please have a look at Shigeharu Takeno's patch on SF: > "#634 save multiline input to a single line in the history" > https://sourceforge.net/p/gnuplot/patches/634/ While I understand that in some contexts it makes sense to concatenate the individual \-terminated lines into a single history entry, this is not true for the most common case. My typical use comes from starting with a command like: plot \ "A" using ... with <something complicated>, \ "B" using ... with <something else>, \ "C" using ... with <next set of options>, \ "D" using ... with <yet more stuff, \ ; After looking at the results, I may decide that I want instead C followed by D followed by A and to not include B at all. As it is now, I can back up and reorder the component line fragments from the history list. If they are concatenated into one very long line it would be more work to edit the line than to type (or cut-n-paste) them in again. For this reason I do not like the idea of concatenating lines in the history. Maybe there is a more creative solution - perhaps a variant on gnuplot> history !4 gnuplot> history !5 gnuplot> history !6 on the order of "history !6,4-5" or maybe "history !4 to EOC" or something like that. Ethan |
|
From: Tait <gnu...@t4...> - 2014-04-15 20:20:35
|
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()? |
|
From: Marek P. <ma...@du...> - 2014-04-15 20:51:58
|
> 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 |
|
From: <pl...@pi...> - 2014-04-16 14:43:09
|
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. |
|
From: Philipp K. J. <ja...@ie...> - 2014-04-16 23:44:18
|
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 |
|
From: Tait <gnu...@t4...> - 2014-04-17 05:49:14
|
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. |
|
From: Philipp K. J. <ja...@ie...> - 2014-04-17 15:48:30
|
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 |
|
From: <pl...@pi...> - 2014-04-17 16:58:47
|
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. |
|
From: Ethan A M. <sf...@us...> - 2014-04-17 17:44:11
|
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 |
|
From: <pl...@pi...> - 2014-04-17 18:49:28
|
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. |
|
From: Ethan A M. <sf...@us...> - 2014-04-17 19:14:37
|
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 |
