Bug 128483 - UI: the "quick curve creation" part of the equation dialog should be clearly separated
Summary: UI: the "quick curve creation" part of the equation dialog should be clearly ...
Status: RESOLVED FIXED
Alias: None
Product: kst
Classification: Applications
Component: general (show other bugs)
Version: 1.x
Platform: unspecified Solaris
: NOR wishlist
Target Milestone: ---
Assignee: Andrew Walker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-02 09:41 UTC by Nicolas Brisset
Modified: 2006-06-14 14:47 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed patch (10.15 KB, patch)
2006-06-08 00:22 UTC, Andrew Walker
Details
Proposed patch (10.01 KB, patch)
2006-06-13 00:00 UTC, Andrew Walker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Brisset 2006-06-02 09:41:31 UTC
Version:           1.3.0_devel (using KDE 3.4.0, compiled sources)
Compiler:          gcc version 3.4.3
OS:                SunOS (sun4u) release 5.8

I have seen many users be confused by the equation dialog (as called from the data manager->New equation). The reason is a lack of separation between the equation creation itself (choice of operators, scalars, vectors and the equation itself) and the rest, which is used to quickly create a new curve using that equation.
What I would suggest (a very simple change) is:
- include only the first 4 items (listed just above) in the "Equation" group
- create a new group called "Direct curve creation" (or something better, but you get the idea) with the X vector and "interpolate to highest ..." checkbox

That would make it much clearer that the last two items are not part of the equation object.

Another closely related point is that the equation dialog as called by double-clicking a curve using an equation contains the same "Equation" group as the plot dialog (with X vector and interpolation checkbox), but if you change the X vector there it is ignored. Another reason to just remove it from there I think :-)
Comment 1 Andrew Walker 2006-06-08 00:22:12 UTC
Created attachment 16520 [details]
Proposed patch

Nicolas' makes a good point. These items have been moved to a separate group.
Comment 2 Netterfield 2006-06-08 07:21:24 UTC
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

Comment 3 Nicolas Brisset 2006-06-08 10:27:09 UTC
> 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
Comment 4 Andrew Walker 2006-06-09 19:37:12 UTC
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.
Comment 5 Netterfield 2006-06-10 23:14:15 UTC
(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.
Comment 6 Andrew Walker 2006-06-13 00:00:08 UTC
Created attachment 16575 [details]
Proposed patch

I believe this is the solution as proposed by Barth.
Comment 7 Andrew Walker 2006-06-14 00:13:57 UTC
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  
Comment 8 Nicolas Brisset 2006-06-14 14:38:22 UTC
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 ?

Comment 9 Nicolas Brisset 2006-06-14 14:47:17 UTC
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 ?