math.eval() doesn't parse the scope correctly

[coolreader18]

If you put an equation through eval with variables and provide a scope with something other than just numbers as a value, it doesn't parse it correctly. I could get around this by just parsing it before putting it into the scope object, but this may not be possible for everyone.

[josdejong]

I think I understand what you mean but can you give an example of what is going wrong?

[coolreader18]

For example, I set a variable in the scope object to sqrt(9), and it returns an error saying that it can't do anything with it.

[josdejong]

Can you post an code example?

I guess you do something like:

math.eval('a + 4', {a: 'sqrt(9)'}) 
// Uncaught Error: Cannot convert "sqrt(9)" to a number

which will not work since the variables in the scope are not evaluated like as an expression.

You can do something like:

math.eval([
  'a = sqrt(9)',
  'a + 4'
])
// [3, 7]

[coolreader18]

Yeah, basically that. The variables in the scope aren't evaluated, which is slightly confusing; in normal math you'd mentally parse
a=sqrt(9)
a + 5
as
sqrt(9) + 5

[josdejong]

In math.js, strings are also valid values, for example math.eval('size(str)', {str: 'hello world'}). It cannot know whether a string should be evaluated or not.

To achieve the behavior you want, you could evaluate the expressions you want to have in your scope
(like {a: 'sqrt(9)'}) beforehand, should be just a few lines of code. Or pass everything as an array of expressions like in the previous code example I gave if the expressions need to be evaluated in a specific order.

Just for reference, we discussed something similar here: #907 (comment)

[ThomasBrierley]

To achieve the behavior you want, you could evaluate the expressions you want to have in your scope
(like {a: 'sqrt(9)'}) beforehand, should be just a few lines of code. Or pass everything as an array of expressions like in the previous code example I gave if the expressions need to be evaluated in a specific order.

I would recommend using eval of an (ordered) array of expressions in your original example because it's explicit and reliable. JavaScript object keys are not guaranteed to be enumerated in any particular order and do vary between engines / versions, modern engines enumeration order seems to be based on property definition order, but I remember a time when it was more common to use alphanumeric order.

Which highlights another requirement if considering implementing this feature for scope: an expression parse followed by a DAG topological sort of the expressions references would be required to determine a valid evaluation order.