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

Re: Release plans: Version 4.4.4 and beyond

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

Tatsuro MATSUOKA <tma...@ya...> wrote
> 
> I have confirmed that 
> Print NaN gives 0.0 for gnuplot 4.4.3 binary.
> 
> As written by Ethan, in the CVS source, the NaN issue is corrected here.
> 2010-10-10  Tatsuro Matsuoka  <tma...@ya...>
> 
>         * src/stdfn.c (not_a_number): Bit-pattern definition of NaN for MINGW
> 
> I also find the above log in the ChangeLog in gnuplot 4.4.3. I checked the source of 4.4.3.
> The modification is also attached to the 4.4.3 source.
> I do not find the reason why this modification is not effective for 4.4.3 binary.

Could it be because the test in stdfn.c is different?
Version 4.4        #if defined(__MINGW__)
Version 4.5        #if defined(__MINGW32__)

	Ethan

Re: Release plans: Version 4.4.4 and beyond

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

Hello

I have confirmed that 
Print NaN gives 0.0 for gnuplot 4.4.3 binary.

As written by Ethan, in the CVS source, the NaN issue is corrected here.
2010-10-10  Tatsuro Matsuoka  <tma...@ya...>

	* src/stdfn.c (not_a_number): Bit-pattern definition of NaN for MINGW

I also find the above log in the ChangeLog in gnuplot 4.4.3. I checked the source of 4.4.3.
The modification is also attached to the 4.4.3 source.
I do not find the reason why this modification is not effective for 4.4.3 binary.

Regards

Tatsuro
--- On Wed, 2011/10/12, pl...@pi...  wrote:

> On 10/11/11 18:40, sfeam (Ethan Merritt) wrote:
> > On Tuesday, 11 October 2011, pl...@pi... wrote:
> >> On 10/11/11 17:53, sfeam (Ethan Merritt) wrote:
> >>> On Tuesday, 11 October 2011, pl...@pi... wrote:
> >>>>
> >>>> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over
> >>>> a year ago but did not seem to be fixed in 4.4.3 release in March.
> >>>
> >>> The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5
> >>> Note that this fix only deals with initializing the NaN variable internally.
> >>> It does not correct for any oddities in the C-language support library.
> >>> I.e., if the library routines fscanf() and atod() cannot deal with the
> >>> string "NaN" in an input file, that's a separate problem.
> >>> I don't know whether or not that is an issue with MinGW.
> >>>
> >>> What is the symptom?
> >>> If you start the program and say "print NaN", what does it show?
> >>>
> >>>     Ethan
> >>>
> >> Hi,
> >>
> >> yes that's exactly the problem as reported in that bug.
> >>
> >> print NaN;
> >>    gives me zero .
> >> (apart from nothing using NaN behaving as expected)
> >
> > Huh. Well, all I can say is that the fix was already in the source at
> > the time 4.4.3 was released.
> >
> > The windows executables from Tatsuro Matsuoka's site do not
> > suffer from this problem:
> >     http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> >
> >     Ethan
> >
> 
> Thanks , I'll get it installed from that source.
> 
> For information the build giving problems was downloaded from SF within 
> the last few days.
> 
> If the SF build is not as stated, maybe it should be replaced by Tatsuro 
> Matsuoka's build.
> 
> BTW I see from the changelog , lots of work getting committed recently. 
> Is 4.4.4 close to release or has it slipped back a bit?
> 
> regards. Peter.
> 
> 
> >>
> >> thx.
> >>
> >>
> >>>
> >>>> I don't use "other" OSes myself but I'm helping a college who has that
> >>>> misfortune. He is very impressed with gnuplot which I encouraged him to
> >>>> use and gave his a script for his data to get him started. However, I
> >>>> had to do a messy hack to get around the NaN=0 bug in the windoze build
> >>>> he got from SF.
> >>>>
> >>>> I don't have a cross-compilation set up for mwing so I can't build it here.
> >>>>
> >>>> Will this be fixed in next release?
> >>>>
> >>>> Best regards, Peter.
> 
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Re: A step too far in regression fit ?

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

On 20:59, pl...@pi... wrote:
> On 10/11/11 19:44, Hans-Bernhard Bröker wrote:
>> On 11.10.2011 14:04, pl...@pi... wrote:

>> A parameter value of zero is particularly bad in that case. No fit
>> parameter may be zero.
> _wrong_
> 
> The following works. I frequently set zero as a starting value if if
> makes sense.
> 
> baseºsedrift=0
> if (use_baseline) fit  baseline(x) datafile using 1:4 via
> base,basedrift
> 
>>
>> As it is, you pretty much explicitly asked for 'fit' to fail. No
>> wonder
>> it did.
> 
> If that were the case , I seem not to have come across that rather
> essential point it in the doc. Since you are wrong that may explain
> the absence of such information.

