Bug 128483

Created attachment 16520 [details]
Proposed patch

Nicolas' makes a good point. These items have been moved to a separate group.

Nicolas is correct that this is confusing, but the solution is, unfortunately, 
wrong.  Do not commit this patch.

The problem is that the 'x' vector serves two purposes:

  1) the X vector in the auto-created curve
  2) the vector that replaces 'x' in equations (eg, when you enter x^2)

In the ancient "barth programs kst on the subway for fun and no one else has 
even heard of it" days, equations were a type of curve, and the concepts were 
intertwined.  

Then equations ceased to be curves and became data objects, and the natural 
association went away.  So in some sense, there should be an entry for the 
curve's X, and an entry for the equation's x.  But if you are creating a new 
equation you will certainly want X and x to be the same....  But now, once 
you have created the curve and the equation, this association ceases, as you 
might plot the eq-sv verse something else with the curve dialog.

So the "edit equation" version of the dialog doesn't have anything about the 
curve.  But you do want/need to be able to edit what you mean by 
'x' (definition 2).

In any case, the "Interpolate to highest resolution vector" has nothing to do 
with curve creation.  It refers to how the equation should deal with 
different length vectors used by the equation.  It also must be in the edit 
equation version of the dialog.

We need a solution to this problem though.

On Wednesday 07 June 2006 15:22, Andrew Walker wrote:
> Nicolas' makes a good point. These items have been moved to a separate

> The problem is that the 'x' vector serves two purposes:
> 
>   1) the X vector in the auto-created curve
>   2) the vector that replaces 'x' in equations (eg, when you 
> enter x^2)

I don't get this... For me, the "X vector" combobox was used to indicate
which X vector to use in the auto-created curve and that's all. If I
want to plot x^2 with x being, say, Vec1, then I'd simply write in the
equation lineedit: "[Vec1]^2". I don't  understand why we'd need
something like an auto-interpret x as ..., especially when there is only
one dialog item to select it. Sure, it is somewhat shorter to write but
not worth the confusion it creates as far as I'm concerned.
The only case where I imagine where this makes a significant usability
difference (in terms of number of mouse clicks/keystrokes) is to switch
from plotting [Vec1]^2 to [Vec2]^2 to [Vec3]^2 etc... via simple
mouseclick, without needing to edit the equation text in the lineedit.
But I don't quite see in which workflow this would be useful. And if it
really is useful for some people, then we could provide a plugin that
takes a f(x) string and a vector as input, and computes y=f(x) (quite
simple I think, at least with the muparser stuff that I used for the
nonlinear fit plugin but probably also possible without that
dependency). It would be redundant with the case of equations taking
only one X vector, but we can keep them, if only for cases where we use
more than one input vector (a case which by the way is not really
handled with the current approach: what if you compute one vector based
on two or more other vectors ?).

So, to sum up this rather long and confusing discussion, my suggestion
would be:
- implement the changes as I suggest in bugzilla
- provide a new plugin to compute y=f(x) taking a string (e.g. x^2) and
a vector as input
- keep equations as they are now for more than one input vector (or
users reluctant to use plugins)
- forget about the interpret x as... feature in equations (I wasn't even
aware it existed and it does not "scale" to multiple vectors anyway)

Does that sound acceptable ? I'd be willing to give a try at the plugin,
using the muparser stuff already in the non-linear fit plugin, unless
there is a preference for using kst "built-in" functionality to parse
the f(x) string and compute the output vector.

Nicolas

If Nicolas' last comment sounds reasonable to everyone then it sounds to me like we should apply the patch as proposed and close the bug report.

(I've already said this on the list, but it didn't make it into the bug 
report... so here it is again).

The correct solution is to make kst do what the current UI suggests - Here is 
how:

The equation should export its X vector as a slave vector, which curves can 
use (esp including the autogenerated curves from the equation dialog), so 
that X concepts 1 and 2 could be locked.  Then if you edit the 'X Vector' in 
the equation dialog, the curve's X vector will also be changed.

It will still be possible to plot the equation's 'Y vector' against something 
besides 'X' using the curve dialog.  But this will be done by hand.

Some caveats:
-equations/curves read from existing .kst files will continue with the current 
behavior unless we decide to do some magic in the file parser (not hard, but 
possibly questionable.)

-If someone changes the X vector of a curve by hand, the automagic 
link-through will go away.

But: this solution is basically what PSDs currenly do, and it has worked very 
well there.

Created attachment 16575 [details]
Proposed patch

I believe this is the solution as proposed by Barth.

SVN commit 551198 by arwalker:

BUG:128483 Create x-slave vector for the equation which can then be modified from the edit equation dialog

 M  +2 -2      libkstapp/ksteqdialog_i.cpp  
 M  +54 -36    libkstmath/kstequation.cpp  
 M  +9 -7      libkstmath/kstequation.h  

Well, I've just tested this and I find it "awkward" for at least the following reasons (in decreasing order of importance in my opinion):
- usability: let us assume I have TIME and VEC1 vectors, and I want to look at VEC1*1.5 vs TIME. If I enter "[VEC1]*1.5" in the lineedit, and select TIME as X vector I will get what I want (this is how I've always done it). Now, if I try to use "x*1.5" and select VEC1 as X, the curve I get does not make sense and I have to hand-edit it separately, in another dialog. In the practice, I will never do it this way (entering "x*1.5" is not enough simplification vs "[VEC1]*1.5" to be worth the extra confusion and clicks) !
- memory usage: now each equation creates two vectors, which means twice as much memory usage unless there is a smart trick somewhere, while the x slave vector is nothing but a copy of the X vector selected in the dialog (if I have understood it correctly). I fail to see why this is required, and it was not the case before...

Note that I can continue working as I used to, with the added benefit that changing the X vector in the equation dialog now has the expected effect (and the drawback that equations will use twice as much memory). But I don't think using equations in the "x^2" form is usable as things are now. Maybe I just don't manage to imagine what the use case (workflow) behind it is ?

In comment #2, Barth says:
"In any case, the "Interpolate to highest resolution vector" has nothing to do 
with curve creation.  It refers to how the equation should deal with 
different length vectors used by the equation.  It also must be in the edit 
equation version of the dialog."
I had a long-standing remark from a user that even when this is unchecked, the data is interpolated despite what the UI suggests. I have tried it with a (0..10) vector and plotting vs a longer X vector, and the x and y slave vectors from the equation get the length of the longest vector even when the checkbox is unchecked. Is there something I have missed, or should I open a bug report for that ?