Quote

Open issues:
- handling of undefined values

Updated. Try again.

Quote

- re-calculation upon mouse release. Currently, even leaving the region will not trigger update of the plot.

I can't do that. Class describing the region doesn't contain the event - leaving the region (OnLeaving). So I can't to know about this event. Besides, I doubt that a user wants such a reaction with long calculations.

working nice on vista/0_96_4883.Mono/XYPlotRegion_20130516r1,
though I can't test Martin's open issues because I don't understand what you guys are talking about

suggestions: zoom around the mouse pointer ; button to 'reset view'

Wrote

Quote

Open issues:
- handling of undefined values

Updated. Try again.

Thanks for the update. Plotting ln(x) now works. Still I keep annoying. Division by zero causes trouble. I frequently use this as a handy trick to limit curves to certain ranges.

---

Quote

Tested in 4883 (with annoying error messages at each interaction and no way to access the context menu of the plot)

Show how it looks. I don't have any problems (xp, 0.96 build 4883, x-y plot 0.1.4884.13578).

Updated.

---

Wrote

Show how it looks. I don't have any problems (xp, 0.96 build 4883, x-y plot 0.1.4884.13578).

Updated.

Thanks for the update, problem solved. Even context menu under 4883 is now accessible (I expected this to be an issue of the main prog, still typing to the placeholder gives errors, just like typing to the canvas or other regions.)

Just to confirm this,

Resizing with the mouse (zooming, moving) will affect X and first Y(left) axis. The second Y2(right) will be static. I suppose this is by design and that simultaneous interactions with X and both Y axis could introduce unnecessary complications.

Regards,
Radovan

SMath crashes, when you try to access the context menu of the plot in SMath 4883 and 4884. It's not exactly a crash, but rather an error message, giving you the option to continue (without chance to access the context menu) or to stop the program.

Removal and inserting a new region solves the problem. The file is from the maplewrapper examples.

---

Trigonometric functions.sm (13 KiB) downloaded 119 time(s).

Wrote

SMath crashes, when you try to access the context menu of the plot in SMath 4883 and 4884. It's not exactly a crash, but rather an error message, giving you the option to continue (without chance to access the context menu) or to stop the program.

Removal and inserting a new region solves the problem. The file is from the maplewrapper examples.

I just downloaded the 4884 version and this example works fine for me. Apparently there is a new "version" in the download link.

Oscar

Wrote

SMath crashes, when you try to access the context menu of the plot in SMath 4883 and 4884. It's not exactly a crash, but rather an error message, giving you the option to continue (without chance to access the context menu) or to stop the program.

Removal and inserting a new region solves the problem. The file is from the maplewrapper examples.

I confirm this and I haven't any idea why this happening. It's really strange behavior. But doubleclick works fine.

If you change showInputData value in attached file ( showInputData="true" ) then error will disappear.

uni, please add this article to your bookmarks, you may find something useful for your plugin.
http://www.codeproject.com/Articles/32836/A-simple-C-library-for-graph-plotting

Wrote

uni, please add this article to your bookmarks, you may find something useful for your plugin.
http://www.codeproject.com/Articles/32836/A-simple-C-library-for-graph-plotting

Ok. I've seen this project before.

There is a problem with the x-y plot of functions involving eval(). Error message says "x undefined".

---

evalxy.sm (10 KiB) downloaded 99 time(s).

Hello Martin,

I suppose this has to do with the fact that the SMath and XY plots have different treatment on the variable named "x". Therefore, I suppose that the source of different treatment of eval() is connected to different "x" behavior (I might be wrong regarding this). XY plot treats the expression more similarly to Mathcad. Like in your last plot with the variable "h". It just represents the plot of y=x because variable h is note defined before (regardless to function h(x)) (like QuickGraph in Mathcad).

For instance, if we use x:=1 and then define f(x):=x^3, SMath plot will give a cubic function y=x^3 but XY plot will give y=1.

Uni could give us more precise explanation about this.

Regards,
Radovan

I'm trying to support different types of expressions and have not found easy way to get the results. Support for one type affects expression of other types. It will take time to carefully separate all the possible types of expressions. Now I use the shortest and fastest way, but it has limitations.

Is there really a need to use the function eval()? What is it for? I think that using an analogue of this function in the plugin.

Quote

I suppose this has to do with the fact that the SMath and XY plots have different treatment on the variable named "x".