Zero is not exactly forbidden as a parameter, but the absolutes of
parameters mustn´t (or rather shouldn´t) be apart by a factor of
more than a few decades.

1e-30 is, well, more than thirty decades away from the values of
your other parameters, and zero even more so.

The fitting algorithm isn´t guaranteed to work well then, running
outside of it´s specifications so to say.

As HB said, if you don´t have an offset, you shoudn´t try to
determine it. ;-) Same goes for a negligible offset, because then
you won´t find it, but the noise in your data gets a variable fitted
to it. That can´t be good.

I´m not sure myself what the error message

Singular matrix in Invert_RtR

exactly means. It is clear that the correlation matrix cannot be
calculated with variables whose absolutes are too far apart, but
what is Invert_RtR ?

Regards,  Karl

Re: clunky fn plots

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

On Tue, 11 Oct 2011, pl...@pi... wrote:

> On 10/11/11 22:51, Allin Cottrell wrote:
>> On Tue, 11 Oct 2011, pl...@pi... wrote:
>>
>>> On 10/11/11 20:25, Juhász Péter wrote:
>>>> By the way, an answer to your original question would be
>>>>
>>>> plot "datafile" using 1:2, "" using 1:(f($1))
>>>>
>>>> which would evaluate your function at exactly the same points as the
>>>> datafile.
>>>
>>> Ah , thank you very much. That , to me would seem to be a logical
>>> default if the fn is in that same command as the data.
>>
>> I disagree strongly; this would be a crazy default. It is not unusual to
>> wish to plot the combination of some data points and a function, where
>> there are relatively few data points yet one wants the function drawn
>> smoothly.
>
> yes, you are right of course. I'm making the classic mistake of thinking 
> what I'm doing is somehow "typical".
>
> I think the key point is to make 'set sample' more discoverable.

