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 :-)
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 ?