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

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: gnuplot-beta
> Cc: 
> Date: 2015/6/11, Thu 19:42
> Subject: Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2015/3/3, Tue 16:16
>>  Subject: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
>> 
>>  Hello
>> 
>>  I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 
>>  4.9.2.
>>  Some observations happened for both 64 bit and 32 bit build.
>> 
>> 
>>  Complier gcc-4.9.2-2 from MinGW-64 project
>>  64 bit : exception:seh, thread:win32 
>>  32 bit : exception:dwarf2, thread:win32 
>> 
>>  Good point
>> 
>>   I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
>> 
>> 
>>  Troubles ?
>>  **********
>>  64 bit
>>  **********
>>  1. I have met an error in compiling qt_conversion.cpp.
>> 
>> 
>>  ../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was 
> not 
>>  declared in this scope
>> 
>>  The error above can be avoided using the following patch:
>> 
>>  --- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000 
> +0900
>>  +++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
>>  @@ -126,7 +126,7 @@
>>   QRgb* line = (QRgb*)(qimage.scanLine(n));
>>   for (int m = 0; m < M; m++)
>>   {
>>  -if (isnan(*image))
>>  +if (std::isnan(*image))
>>   {
>>   image++;
>>   *line++ = 0x00000000;
>> 
>> 
>>  2. For first plotting in wxt terminal, I see a waring message like an 
> attached 
>>  file.
>>  Here I write the text:
>> 
>>   You probably called setlocale() directly instead
>>   of using wxLocale and now there is a
>>   mismatch between C/C++ and Windows locale.
>>   Things are going to break, please only change
>>   locale by creating wxLocale objects to avoid this!
>> 
>>  The above message is written in wxWidgets-3.0.2/src/common/intl.cpp
>> 
>>  wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
>>  {
>>      const wxLanguageInfo * const
>>          info = wxGetLocale() ? 
> GetLanguageInfo(wxGetLocale()->GetLanguage())
>>                               : NULL;
>>      if ( !info )
>>      {
>>          // wxSetLocale() hadn't been called yet of failed, hence CRT 
> must be
>>          // using "C" locale -- but check it to detect bugs that 
> would 
>>  happen if
>>          // this were not the case.
>>         wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
>>                        wxS("You probably called setlocale() directly 
> instead 
>>  ")
>>                        wxS("of using wxLocale and now there is a 
> ")
>>                        wxS("mismatch between C/C++ and Windows 
>>  locale.\n")
>>                        wxS("Things are going to break, please only 
> change 
>>  ")
>>                        wxS("locale by creating wxLocale objects to 
> avoid 
>>  this!") );
>> 
>> 
>>          // Return the hard coded values for C locale. This is really the 
> right
>>          // thing to do as there is no LCID we can use in the code below in 
> this
>>          // case, even LOCALE_INVARIANT is not quite the same as C locale 
> (the
>>          // only difference is that it uses %Y instead of %y in the date 
> format
>>          // but this difference is significant enough).
>> 
>>  The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
>>  However, I do not see the message building wxWidgets-3 by gcc-4.9.0.
>> 
>>  Any ideas to avoid the message? Otherwise, is the above problem of 
> complier?
>> 
>>  ******
>>  32 bit
>>  ******
>>  gnuplot crashes by segmentation fault when one use cairo based terminals.
>> 
>>  Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 bit 
> gcc-4.9.2
>> 
>>  I have met a  Segmentation fault at using gnuplot-5.1 built by myself on 
>>  windows.
>>  The Segmentation fault seems to be related with the cairo based terminals.
>>  (The cairo based terminals use libglib.)
>> 
>>  Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
>>  Glib version : 2.42.1. Build from source.
>> 
>>  gdb message:
>> 
>>  Program received signal SIGSEGV, Segmentation fault.
>>  0x6862318f in g_utf8_validate (str=0x2888a68 "-1", max_len=-1, 
>>  end=0xffffffff)
>>      at ../../glib-2.42.1/glib/gutf8.c:1634
>>  1634        *end = p;
>> 
>>  Program received signal SIGSEGV, Segmentation fault.
>>  0x6862318f in g_utf8_validate (str=0xb28a68 "-1", max_len=-1, 
>>  end=0xffffffff)
>>      at ../../glib-2.42.1/glib/gutf8.c:1634
>>  1634        *end = p;
>> 
>> 
>>  Perhaps this is a bug of glib (2.42.1 and 2.33.14).
>> 
>>  I have filed the issue to  the bug tracker of Gnome.
>>   
>>  https://bugzilla.gnome.org/show_bug.cgi?id=745485
>> 
>> 
>> 
>>  At this moment, I abandon the complier update. However, is the trouble 2 
> for 64 
>>  bit case not a issue of gnuplot code?
>> 
>>  Regards
>> 
>>  Tatsuro 
> 
> 
> *****************************************************************
> Hello
> 
>> From above problems, I have been backed to gcc-4.9.0
> (For 32bit build suffers from Glib related seg-fault.)
> 
> 
> Recently I have update gcc-4.9.2 on MinGW project to release 3 and some 
> libraries updated
> and re-try to build gnuplot using the tools.
> 
> (The version of glib is updated to 2.44.1 from 2.42.1. )
> 
> The segmentation fault for 32 bit build disappeared!!
> 
> However, the problem became the same between 32 bit and 64 bit.
> 
>>  1. I have met an error in compiling qt_conversion.cpp.
>>  
>>  
>>  ../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was 
> not 
>>  declared in this scope
>>  
>>  The error above can be avoided using the following patch:
>>  
>>  --- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000 
> +0900
>>  +++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
>>  @@ -126,7 +126,7 @@
>>   QRgb* line = (QRgb*)(qimage.scanLine(n));
>>   for (int m = 0; m < M; m++)
>>   {
>>  -if (isnan(*image))
>>  +if (std::isnan(*image))
>>   {
>>   image++;
>>   *line++ = 0x00000000;
>>  
>>  
>>  2. For first plotting in wxt terminal, I see a waring message like an 
> attached 
>>  file.
>>  Here I write the text:
>>  
>>   You probably called setlocale() directly instead
>>   of using wxLocale and now there is a
>>   mismatch between C/C++ and Windows locale.
>>   Things are going to break, please only change
>>   locale by creating wxLocale objects to avoid this!
>>  
>>  The above message is written in wxWidgets-3.0.2/src/common/intl.cpp
>>  
>>  wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
>>  {
>>      const wxLanguageInfo * const
>>          info = wxGetLocale() ? 
> GetLanguageInfo(wxGetLocale()->GetLanguage())
>>                               : NULL;
>>      if ( !info )
>>      {
>>          // wxSetLocale() hadn't been called yet of failed, hence CRT 
> must be
>>          // using "C" locale -- but check it to detect bugs that 
> would 
>>  happen if
>>          // this were not the case.
>>         wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
>>                        wxS("You probably called setlocale() directly 
> instead 
>>  ")
>>                        wxS("of using wxLocale and now there is a 
> ")
>>                        wxS("mismatch between C/C++ and Windows 
>>  locale.\n")
>>                        wxS("Things are going to break, please only 
> change 
>>  ")
>>                        wxS("locale by creating wxLocale objects to 
> avoid 
>>  this!") );
>>  
>>  
>>          // Return the hard coded values for C locale. This is really the 
> right
>>          // thing to do as there is no LCID we can use in the code below in 
> this
>>          // case, even LOCALE_INVARIANT is not quite the same as C locale 
> (the
>>          // only difference is that it uses %Y instead of %y in the date 
> format
>>          // but this difference is significant enough).
>>  
>>  The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
>>  However, I do not see the message building wxWidgets-3 by gcc-4.9.0.
>>  
>>  Any ideas to avoid the message? Otherwise, is the above problem of 
> complier?
> 
> 
> For the problem 2, I temporally disabled to the ability to the message and built 
> wx-3.0.2.
> (Just commented out the message part.)
> The treatment is not desirable. 
> Could someone give me some hints?
> 
> Tatsuro


Correction and clarification:


1. Complier gcc-4.9.2-3 from MinGW-64 project
 64 bit : exception:seh, thread:win32 
 32 bit : exception:dwarf2, thread:win32 


2. Glib is updated from 2.42.1 to 2.44.1.
(Glib related segmentation fault is disappeared.)


3. wxWidgets error dialog message

The comment out part of wxWidgets-3.0.2/src/common/intl.cpp is as follows:



--- intl.orig.cpp2014-10-07 06:33:44.000000000 +0900
+++ intl.cpp2015-02-25 16:24:12.462616200 +0900
@@ -1441,13 +1441,13 @@
         // wxSetLocale() hadn't been called yet of failed, hence CRT must be
         // using "C" locale -- but check it to detect bugs that would happen if
         // this were not the case.
-        wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
+/*        wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
                       wxS("You probably called setlocale() directly instead ")
                       wxS("of using wxLocale and now there is a ")
                       wxS("mismatch between C/C++ and Windows locale.\n")
                       wxS("Things are going to break, please only change ")
                       wxS("locale by creating wxLocale objects to avoid this!") );
-
+*/
 
         // Return the hard coded values for C locale. This is really the right
         // thing to do as there is no LCID we can use in the code below in this
Without the above, gnuplot hangs when plotting on wxt terminal for 32 bit build.
(This is a correction.)
For 64 bit build, a MS-windows dialog which alert the message appears.

From the message, it can be said that CRT is not "C" locale.
Should I check the locale in wxt terminal codes and where should I check?

Tatsuro

Re: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)

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

----- Original Message -----

> From: Tatsuro MATSUOKA
> To: gnuplot-beta
> Cc: 
> Date: 2015/3/3, Tue 16:16
> Subject: Some observations building gnuplot for win by gcc-4.9.2 (MinGW64)
> 
> Hello
> 
> I have tried to update gcc for windows build of gnuplot from ver. 4.9.0 to 
> 4.9.2.
> Some observations happened for both 64 bit and 32 bit build.
> 
> 
> Complier gcc-4.9.2-2 from MinGW-64 project
> 64 bit : exception:seh, thread:win32 
> 32 bit : exception:dwarf2, thread:win32 
> 
> Good point
> 
>  I can built gd-2.1.1 flawlessly for both 64 bit and 32 bit platform.
> 
> 
> Troubles ?
> **********
> 64 bit
> **********
> 1. I have met an error in compiling qt_conversion.cpp.
> 
> 
> ../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was not 
> declared in this scope
> 
> The error above can be avoided using the following patch:
> 
> --- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000 +0900
> +++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
> @@ -126,7 +126,7 @@
>  QRgb* line = (QRgb*)(qimage.scanLine(n));
>  for (int m = 0; m < M; m++)
>  {
> -if (isnan(*image))
> +if (std::isnan(*image))
>  {
>  image++;
>  *line++ = 0x00000000;
> 
> 
> 2. For first plotting in wxt terminal, I see a waring message like an attached 
> file.
> Here I write the text:
> 
>  You probably called setlocale() directly instead
>  of using wxLocale and now there is a
>  mismatch between C/C++ and Windows locale.
>  Things are going to break, please only change
>  locale by creating wxLocale objects to avoid this!
> 
> The above message is written in wxWidgets-3.0.2/src/common/intl.cpp
> 
> wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
> {
>     const wxLanguageInfo * const
>         info = wxGetLocale() ? GetLanguageInfo(wxGetLocale()->GetLanguage())
>                              : NULL;
>     if ( !info )
>     {
>         // wxSetLocale() hadn't been called yet of failed, hence CRT must be
>         // using "C" locale -- but check it to detect bugs that would 
> happen if
>         // this were not the case.
>        wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
>                       wxS("You probably called setlocale() directly instead 
> ")
>                       wxS("of using wxLocale and now there is a ")
>                       wxS("mismatch between C/C++ and Windows 
> locale.\n")
>                       wxS("Things are going to break, please only change 
> ")
>                       wxS("locale by creating wxLocale objects to avoid 
> this!") );
> 
> 
>         // Return the hard coded values for C locale. This is really the right
>         // thing to do as there is no LCID we can use in the code below in this
>         // case, even LOCALE_INVARIANT is not quite the same as C locale (the
>         // only difference is that it uses %Y instead of %y in the date format
>         // but this difference is significant enough).
> 
> The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
> However, I do not see the message building wxWidgets-3 by gcc-4.9.0.
> 
> Any ideas to avoid the message? Otherwise, is the above problem of complier?
> 
> ******
> 32 bit
> ******
> gnuplot crashes by segmentation fault when one use cairo based terminals.
> 
> Segmentation fault : g_utf8_validate gutf8.c:1634 on MinGW-64 32 bit gcc-4.9.2
> 
> I have met a  Segmentation fault at using gnuplot-5.1 built by myself on 
> windows.
> The Segmentation fault seems to be related with the cairo based terminals.
> (The cairo based terminals use libglib.)
> 
> Compiler gcc-4.9.2 (MinGW-w64 32bit. dwarf, win32 thread).
> Glib version : 2.42.1. Build from source.
> 
> gdb message:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x6862318f in g_utf8_validate (str=0x2888a68 "-1", max_len=-1, 
> end=0xffffffff)
>     at ../../glib-2.42.1/glib/gutf8.c:1634
> 1634        *end = p;
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x6862318f in g_utf8_validate (str=0xb28a68 "-1", max_len=-1, 
> end=0xffffffff)
>     at ../../glib-2.42.1/glib/gutf8.c:1634
> 1634        *end = p;
> 
> 
> Perhaps this is a bug of glib (2.42.1 and 2.33.14).
> 
> I have filed the issue to  the bug tracker of Gnome.
>  
> https://bugzilla.gnome.org/show_bug.cgi?id=745485
> 
> 
> 
> At this moment, I abandon the complier update. However, is the trouble 2 for 64 
> bit case not a issue of gnuplot code?
> 
> Regards
> 
> Tatsuro 


*****************************************************************
Hello

From above problems, I have been backed to gcc-4.9.0
(For 32bit build suffers from Glib related seg-fault.)


Recently I have update gcc-4.9.2 on MinGW project to release 3 and some libraries updated
and re-try to build gnuplot using the tools.

(The version of glib is updated to 2.44.1 from 2.42.1. )

The segmentation fault for 32 bit build disappeared!!

However, the problem became the same between 32 bit and 64 bit.

> 1. I have met an error in compiling qt_conversion.cpp.
> 
> 
> ../../src/qtterminal/qt_conversion.cpp:129:21: error: 'isnan' was not 
> declared in this scope
> 
> The error above can be avoided using the following patch:
> 
> --- src/qtterminal/qt_conversion.orig.cpp2014-04-21 03:46:32.000000000 +0900
> +++ src/qtterminal/qt_conversion.cpp2015-02-25 08:40:45.485861900 +0900
> @@ -126,7 +126,7 @@
>  QRgb* line = (QRgb*)(qimage.scanLine(n));
>  for (int m = 0; m < M; m++)
>  {
> -if (isnan(*image))
> +if (std::isnan(*image))
>  {
>  image++;
>  *line++ = 0x00000000;
> 
> 
> 2. For first plotting in wxt terminal, I see a waring message like an attached 
> file.
> Here I write the text:
> 
>  You probably called setlocale() directly instead
>  of using wxLocale and now there is a
>  mismatch between C/C++ and Windows locale.
>  Things are going to break, please only change
>  locale by creating wxLocale objects to avoid this!
> 
> The above message is written in wxWidgets-3.0.2/src/common/intl.cpp
> 
> wxString wxLocale::GetInfo(wxLocaleInfo index, wxLocaleCategory cat)
> {
>     const wxLanguageInfo * const
>         info = wxGetLocale() ? GetLanguageInfo(wxGetLocale()->GetLanguage())
>                              : NULL;
>     if ( !info )
>     {
>         // wxSetLocale() hadn't been called yet of failed, hence CRT must be
>         // using "C" locale -- but check it to detect bugs that would 
> happen if
>         // this were not the case.
>        wxASSERT_MSG( strcmp(setlocale(LC_ALL, NULL), "C") == 0,
>                       wxS("You probably called setlocale() directly instead 
> ")
>                       wxS("of using wxLocale and now there is a ")
>                       wxS("mismatch between C/C++ and Windows 
> locale.\n")
>                       wxS("Things are going to break, please only change 
> ")
>                       wxS("locale by creating wxLocale objects to avoid 
> this!") );
> 
> 
>         // Return the hard coded values for C locale. This is really the right
>         // thing to do as there is no LCID we can use in the code below in this
>         // case, even LOCALE_INVARIANT is not quite the same as C locale (the
>         // only difference is that it uses %Y instead of %y in the date format
>         // but this difference is significant enough).
> 
> The message appears for both wxWidgets-3.0.2 and wxWidgets-3.0.1.
> However, I do not see the message building wxWidgets-3 by gcc-4.9.0.
> 
> Any ideas to avoid the message? Otherwise, is the above problem of complier?


For the problem 2, I temporally disabled to the ability to the message and built wx-3.0.2.
(Just commented out the message part.)
The treatment is not desirable. 
Could someone give me some hints?

Tatsuro

Re: pm3d face and line color control or surface color

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

On 06/10/2015 03:20 PM, Ethan A Merritt wrote:
> On Wednesday, 10 June, 2015 14:29:27 Daniel J Sebald wrote:
[snip]
>> Is there some way of controlling face color and line color in pm3d at
>> the moment?
>
> set pm3d border lt black hidden3d
> plot $foo with pm3d lc rgb variable

Ah, there we go!  Thank you.

Dan

Re: pm3d face and line color control or surface color

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

On Wednesday, 10 June, 2015 14:29:27 Daniel J Sebald wrote:
> I have a question for anyone who might know how pm3d color can be 
> controlled.  I'm trying to do something that is actually rather simple, 
> which is basically a 3D surface plot with a color different from 
> white/background.  Think of a typical hidden3d surface plot but with the 
> interior of the mesh elements with a color other than white.

I do not know of any way to produce a hidden3d plot with colored
faces.  The hidden3d code does not draw the surface quadrangles at all.
I.e. they are not "white", they are simply not drawn at all and the
objects behind them are not drawn either.


> I can get something close using pm3d, but not exactly.  Also, pm3d has 
> the limitation of not working so well with hidden3d, but that's of 
> secondary importance.  In the demo
> 
> rgb_variable.dem
> 
> are a couple examples where the pm3d colors can be controlled with color 
> information in a file.  It is something like this:
> 
> with pm3d lc rgb variable
>
> and with RGB values in the data file, all having the same value, the 
> pm3d plot does come out to have the correct color.  It's a bit odd in 
> the sense that "lc" or "linecolor" controls the face color, rather than 
> some line color.  Unfortunately, the lines used in the pm3d plot seems 
> random, perhaps, or not controllable as far as I can tell.  I try 
> something like
> 
> with pm3d lc rgb variable linestyle 2
> 
> and that cause pm3d to go back to using palette lookup for the color 
> (which is at the extreme end of the palette because RGB triples work out 
> to very large numbers).
> 
> Is there some way of controlling face color and line color in pm3d at 
> the moment?

set pm3d border lt black hidden3d
plot $foo with pm3d lc rgb variable

	Ethan

pm3d face and line color control or surface color

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

I have a question for anyone who might know how pm3d color can be 
controlled.  I'm trying to do something that is actually rather simple, 
which is basically a 3D surface plot with a color different from 
white/background.  Think of a typical hidden3d surface plot but with the 
interior of the mesh elements with a color other than white.

I can get something close using pm3d, but not exactly.  Also, pm3d has 
the limitation of not working so well with hidden3d, but that's of 
secondary importance.  In the demo

rgb_variable.dem

are a couple examples where the pm3d colors can be controlled with color 
information in a file.  It is something like this:

with pm3d lc rgb variable

and with RGB values in the data file, all having the same value, the 
pm3d plot does come out to have the correct color.  It's a bit odd in 
the sense that "lc" or "linecolor" controls the face color, rather than 
some line color.  Unfortunately, the lines used in the pm3d plot seems 
random, perhaps, or not controllable as far as I can tell.  I try 
something like

with pm3d lc rgb variable linestyle 2

and that cause pm3d to go back to using palette lookup for the color 
(which is at the extreme end of the palette because RGB triples work out 
to very large numbers).

Is there some way of controlling face color and line color in pm3d at 
the moment?

Dan

Re: Re: gnuplot 5.0.1?

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

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: Merritt Ethan ; Tatsuro MATSUOKA 
> Cc: gnuplot-beta
> Date: 2015/6/8, Mon 05:11
> Subject: Re: Re: gnuplot 5.0.1?
> 
> --- Tatsuro MATSUOKA wrote:
>>  ----- Original Message -----
>>  >From: sfeam 
>>  >To: Tatsuro MATSUOKA
>>  >Cc: gnuplot-beta
>>  >Date: 2015/6/7, Sun 14:25
>>  >Subject: Re: gnuplot 5.0.1?
>>  > 
>>  >
>>  > 
>>  >On Sunday, 07 June 2015 Tatsuro MATSUOKA <tma...@ya...> 
> wrote:
>>  >> The gnuplot web site announces that ver. 5.0.1 is released.
>>  >> 
>>  >> http://www.gnuplot.info/ReleaseNotes_5_0_1.html
>>  >> 
>>  >> 
>>  >> However, on the sourceforge site does not contain 5.0.1 contents.
>>  >> 
>>  >> Is this mere delay of sourceforge site?
>>  > 
>>  >Karl Ratzsch requested that we look at Bug #1594 before releasing 5.0.1 
> 
>>  >There has been some discussion, so I have waited to learn if
>>  >there is agreement how it should be fixed.
>>  > 
>>  >Right now I am leaning towards restoring 4.6.6 behavior (second 
> bracketed
>>  >range applies to column 2 of input data, which makes sense, and that
>>  >column is called z, which makes no sense to me but it's been like 
> that
>>  >for 5 years). I will also print a warning line to the console
>>  >and to the log file stating exactly what is done, if anything, to
>>  >filter input based on the range of the independent variable.
>>  > 
>>  >The output in the log file would look like this:
>>  > 
>> 
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>  >FIT:    data read from 'lcdemo.dat'
>>  >format = z
>>  >Warning: using last bracketed range to filter input data lines
>>  >based on value of the independent variable in column 2
>>  >independent variable range restricted to [1.02700 : 1.05000]
>>  >#datapoints = 14
>>  >residuals are weighted equally (unit weight)
>> 
>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>  > 
>>  >If people are OK with that I will prepare a release tarball tomorrow
>>  >containing that one change from today's cvs.
>>  >If there is no agreement, I will prepare a release tarball that does
>>  >not contain a fix for Bug #1594 but will add it to the "KNOWN 
> ISSUES"
>>  >section of the release notes.
>>  > 
>>  >best regards,
>>  > 
>>  >Ethan
>>  > 
>>  Thank you for your quick response.
>>  I understand situation.
>> 
>>  I will wait a new release come up.
>> 
>>  Tatsuro 
>> 
> I have found that source of gnuplot-5.0.1 was uploaded on the SourceForge site.
> 
> I will prepare windows binary asap,
> 
> Tatsuro



I have prepared windows binaries and Ethan has uploaded them on SourceForge site.
Enjoy new version of gnuplot 5.0.1.

http://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.1/


Tatsuro

Re: Re: gnuplot 5.0.1?

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

--- Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> >From: sfeam 
> >To: Tatsuro MATSUOKA
> >Cc: gnuplot-beta
> >Date: 2015/6/7, Sun 14:25
> >Subject: Re: gnuplot 5.0.1?
> > 
> >
> > 
> >On Sunday, 07 June 2015 Tatsuro MATSUOKA <tma...@ya...> wrote:
> >> The gnuplot web site announces that ver. 5.0.1 is released.
> >> 
> >> http://www.gnuplot.info/ReleaseNotes_5_0_1.html
> >> 
> >> 
> >> However, on the sourceforge site does not contain 5.0.1 contents.
> >> 
> >> Is this mere delay of sourceforge site?
> > 
> >Karl Ratzsch requested that we look at Bug #1594 before releasing 5.0.1 
> >There has been some discussion, so I have waited to learn if
> >there is agreement how it should be fixed.
> > 
> >Right now I am leaning towards restoring 4.6.6 behavior (second bracketed
> >range applies to column 2 of input data, which makes sense, and that
> >column is called z, which makes no sense to me but it's been like that
> >for 5 years). I will also print a warning line to the console
> >and to the log file stating exactly what is done, if anything, to
> >filter input based on the range of the independent variable.
> > 
> >The output in the log file would look like this:
> > 
> >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >FIT:    data read from 'lcdemo.dat'
> >format = z
> >Warning: using last bracketed range to filter input data lines
> >based on value of the independent variable in column 2
> >independent variable range restricted to [1.02700 : 1.05000]
> >#datapoints = 14
> >residuals are weighted equally (unit weight)
> >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > 
> >If people are OK with that I will prepare a release tarball tomorrow
> >containing that one change from today's cvs.
> >If there is no agreement, I will prepare a release tarball that does
> >not contain a fix for Bug #1594 but will add it to the "KNOWN ISSUES"
> >section of the release notes.
> > 
> >best regards,
> > 
> >Ethan
> > 
> Thank you for your quick response.
> I understand situation.
> 
> I will wait a new release come up.
> 
> Tatsuro 
> 
I have found that source of gnuplot-5.0.1 was uploaded on the SourceForge site.

I will prepare windows binary asap,

Tatsuro

Fwd: Re: fit ignores yrange

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

[Ooops, forgot CC to list...]

Am 06.06.2015 um 18:08 schrieb sfeam:
> Version 4.2.5 (Feb 2009)
>
> Syntax:
>
> fit {[xrange] {[yrange]}} <function> '<datafile>'
>
> Ranges may be specified to temporarily limit the data which is to be fitted;
>
> any out-of-range data points are ignored. The syntax is
>
> [{dummy_variable=}{<min>}{:<max>}],

That syntax description has, unfortunately, been subtly wrong forever
(as in: since at least version 3.7.3).  The actual syntax was never
fully expressible in a single rule, because of the difference between
1-var and 2-var fits:

	# 2-var fit:
	fit {<xrange> {<yrange> {<zrange>}}} <function>
	# 1-var fit:
	fit {<xrange> {<zrange>}} <function>

where <xrange>  and <yrange> are of the form

	[{<dummy_var>=}{<min>}{:<max>}]

and <zrange> is

	[<min>{:<max>}]

The difference is that it makes no sense to change the name of the
dependent variable, because that doesn't appear anywhere.  We call it
'z' only because the corresponding data columns need some name they can
be referred to by.  And fit has always refused to allow it, too:

gnuplot> fit [][zz=0:8] a*x+b 'tfit.dat' u 1:2 via a,b
                 ^
          Can't re-name 'y' in a one-variable fit


> Given the ambiguity of whether the second pair of inline brackets
>
> in a fit command refers to y or z, isn't it better not to allow this at all,
>
> or issue a warning:
>
> gnuplot> fit [][ymin:ymax] f(x) 'data' via a,b
>
> Warning: bracketed range on "y" is ignored

No, it's not better, because it breaks script compatibility for no
benefit, nor is that range actually supposed to be for the y axis.

Fit has long been different from (s)plot in one important regard: the
distinction between plot and splot does not exist, so a single command
(and its documentation) has to cover both 2D and 3D dataset situations.
  This creates some additional complications both for the documentation
and for command parsing.

A long time ago we decided to handle this complication in the
documentation by always referring to a fit's dependent variable as 'z',
even if it's a 1-variable fit.  The code was only changed to mimic this
much later, IIRC as part of the extension to more than two independent
variables in 'fit'.

> Maybe we should fix this and *require* the z= form of the command?

No.  We just have to fix the bug in the implementation (which I already
did), and update the documentation to reflect both past and current reality.

Re: gnuplot 5.0.1?

[Karl R. <ra...@un...>]

Am 07.06.2015 um 08:56 schrieb pl...@pi...:
> On 07/06/15 07:25, sfeam wrote:
>> On Sunday, 07 June 2015 Tatsuro MATSUOKA <tma...@ya...> wrote:

>>  > The gnuplot web site announces that ver. 5.0.1 is released.

>> Karl Ratzsch requested that we look at Bug #1594 before releasing 5.0.1

With the fix Hans-Bernhard submitted, the problem seems quite solved
for me. Version 4.6 behaviour is restored, I see no technical reason
to hold up 5.0.1 any more.

I've uploaded two small patches for the docs and for the
errormessage when someone tries to rename the dependent variable
(still named it "y").
https://sourceforge.net/p/gnuplot/bugs/1594/#dd43


> If a warning is to be printed to console, I think this should be AFTER 

Perhaps the final result output should always report _any_ range
specs that was in place during the fit:

I find it pretty obvious that a range filter might cut off an
outlying datapoint. If that range is specified in the "fit" command,
the user should be well aware of it. What concerns me more is that a
forgotten "set zrange" from the last 3D plot could cut off half the
datapoints in a fit and it's never noticed.


   Karl

Re: gnuplot 5.0.1?

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

On 07/06/15 07:25, sfeam wrote:
> On Sunday, 07 June 2015 Tatsuro MATSUOKA <tma...@ya...> wrote:
>
>  > The gnuplot web site announces that ver. 5.0.1 is released.
>
>  >
>
>  > http://www.gnuplot.info/ReleaseNotes_5_0_1.html
>
>  >
>
>  >
>
>  > However, on the sourceforge site does not contain 5.0.1 contents.
>
>  >
>
>  > Is this mere delay of sourceforge site?
>
> Karl Ratzsch requested that we look at Bug #1594 before releasing 5.0.1
>
> There has been some discussion, so I have waited to learn if
>
> there is agreement how it should be fixed.
>
> Right now I am leaning towards restoring 4.6.6 behavior (second bracketed
>
> range applies to column 2 of input data, which makes sense, and that
>
> column is called z, which makes no sense to me but it's been like that
>
> for 5 years). I will also print a warning line to the console
>
> and to the log file stating exactly what is done, if anything, to
>
> filter input based on the range of the independent variable.
>
> The output in the log file would look like this:
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> FIT: data read from 'lcdemo.dat'
>
> format = z
>
> Warning: using last bracketed range to filter input data lines
>
> based on value of the independent variable in column 2
>
> independent variable range restricted to [1.02700 : 1.05000]
>
> #datapoints = 14
>
> residuals are weighted equally (unit weight)
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> If people are OK with that I will prepare a release tarball tomorrow
>
> containing that one change from today's cvs.
>
> If there is no agreement, I will prepare a release tarball that does
>
> not contain a fix for Bug #1594 but will add it to the "KNOWN ISSUES"
>
> section of the release notes.
>
> best regards,
>
> Ethan
>


If a warning is to be printed to console, I think this should be AFTER 
all the usual stream of output during fit and the fit results and stats, 
otherwise it is likely to go completely unnoticed.


  ".... independent variable in column 2....independent variable range 
restricted   "

Isn't col 2 treated as being the DEPENDANT variable?

Also explicitly stating col 2 will not be correct if 'using' clause says 
otherwise !  eg using 1:3  or 1:($3+$4)


"residuals are weighted equally (unit weight)"

This would be a good place to state explicitly that the ( correctly 
named ) independant variable : x or column 1 or whatever was specified 
in 'using' clause is assumed to have zero error unless xyerror options 
is used.


While your argument that gnuplot should just assume that users are using 
the function "responsibly"  seems sensible, the problem is that a 
worrying proportion of people even at PhD level seem blissfully unaware 
of the basic assumptions involved in LSQ fitting and thus are not act 
responsibly.

You don't need to search very far before finding someone using LSQ on a 
scatter plot between two error laden experimental variables, usually 
resulting in regression dilution and erroneously low fitted "slope". 
This is often visible obvious if one is aware of the problem but people 
have so much faith in LSQ that they never question it.

If a message is now deemed necessary due to the rather crazy changes 
made 5 years ago, this presents a good opportunity to help users be 
aware of the assumption of zero ( or negligible ) error in x  in LSQ 
fitting.

This may at least prompt them to inform themselves of the issue.

Peter.

Re: gnuplot 5.0.1?

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

----- Original Message -----
>From: sfeam 
>To: Tatsuro MATSUOKA
>Cc: gnuplot-beta
>Date: 2015/6/7, Sun 14:25
>Subject: Re: gnuplot 5.0.1?
> 
>
> 
>On Sunday, 07 June 2015 Tatsuro MATSUOKA <tma...@ya...> wrote:
>> The gnuplot web site announces that ver. 5.0.1 is released.
>> 
>> http://www.gnuplot.info/ReleaseNotes_5_0_1.html
>> 
>> 
>> However, on the sourceforge site does not contain 5.0.1 contents.
>> 
>> Is this mere delay of sourceforge site?
> 
>Karl Ratzsch requested that we look at Bug #1594 before releasing 5.0.1 
>There has been some discussion, so I have waited to learn if
>there is agreement how it should be fixed.
> 
>Right now I am leaning towards restoring 4.6.6 behavior (second bracketed
>range applies to column 2 of input data, which makes sense, and that
>column is called z, which makes no sense to me but it's been like that
>for 5 years). I will also print a warning line to the console
>and to the log file stating exactly what is done, if anything, to
>filter input based on the range of the independent variable.
> 
>The output in the log file would look like this:
> 
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>FIT:    data read from 'lcdemo.dat'
>format = z
>Warning: using last bracketed range to filter input data lines
>based on value of the independent variable in column 2
>independent variable range restricted to [1.02700 : 1.05000]
>#datapoints = 14
>residuals are weighted equally (unit weight)
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
>If people are OK with that I will prepare a release tarball tomorrow
>containing that one change from today's cvs.
>If there is no agreement, I will prepare a release tarball that does
>not contain a fix for Bug #1594 but will add it to the "KNOWN ISSUES"
>section of the release notes.
> 
>best regards,
> 
>Ethan
> 
Thank you for your quick response.
I understand situation.

I will wait a new release come up.

Tatsuro 

Re: gnuplot 5.0.1?

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

On Sunday, 07 June 2015 Tatsuro MATSUOKA <tma...@ya...> wrote:
> The gnuplot web site announces that ver. 5.0.1 is released.
> 
> http://www.gnuplot.info/ReleaseNotes_5_0_1.html
> 
> 
> However, on the sourceforge site does not contain 5.0.1 contents.
> 
> Is this mere delay of sourceforge site?

Karl Ratzsch requested that we look at Bug #1594 before releasing 5.0.1   
There has been some discussion, so I have waited to learn if
there is agreement how it should be fixed.

Right now I am leaning towards restoring 4.6.6 behavior (second bracketed
range applies to column 2 of input data, which makes sense, and that
column is called z, which makes no sense to me but it's been like that
for 5 years). I will also print a warning line to the console
and to the log file stating exactly what is done, if anything, to
filter input based on the range of the independent variable.

The output in the log file would look like this:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
FIT:    data read from 'lcdemo.dat'
        format = z
        Warning: using last bracketed range to filter input data lines
                 based on value of the independent variable in column 2
        independent variable range restricted to [1.02700 : 1.05000]
        #datapoints = 14
        residuals are weighted equally (unit weight)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

If people are OK with that I will prepare a release tarball tomorrow
containing that one change from today's cvs.
If there is no agreement, I will prepare a release tarball that does
not contain a fix for Bug #1594 but will add it to the "KNOWN ISSUES"
section of the release notes.

	best regards,

		Ethan

> 
> Tatsuro

gnuplot 5.0.1?

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

The gnuplot web site announces that ver. 5.0.1 is released.

http://www.gnuplot.info/ReleaseNotes_5_0_1.html


However, on the sourceforge site does not contain 5.0.1 contents.

Is this mere delay of sourceforge site?

Tatsuro

Re: fit ignores yrange

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

On Saturday, 06 June 2015 06:59:45 PM pl...@pi... wrote:
> >
> > gnuplot> fit [][ymin:ymax] f(x) 'data' via a,b
> > Warning: bracketed range on "y" is ignored
> >
> > or
> >
> > gnuplot> fit [][ymin:ymax] f(x) 'data' via a,b
> > Error: Second bracketed range in a 1-parameter fit must begin with z=
> >

> Thanks Ethan.
> 
> that may be a start but I think the issue of whether this is legitimate 
> application of least squares regression needs to be addressed.
> 
> x is the independant variable thus any limits on the data range should 
> be expressed in x coordinates.

>From a data-centric viewpoint, I don't think I buy that argument.
When both x and y are experimentally determined values, why should
you be able to limit the acceptable range of one but not the other?

> Since y ( or z ) values are assumed by the fitting algo to be error 
> laden using them to select a range is not valid.  

I do not follow your line of thinking there, unless you are
suggesting that the limit should be applied to (y +/- yerror)
rather than to y.

Anyhow, there can also be errors associated with x.

I realize the default form of the fit command does not handle errors on x,
but version 5 introduced an option "fit xyerror" that does.

> If there is a 
> need/desire to do this maybe the regression should be being done the 
> other way around.
> 
> There are huge problems in many fields of science from the lack of 
> appreciation of the assumptions and pre-conditions required for 
> least-squares to provide a result that is a valid estimator of the 
> regressed function.
> 
> Perhaps someone could suggest why this feature is there at all and in 
> which circumstances it can be considered a legitimate application of LSQ.

If you mean "why do we allow bracketed ranges in the fit command?"
the only justification I see is backwards compatibility.
I recommend against using bracketed ranges in any of the commands,
'plot', 'fit', or 'stats'.  

If you mean "why do we allow filtering on z range?", I think that
is a case of providing a tool and leaving it up to the user to make
responsible use of it.   I don't use gnuplot's fit routine that much,
and when I do I usually pre-filter the data in an external tool before
giving it to gnuplot.  But there are times when it is convenient
to filter on the range of either x or y in 2D experimental data,
or on the range of all observed values in higher dimensional data.

	Ethan

Re: fit ignores yrange

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

On 06/06/15 18:08, sfeam wrote:
> On Saturday, 06 June 2015 08:48:38 AM pl...@pi... wrote:
>
>  >
>
>  > I don't understand where z comes into the discussion in x,y data. :?
>
>  >
>
> Digging into the history of "fit" documentation, here are extracts from
>
> gnuplot.doc for earlier gnuplot versions. (irrelevant lines trimmed)
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Version 4.2.5 (Feb 2009)
>
> Syntax:
>
> fit {[xrange] {[yrange]}} <function> '<datafile>'
>
> Ranges may be specified to temporarily limit the data which is to be fitted;
>
> any out-of-range data points are ignored. The syntax is
>
> [{dummy_variable=}{<min>}{:<max>}],
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Version 4.4.0 (Feb 2010)
>
> The `fit` command can fit a user-supplied expression to a set of data points
>
> (x,z) or (x,y,z), using an implementation of the nonlinear least-squares
>
> (NLLS) Marquardt-Levenberg algorithm.
>
> Syntax:
>
> fit {<ranges>} <expression>
>
> Ranges may be specified to temporarily limit the data which is to be fitted;
>
> any out-of-range data points are ignored. The syntax is
>
> [{dummy_variable=}{<min>}{:<max>}],
>
> The default data formats for fitting functions with a single
>
> independent variable, z=f(x), are z or x:z.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> So the change from treating the function range as "y" to treating it as "z"
>
> happened in the 4.3 development period and first appeared in the 4.4
> release.
>
> I have confirmed that the 4.4.0 executable applied "set zrange"
>
> rather than "set yrange" as a filter on data read by
>
> fix f(x) 'data'
>
> So really this discussion is about 5 years too late.
>
> We do try to maintain backwards compatibility where possible,
>
> but ...
>
> Given the ambiguity of whether the second pair of inline brackets
>
> in a fit command refers to y or z, isn't it better not to allow this at all,
>
> or issue a warning:
>
> gnuplot> fit [][ymin:ymax] f(x) 'data' via a,b
>
> Warning: bracketed range on "y" is ignored
>
> Note that the documentation has always [incorrectly!] implied that it would
>
> work to say
>
> gnuplot> fit [][z=ymin:ymax] f(x) 'data' via a,b
>
> Maybe we should fix this and *require* the z= form of the command?
>
> gnuplot> fit [][ymin:ymax] f(x) 'data' via a,b
>
> Error: Second bracketed range in a 1-parameter fit must begin with z=
>
> Ethan

Thanks Ethan.

that may be a start but I think the issue of whether this is legitimate 
application of least squares regression needs to be addressed.

x is the independant variable thus any limits on the data range should 
be expressed in x coordinates.

Since y ( or z ) values are assumed by the fitting algo to be error 
laden using them to select a range is not valid.  If there is a 
need/desire to do this maybe the regression should be being done the 
other way around.

There are huge problems in many fields of science from the lack of 
appreciation of the assumptions and pre-conditions required for 
least-squares to provide a result that is a valid estimator of the 
regressed function.

Perhaps someone could suggest why this feature is there at all and in 
which circumstances it can be considered a legitimate application of LSQ.

Peter.



>
>  > >> It's a rather bad regression against previous versions, and one that's
>
>  > >> possibly hard to spot for some people. It'd be great if the next
> release
>
>  > >> contained a fix.
>
>  > >>
>
>  > >> Many thanks in advance, and of course to all developers!
>
>  > >>
>
>  > >> Best regards
>
>  > >>
>
>  > >> Karl
>
>  > >>
>
>  > >>
>
>  >
>
>  > setting xrange, either explicitly or via a range parameter to fit
>
>  > command, works as expected.
>
>  >
>
>  > m=c=0.1;fit [1975:2000] lin(x) datafile u 1:2 via m,c;
>
>  >
>
>  > since x is by convention the independent variable and is REQUIRED to
>
>  > have negligible error and negligible non linear variability to
>
>  > regression to give an accurate estimation of the supposed linear
>
>  > relationship, this seems appropriate.
>
>  >
>
>  > I don't understand where z comes into the discussion in x,y data. :?
>
>  >
>
>  > Trying to set the range of the fitting process by defining a range on
>
>  > the dependent variable suggests it may be being applied correctly. I can
>
>  > understand that the algorithm doing the fitting is based on the
>
>  > assumption that x is the independent variable and that is it xrange that
>
>  > defines any subset used for a particular fit.
>
>  >
>
>  > Maybe this needs to be stated explicitly in the documentation.
>
>  >
>
>  > Peter.
>
>  >
>
>  >
>
>  >
>
>  >
>
>  >
>
>  >
>
>  >
> ------------------------------------------------------------------------------
>
>  > _______________________________________________
>
>  > gnuplot-beta mailing list
>
>  > gnu...@li...
>
>  > Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: fit ignores yrange

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

On Saturday, 06 June 2015 08:48:38 AM pl...@pi... wrote:
> 
> I don't understand where z comes into the discussion in x,y data. :?
> 

Digging into the history of "fit" documentation, here are extracts from
gnuplot.doc for earlier gnuplot versions. (irrelevant lines trimmed)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Version 4.2.5 (Feb 2009)
 Syntax:
       fit {[xrange] {[yrange]}} <function> '<datafile>'

 Ranges may be specified to temporarily limit the data which is to be fitted;
 any out-of-range data points are ignored. The syntax is
       [{dummy_variable=}{<min>}{:<max>}],
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Version 4.4.0 (Feb 2010)
 The `fit` command can fit a user-supplied expression to a set of data points
 (x,z) or (x,y,z), using an implementation of the nonlinear least-squares
 (NLLS) Marquardt-Levenberg algorithm.

 Syntax:
       fit {<ranges>} <expression>

 Ranges may be specified to temporarily limit the data which is to be fitted;
 any out-of-range data points are ignored. The syntax is
       [{dummy_variable=}{<min>}{:<max>}],

 The default data formats for fitting functions with a single
 independent variable, z=f(x), are z or x:z.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

So the change from treating the function range as "y" to treating it as "z" 
happened in the 4.3 development period and first appeared in the 4.4 release.

I have confirmed that the 4.4.0 executable applied "set zrange"
rather than "set yrange" as a filter on data read by 
    fix f(x) 'data'

So really this discussion is about 5 years too late.
We do try to maintain backwards compatibility where possible,
but ...
 
Given the ambiguity of whether the second pair of inline brackets
in a fit command refers to y or z, isn't it better not to allow this at all,
or issue a warning:
   gnuplot> fit [][ymin:ymax] f(x) 'data' via a,b
   Warning:  bracketed range on "y" is ignored

Note that the documentation has always [incorrectly!] implied that it would
work to say
   gnuplot> fit [][z=ymin:ymax] f(x) 'data' via a,b

Maybe we should fix this and *require* the z= form of the command?
   gnuplot> fit [][ymin:ymax] f(x) 'data' via a,b
   Error:   Second bracketed range in a 1-parameter fit must begin with z=


			Ethan

> >> It's a rather bad regression against previous versions, and one that's
> >> possibly hard to spot for some people. It'd be great if the next release
> >> contained a fix.
> >>
> >> Many thanks in advance, and of course to all developers!
> >>
> >> Best regards
> >>
> >>     Karl
> >>
> >>
> 
> setting xrange, either explicitly or via a range parameter to fit 
> command, works as expected.
> 
>   m=c=0.1;fit [1975:2000] lin(x) datafile u 1:2 via m,c;
> 
> since x is by convention the independent variable and is REQUIRED to 
> have negligible  error  and negligible non linear variability to 
> regression to give an accurate estimation of the supposed linear 
> relationship, this seems appropriate.
> 
> I don't understand where z comes into the discussion in x,y data. :?
> 
> Trying to set the range of the fitting process by defining a range on 
> the dependent variable suggests it may be being applied correctly. I can 
> understand that the algorithm doing the fitting is based on the 
> assumption that x is the independent variable and that is it xrange that 
> defines any subset used for a particular fit.
> 
> Maybe this needs to be stated explicitly in the documentation.
> 
> Peter.
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: fit ignores yrange

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

On 05/06/15 22:49, Ethan A Merritt wrote:
> On Friday, 05 June, 2015 16:36:12 Karl Ratzsch wrote:
>> Hi,
>>
>> as Ethan has started preparing the release of 5.0pl1, I wanted to draw
>> attention to this bug
>>
>> https://sourceforge.net/p/gnuplot/bugs/1594/
>>
>> . Since gp5.0, "fit" ignores any set y range, both from "set yrange" or
>> inline.
>
> As I understand it, all fits now use "z" as the function range variable.
> So in order to restrict the function range, use
>
>    set zrange [min:max]
>
> I don't know what the intent was with regard to adding in-line
> range restrictions in the "fit" command.
>
> 	Ethan
>
>
>
>
>> It's a rather bad regression against previous versions, and one that's
>> possibly hard to spot for some people. It'd be great if the next release
>> contained a fix.
>>
>> Many thanks in advance, and of course to all developers!
>>
>> Best regards
>>
>>     Karl
>>
>>

setting xrange, either explicitly or via a range parameter to fit 
command, works as expected.

  m=c=0.1;fit [1975:2000] lin(x) datafile u 1:2 via m,c;

since x is by convention the independent variable and is REQUIRED to 
have negligible  error  and negligible non linear variability to 
regression to give an accurate estimation of the supposed linear 
relationship, this seems appropriate.

I don't understand where z comes into the discussion in x,y data. :?

Trying to set the range of the fitting process by defining a range on 
the dependent variable suggests it may be being applied correctly. I can 
understand that the algorithm doing the fitting is based on the 
assumption that x is the independent variable and that is it xrange that 
defines any subset used for a particular fit.

Maybe this needs to be stated explicitly in the documentation.

Peter.

Re: fit ignores yrange

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

On Friday, 05 June, 2015 23:07:19 Hans-Bernhard Bröker wrote:
> Am 05.06.2015 um 22:49 schrieb Ethan A Merritt:
> 
> > I don't know what the intent was with regard to adding in-line
> > range restrictions in the "fit" command.
> 
> The intent should be obvious: 'fit' should accept the same data input 
> options as 'plot'.  That's what the documentation always said, and it's 
> what the code did until two years ago, and almost did even after that 
> change.
> 
> Overriding 'set' options on-the-fly has been possible in gnuplot since 
> day one, and 'fit' was no exception to that, nor should it be.
> 
> 'fit' actually still did honor a yrange ... but only in a fit with more 
> than one independent variable.  The yrange was ignored only if there was 
> one variable, but two range specifications.

Exactly.  

'fit' is treating y as the name of an independent variable, not
as the name of the result f(x).  The question is whether the
intent was to allow
   fit [xmin:xmax][zmin:zmax]  f(x) 'data'
even though the plot command, the documentation, and the
current fit command all treat the second bracketed range
as a restriction on y rather than on z.

Alternatively the intent of 
  "f(x, y, ...) = z  even for the case f(x) = z" 
might have been to allow
   fit [xmin:xmax][][zmin:zmax] f(x) 'data'

I.e. a range restriction on z requires 3 bracketed pairs
even if there is no 'y'.

Neither of these works at the moment, but which would
cause the least confusion?

	Ethan

Re: fit ignores yrange

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

Am 05.06.2015 um 22:49 schrieb Ethan A Merritt:

> I don't know what the intent was with regard to adding in-line
> range restrictions in the "fit" command.

The intent should be obvious: 'fit' should accept the same data input 
options as 'plot'.  That's what the documentation always said, and it's 
what the code did until two years ago, and almost did even after that 
change.

Overriding 'set' options on-the-fly has been possible in gnuplot since 
day one, and 'fit' was no exception to that, nor should it be.

'fit' actually still did honor a yrange ... but only in a fit with more 
than one independent variable.  The yrange was ignored only if there was 
one variable, but two range specifications.

Re: fit ignores yrange

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

On Friday, 05 June, 2015 16:36:12 Karl Ratzsch wrote:
> Hi,
> 
> as Ethan has started preparing the release of 5.0pl1, I wanted to draw
> attention to this bug
> 
> https://sourceforge.net/p/gnuplot/bugs/1594/
> 
> . Since gp5.0, "fit" ignores any set y range, both from "set yrange" or
> inline.

As I understand it, all fits now use "z" as the function range variable.
So in order to restrict the function range, use

  set zrange [min:max]

I don't know what the intent was with regard to adding in-line
range restrictions in the "fit" command.

	Ethan




> It's a rather bad regression against previous versions, and one that's
> possibly hard to spot for some people. It'd be great if the next release
> contained a fix.
> 
> Many thanks in advance, and of course to all developers!
> 
> Best regards
> 
>    Karl
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: "make distclean" fails with cvs HEAD

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

Am 05.06.2015 um 11:50 schrieb Jun T.:
> With the latest cvs HEAD, "make distclean" fails as follows:

This is known, and a bug report about it has been sent to the automake 
maintainers.  No reaction yet, though.

fit ignores yrange

[Karl R. <ra...@un...>]

Hi,

as Ethan has started preparing the release of 5.0pl1, I wanted to draw
attention to this bug

https://sourceforge.net/p/gnuplot/bugs/1594/

. Since gp5.0, "fit" ignores any set y range, both from "set yrange" or
inline.

It's a rather bad regression against previous versions, and one that's
possibly hard to spot for some people. It'd be great if the next release
contained a fix.

Many thanks in advance, and of course to all developers!

Best regards

   Karl

"make distclean" fails with cvs HEAD

[Jun T. <tak...@kb...>]

With the latest cvs HEAD, "make distclean" fails as follows:

-----
Making distclean in docs
Makefile:554: ../src/.deps/doc2wxhtml-version.Po: No such file or directory
make[1]: *** No rule to make target `../src/.deps/doc2wxhtml-version.Po'.  Stop.
make: *** [distclean-recursive] Error 1
-----

The line 554 of docs/Makefile is:
include ../src/$(DEPDIR)/doc2wxhtml-version.Po

In revision 1.26, Makefile.am has been modified so that the rule for
doc2wxhtml is generated by automake. But automake places the
generated dependency file doc2wxhtml-version.Po in src/.deps/ (not
docs/.deps/) since the source file version.c is under src/.
So docs/Makefile includes src/.deps/doc2wxhtml-version.Po,
but the directory src/.deps/ has been already removed when
"make distclean" is called for the directory src/.

I'm using automake-1.13.1 and autoconf-2.69.

Re: "noreverse" is listed as option to xrange when it is no longer interpreted

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

On 05/23/2015 09:45 AM, sfeam wrote:
> On Saturday, 23 May 2015 01:56:30 AM Daniel J Sebald wrote:
>> I notice that even though "reverse/noreverse" has been deprecated,
>
> reverse/noreverse is deprecated only in the sense that its meaning
> has been restricted to the originally documented case of autoscaling.
>
>> the option setting "noreverse" appears in the list, i.e.:
>>
>> Terminal type set to 'qt'
>> gnuplot>  show xrange
>>
>> 	set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
>> Might it be better to leave out the "noreverse" value?
>
> That tells you autoscaling on x will produce the 'normal' axis layout
> with lower x values on the left side.  If it said instead
>> 	set xrange [ * : * ] reverse nowriteback  # (currently [-10.0000:10.0000] )
> that would indicate autoscaling will produce a layout with lower x values
> on the right side.

Oh yeah, reverse autoscaling.


>> From "help set xrange":
>
>   The `reverse` option reverses the direction of an autoscaled axis. For example,
>   if the data values range from 10 to 100, it will autoscale to the equivalent of
>   set xrange [100:10].  The `reverse` flag has no effect if the axis is not
>   autoscaled. NB: This is a change introduced in version 4.7.

I've built version 4.6 and the [b:a] for a < b and no "reverse" option 
does a reverse.  Was it always the case that worked?  If so, there's no 
need for a version/feature check.

Dan

Re: "noreverse" is listed as option to xrange when it is no longer interpreted

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

On Saturday, 23 May 2015 01:56:30 AM Daniel J Sebald wrote:
> I notice that even though "reverse/noreverse" has been deprecated, 

reverse/noreverse is deprecated only in the sense that its meaning
has been restricted to the originally documented case of autoscaling.

> the option setting "noreverse" appears in the list, i.e.:
> 
> Terminal type set to 'qt'
> gnuplot> show xrange
> 
> 	set xrange [ * : * ] noreverse nowriteback  # (currently [-10.0000:10.0000] )
> Might it be better to leave out the "noreverse" value?  

That tells you autoscaling on x will produce the 'normal' axis layout
with lower x values on the left side.  If it said instead
> 	set xrange [ * : * ] reverse nowriteback  # (currently [-10.0000:10.0000] )
that would indicate autoscaling will produce a layout with lower x values
on the right side.

>From "help set xrange":

 The `reverse` option reverses the direction of an autoscaled axis. For example,
 if the data values range from 10 to 100, it will autoscale to the equivalent of
 set xrange [100:10].  The `reverse` flag has no effect if the axis is not
 autoscaled. NB: This is a change introduced in version 4.7.


	Ethan



> It would be a 
> good "feature check" if the "noreverse" were no longer printed.
> 
> Of course, now that some versions have been released that do print 
> "noreverse", that sort of destroys the integrity of such a feature check.
> 
> However, even this is problematic:
> 
> gnuplot> set xrange [0:1] reverse
> gnuplot> show xrange
> 
> 	set xrange [ 0.00000 : 1.00000 ] reverse nowriteback
> 
> gnuplot> plot x
> 
> The "show" function is indicating xrange is reversed when clearly it 
> isn't.  So one can't rely on a set/show combination to determine if 
> reverse/noreverse is an acceptable syntax.
> 
> Well, don't use "reverse" keyword is the lesson, but gnuplot still 
> keeping track of reverse/noreverse and showing the option seems superfluous.
> 
> Dan