Yes, I'd agree about that. I happen to have figured that out some
time ago (I can't remember how), but it's not very obvious. Seems 
like it should be cross-referenced under "plot".

Allin Cottrell

Re: Release plans: Version 4.4.4 and beyond

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

On 10/11/11 18:40, sfeam (Ethan Merritt) wrote:
> On Tuesday, 11 October 2011, pl...@pi... wrote:
>> On 10/11/11 17:53, sfeam (Ethan Merritt) wrote:
>>> On Tuesday, 11 October 2011, pl...@pi... wrote:
>>>>
>>>> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over
>>>> a year ago but did not seem to be fixed in 4.4.3 release in March.
>>>
>>> The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5
>>> Note that this fix only deals with initializing the NaN variable internally.
>>> It does not correct for any oddities in the C-language support library.
>>> I.e., if the library routines fscanf() and atod() cannot deal with the
>>> string "NaN" in an input file, that's a separate problem.
>>> I don't know whether or not that is an issue with MinGW.
>>>
>>> What is the symptom?
>>> If you start the program and say "print NaN", what does it show?
>>>
>>> 	Ethan
>>>
>> Hi,
>>
>> yes that's exactly the problem as reported in that bug.
>>
>> print NaN;
>>    gives me zero .
>> (apart from nothing using NaN behaving as expected)
>
> Huh. Well, all I can say is that the fix was already in the source at
> the time 4.4.3 was released.
>
> The windows executables from Tatsuro Matsuoka's site do not
> suffer from this problem:
>     http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
>
> 	Ethan
>

Thanks , I'll get it installed from that source.

For information the build giving problems was downloaded from SF within 
the last few days.

If the SF build is not as stated, maybe it should be replaced by Tatsuro 
Matsuoka's build.

BTW I see from the changelog , lots of work getting committed recently. 
Is 4.4.4 close to release or has it slipped back a bit?

regards. Peter.


>>
>> thx.
>>
>>
>>>
>>>> I don't use "other" OSes myself but I'm helping a college who has that
>>>> misfortune. He is very impressed with gnuplot which I encouraged him to
>>>> use and gave his a script for his data to get him started. However, I
>>>> had to do a messy hack to get around the NaN=0 bug in the windoze build
>>>> he got from SF.
>>>>
>>>> I don't have a cross-compilation set up for mwing so I can't build it here.
>>>>
>>>> Will this be fixed in next release?
>>>>
>>>> Best regards, Peter.

Re: clunky fn plots

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

On Tue, 11 Oct 2011, pl...@pi... wrote:

> On 10/11/11 20:25, Juhász Péter wrote:
>> By the way, an answer to your original question would be
>>
>> plot "datafile" using 1:2, "" using 1:(f($1))
>>
>> which would evaluate your function at exactly the same 
>> points as the datafile.
>
> Ah , thank you very much. That , to me would seem to be a logical 
> default if the fn is in that same command as the data.

I disagree strongly; this would be a crazy default. It is not 
unusual to wish to plot the combination of some data points 
and a function, where there are relatively few data points yet 
one wants the function drawn smoothly.

Allin Cottrell

Re: clunky fn plots

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

On 10/11/11 22:51, Allin Cottrell wrote:
> On Tue, 11 Oct 2011, pl...@pi... wrote:
>
>> On 10/11/11 20:25, Juhász Péter wrote:
>>> By the way, an answer to your original question would be
>>>
>>> plot "datafile" using 1:2, "" using 1:(f($1))
>>>
>>> which would evaluate your function at exactly the same points as the
>>> datafile.
>>
>> Ah , thank you very much. That , to me would seem to be a logical
>> default if the fn is in that same command as the data.
>
> I disagree strongly; this would be a crazy default. It is not unusual to
> wish to plot the combination of some data points and a function, where
> there are relatively few data points yet one wants the function drawn
> smoothly.
>
> Allin Cottrell

yes, you are right of course. I'm making the classic mistake of thinking 
what I'm doing is somehow "typical".

I think the key point is to make 'set sample' more discoverable.

regards.

Re: clunky fn plots

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

On 10/11/11 20:25, Juhász Péter wrote:
> On Tue, 2011-10-11 at 19:49 +0200, pl...@pi... wrote:
>> On 10/11/11 19:21, sfeam (Ethan Merritt) wrote:
>>> On Tuesday, 11 October 2011, pl...@pi... wrote:
>>>> On 10/11/11 18:42, sfeam (Ethan Merritt) wrote:
>>>>> On Tuesday, 11 October 2011, pl...@pi... wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I was under the impression that plotting functions and data in the same
>>>>>> plot command meant the interval for the fn plot would follow the
>>>>>> datafile.
>>>>>
>>>>> The sample interval for function plots is controlled only by the
>>>>> "set sample" and "set isosample" commands.   There is no connection to
>>>>> the number or location of points in any of the data plots.
>>>>>
>>>>> 	Ethan
>>>>>
>>>>
>>>> Many thanks Ethan .
>>>>
>>>> in fact my college had just discovered that setting via wgnuplot's menus
>>>> . It would have taken me a lot longer on linux digging blindly thought
>>>> the help.
>>>
>>> Then the most useful thing might be for you to suggest where in the help
>>> system to add this information.  Where did you look first?  Would that be
>>> a logical place to add mention of "set sample"?
>>
>> Well , I think that is half (most of ) the discovery problem. Why would
>> I think of looking for sample or set sample without already know the answer?
>>
>> This term is presumably short for sample rate, but when a _user_ is
>> thinking of plotting a function he will not consider that he is
>> "sampling".  The term does not evoke what it does.
>>
>> "help function" is very terse and does not deal directly with plotting
>> functions nor does it direct you to that sort of info with a "see also".
>>
>> "help plot" does not even have a subtopic about functions.
>>
>> help plot>  ranges does not cover it either, though there would be some
>> logical reason to look there.
>>
>> Indeed , could this actually be set as a extension to the range specifier ?
>>
>>
>> Any , or perhaps all those places could be used to at least point the
>> user with a "see also" comment.
>>
>> I hope those suggestions are useful.
>>
>> best.
>>
>
> An idea I've just had:
> perhaps it would be worth introducing a feature like "man -k" in *nix
> or ?? in R.
>
> If the user were looking for the way to do something but didn't know
> where he should look, he could use a hypothetical new "searchhelp" or
> "helpindex" command with some keyword related to his troubles, and
> gnuplot would list the relevant help topics.
>
>
> By the way, an answer to your original question would be
>
> plot "datafile" using 1:2, "" using 1:(f($1))
>
> which would evaluate your function at exactly the same points as the
> datafile.
>
> Péter Juhász
>
>

Ah , thank you very much. That , to me would seem to be a logical 
default if the fn is in that same command as the data.

set sample is sufficient if it is findable, but I prefer this solution.

Hopefully it can be a bit more visible as a result of this thread.

Thanks for that tip.

regards. Peter.

Re: clunky fn plots

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

On Tuesday, October 11, 2011 11:25:15 am Juhász Péter wrote:
> 
> An idea I've just had: 
> perhaps it would be worth introducing a feature like "man -k" in *nix
> or ?? in R. 
> 
> If the user were looking for the way to do something but didn't know
> where he should look, he could use a hypothetical new "searchhelp" or
> "helpindex" command with some keyword related to his troubles, and
> gnuplot would list the relevant help topics.

Doesn't this already exist?  The same keywords and index entries 
used to generate the index in the TeX-based documentation are supposed
to be found by the "help" command also.  The usual problem, of which
the current query is a perfect example, is that the user doesn't know
what keyword to search for.  "help sample" works fine, but only if
you think of asking about "sample".

I have myself pretty much abandoned the builtin "help" in favor of
the PDF document.  It has an index, and allows searching.  It also
has figures.  But you still need a starting point.

Anyhow, suggestions for keyword/index entries are very welcome.

	Ethan

 
> 
> By the way, an answer to your original question would be
> 
> plot "datafile" using 1:2, "" using 1:(f($1))
> 
> which would evaluate your function at exactly the same points as the
> datafile.
> 
> Péter Juhász

Re: clunky fn plots

[Juhász P. <pet...@gm...>]

On Tue, 2011-10-11 at 19:49 +0200, pl...@pi... wrote:
> On 10/11/11 19:21, sfeam (Ethan Merritt) wrote:
> > On Tuesday, 11 October 2011, pl...@pi... wrote:
> >> On 10/11/11 18:42, sfeam (Ethan Merritt) wrote:
> >>> On Tuesday, 11 October 2011, pl...@pi... wrote:
> >>>> Hi,
> >>>>
> >>>> I was under the impression that plotting functions and data in the same
> >>>> plot command meant the interval for the fn plot would follow the
> >>>> datafile.
> >>>
> >>> The sample interval for function plots is controlled only by the
> >>> "set sample" and "set isosample" commands.   There is no connection to
> >>> the number or location of points in any of the data plots.
> >>>
> >>> 	Ethan
> >>>
> >>
> >> Many thanks Ethan .
> >>
> >> in fact my college had just discovered that setting via wgnuplot's menus
> >> . It would have taken me a lot longer on linux digging blindly thought
> >> the help.
> >
> > Then the most useful thing might be for you to suggest where in the help
> > system to add this information.  Where did you look first?  Would that be
> > a logical place to add mention of "set sample"?
> 
> Well , I think that is half (most of ) the discovery problem. Why would 
> I think of looking for sample or set sample without already know the answer?
> 
> This term is presumably short for sample rate, but when a _user_ is 
> thinking of plotting a function he will not consider that he is 
> "sampling".  The term does not evoke what it does.
> 
> "help function" is very terse and does not deal directly with plotting 
> functions nor does it direct you to that sort of info with a "see also".
> 
> "help plot" does not even have a subtopic about functions.
> 
> help plot > ranges does not cover it either, though there would be some 
> logical reason to look there.
> 
> Indeed , could this actually be set as a extension to the range specifier ?
> 
> 
> Any , or perhaps all those places could be used to at least point the 
> user with a "see also" comment.
> 
> I hope those suggestions are useful.
> 
> best.
> 

An idea I've just had: 
perhaps it would be worth introducing a feature like "man -k" in *nix
or ?? in R. 

If the user were looking for the way to do something but didn't know
where he should look, he could use a hypothetical new "searchhelp" or
"helpindex" command with some keyword related to his troubles, and
gnuplot would list the relevant help topics.


By the way, an answer to your original question would be

plot "datafile" using 1:2, "" using 1:(f($1))

which would evaluate your function at exactly the same points as the
datafile.

Péter Juhász

Re: A step too far in regression fit ?

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

On 10/11/11 19:44, Hans-Bernhard Bröker wrote:
> On 11.10.2011 14:04, pl...@pi... wrote:
>
>> The fit is basically making to a convergence
>
> No, it's not. It's making it to failure.
>
>> necessary to it to do the invert RtR
>
> Yes.
>
>> since it has done all I asked.
>
> No, it hasn't. It may have done all you believe you need, but not all
> you actually asked for.

What has not been done if it has already found the result and output 
that it has found a convergence? I'm not saying you're wrong but it 
would be helpful if you said what I am missing rather than suggesting 
there is something more but not saying what it is .

I asked for a regression fit. I got one , I got convergence (apparently 
according to fit) I got the results , I got the stats. I got more that I 
asked for.

What do you think I "actually asked for"?
You love being smart , being explicit would be more help.


>
>> In this case I had started with data where no extra offset was needed ,
>> ie c0=0 was correct before running fit.
>
> Then you _shouldn't_ have told fit to modify it.

I was expecting it to be slightly different from zero but close to that 
value. That made it a logical starting point . If I knew it was exactly 
zero , clearly I would not have added it as a via parameter. I may not 
quite as smart as HBB but I'm not a complete cretin.

>
> A parameter value of zero is particularly bad in that case. No fit
> parameter may be zero.
_wrong_

The following works. I frequently set zero as a starting value if if 
makes sense.

base=basedrift=0
if (use_baseline) fit  baseline(x) datafile using 1:4 via base,basedrift

>
> As it is, you pretty much explicitly asked for 'fit' to fail. No wonder
> it did.

If that were the case , I seem not to have come across that rather 
essential point it in the doc. Since you are wrong that may explain the 
absence of such information.

Gruss.

Re: clunky fn plots

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

On 10/11/11 19:21, sfeam (Ethan Merritt) wrote:
> On Tuesday, 11 October 2011, pl...@pi... wrote:
>> On 10/11/11 18:42, sfeam (Ethan Merritt) wrote:
>>> On Tuesday, 11 October 2011, pl...@pi... wrote:
>>>> Hi,
>>>>
>>>> I was under the impression that plotting functions and data in the same
>>>> plot command meant the interval for the fn plot would follow the
>>>> datafile.
>>>
>>> The sample interval for function plots is controlled only by the
>>> "set sample" and "set isosample" commands.   There is no connection to
>>> the number or location of points in any of the data plots.
>>>
>>> 	Ethan
>>>
>>
>> Many thanks Ethan .
>>
>> in fact my college had just discovered that setting via wgnuplot's menus
>> . It would have taken me a lot longer on linux digging blindly thought
>> the help.
>
> Then the most useful thing might be for you to suggest where in the help
> system to add this information.  Where did you look first?  Would that be
> a logical place to add mention of "set sample"?

Well , I think that is half (most of ) the discovery problem. Why would 
I think of looking for sample or set sample without already know the answer?

This term is presumably short for sample rate, but when a _user_ is 
thinking of plotting a function he will not consider that he is 
"sampling".  The term does not evoke what it does.

"help function" is very terse and does not deal directly with plotting 
functions nor does it direct you to that sort of info with a "see also".

"help plot" does not even have a subtopic about functions.

help plot > ranges does not cover it either, though there would be some 
logical reason to look there.

Indeed , could this actually be set as a extension to the range specifier ?


Any , or perhaps all those places could be used to at least point the 
user with a "see also" comment.

I hope those suggestions are useful.

best.






>
>> Is there a particular reason this is such a course setting by default. ?
>> I've often been frustrated by quality when working with functions and I
>> would imagine most users would be too, or more likely confused by odd
>> effects that happen with things like sine plots with many cycles displayed.
>>
>> Since most PCs will be operating with at least 600x800 window, wouldn't
>> sample 1000 be a better choice?
>
> No default value will be ideal for all purposes.
> Setting a large number would have disadvantages for point plots,
> for 3D surface rendering, for the file size of vector output
> (eps svg emf ...) and for the computational time if the function
> is complicated (for example spinning the plot in 3D becomes slow).
>
> 	Ethan
>

Re: clunky fn plots

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 11 October 2011, pl...@pi... wrote:
> On 10/11/11 18:42, sfeam (Ethan Merritt) wrote:
> > On Tuesday, 11 October 2011, pl...@pi... wrote:
> >> Hi,
> >>
> >> I was under the impression that plotting functions and data in the same
> >> plot command meant the interval for the fn plot would follow the
> >> datafile.
> >
> > The sample interval for function plots is controlled only by the
> > "set sample" and "set isosample" commands.   There is no connection to
> > the number or location of points in any of the data plots.
> >
> > 	Ethan
> >
> 
> Many thanks Ethan .
> 
> in fact my college had just discovered that setting via wgnuplot's menus 
> . It would have taken me a lot longer on linux digging blindly thought 
> the help.

Then the most useful thing might be for you to suggest where in the help
system to add this information.  Where did you look first?  Would that be
a logical place to add mention of "set sample"?

> Is there a particular reason this is such a course setting by default. ? 
> I've often been frustrated by quality when working with functions and I 
> would imagine most users would be too, or more likely confused by odd 
> effects that happen with things like sine plots with many cycles displayed.
> 
> Since most PCs will be operating with at least 600x800 window, wouldn't 
> sample 1000 be a better choice?

No default value will be ideal for all purposes.  
Setting a large number would have disadvantages for point plots, 
for 3D surface rendering, for the file size of vector output 
(eps svg emf ...) and for the computational time if the function
is complicated (for example spinning the plot in 3D becomes slow).

	Ethan

Re: clunky fn plots

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

On 10/11/11 18:42, sfeam (Ethan Merritt) wrote:
> On Tuesday, 11 October 2011, pl...@pi... wrote:
>> Hi,
>>
>> I was under the impression that plotting functions and data in the same
>> plot command meant the interval for the fn plot would follow the
>> datafile.
>
> The sample interval for function plots is controlled only by the
> "set sample" and "set isosample" commands.   There is no connection to
> the number or location of points in any of the data plots.
>
> 	Ethan
>

Many thanks Ethan .

in fact my college had just discovered that setting via wgnuplot's menus 
. It would have taken me a lot longer on linux digging blindly thought 
the help.

Is there a particular reason this is such a course setting by default. ? 
I've often been frustrated by quality when working with functions and I 
would imagine most users would be too, or more likely confused by odd 
effects that happen with things like sine plots with many cycles displayed.

Since most PCs will be operating with at least 600x800 window, wouldn't 
sample 1000 be a better choice?

regards, Peter.

Re: clunky fn plots

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 11 October 2011, pl...@pi... wrote:
> Hi,
> 
> I was under the impression that plotting functions and data in the same 
> plot command meant the interval for the fn plot would follow the 
> datafile. 

The sample interval for function plots is controlled only by the
"set sample" and "set isosample" commands.   There is no connection to
the number or location of points in any of the data plots.

	Ethan


> Hwvr, this seems not to be the case.
> 
> This seems to be a bit of a short-coming.
> 
> For ex. I have raw data and a fitted function. I plot the two on the 
> same graph but the function (which should be a nice smooth gaussian 
> bell) is decidedly clunky.
> 
> If I zoom the wxt window I get a smoother line but it seems a bit 
> incoherent that data file has more detail than the analytic function plot.
> 
> This is also unfortunate since I'm outputting to svg as well and when I 
> try to make use of the zoom in svg to get a closer look, I find I have a 
> very poor rendition of the function.
> 
> I would have expected to see exactly as many points (vectors) in the 
> function line as in the data line.
> 
> 
> Best regards, Peter.
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Release plans: Version 4.4.4 and beyond

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 11 October 2011, pl...@pi... wrote:
> On 10/11/11 17:53, sfeam (Ethan Merritt) wrote:
> > On Tuesday, 11 October 2011, pl...@pi... wrote:
> >>
> >> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over
> >> a year ago but did not seem to be fixed in 4.4.3 release in March.
> >
> > The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5
> > Note that this fix only deals with initializing the NaN variable internally.
> > It does not correct for any oddities in the C-language support library.
> > I.e., if the library routines fscanf() and atod() cannot deal with the
> > string "NaN" in an input file, that's a separate problem.
> > I don't know whether or not that is an issue with MinGW.
> >
> > What is the symptom?
> > If you start the program and say "print NaN", what does it show?
> >
> > 	Ethan
> >
> Hi,
> 
> yes that's exactly the problem as reported in that bug.
> 
> print NaN;
>   gives me zero .
> (apart from nothing using NaN behaving as expected)

Huh. Well, all I can say is that the fix was already in the source at
the time 4.4.3 was released.

The windows executables from Tatsuro Matsuoka's site do not
suffer from this problem:
   http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

	Ethan

> 
> thx.
> 
> 
> >
> >> I don't use "other" OSes myself but I'm helping a college who has that
> >> misfortune. He is very impressed with gnuplot which I encouraged him to
> >> use and gave his a script for his data to get him started. However, I
> >> had to do a messy hack to get around the NaN=0 bug in the windoze build
> >> he got from SF.
> >>
> >> I don't have a cross-compilation set up for mwing so I can't build it here.
> >>
> >> Will this be fixed in next release?
> >>
> >> Best regards, Peter.
> >>
> >> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure contains a
> >> definitive record of customers, application performance, security
> >> threats, fraudulent activity and more. Splunk takes this data and makes
> >> sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2d-oct
> >> _______________________________________________
> >> gnuplot-beta mailing list
> >> gnu...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >>
> >
> >
> 
> 

clunky fn plots

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

Hi,

I was under the impression that plotting functions and data in the same 
plot command meant the interval for the fn plot would follow the 
datafile. Hwvr, this seems not to be the case.

This seems to be a bit of a short-coming.

For ex. I have raw data and a fitted function. I plot the two on the 
same graph but the function (which should be a nice smooth gaussian 
bell) is decidedly clunky.

If I zoom the wxt window I get a smoother line but it seems a bit 
incoherent that data file has more detail than the analytic function plot.

This is also unfortunate since I'm outputting to svg as well and when I 
try to make use of the zoom in svg to get a closer look, I find I have a 
very poor rendition of the function.

I would have expected to see exactly as many points (vectors) in the 
function line as in the data line.


Best regards, Peter.

Re: Release plans: Version 4.4.4 and beyond

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

On 10/11/11 17:53, sfeam (Ethan Merritt) wrote:
> On Tuesday, 11 October 2011, pl...@pi... wrote:
>>
>> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over
>> a year ago but did not seem to be fixed in 4.4.3 release in March.
>
> The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5
> Note that this fix only deals with initializing the NaN variable internally.
> It does not correct for any oddities in the C-language support library.
> I.e., if the library routines fscanf() and atod() cannot deal with the
> string "NaN" in an input file, that's a separate problem.
> I don't know whether or not that is an issue with MinGW.
>
> What is the symptom?
> If you start the program and say "print NaN", what does it show?
>
> 	Ethan
>
Hi,

yes that's exactly the problem as reported in that bug.

print NaN;
  gives me zero .

(apart from nothing using NaN behaving as expected)

thx.


>
>> I don't use "other" OSes myself but I'm helping a college who has that
>> misfortune. He is very impressed with gnuplot which I encouraged him to
>> use and gave his a script for his data to get him started. However, I
>> had to do a messy hack to get around the NaN=0 bug in the windoze build
>> he got from SF.
>>
>> I don't have a cross-compilation set up for mwing so I can't build it here.
>>
>> Will this be fixed in next release?
>>
>> Best regards, Peter.
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2d-oct
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>

Re: Release plans: Version 4.4.4 and beyond

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 11 October 2011, pl...@pi... wrote:
> 
> I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over 
> a year ago but did not seem to be fixed in 4.4.3 release in March.

The same fix (10-10-2010) went into stdfn.c in both 4.4 and 4.5
Note that this fix only deals with initializing the NaN variable internally.
It does not correct for any oddities in the C-language support library.
I.e., if the library routines fscanf() and atod() cannot deal with the
string "NaN" in an input file, that's a separate problem.  
I don't know whether or not that is an issue with MinGW.

What is the symptom?   
If you start the program and say "print NaN", what does it show?

	Ethan

 
> I don't use "other" OSes myself but I'm helping a college who has that 
> misfortune. He is very impressed with gnuplot which I encouraged him to 
> use and gave his a script for his data to get him started. However, I 
> had to do a messy hack to get around the NaN=0 bug in the windoze build 
> he got from SF.
> 
> I don't have a cross-compilation set up for mwing so I can't build it here.
> 
> Will this be fixed in next release?
> 
> Best regards, Peter.
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

A step too far in regression fit ?

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

Hi,

I have hit this in a couple of ways recently in cases where it seemed it 
should succeed.

The fit is basically making to a convergence , printing all the fitted 
values , stats , the lot but then failing. I am wondering if it is still 
necessary to it to do the invert RtR since it has done all I asked.



resultant parameter values

a0              = 384.634
b0              = 4850.85
c0              = 1e-30
pk0             = 9.10484

After 11 iterations the fit converged.
final sum of squares of residuals : 304.992
rel. change during last iteration : -1.04716e-06

degrees of freedom    (FIT_NDF)                        : 197
rms of residuals      (FIT_STDFIT) = sqrt(WSSR/ndf)    : 1.24426
variance of residuals (reduced chisquare) = WSSR/ndf   : 1.54818

          Singular matrix in Invert_RtR


In this case I had started with data where no extra offset was needed , 
ie c0=0 was correct before running fit.

I had a similar occurrence where another via param was at its final 
value and I got a singularity. If I deliberately initialised it to be a 
bit off, fit put it back where it was to start with without failing.

Is it correct for the method to succeed but fail :?

Thanks.

Release plans: Version 4.4.4 and beyond

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

 >>
My plan is to release version 4.4.4 some time in the next month,
consistent with the ~6 month release cycle that has held throughout
the 4.2 and 4.4 release series.  NEWS entries for 4.4.4 include

* NEW boxxyerrors plot style now allows variable color
* NEW splot with pm3d now allows variable rgb color
* NEW "nonuniform matrix" indicates ascii data with explicit x, y
* CHANGE columnhead(N) is a string-valued function, not a keyword
* CHANGE Demarcate plots in svg output using <g id="Plot_#"><title>...
* CHANGE xticlabels() works for binary data files as well as ascii
* CHANGE "set key maxrows" now applies to 3D plots as well as 2D
* CHANGE rewrite installation path rules for TeX files
* FIX wxt terminal should now work on at least some flavors of OSX
* FIX incorrect space allowed for outside left key box
* FIX buffer overflow from enhanced text timefmt tic labels
* FIX correction for offset in epochs when reading in time format "%s"
* FIX discontinuity in defined palette limited by maxcolors
* FIX initialization of svg pattern-fill definitions
* FIX positioning of histogram bars when some data entries are missing
* FIX emf terminal can handle UTF-8 encoding

 >>


I saw "not_a_number for MinGW build (gcc-4.5.0)" was committed just over 
a year ago but did not seem to be fixed in 4.4.3 release in March.

I don't use "other" OSes myself but I'm helping a college who has that 
misfortune. He is very impressed with gnuplot which I encouraged him to 
use and gave his a script for his data to get him started. However, I 
had to do a messy hack to get around the NaN=0 bug in the windoze build 
he got from SF.

I don't have a cross-compilation set up for mwing so I can't build it here.

Will this be fixed in next release?

Best regards, Peter.

Re: sprintf() error (compiled by VC++)

[Shigeharu T. <sh...@ie...>]

shige 10/07 2011
----------------

I wrote:
| The last behaver seems to be the reason the gnuplot says 
| "undefined value". The following patch for src/internal.c is the
| dirty huck for this problem:
| 
| ----- From here -----
| --- internal.c~ Fri Oct  7 12:33:11 2011
| +++ internal.c  Fri Oct  7 12:35:29 2011
| @@ -1312,6 +1312,10 @@
|         default:
|             int_error(NO_CARET,"internal error: invalid spec_type");
|         }
| +#if MSVC
| +       buffer[bufsize-1] = '\0'; /* shige : for safe for VC++ */
| +       if (errno == ERANGE) errno = 0; /* shige : very dirty huck for VC++ */
| +#endif 
|  #endif
|  
|         next_start[next_length] = tempchar;
| ----- To here -----

