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

Re: How to clear screen?

[iloveX <ah...@ya...>]

ctlr+L works for any console!
The 'system' command is very powerful though. With this keyword, any command
from linux can be executed. For example, <system "ls">" will list as usual.
<system "vi somefile"> will open somefile in vi editor and so on.



--
View this message in context: http://gnuplot.10905.n7.nabble.com/How-to-clear-screen-tp10309p17438.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: apple compiler: add explicit braces to avoid dangling else

[Mojca M. <moj...@gm...>]

On Mon, Jun 24, 2013 at 6:25 AM, Ethan Merritt wrote:
> On Saturday, June 22, 2013 11:44:36 PM Mojca Miklavec wrote:
>> On Sat, Jun 22, 2013 at 11:00 PM, Mojca Miklavec wrote:
>> > Hi,
>> >
>> > just to let you know: the compiler (I just updated to a newer version
>> > of Xcode) started complaining about "missing braces":
>> >
>> > wxterminal/wxt_gui.cpp:1500:4: warning: add explicit braces to avoid
>> > dangling else [-Wdangling-else]
>> >
>> >                         wxLogError(wxT("Cannot write raise"));
>> >                         ^
>>
>> I'm sorry, I've sent an incomplete error report earlier (because I
>> thought at first that the other errors were unrelated). The problem is
>> that wxLogError is a macro itself which expands into some if-else
>> clauses and one indeed ends up with "if ... if ... else", so maybe the
>> compiler is right after all. I'm attaching the patch. If you apply it,
>> please also patch the stable branch.
>>
>> wxterminal/wxt_gui.cpp:1500:4: warning: add explicit braces to avoid
>> dangling else [-Wdangling-else]
>>                         wxLogError(wxT("Cannot write raise"));
>>                         ^
>> /opt/local/include/wx-2.9/wx/log.h:1360:20: note: expanded from macro
>> 'wxLogError'
>> #define wxLogError wxDO_LOG_IF_ENABLED(Error)
>>                    ^
>> /opt/local/include/wx-2.9/wx/log.h:1353:5: note: expanded from macro
>> 'wxDO_LOG_IF_ENABLED'
>>     else
>>  \ ^
>> wxterminal/wxt_gui.cpp:1502:4: warning: add explicit braces to avoid
>> dangling else [-Wdangling-else]
>>                         wxLogError(wxT("Cannot write persist"));
>>                         ^
>> /opt/local/include/wx-2.9/wx/log.h:1360:20: note: expanded from macro
>> 'wxLogError'
>> #define wxLogError wxDO_LOG_IF_ENABLED(Error)
>>                    ^
>> /opt/local/include/wx-2.9/wx/log.h:1353:5: note: expanded from macro
>> 'wxDO_LOG_IF_ENABLED'
>>     else
>>  \ ^
>>
>> (Of course it wouldn't hurt if wxWidgets would put a pair of braces
>> into their source code where wxDO_LOG_IF_ENABLED is defined, but
>> that's another story.)
>
> On wxt2.8 as installed here, wxLogError() is a function provided by a
> library. It is not a macro.  So the message you show makes no sense to me.
> The on-line docs also list it as a function, so far as I tell tell.

OK, I have 2.9.4, and according to this:
    https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/log.h
it seems that the code I have installed is "the latest one".

#define wxDO_LOG_IF_ENABLED(level)                                            \
    if ( !wxLog::IsLevelEnabled(wxLOG_##level, wxLOG_COMPONENT) )             \
    {}                                                                        \
    else                                                                      \
        wxDO_LOG(level)

// wxLogFatalError() is special as it can't be disabled
#define wxLogFatalError wxDO_LOG(FatalError)
#define wxVLogFatalError(format, argptr) wxDO_LOGV(FatalError, format, argptr)

#define wxLogError wxDO_LOG_IF_ENABLED(Error)


Unless you consider this being a bug in wxt and someone submits a bug
report, this will probably end up in 3.0, so one would face the
problem sooner or later.

Mojca

Re: apple compiler: add explicit braces to avoid dangling else

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

On Saturday, June 22, 2013 11:44:36 PM Mojca Miklavec wrote:
> On Sat, Jun 22, 2013 at 11:00 PM, Mojca Miklavec wrote:
> > Hi,
> > 
> > just to let you know: the compiler (I just updated to a newer version
> > of Xcode) started complaining about "missing braces":
> > 
> > wxterminal/wxt_gui.cpp:1500:4: warning: add explicit braces to avoid
> > dangling else [-Wdangling-else]
> > 
> >                         wxLogError(wxT("Cannot write raise"));
> >                         ^
> 
> I'm sorry, I've sent an incomplete error report earlier (because I
> thought at first that the other errors were unrelated). The problem is
> that wxLogError is a macro itself which expands into some if-else
> clauses and one indeed ends up with "if ... if ... else", so maybe the
> compiler is right after all. I'm attaching the patch. If you apply it,
> please also patch the stable branch.
> 
> wxterminal/wxt_gui.cpp:1500:4: warning: add explicit braces to avoid
> dangling else [-Wdangling-else]
>                         wxLogError(wxT("Cannot write raise"));
>                         ^
> /opt/local/include/wx-2.9/wx/log.h:1360:20: note: expanded from macro
> 'wxLogError'
> #define wxLogError wxDO_LOG_IF_ENABLED(Error)
>                    ^
> /opt/local/include/wx-2.9/wx/log.h:1353:5: note: expanded from macro
> 'wxDO_LOG_IF_ENABLED'
>     else                                                                    
>  \ ^
> wxterminal/wxt_gui.cpp:1502:4: warning: add explicit braces to avoid
> dangling else [-Wdangling-else]
>                         wxLogError(wxT("Cannot write persist"));
>                         ^
> /opt/local/include/wx-2.9/wx/log.h:1360:20: note: expanded from macro
> 'wxLogError'
> #define wxLogError wxDO_LOG_IF_ENABLED(Error)
>                    ^
> /opt/local/include/wx-2.9/wx/log.h:1353:5: note: expanded from macro
> 'wxDO_LOG_IF_ENABLED'
>     else                                                                    
>  \ ^
> 
> (Of course it wouldn't hurt if wxWidgets would put a pair of braces
> into their source code where wxDO_LOG_IF_ENABLED is defined, but
> that's another story.)

On wxt2.8 as installed here, wxLogError() is a function provided by a
library. It is not a macro.  So the message you show makes no sense to me.
The on-line docs also list it as a function, so far as I tell tell.

	Ethan

> 
> Thank you,
>     Mojca

Re: Broken build - was: removal of pgnuplot

[Bastian M. <bma...@we...>]

Am 24.06.2013 00:58, schrieb Hans-Bernhard Bröker:
> On 24.06.2013 00:25, Bastian Märkisch wrote:
>> Am 23.06.2013 23:37, schrieb Hans-Bernhard Bröker:
>>>
>>> Oh, but while on the topic of pgnuplot: some of your recent changes
>>> related to wredirect.c seem to have broken its build.  It now reports
>>> variations of
>>>
>>> Error! E2028: MyPrintF_ is an undefined reference
>>> Error! E2028: MyFPrintF_ is an undefined reference
>>> Error! E2028: MyFGetS_ is an undefined reference
>>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>>> symbol MyPrintF_
>>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>>> symbol MyFPrintF_
>>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>>> symbol MyFGetS_
>>>
>>> on all Windows compilers I tried. Building bf_test.exe fails similarly.
>>>
>>
>> I cannot reproduce that problem here using MinGW or MSVC 2008.  The
>> intention was not to compile wredirect.cpp when using OpenWatcom, since
>> it is only helpful when using third party C++ libraries.
>
> Well, it breaks here on all three of those.  And it didn't until
> relatively recently.  Did you do a full rebuild (e.g. "wmake realclean
> all")?  Is there a possibility you have some local change to the
> Makefiles / Windows sources which would be needed?

Clean source and "(n)make veryclean && (n)make all", indeed. The only 
change to config/mingw/Makefile is that I enabled gd,wxt,cairo, and lua 
terminals. No changes at all to config/msvc/Makefile. Only building 
wgnuplot-ja.chm using the MingW makefile currently fails because the 
Japanese patches in CVS are outdated. Everything else works as it 
should. (Just double checked again.)

Are you sure that your source tree is a clean checkout?

Btw. I no longer have the possibility to check building with OpenWatcom 
or Cygwin.

>
> wredirect.cpp itself may be a red herring.  It could have been some of
> the other changes you did around that time.
>
>>> Oh, and OpenWatcom dislikes the redefinition of ETO_PDY in emf.trm. It's
>>> not used anywhere in gnuplot, and it conflicts with <wingdi.h>.
>>
>> Interesting.  That has been there since Ethan introduced enhanced text
>> support in 2008 (rev 1.55).
>
> The reason this never caused trouble before must be that we managed to
> keep the Windows headers invisible to the compilation of term.c before.

No it must be something else.  That "#include <windows.h>" line has been 
in win.trm since rev 1.1, ie. since before the beginning of the CVS 
repository, and win.trm is always included before emf.trm in src/term.h.
Anyway, that duplicate definition should be removed or protected by an 
#ifdef / #endif.

Re: Broken build - was: removal of pgnuplot

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

On 24.06.2013 00:25, Bastian Märkisch wrote:
> Am 23.06.2013 23:37, schrieb Hans-Bernhard Bröker:
>>
>> Oh, but while on the topic of pgnuplot: some of your recent changes
>> related to wredirect.c seem to have broken its build.  It now reports
>> variations of
>>
>> Error! E2028: MyPrintF_ is an undefined reference
>> Error! E2028: MyFPrintF_ is an undefined reference
>> Error! E2028: MyFGetS_ is an undefined reference
>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>> symbol MyPrintF_
>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>> symbol MyFPrintF_
>> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
>> symbol MyFGetS_
>>
>> on all Windows compilers I tried. Building bf_test.exe fails similarly.
>>
>
> I cannot reproduce that problem here using MinGW or MSVC 2008.  The
> intention was not to compile wredirect.cpp when using OpenWatcom, since
> it is only helpful when using third party C++ libraries.

Well, it breaks here on all three of those.  And it didn't until 
relatively recently.  Did you do a full rebuild (e.g. "wmake realclean 
all")?  Is there a possibility you have some local change to the 
Makefiles / Windows sources which would be needed?

wredirect.cpp itself may be a red herring.  It could have been some of 
the other changes you did around that time.

>> Oh, and OpenWatcom dislikes the redefinition of ETO_PDY in emf.trm. It's
>> not used anywhere in gnuplot, and it conflicts with <wingdi.h>.
>
> Interesting.  That has been there since Ethan introduced enhanced text
> support in 2008 (rev 1.55).

The reason this never caused trouble before must be that we managed to 
keep the Windows headers invisible to the compilation of term.c before.

Re: Broken build - was: removal of pgnuplot

[Bastian M. <bma...@we...>]

Am 23.06.2013 23:37, schrieb Hans-Bernhard Bröker:
>
> Oh, but while on the topic of pgnuplot: some of your recent changes
> related to wredirect.c seem to have broken its build.  It now reports
> variations of
>
> Error! E2028: MyPrintF_ is an undefined reference
> Error! E2028: MyFPrintF_ is an undefined reference
> Error! E2028: MyFGetS_ is an undefined reference
> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
> symbol MyPrintF_
> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
> symbol MyFPrintF_
> file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined
> symbol MyFGetS_
>
> on all Windows compilers I tried. Building bf_test.exe fails similarly.
>

I cannot reproduce that problem here using MinGW or MSVC 2008.  The 
intention was not to compile wredirect.cpp when using OpenWatcom, since 
it is only helpful when using third party C++ libraries.

> Oh, and OpenWatcom dislikes the redefinition of ETO_PDY in emf.trm. It's
> not used anywhere in gnuplot, and it conflicts with <wingdi.h>.

Interesting.  That has been there since Ethan introduced enhanced text 
support in 2008 (rev 1.55).

>
> ... and the build of the 4.6 branch is broken in fit.c for all platforms.

Should be fixed in CVS.

Re: removal of pgnuplot

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

On 23.06.2013 23:08, Hans-Bernhard Bröker wrote:
> On 23.06.2013 22:14, Bastian Märkisch wrote:
>> In other words: I am proposing to remove pgnuplot in the next release
>> altogether.  Objections?
>
> Since will break compatibility with existing installations' use of the
> tool, the 5.0 release may be the only sensible point to do that, ever.
> I'm for it --- but we should expect backlash from the users.

Oh, but while on the topic of pgnuplot: some of your recent changes 
related to wredirect.c seem to have broken its build.  It now reports 
variations of

Error! E2028: MyPrintF_ is an undefined reference
Error! E2028: MyFPrintF_ is an undefined reference
Error! E2028: MyFGetS_ is an undefined reference
file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined 
symbol MyPrintF_
file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined 
symbol MyFPrintF_
file pgnuplot.obj(c:\prg\gp\gnuplot\src\win\pgnuplot.c): undefined 
symbol MyFGetS_

on all Windows compilers I tried. Building bf_test.exe fails similarly.

Oh, and OpenWatcom dislikes the redefinition of ETO_PDY in emf.trm. 
It's not used anywhere in gnuplot, and it conflicts with <wingdi.h>.

... and the build of the 4.6 branch is broken in fit.c for all platforms.

Re: docs/Makefile.am

[Bastian M. <bma...@we...>]

Am 23.06.2013 23:06, schrieb Hans-Bernhard Bröker:
> On 23.06.2013 22:01, Bastian Märkisch wrote:
>> It looks to me like docs/Makefile.am contains a hard-coded copy
>> of the contents of src/makefile.all (which is auto-generated).  Is
>> there a reason not to just 'include' src/makefile.all?
>
> It's not actually a full copy (Makefile.all only has CORETERM, not
> COREOBJS).  And there might be a chicken-and-egg problem, what with
> docs/Makefile.am being a primary, non-generated file, and
> src/makefile.all a generated one.

Those COREOBJS won't do any harm though, would they?

>
> Nor would that "include" command necessarily do what you expect, either,
> since it'd be processed by automake rather than make.

I actually gave this a try before suggesting it.  Adding an "include" to 
docs/Makefile.am causes the generated docs/Makefile.in and docs/Makefile 
to contain a copy of src/makefile.all.  So, it seems to work just fine, 
but you might be right about the chicken-and-egg problem.

>
> The typical gnuplot way would be to generate docs/Makefile.am at
> ./prepare time, too, just like the instances of CORETERM in
> term/Makefile.am and src/makefile.all
>

Avoiding hard-coded lists would be a worthwhile project in my opinion. 
But I would probably not have enough expertise using autotools to do 
that myself.

Re: removal of pgnuplot

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

On 23.06.2013 22:14, Bastian Märkisch wrote:
> In other words: I am proposing to remove pgnuplot in the next release
> altogether.  Objections?

Since will break compatibility with existing installations' use of the 
tool, the 5.0 release may be the only sensible point to do that, ever. 
I'm for it --- but we should expect backlash from the users.

Re: docs/Makefile.am

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

On 23.06.2013 22:01, Bastian Märkisch wrote:
> It looks to me like docs/Makefile.am contains a hard-coded copy
> of the contents of src/makefile.all (which is auto-generated).  Is
> there a reason not to just 'include' src/makefile.all?

It's not actually a full copy (Makefile.all only has CORETERM, not 
COREOBJS).  And there might be a chicken-and-egg problem, what with 
docs/Makefile.am being a primary, non-generated file, and 
src/makefile.all a generated one.

Nor would that "include" command necessarily do what you expect, either, 
since it'd be processed by automake rather than make.

The typical gnuplot way would be to generate docs/Makefile.am at 
./prepare time, too, just like the instances of CORETERM in 
term/Makefile.am and src/makefile.all

USE_MOUSE

[Bastian M. <bma...@we...>]

Some terminals like wxt and windows currently cannot be compiled without 
defining USE_MOUSE.  Should we fix this or is it time to remove this 
switch altogether?

   Bastian

removal of pgnuplot

[Bastian M. <bma...@we...>]

The CVS version of gnuplot includes a console mode version (gnuplot.exe) 
which supports pipes, a windowed version (wgnuplot_pipes.exe) with 
support for pipes, and the (traditional) windows version (wgnuplot.exe) 
with (fake) pipe support from within the program.  Should version 5 
really still include 'pgnuplot' to pipe to wgnuplot.exe?

In other words: I am proposing to remove pgnuplot in the next release 
altogether.  Objections?

   Bastian

docs/Makefile.am

[Bastian M. <bma...@we...>]

It looks to me like docs/Makefile.am contains a hard-coded copy
of the contents of src/makefile.all (which is auto-generated).  Is
there a reason not to just 'include' src/makefile.all?

   Bastian

Re: apple compiler: add explicit braces to avoid dangling else

[Mojca M. <moj...@gm...>]

On Sat, Jun 22, 2013 at 11:00 PM, Mojca Miklavec wrote:
> Hi,
>
> just to let you know: the compiler (I just updated to a newer version
> of Xcode) started complaining about "missing braces":
>
> wxterminal/wxt_gui.cpp:1500:4: warning: add explicit braces to avoid
> dangling else [-Wdangling-else]
>                         wxLogError(wxT("Cannot write raise"));
>                         ^

I'm sorry, I've sent an incomplete error report earlier (because I
thought at first that the other errors were unrelated). The problem is
that wxLogError is a macro itself which expands into some if-else
clauses and one indeed ends up with "if ... if ... else", so maybe the
compiler is right after all. I'm attaching the patch. If you apply it,
please also patch the stable branch.

wxterminal/wxt_gui.cpp:1500:4: warning: add explicit braces to avoid
dangling else [-Wdangling-else]
                        wxLogError(wxT("Cannot write raise"));
                        ^
/opt/local/include/wx-2.9/wx/log.h:1360:20: note: expanded from macro
'wxLogError'
#define wxLogError wxDO_LOG_IF_ENABLED(Error)
                   ^
/opt/local/include/wx-2.9/wx/log.h:1353:5: note: expanded from macro
'wxDO_LOG_IF_ENABLED'
    else                                                                      \
    ^
wxterminal/wxt_gui.cpp:1502:4: warning: add explicit braces to avoid
dangling else [-Wdangling-else]
                        wxLogError(wxT("Cannot write persist"));
                        ^
/opt/local/include/wx-2.9/wx/log.h:1360:20: note: expanded from macro
'wxLogError'
#define wxLogError wxDO_LOG_IF_ENABLED(Error)
                   ^
/opt/local/include/wx-2.9/wx/log.h:1353:5: note: expanded from macro
'wxDO_LOG_IF_ENABLED'
    else                                                                      \
    ^

(Of course it wouldn't hurt if wxWidgets would put a pair of braces
into their source code where wxDO_LOG_IF_ENABLED is defined, but
that's another story.)

Thank you,
    Mojca

apple compiler: add explicit braces to avoid dangling else

[Mojca M. <moj...@gm...>]

Hi,

just to let you know: the compiler (I just updated to a newer version
of Xcode) started complaining about "missing braces":

wxterminal/wxt_gui.cpp:1500:4: warning: add explicit braces to avoid
dangling else [-Wdangling-else]
                        wxLogError(wxT("Cannot write raise"));
                        ^

See also
    http://stackoverflow.com/questions/12023653/how-do-i-disable-add-explicit-braces-to-avoid-dangling-else-in-new-xcode
and the comment: "imo it's a bug, but apple developer support has his
own definition of dangling-else: This is only a style warning. This
code is inherently hard to read, which is why the warning exists. If
you do not like the warning you can silence it by passing
-Wno-dangling-else to the compiler. – peko May 24 at 13:49"

It needs a trivial patch and I can send one, but only if you agree to
patch the code (= add extra braces).

Mojca

Re: contour labels

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

On Friday, June 21, 2013 08:56:09 am don taber wrote:
> I note that the revision to the contour labeling code
> in current cvs is a work in progress.  I find two problems:
> 
> 1. Contours are all drawn with the same linetype even
> when they are supposed to have different linetypes.
> Attached is a patch that fixes #1.

To the best of my knowledge this was deliberate, but I may be overlooking
a problem.  This bit of code, by the way, was not changed by the contour
labeling patch. So whatever problem you are seeing is independent of labels.

The idea is that if you give a plot command
   splot FOO with lines lt 0 
properties such as the dot pattern of lt 0 are maintained for all
of the contours jointly.  With your change, that "lt 0" would be
overwritten by whatever dash pattern was previously associated
with linetypes 4, 5, 6, etc. 

Was that your intention? 

> 2. When labels are placed on the actual contour lines
> (splot '' with labels), the labels seem very nicely
> placed.  Unfortunately, the contours themselves and the
> surface are missing.

I'm not sure I understand what you mean by "missing".

Do you mean that drawing the labels has the effect of
erasing the contour lines?  That would certainly be a bug.
The only thing I can think of that might cause that would be the
dimensions of the textbox (another new option that has only
been lightly tested).

Is the output you see from the demo equivalent that that on
the web site:

   http://gnuplot.sourceforge.net/demo_cvs/contours.html

If not, what happens if you say "set style textbox border transparent"?



On the other hand, if you mean simply that "splot ... with labels" draws
only the labels and not the lines, isn't that the expected behaviour?  
E.g.
  "[s]plot ... with points" only draws points.  
  "[s]plot ... with impulses" only draws impulses.
Why would labels be any different?

On the third hand, it is true that the code currently makes no attempt
to draw labels onto the surface itself, only onto contours drawn by
projection onto the xy plane.  This is mostly because early attempts at
labeling the surface looked terrible.  It is possible that the result
would be cleaner now that the "textbox" option has been added.

> I will leave #2 for  the instigator of the new feature. It is a good one.

Thanks for the feedback.
 
> Don Taber
> dt...@to...
> 

contour labels

[don t. <dt...@to...>]

I note that the revision to the contour labeling code
in current cvs is a work in progress.  I find two problems:

1. Contours are all drawn with the same linetype even
when they are supposed to have different linetypes.

2. When labels are placed on the actual contour lines
(splot '' with labels), the labels seem very nicely
placed.  Unfortunately, the contours themselves and the
surface are missing.

Attached is a patch that fixes #1. I will leave #2 for
the instigator of the new feature. It is a good one.

Don Taber
dt...@to...

Re: Does "fit" really need to use the axis structures?

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

On Thursday, 13 June 2013, Bastian Märkisch wrote:
> Am 12.06.2013 23:29, schrieb Ethan A Merritt:
> > In response to a request on the newsgroup, I've been looking into relaxing
> > the limit of 5 independent parameters in "fit".
> >
> > So far as I can see there are 2 reasons for this limit.
> >
> > 1)  df_readline() limits the number of fields in a 'using' clause to
> >      MAXDATACOLS, and this is currently defined as 7.
> >
> > 2)  the fit parameters can be range-limited in the "fit" command,
> >      and these ranges are stored in the axis data structures for the
> >      x, y, t, u, and v axes.
> >
> > (1) It is easy to change MAXDATACOLS, and I have confirmed that by
> > itself this doesn't break anything.
> >
> > (2) is harder to relax if it really is necessary to use the axis data
> > structures.  But is it really necessary?
> >
> > It looks to me that the only reason the axis data structures are involved
> > is that routine parse_range(), which used to be macro PARSE_NAMED_RANGE,
> > takes an axis index as input parameter and overwrites the
> > autoscale/min/max fields in that axis structure.
> > During the fit operation, these ranges are checked in the axis structure.
> >
> > Is there some other reason I am missing that requires access to the
> > axis data structures?  Can we just provide a local array containing
> > autoscale/min/max for each fit parameter and not access the axis
> > structures at all?
> >
> > 	Ethan
> 
> I am not familiar enough with the axis structures to comment on this. 
> The fitting code itself certainly does not have a restriction to the 
> number of indep. variables.  Hans-Bernhard, any comments?
> 
> Support for up to five independent variables was implemented by Jim Van 
> Zandt.  Interestingly, the discussion about the axis array was brought 
> up already in the original discussion:
> http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/8319
> 
> There was also was a proposal by SF user Hanno, where he discusses a 
> patch he was working on with support for more than 2 indep. variables. 
> Sadly, no code is attached.
> http://sourceforge.net/p/gnuplot/feature-requests/191/
> 
>    Bastian

Thanks for the feedback on understanding the current fitting code.
As I said, this is the first time I've looked at it.   

I have put a patch on SourceForge increases the number of independent
variables from 5 to 12.   In principle it could be increased much more than
that, and indeed I tested setting it as high as 99.
 
   <https://sourceforge.net/p/gnuplot/patches/625/>

First it decouples the fit variables (other than x and y) from the normal
axis structures.  That removes one cap on the maximum number of
independent variables.  The only change to current behaviour
(IMHO a benefit) is that setting a range on t/u/v does not affect
subsequent fit commands.

Having removed that limiting cap, the next one hit is MAXDATACOLS.
I've audited the code and am 99% convinced that it is OK to increase
this as needed.  The patch sets it to 14 (==MAX_VAR_NUM+2)

Finally, "fit" requires giving names ("dummy names") to the independent
variables.  The number of dummy variables is capped by MAX_VAR_NUM,
which is currently 12.    I raised that to 99 for testing, but left it at 12
in the patch.  To make it easy to set these, I've changed the code in CVS
so that "fit" will use the names (if any) previously requested by a
"set dummy x1,x2,x3,x4,...." command.  This already worked in 4.6/4.7
but only for the first two dummies (default "x" and "y").  Now it works
for as many as you like.

Hanno Hofstadt's test script was very useful in testing, so I have added
it to the CVS demo collection for both 4.6 and 4.7. 

Bastian:  I didn't try to reconcile this patch set with your patch #621 
that adds per-dimension error terms.   There may or may not be any
conflict.  At any rate this one makes it easy to read in larger numbers of
data columns, which will help if there are two input columns per dimension
needed.

	Ethan

Re: Does "fit" really need to use the axis structures?

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

On 14.06.2013 08:46, Bastian Märkisch wrote:
> Am 12.06.2013 23:29, schrieb Ethan A Merritt:

>> It looks to me that the only reason the axis data structures are involved
>> is that routine parse_range(), which used to be macro PARSE_NAMED_RANGE,
>> takes an axis index as input parameter and overwrites the
>> autoscale/min/max fields in that axis structure.

In a nutshell: data file reading refers to axis data structures (--> 
global df_axis[]), e.g. for time/date data handling and pseudo files '+' 
and '++'.

Fit has to read data.  So fit has to set up at least some semblance of 
axis data structures.  And currently, those have to be in the main 
axis_array[] because that's the only one handled by interfaces using an 
AXIS_INDEX argument (including df_axis[]).  But that axis_array[] can't 
be extended all that easily, if only because its entries are presented 
to the user by way of names ("x1", "z", "cb", ...), not numbers.

> The fitting code itself certainly does not have a restriction to the
> number of indep. variables.  Hans-Bernhard, any comments?

I wouldn't know.  It wasn't me who lifted the original restriction of 2 
independent variables, which used to be the same as with all other 
commands in gnuplot: 2.  I didn't study James Van Zandt's changes in detail.

The restriction is ultimately in how ranges are handled in gnuplot. 
Ever since the big "axis array" change in year 2000, a range has been a 
internal property of an axis, and thus completely handled by code in 
axis.c/axis.h.  This worked well as long as fit tried to model its 
behaviour after (s)plot, including its number of independent variables. 
Variable ranges for 'fit', e.g., are parsed by axis.c::parse_range().

But if we want 'fit' to support more independent variables than any 
other command in gnuplot (which it already does), or even support an 
unlimited number of them, that whole concept of

	one indepentent variable --> one range <--> one axis

will have to be given up and replaced by something else.  And that 
change would affect not just 'fit', but also 'plot', 'splot' and a good 
deal of other commands.  Ranges would get a data structure of their own, 
and axis would point to (or contain) such a range struct.

Re: Error in "fit" documentation?

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

On Thursday, 13 June 2013, Bastian Märkisch wrote:
> Am 14.06.2013 02:07, schrieb Ethan A Merritt:
> > Current documentation for "fit" says
> >
> >    Note that if you don't pecify a `using` option at all, no z standard
> >    deviations are read from the datafile even if it does have a third
> >    column, so you'll always get unit weights.
> >
> > But from looking at the code I think this is not true.  If there is
> > no using spec then the number of independent variables is always two
> > less than the number of columns in the input file, and the final
> > input column is indeed interpreted as a standard deviation on z.
> >
> I think the documentation is correct, albeit somewhat unclear. 
> Previously fit used to support only a maximum of two independent 
> variables and I think this statement stems from that era as it refers to 
> a "third" column.

> And later, the "error" is saved by the following line:
> 
>      /* only use error from data file if _explicitly_ asked for by
>       * a using spec
>       */
>      err_data[num_data++] = (columns > 2) ? v[i] : 1;
> 
> Again, we obtain unit weight without using specs.

OK, I see now.  The value "columns = 0" is carried all the way through to
this line if there is no using spec.    This is the first time I've looked at
the code in fit.c, so I'm still learning my way around it.

	Ethan

>    Bastian
> 
> > The comment in the fit.c source code is also wrong, as it claims
> > that the standard deviation is used only if there is an explicit
> > using spec.
> >
> > Have I misread this?
> >
> > 	Ethan
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Does "fit" really need to use the axis structures?

[Bastian M. <bma...@we...>]

Am 12.06.2013 23:29, schrieb Ethan A Merritt:
> In response to a request on the newsgroup, I've been looking into relaxing
> the limit of 5 independent parameters in "fit".
>
> So far as I can see there are 2 reasons for this limit.
>
> 1)  df_readline() limits the number of fields in a 'using' clause to
>      MAXDATACOLS, and this is currently defined as 7.
>
> 2)  the fit parameters can be range-limited in the "fit" command,
>      and these ranges are stored in the axis data structures for the
>      x, y, t, u, and v axes.
>
> (1) It is easy to change MAXDATACOLS, and I have confirmed that by
> itself this doesn't break anything.
>
> (2) is harder to relax if it really is necessary to use the axis data
> structures.  But is it really necessary?
>
> It looks to me that the only reason the axis data structures are involved
> is that routine parse_range(), which used to be macro PARSE_NAMED_RANGE,
> takes an axis index as input parameter and overwrites the
> autoscale/min/max fields in that axis structure.
> During the fit operation, these ranges are checked in the axis structure.
>
> Is there some other reason I am missing that requires access to the
> axis data structures?  Can we just provide a local array containing
> autoscale/min/max for each fit parameter and not access the axis
> structures at all?
>
> 	Ethan

I am not familiar enough with the axis structures to comment on this. 
The fitting code itself certainly does not have a restriction to the 
number of indep. variables.  Hans-Bernhard, any comments?

Support for up to five independent variables was implemented by Jim Van 
Zandt.  Interestingly, the discussion about the axis array was brought 
up already in the original discussion:
http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/8319

There was also was a proposal by SF user Hanno, where he discusses a 
patch he was working on with support for more than 2 indep. variables. 
Sadly, no code is attached.
http://sourceforge.net/p/gnuplot/feature-requests/191/

   Bastian

Re: Error in "fit" documentation?

[Bastian M. <bma...@we...>]

Am 14.06.2013 02:07, schrieb Ethan A Merritt:
> Current documentation for "fit" says
>
>    Note that if you don't pecify a `using` option at all, no z standard
>    deviations are read from the datafile even if it does have a third
>    column, so you'll always get unit weights.
>
> But from looking at the code I think this is not true.  If there is
> no using spec then the number of independent variables is always two
> less than the number of columns in the input file, and the final
> input column is indeed interpreted as a standard deviation on z.
>
I think the documentation is correct, albeit somewhat unclear. 
Previously fit used to support only a maximum of two independent 
variables and I think this statement stems from that era as it refers to 
a "third" column.

Actually, the code says

     columns = df_open(file_name, 7, NULL);    /* up to 7 using specs 
allowed */

df_open() is supposed to "return number of using specs", so columns == 0 
if we do not have using specs. The number of indep. variables is 
determined in the following line:

     num_indep = (columns < 3) ? 1 : columns - 2;

Which means num_indep == 1 without using specs.

And later, the "error" is saved by the following line:

     /* only use error from data file if _explicitly_ asked for by
      * a using spec
      */
     err_data[num_data++] = (columns > 2) ? v[i] : 1;

Again, we obtain unit weight without using specs.

   Bastian

> The comment in the fit.c source code is also wrong, as it claims
> that the standard deviation is used only if there is an explicit
> using spec.
>
> Have I misread this?
>
> 	Ethan

Error in "fit" documentation?

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

Current documentation for "fit" says

  Note that if you don't pecify a `using` option at all, no z standard
  deviations are read from the datafile even if it does have a third 
  column, so you'll always get unit weights.

But from looking at the code I think this is not true.  If there is
no using spec then the number of independent variables is always two
less than the number of columns in the input file, and the final 
input column is indeed interpreted as a standard deviation on z.

The comment in the fit.c source code is also wrong, as it claims
that the standard deviation is used only if there is an explicit
using spec.

Have I misread this?

	Ethan

Does "fit" really need to use the axis structures?

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

In response to a request on the newsgroup, I've been looking into relaxing
the limit of 5 independent parameters in "fit".

So far as I can see there are 2 reasons for this limit.

1)  df_readline() limits the number of fields in a 'using' clause to
    MAXDATACOLS, and this is currently defined as 7.