Yes, it is. I use the more general case. I don't want bind to the variable name. I can't substitute the value of the variable x, so eval() doesn't work. In the original, first there is a substitution, then the calculation (I use the pre-transformations to determine the type of expression, eval() function prevents this). I'll think maybe it can somehow be workaround.

Wrote

Is there really a need to use the function eval()? What is it for? I think that using an analogue of this function in the plugin.

There were multiple occasions in the past, where users got the recommendation to speed up the performance of their calculations by use of eval(). I tried this when preparing this post. Who has ever tried to change the axes scaling by some orders of magnitude in the built in 2D graphics, knows how it feels with a slow function and the plot re-calculated after every mouse-wheel increment.

In the case of the xyplot plugin, this is relieved because recalculation does not happen unless you enforce it. And coming back to your question: I do not dare to answer what exactly the eval() function is for. Just guesses that may be wrong in some details.

I would not mind the independent variable names be limited to x and y or r and φ if that simplifies the rest of expression treatment. If you do not want x and y to show up in the expression, you are free to bind other names to that variables in advance.

SMath should provide as few as possible pitfalls and inconsistencies as possible. That is sort of driven by handbook-writing. The more consistent the program's behaviour is, the less you have to explain.

uni, are you re-engineering expression evaluation because you are unhappy with the limitations of the internal graphics functions (in terms of function evaluations, sticking to x,y,t) or just because you do not have access to Andrey's code?

As much as eval() and numerical optimization are solving some problems in SMath, it seems that this relation symbolic-numeric-eval() is the most headache-giving at the same time.

Regards,
Radovan

Wrote

There is a problem with the x-y plot of functions involving eval(). Error message says "x undefined".

As I understand eval(expression) gives a numeric result of evaluation of "expression", so, f(x)=eval((x-2m)^2) needs a previously defined value for x.

If you type "f(x)=" in SMath, you obtain the "x not defined" warning. Now, if you define a value for x, (say x=1), f(x) can be evaluated and it will give a numerical result, (f(1)=1), which is plotted as a constant in XYplot plugin.

Oscar

Wrote

Wrote

There is a problem with the x-y plot of functions involving eval(). Error message says "x undefined".

As I understand eval(expression) gives a numeric result of evaluation of "expression", so, f(x)=eval((x-2m)^2) needs a previously defined value for x.

If you type "f(x)=" in SMath, you obtain the "x not defined" warning. Now, if you define a value for x, (say x=1), f(x) can be evaluated and it will give a numerical result, (f(1)=1), which is plotted as a constant in XYplot plugin.

Oscar

eval() is used to strip any symbols down to numeric values if that is possible. In definitions, however, the dummy or formal parameters must not be touched by that mechanism. Otherwise using formal parameters inside eval() in function definitions would be an error that the system should warn about.

Things get more complicated if interactions with setting the whole formula region with function definition to symbolic or numeric optimization. To add more complexity, think of the implications of similar settings at evaluation (function call) time. This is where the plot functions have to survive.

Regardless of how things are and why: using some construct like eval should not render a function unplottable, just because there is no reason to expect such behaviour.

Wrote

Regardless of how things are and why: using some construct like eval should not render a function unplottable, just because there is no reason to expect such behaviour.

It's not so easy; when you call a primitive (a function or an object, like a graph) you can put in the placeholder anything...
Correctly (IMHO) from a plugin you can retrieve what you have written in the placeholder or what are "linked" by what you have written (if you define A(x):2*x and you write in the placeholder A(x), then you can retrieve both A(x) or 2*x); to obtain 2*x there are 2 ways, a "simple" preprocessing and a symbolic preprocessing... in both the cases the eval() function works like a super-function and force an "in-place" evaluation, so if there is something not defined an error appears. Probably Andrey can change this behavior when eval contains undefined variables - I hope not in other case, because I widely use eval() + preprocessing in my plugins :d - but I suspect that this would be not "for free" (I think about consequences on some built-in feature and obviously on the existing homemade plugins). Obviously there is a solution for everything, it is only a matter of time, work and patience


best regards,

w3b5urf3r

For now my conclusion is a new survival rule:
"Do not use eval() in functions that you want to plot with xyplotregion."

I don't know if that is a bug or a feature of function definitions in general (dummy argument namespace concept), of eval() in particular or of the plugin. Of course, the fact that the internal plot function works with eval(), is sort of a hint...