X-Y Plot Region - Extends SMath Studio with a X-Y Plot Region. - Mensajes
#121 Publicado: 22/5/2013 6:07:20
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...
In the same way you cannot use eval() with my Nonlinear Solvers, if eval() contains undefined variables (this behavior was noticed by omorr some month ago).
[edit] this is true also for the built-in solve() function.
best regards,
w3b5urf3r
If you like my plugins please consider to support the program buying a license; for personal contributions to me: paypal.me/dcprojects
A 1 usuarios les gustó este mensaje
Radovan Omorjan 22/5/2013 7:25:00
#122 Publicado: 22/5/2013 7:27:26
The same inability to use eval() may be seen in functions as arguments:
[MATH lang=eng]f.1(x):x[/MATH]
[MATH lang=eng]f.2(x):eval(x)[/MATH]
[MATH lang=eng]k(f(x),y):f(y)[/MATH]
[MATH lang=eng]k(f.1(x),5)=5[/MATH]
[MATH lang=eng]k(f.2(x),5)=#[/MATH] -- x - not defined
[MATH lang=eng]f.1(x):x[/MATH]
[MATH lang=eng]f.2(x):eval(x)[/MATH]
[MATH lang=eng]k(f(x),y):f(y)[/MATH]
[MATH lang=eng]k(f.1(x),5)=5[/MATH]
[MATH lang=eng]k(f.2(x),5)=#[/MATH] -- x - not defined
С уважением,
Михаил Каганский
A 2 usuarios les gustó este mensaje
#123 Publicado: 22/5/2013 7:56:18
Thank you for mentioned this once more 
We discussed about this many times with lots of examples of this contradictory situation. To make long story short, I think we are in some kind of "Catch-22" situation with eval() here. There are many situations where:
a ) if you do not use eval() you can not get the result
b ) the obtained result can not be used if you used eval()
and of course vice versa, more or less...
The question is. Is there any chance to get out of this paradoxal situation ?
Regards,
Radovan
We discussed about this many times with lots of examples of this contradictory situation. To make long story short, I think we are in some kind of "Catch-22" situation with eval() here. There are many situations where:
a ) if you do not use eval() you can not get the result
b ) the obtained result can not be used if you used eval()
and of course vice versa, more or less...
The question is. Is there any chance to get out of this paradoxal situation ?
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
A 3 usuarios les gustó este mensaje
#124 Publicado: 22/5/2013 8:00:09
The same inability to use eval() may be seen in functions as arguments
Yes, I suppose because the arguments preprocessing of user functions works like as I've explained in the post #120 about plugins functions
If you like my plugins please consider to support the program buying a license; for personal contributions to me: paypal.me/dcprojects
A 1 usuarios les gustó este mensaje
ioan92 23/5/2013 6:22:00
#125 Publicado: 22/5/2013 17:14:37
The source code for the function eval():
Therefore, it makes no sense to use this function where needed purely symbolic (pre)processing. This function is a numeric (TNumber eq = SMath.Math.Numeric.Expression.Calculate(args[0], store); ). Accordingly, the standard plot region is also numeric. X-Y Plot Region is not numeric since it uses a symbolic (pre)processing.
Therefore, it makes no sense to use this function where needed purely symbolic (pre)processing. This function is a numeric (TNumber eq = SMath.Math.Numeric.Expression.Calculate(args[0], store); ). Accordingly, the standard plot region is also numeric. X-Y Plot Region is not numeric since it uses a symbolic (pre)processing.
Russia ☭ forever, Viacheslav N. Mezentsev
A 2 usuarios les gustó este mensaje
#126 Publicado: 22/5/2013 19:49:08
The source code for the function eval():
Thank you for this useful information.
The problem, however, remains unresolved. There are cases when one must use eval() in a function (like the case I posted here) because there's no other way to obtain result (in my case it was too large number in the middle of a calculation). In the same time one must use tools like solve() or w3b5urf3r's NonlinearSolvers (or may like to use your wonderful extension).
So, the question is not why this is impossible (we kind of already guessed it), but how to change it from current unacceptable state in a satisfactory way.
The problem must not be totally unsolvable. If you use my example above like this:
k(eval(x);5)then if x is undefined before the call, you get the standard "x - not defined" error, but if you define x previously, then the error will say "Variables should be defined for argument-functions" (as a side note, I must say that Russian translation of this text makes more sense - "You cannot pass values inside argument-functions" ). This means that Andrey has means to differentiate cases when a function is passed as argument, and not its value. In this case, if unresolved (throwing "x - not defined" error) eval() inside such function is detected, its processing must be postponed until its invocation, in which place the usual rules should be applied to the eval() called with actual defined parameters. In other words, when preparing functions, the resulting pseudo-code must still have all unresolved eval()s inherited from its "parents" in the corresponding places, and not preprocessed results of such eval()s.
This would eliminate a lot of frustration and limitations, and allow for much higher usability and intuitivity. SMath will simply be useful, and not just a toy.
Edit:
1. I might guess that the preparation of a function creates a representation where all user-defined functions are expanded, all extension (dll) functions are represented as their entry points and all special functions are processed like in the source code that you provided above. If so, then it would make sense to define yet another dll function "eval" that would take simply SMath-syntax text and act like a "SMath inside SMath". It would be used when the conditions depicted above are met instead of usual processing.
2. The same technique could be used for other special functions that create problems inside argument-functions, like str2num().
3. It is already possible for SMath to correctly process expressions which have some placeholders not filled (consider [MATH]time(#)[/MATH] call that in this partial form yields correct results). Thus, it could be useful to allow syntax like this: [MATH]k(f(#);5)[/MATH] to work without throwing errors. This would avoid cases when a formal parameter name happens to be previously defined.
С уважением,
Михаил Каганский
A 2 usuarios les gustó este mensaje
#127 Publicado: 22/5/2013 21:28:17
In my opinion there is one solution. The function should only work with numerical optimization. In all other cases the argument must be returned as is.
[MATH]time(#)[/MATH] - this is a bug
[MATH]time(#)[/MATH] - this is a bug
Russia ☭ forever, Viacheslav N. Mezentsev
#128 Publicado: 22/5/2013 21:43:12
This is a bug that would be nice to turn into a feature This would make syntax of formal placeholders clean.
As to your solution - I seem to fail to follow you. Could you please show me what do I need to do to make XYPlot to show me a graph of the function ν(x*'MPa,300*'K) from this file?
This would make syntax of formal placeholders clean.As to your solution - I seem to fail to follow you. Could you please show me what do I need to do to make XYPlot to show me a graph of the function ν(x*'MPa,300*'K) from this file?
С уважением,
Михаил Каганский
#129 Publicado: 22/5/2013 22:03:54
As to your solution - I seem to fail to follow you. Could you please show me what do I need to do to make XYPlot to show me a graph of the function ν(x*'MPa,300*'K) from this file?
In earlier versions SMath Studio support the long integers. But the implementation is too slow, so Andrey lowered accuracy and range of integers. I think that this is the main problem. You bypass the big integers by using the eval(). Andrey promised to try to return long integers reworking their implementation.
My suggestion - it is an additional opportunity to skip this function without any exceptions.
Russia ☭ forever, Viacheslav N. Mezentsev
A 3 usuarios les gustó este mensaje
#130 Publicado: 22/5/2013 22:38:07
To summarize, this solution will only be universally possible when the results of any thinkable expression that contains eval()s will be exactly same as of the same expression with eval()s removed (with only possibly different calculation time).
That would be a great time!
That would be a great time!
С уважением,
Михаил Каганский
A 2 usuarios les gustó este mensaje
#131 Publicado: 23/5/2013 4:44:38
To summarize, this solution will only be universally possible when the results of any thinkable expression that contains eval()s will be exactly same as of the same expression with eval()s removed (with only possibly different calculation time).
That would be a great time!
One more "hedeach-giving" example of this symptomatic behavior.
Regards
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#132 Publicado: 26/5/2013 6:30:02
SMath crash on accessing context menu (try to switch on input display)
Error message details in attached text file
Konische Welle.sm
Error message details in attached text file
Konische Welle.sm
Technische Mechanik mit SMath Studio: https://link.springer.com/book/10.1007/978-3-658-50592-9
#133 Publicado: 26/5/2013 6:45:55
Hello Martin,
I have no problems with Win7 and Smath 0.96 build 4884
Sergio
I have no problems with Win7 and Smath 0.96 build 4884
Sergio
#134 Publicado: 26/5/2013 6:47:56
I can confirm this - 0.96 build 4884, Win7(32). XY-plugin 0.1.4884.13578
I think Martin already mentioned this "Continue" thing. Context menu will produce this error, but we can choose "Continue".
BTW, plot should be selected first - just left click into it, then right click.
Regards,
Radovan
I think Martin already mentioned this "Continue" thing. Context menu will produce this error, but we can choose "Continue".
BTW, plot should be selected first - just left click into it, then right click.
Regards,
Radovan
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#135 Publicado: 26/5/2013 6:55:33
I think Martin already mentioned this "Continue" thing. Context menu will produce this error, but we can choose "Continue".
Right, but there is no way to access the context menu to switch on the input area and change the input expressions :-(
Technische Mechanik mit SMath Studio: https://link.springer.com/book/10.1007/978-3-658-50592-9
#136 Publicado: 26/5/2013 6:57:56
I think Martin already mentioned this "Continue" thing. Context menu will produce this error, but we can choose "Continue".
Right, but there is no way to access the context menu to switch on the input area and change the input expressions :-(
Yes, you are right. Trying to select, copy or whatever will be impossible. Quite annoying
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
#137 Publicado: 26/5/2013 7:00:48
Hello Martin,
I have no problems with Win7 and Smath 0.96 build 4884
Sergio
Sergio, can you please switch on the input area of both plots, save the file and post it (or send it to kraska@fh-brandenburg.de)?
Currently I almost rebuilt the plots from scratch, but would be interesting if that would be an option to recover a file.
Thanks, Martin
Technische Mechanik mit SMath Studio: https://link.springer.com/book/10.1007/978-3-658-50592-9
#138 Publicado: 26/5/2013 7:10:57
Hmm... a bit puzzling 
I used Martin's previous version (SMath with plugins - 0.96.4875 and XY plugin 0.1.4883.2883) and it works. See the picture and the attached file
Konische Welle-debug.sm
I used Martin's previous version (SMath with plugins - 0.96.4875 and XY plugin 0.1.4883.2883) and it works. See the picture and the attached file
Konische Welle-debug.sm
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!"
A 1 usuarios les gustó este mensaje
Martin Kraska 26/5/2013 7:41:00
#139 Publicado: 26/5/2013 7:13:24
Hello Martin,
I had mistakenly understood that the problem is on the plot ' geometries '
It was working fine
now trying on "spannungen" plot, I have the same problem
I apologize
Sergio
I had mistakenly understood that the problem is on the plot ' geometries '
It was working fine
now trying on "spannungen" plot, I have the same problem
I apologize
Sergio
A 1 usuarios les gustó este mensaje
Martin Kraska 26/5/2013 7:42:00
- Nuevos mensajes
- Sin mensajes nuevos