2)  the fit parameters can be range-limited in the "fit" command,
    and these ranges are stored in the axis data structures for the
    x, y, t, u, and v axes.

(1) It is easy to change MAXDATACOLS, and I have confirmed that by
itself this doesn't break anything.

(2) is harder to relax if it really is necessary to use the axis data
structures.  But is it really necessary?

It looks to me that the only reason the axis data structures are involved
is that routine parse_range(), which used to be macro PARSE_NAMED_RANGE,
takes an axis index as input parameter and overwrites the 
autoscale/min/max fields in that axis structure.
During the fit operation, these ranges are checked in the axis structure.

Is there some other reason I am missing that requires access to the
axis data structures?  Can we just provide a local array containing
autoscale/min/max for each fit parameter and not access the axis
structures at all?

	Ethan

Re: "Set label front" "set grid back" not working

[Christoph B. <us...@be...>]

Hi,

Am 12.06.2013 15:05, schrieb HorstSAut:
> Hello !
>
> In Gnuplot 4.6.0 I did not succeed write labels over the grid,
> even when I set label front, grid back:
>
> set grid xtics ytics
> set grid back
> set label 1 at -1,0 "This text should be in front"
> set label 1 front

the label is placed in front of the grid, but the label does not have a 
background box, so between the letters you still see the grid. You can 
see this, if you test your examples with a thicker line and a different 
color, e.g.

reset
set xrange[-3:3]
set yrange[-3:3]
set xtics 1
set ytics 1
set grid xtics ytics
set grid back lw 10 lc rgb 'red'
set label 1 at -1,0 "This text should be in front"
set label 1 front
plot -1


So with version 4.6.0 you must place a rectangle object with white 
fillcolor between grid and label:

reset
set xrange[-3:3]
set yrange[-3:3]
set xtics 1
set ytics 1
set grid xtics ytics
set grid back
set object rectangle from -1,-0.2 rto 1.8,0.4 fillcolor rgb 'white'\
     fillstyle solid 1.0 noborder
set label 1 at -1,0 "This text should be in front"
set label 1 front
plot -1

To optimize this, you must adapt the size of the rectangle to your label.

In the development version of gnuplot there is an option 'boxed' for 
labels, which allows this in an easy way:

reset
set xrange [-3:3]
set yrange[-3:3]
set xtics 1
set ytics 1
set grid xtics ytics
set grid back
set style textbox opaque noborder
set label 1 at -1,0 "This text should be in front" boxed
set label 1 front
plot -1

Christoph