Feature SS-3525
1 vote

Evaluate objects prior to applying element assignments
Created by Martin Kraska on 3/26/2018 6:17 PM Last Updated by smath on 3/28/2018 4:50 PM
%
 (hrs)
Logged: 0   (hrs)

 Description

In the example below, matrix m is stored as symbolic expression. When applying the element assignment to m[2,2 SMath doesn't care about that m could evaluate to a matrix and stores the content of m as the first element of a new matrix.

The user was sure to assign to a matrix, as m displayed as such. He could have seen the difference from the dynamic assistent but how could he guess that the expression would not be treated like a matrix.

Besides this, it is another case where a visible clue as to the optimization would be essential (SS-19)

The generic solution would be to evaluate the assignment target first, in order to determine it's actual type, just like recently done with index expressions.

On the other hand, this might be a bug in the pre-evaluation type detection logic. Any expression of type augment() must be a matrix.
Skip Navigation Links

    smath (Wednesday, March 28, 2018 4:50 PM) #

1) Thank you Martin! Good point regarding more convenient error message. Unfortunately currently SMath Studio generally cannot see what type of function output will be after calculation, so I cannot implement it, but in future I will try.

2) Yes, issues like 30! and 10...0+1 must be fixed. The main purpose of symbolic engine is to be sure nothing will be lost during calculation, but as you have shown all cases where symbolic engine optimizes numeric expressions inside it may result in the same accuracy problems as we have in numeric engine.

Please create a separate ticket where this issue will be addressed. Thanks again!

    Martin Kraska (Wednesday, March 28, 2018 4:04 PM) #

> Symbolic result of the 30! is an error. It must be fixed.

So in principle, you are committed to exact integer arithmetics in symbolic evaluation? I wasn't aware of that. If so, there is more to fix:

    Martin Kraska (Wednesday, March 28, 2018 3:53 PM) #

Don't agree. Knowing that the expression would evaluate to a matrix helps to issue a more helpful error message. Something that gives the user a clue of what has happened:

"{0}  must be undefined or stored as evaluated matrix/vector for symbolic assignment by element."

The user usually isn't aware that the assignment is symbolic by default and in many cases has no reasons to insist on symbolic evaluation.

IMHO the confusion of the topic starter in the forum  results from assignments with : being made symbolically by default and display with = is numeric.

I guess that the problem will fade with SS-19 being handled.

 

    smath (Wednesday, March 28, 2018 3:15 PM) #

Knowing that output expression is a matrix gives nothing. Question is how to set matrix element of the expression which is not yet evaluated. Expression have to be evaluated first, but how? Numerically? Yes, but it will give possible accuracy errors without user permissions. If user is ready for issues specific to numeric calculation then (s)he should implicitely perform this calculation - program cannot intiailize this by itself.

 

Error is something like "Cannot calculate" as I remember. It is a general one. Displaying of some exception is a good workaround here as a main goal of math program is to avoid silent errors in calculations.

 

Symbolic result of the 30! is an error. It must be fixed.

    Martin Kraska (Wednesday, March 28, 2018 2:57 PM) #

As far as I can see, there is no need to evaluate m in order to find out that it is a matrix or a vector. Functions stack() and augment() can't have other than vector or matrix results no matter what the arguments are, even if it is a single scalar. This also applies for other functions like cross product or range().

What is the error message you are going to produce? If it says m is not a matrix, then the user will be unhappy, because m displays as matrix.

But I see that there is no easy way to store the additional assignment to elements for delayed evaluation (except perhaps using line operator)

Unexpected accuracy errors aren't limited to numeric evaluation (just evaluate 100! symbolically). But that is of course a matter of individual accuracy expectations ;-)

    smath (Tuesday, March 27, 2018 7:14 PM) #

I mean when m is not a matrix or vector AND if m was not fully calculated (contains not evaluated functions). It is a workaround as I just can't force numeric evaluation here as it may cause unexpected accuracy errors.

But in short words yes, you are right. Please check index_error_check_1.PNG attached.

Fix is performed.

    Martin Kraska (Tuesday, March 27, 2018 1:04 AM) #

You mean in cases where m isn't a mat() object or undefined?

In the above example, the user would have asked, why the error pops up in one case and not in the other one.

Making assignments numeric by default would help here. Also clearly indicating the optimization type (SS-19) would help.

Anyways, an error message is always better than silent rubbish.

    smath (Monday, March 26, 2018 8:24 PM) #

My proposal is to show calculation error for m[2,2 and m in such cases.

Currently it is impossible to handle matrix element definition using any other approach.