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.