SMath Studio Forum
»
SMath Studio
»
Bugs & Problems
»
slow and fast growing sheet computation time
  Rank: Member Groups: Registered
Joined: 29/01/2010(UTC)
Posts: 13
Location: Portsmouth UK
|
Why is it that the following sheet takes so long to evaluate (~25s) and that time grows exponentially with the number itterations (or rather has not updated before I get bored waiting at something over 1.5 minutes when I want 10 iterations)?  CB Edited by user 28 March 2010 15:07:10(UTC)
| Reason: Not specified
|
|
|
|
|
|
  Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740   Was thanked: 318 time(s) in 268 post(s)
|
Hello CB,
Just use "eval" function in for loops:
x(i)=x(i-1)-eval(...
y(i)=y(i-1)-eval(...
The symbolic engine will produce complicated expressions in this case and slow down the speed. The symbolic engine will be avoided and, therefore, the speed of the numerical calculation will be drastically increased.
Regards,
Radovan |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
Rank: Member Groups: Registered
Joined: 29/01/2010(UTC)
Posts: 13
Location: Portsmouth UK
|
omorr wrote:Hello CB,
Just use "eval" function in for loops:
x(i)=x(i-1)-eval(...
y(i)=y(i-1)-eval(...
The symbolic engine will produce complicated expressions in this case and slow down the speed. The symbolic engine will be avoided and, therefore, the speed of the numerical calculation will be drastically increased.
Regards,
Radovan Using eval() will work but it negates the advantage of using SMath Studio, that the sheet looks like the equations in the statement of the problem. With eval's the code sheet is only little more usefull in explaining things that standard Matlab like code. CB
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
Hello, captainblack wrote:Using eval() will work but it negates the advantage of using SMath Studio, that the sheet looks like the equations in the statement of the problem. With eval's the code sheet is only little more usefull in explaining things that standard Matlab like code. Regarding to the most recent Andrey's efforts about Enabling and Disabling optimization of Symbolic library http://en.smath.info/forum/default.aspx?g=posts&t=393, I wonder if there could be also an option for a Math region to force numerical calculation of the right hand side instead of symbolical, besides the "eval" function. Regards, Radovan |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
Rank: Member Groups: Registered
Joined: 29/01/2010(UTC)
Posts: 13
Location: Portsmouth UK
|
omorr wrote:Hello, captainblack wrote:Using eval() will work but it negates the advantage of using SMath Studio, that the sheet looks like the equations in the statement of the problem. With eval's the code sheet is only little more usefull in explaining things that standard Matlab like code. Regarding to the most recent Andrey's efforts about Enabling and Disabling optimization of Symbolic library http://en.smath.info/forum/default.aspx?g=posts&t=393, I wonder if there could be also an option for a Math region to force numerical calculation of the right hand side instead of symbolical, besides the "eval" function. Regards, Radovan I've seen that post and think that will solve whatever is geing wrong here as well. CB
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
captainblack wrote:I've seen that post and think that will solve whatever is going wrong here as well.
CB
I hope you are right. It would be very good if only the disabling of Symbolic optimization will increase the calculation speed of your examples and, therefore, causing no need of using "eval". As far as I could see, loops with more complicated iterating formulas can cause problems concerning calculation speed. Regards, Radovan |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
Rank: Member Groups: Registered
Joined: 29/01/2010(UTC)
Posts: 13
Location: Portsmouth UK
|
omorr wrote:captainblack wrote:I've seen that post and think that will solve whatever is going wrong here as well.
CB
I hope you are right. It would be very good if only the disabling of Symbolic optimization will increase the calculation speed of your examples and, therefore, causing no need of using "eval". As far as I could see, loops with more complicated iterating formulas can cause problems concerning calculation speed. Regards, Radovan The reason that I think that disabling symbolic optimisation will work here is that the obvious reason for the problem is that SMath is trying to unfold the loop (I could be wrong but ...) See the pic:  CB Edited by user 03 April 2010 16:04:44(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
Hello CB, This is exactly I was thinking about. Yes, that was the point. Unfolding the loop can make quite complicated expression (as you presented just with few iterations). Just like you, I am not sure what would disabled optimization do in this case. Regards, Radovan Edited by user 03 April 2010 16:36:54(UTC)
| Reason: Not specified |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
 Rank: Administration Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member Joined: 11/07/2008(UTC) Posts: 1,616  Was thanked: 1978 time(s) in 666 post(s)
|
Hello. Here is what I've got after disabling optimization of the last Math Region:  This will help with performance (because symbolic library will not try to simplify the result), but expression is still rather large. Regards.
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
Thanks Andrey for the answer, We are getting back to the point that sometimes numerical calculation is inevitable avoiding Symbolic preprocessor. This is calculating in no time.  I could make some of my impressions concerning the comments about this issue: 1. We can do all by symbolic calculation first. 2. Symbolic calculations (Optimised or not) are useful here in order to see, say, if we've done this correct or not. 3. If the calculation is to slow, we could disable optimization or use "eval", "round" to force it numerically. 4. CB pointed out that using these functions is not so ellegant, because they are visible and might distract the "paper-like" intention of SMath. I suppose that - making it unvisible might be the solution or - having the option for a given math region (as I mentined) to disable Symbolic library and using just strict numerical calculation Regards, Radovan |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
Rank: Administration Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member Joined: 11/07/2008(UTC) Posts: 1,616 Was thanked: 1978 time(s) in 666 post(s)
|
OK, then I can propose the solution:  Default option will be defined through the global settings file and user will be able to change it manually. Regards.
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
Hello Andrey, I think this would be great and desirable for most of the users  . If this is going to be applied (global and local settings - symbolical, optimized, numerical) I suppose this way will help the users to better understand how SMath works. Regards, Radovan |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
Rank: Administration Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member Joined: 11/07/2008(UTC) Posts: 1,616 Was thanked: 1978 time(s) in 666 post(s)
|
... The behavior of the SMath Studio 0.87 (and earlier versions > 0.50) is that program always tries to process symbolic calculation for every definition of the page. Even if you use eval(..) function program will process argument of this function through the symbolic engine and will raise numeric evaluation only when eval(..) function will be found.
In fact, the solution we have invented here makes SMath Studio more flexible then ever. User will be able to use the most usable logic for specific expression definition.
Regards.
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
Yes, Andrey, you explained what I've been thinking about. Everything is working trough Symbolic calculation first (including "eval" ). It has very nice features, but it seems that there were obstacles when required the numerical results only. I think that many users mentioned the same thing here and there on this Forum. If I understood you well, the new SMath version will include pure numerical calculation as an option, skipping the symbolical engine. Am I right? If this is the case, I think the combination of symbolical and numerical calculation will bring new flexibility, usability etc. This would be really great . Regards, Radovan Edited by user 03 April 2010 23:53:13(UTC)
| Reason: Not specified |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
Rank: Administration Groups: Developers, Registered, Knovel Developers, Administrators, Advanced Member Joined: 11/07/2008(UTC) Posts: 1,616 Was thanked: 1978 time(s) in 666 post(s)
|
Done. Results is pretty good (see tests at the end)  Figure 1: Setting of optimization option using main menu.  Figure 2: Setting of optimization option using context menu.  Figure 3: Results of evaluation. Updated (Performance tests): If "i" defined within the range from 2 to 10: - Numeric optimization - takes 0.016 sec. to evaluate.
- Symbolic optimization, with eval(..) function - takes 0.015 sec. to evaluate.
- Symbolic optimization - takes about an infinity (interrupted after 13 min. elapsed) to evaluate.
- Without optimization (None) - takes 2 min. 53 sec. to evaluate.
If "i" defined within the range from 2 to 1000: - Numeric optimization - takes 29.97 sec. to evaluate.
- Symbolic optimization, with eval(..) function - takes 17.352 sec. to evaluate.
- Symbolic optimization - senseless action.
- Without optimization (None) - senseless action.
Edited by user 07 April 2010 06:29:46(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Member Groups: Registered
Joined: 29/01/2010(UTC)
Posts: 13
Location: Portsmouth UK
|
That looks great, thanks
RonL
|
|
|
|
|
|
Rank: Administration Groups: Registered, Advanced Member Joined: 23/06/2009(UTC) Posts: 1,740 Was thanked: 318 time(s) in 268 post(s)
|
I agree. That is very good. I believe that there is some more room to improve the overall speed of SMath in the feature. At the time being, I am quite satisfied regarding the example Andrey presented Regards, Radovan |
When Sisyphus climbed to the top of a hill, they said: "Wrong boulder!" |
|
|
|
|
|
SMath Studio Forum
»
SMath Studio
»
Bugs & Problems
»
slow and fast growing sheet computation time
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