Sorry, I made a mistake for the position. The following is 
correct:

----- From here -----
--- internal.c~	Fri Oct  7 12:33:11 2011
+++ internal.c	Fri Oct  7 12:54:38 2011
@@ -1297,6 +1297,10 @@
 	default:
 	    int_error(NO_CARET,"internal error: invalid spec_type");
 	}
+#if VCPP
+	buffer[bufsize-1] = '\0'; /* shige : for safe for VC++ */
+	if (errno == ERANGE) errno = 0; /* shige : very dirty huck for VC++ */
+#endif	
 #else
 	/* FIXME - this is bad; we should dummy up an snprintf equivalent */
 	switch(spec_type) {
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: sprintf() error (compiled by VC++)

[Shigeharu T. <sh...@ie...>]

shige 10/07 2011
----------------

I wrote:
| Ethan Merritt <merritt@u.washington.edu> wrote:
| | Some Googling suggests that VC++ may work if you do
| | #define snprintf _snprintf
| | 
| | This would have to go in some header or configuration file,
| | along with HAVE_SNPRINTF.
| 
| Thank you for your reply. But, we already use them (see 
| config/config.nt).

I found that the function _snprintf(s, n, format, ...) of VC++ 
does:

1) if the length of the result string is larger than n, then
  it copies n charcters to s and does not add '\0',
