Correction SS-2337
1 vote

Remove numeric optimization mode
Created by Mike Kaganski on 5/6/2016 6:51 AM Last Updated by smath on 5/6/2016 2:46 PM
%
 (hrs)
Logged: 0   (hrs)

 Description

I am aware of controversy that exists about symbolic optimization mode in SMath.


Yet, I suppose, that in some (distant) future, the only existing mode should be symbolic, removing numerical "optimization" altogether.

 


Here is the rationale for that.


I suppose that the inconsistency between the results we have for numeric and symbolic modes in most cases is caused by existence of the two modes, that have their own computation algorithms for many functions, and must be kept in sync to provide the same final results. It's a kind of herculean load.


But the primary use of numerical mode is to get a number at some specific point of calculations. I see two places where it may happen:

  1. When the result is requested using "=";
  2. Somewhere in the middle of a calculation using eval().


Both may perfectly use symbolic engine to simplify their subexpressions as needed, and then finally request numeric result. So, there is no numeric "mode", just numeric result of some (limited) number of functions.


Here finally the clear distinction should be done between the "=" that returns number, and another one (requested multiple times, like "->") that corresponds to current symbolical result taken using Ctrl+.


Also, usual ":=" may be split to two: say, ":=" would mean shortsut for current ":=eval()", while something like "<-" would mean "assign usual symbolic expression" (as in SS-19).


If this removal of numeric mode will be performed, then any unwanted behaviour of symbolic engine will enjoy highest-level attention, because (a) there will be no additional load to support another 50% of code doing the same differently, and (b) there will be no workaround available that lowers the severity of the problem. Any expression will have exactly one meaning, regardless of "mode", and results will be deterministic.

 

When taking symbolic result, any function would either return itself with symbolically processed arguments, of (if possible) a substitutional expression without itself if possible. Those functions that return themselves, will need to be able to also return numbers when getting final result.

Being able to control when one gets numerical result using eval() or (new numeric) := is enough for both optimization for speed or controlling over/underflows where it's possible.

 

Hope this sounds sane.
 
Skip Navigation Links

    smath (Friday, May 6, 2016 2:46 PM) #

Ah, ok. In future it will be definitely removed.

For now this option helps to overcome some difficulties related to symbolic optimization (it allows user to influence on the result without changing of visual look of the equation). Yes, today it is some kind of workaround, so I will remove it as only symbolic engine will be improved enough.

    Mike Kaganski (Friday, May 6, 2016 1:58 PM) #

I didn't mean removing numeric engine; I only want to remove numeric mode that is enabled by selecting numeric optimization on SMath blocks. This mode is something that somehow makes the calculation logic different for unclear reasons. One doesn't control exact places where the numerical results are obtained; and because symbolics are still used, the reason for different results are unclear.

    smath (Friday, May 6, 2016 12:09 PM) #

Hello, Mike.

Thanks, you are partially right regarding complexity to support two engins - it is very complex pair of worlds. But they are not actually separated from each other and currently they works similar to what you described in the ticket.

  1. First of all, currently there is no problem to support the same functions in both engins, because every engine support only those functions/operations which it can support;
  2. Second, numeric engine uses symbolic engine inside. This is done because of units support: when one calculates numerically 2*'m+3*'cm SMath Studio performs numeric calculation for everything except units. Units are always calculated symbolically in parallel with numeric evaluations;
  3. And finally, if numeric engine will be illuminated, then how we will calculate f.e. sin(3) or sqrt(5)? We will still need to find a place for this kind of calculation logic.

But you're absolutely right regarding priority of engins. Symbolic engine should be used by default and numeric one used only to produce final numerical results or when it is manually requested by user (eval() or selected numeric optimization). This is the only possible guarantee that final resuls will be shown with no (meaning as less as possible) calculation errors. This is why I do not support ideas like described in http://smath.info/bts/Issues/IssueDetail.aspx?id=65.

Thanks again for your analysis!