2) and then it sets errno to ERANGE.

The last behaver seems to be the reason the gnuplot says 
"undefined value". The following patch for src/internal.c is the
dirty huck for this problem:

----- From here -----
--- internal.c~	Fri Oct  7 12:33:11 2011
+++ internal.c	Fri Oct  7 12:35:29 2011
@@ -1312,6 +1312,10 @@
 	default:
 	    int_error(NO_CARET,"internal error: invalid spec_type");
 	}
+#if MSVC
+	buffer[bufsize-1] = '\0'; /* shige : for safe for VC++ */
+	if (errno == ERANGE) errno = 0; /* shige : very dirty huck for VC++ */
+#endif	
 #endif
 
 	next_start[next_length] = tempchar;
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: sprintf() error (compiled by VC++)

[Shigeharu T. <sh...@ie...>]

shige 10/07 2011
----------------

Ethan Merritt <merritt@u.washington.edu> wrote:
| Some Googling suggests that VC++ may work if you do
| #define snprintf _snprintf
| 
| This would have to go in some header or configuration file,
| along with HAVE_SNPRINTF.

Thank you for your reply. But, we already use them (see 
config/config.nt).

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: sprintf() error (compiled by VC++)

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

On Thursday, October 06, 2011 04:22:52 pm Ethan Merritt wrote:
> On Thursday, October 06, 2011 03:46:13 pm Hans-Bernhard Br�ker wrote:
> > On 06.10.2011 10:01, Shigeharu TAKENO wrote:
> > 
> > > I saw that gnuplot.exe of CVS version compiled by VC++ reports
> > [...]
> > >    foo = sprintf("%40d %40d %40d %40d %40d %40d",1,2,3,4,5,6)
> > >          ^
> > >    "stringvar.dem", line 59: undefined value
> > 
> > For what it's worth: this program doesn't appear in gnuplot.exe compiled 
> > by Open Watcom.
> > 
> > > The gnuplot show no erorr message for the command
> > >
> > >    foo = sprintf("%83d",1)
> > >
> > > but it show the same error message above for the command
> > >
> > >    foo = sprintf("%84d",1)
> > 
> > This doesn't cause problem either.
> > 
> > The root of the problem appears to be the buffer size computation and 
> > subsequent realloc()ation in f_sprintf().  The number 84 is magic 
> > because it's 84 plus the length of the format string "%84d".  Go figure.
> 
> The problem occurs when the platform/compiler does not support snprintf.
> f_sprintf() has:
> 
> #ifdef HAVE_SNPRINTF
>         /* Use the format to print next arg */
>     ... this code works fine ...
> #else
>         /* FIXME - this is bad; we should dummy up an snprintf equivalent */
>     ... this code triggers a buffer overflow if the format width is too large
> #endif

Some Googling suggests that VC++ may work if you do
#define snprintf _snprintf

This would have to go in some header or configuration file,
along with HAVE_SNPRINTF.



-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742