More rules in Evaluate about mathnet-symbolics HOT 5 OPEN

I'm currently experimenting with an alternative value type (see alternative-valuetype branch; NewValue.fs, work in progress). The goal of the new type is to consolidate and simplify the redundancies between Approximations, Values and Evaluation by implementing arithmetics, operators and functions on "values" (i.e. known leaf expressions) once, with proper handling of special numbers, infinity etc. I think this would in the end resolve this problem as well. Evaluate could completely rely on this value type, and Expression could leverage it as well if all arguments are equivalent to values (and the result doesn't introduce approximations).

A value of this new type is one of:

• a rational number
• a real approximation (double precision float)
• a complex approximation (double precision complex)
• a constant
• positive infinity
• negative infinity
• complex infinity
• undefined

The explicit infinity values allow to handle infinity properly, what should resolve the mentioned issue. The inclusion of constants allows e.g. to return or handle pi nicely. However, it cannot represent e.g. negative pi this way and has to fall back to a real approximation. This somewhat reduces the usefulness of including constants in the first place, not sure yet whether to keep it. I've also noticed it cannot nicely represent non-real directed infinity like i*oo, or rational complex numbers like 3*i. Likely the definition should thus be adapted slightly.

Let me know what you think about this.

from mathnet-symbolics.

The modules typically just accompany a type, so the type is where the difference is. The distinct property of the Approximation type is that it is part of the Expression type, therefore represents a proper expression tree node. From a symbolic view point, the type allows to represent ad-hoc constant "symbols" with known but non-exact values, hence the name - other than integer or rational numbers, or proper constants like Pi. Currently it covers double precision real and complex numbers, but it could indeed be extended to arbitrary precision numbers in the future in principle.

Before we had the Approximation type, the parser used to interpret 1.2 as unrounded exact rational number 6/5, which was arguably wrong.

On the other hand, evaluate transforms expressions into a machine precision FloatingPoint type instance completely unrelated to expression trees, substituting variables with known values on the way; compile turns expressions into "code", similar also all the parsers and formatters that transform to/from strings, xml etc.

The Approximation module implements operations directly on Approximation instances, originally mainly to offload repetition from the Expression-related modules. The problem with this is that we cannot deal with e.g. infinity here properly and we cannot leverage it for evaluation and other use cases.

from mathnet-symbolics.

I love the new concept in that it makes it clearer and simpler to understand the product. However, I found that I didn't know the exact purpose of the modules. I am wondering what is the purpose of Approximation and Evaluation. Is the Approximation for arbitrary precision numbers, e.g. N function of Mathematica, in the end? Evaluation and Compilation are for machine precision numbers?

• Surprisingly my issue is not found in Compilation.

from mathnet-symbolics.

NB: to answer the original question, it might be possible to leverage at least some of the existing Expression rules in evaluation by substituting the values first (Structure.substitute) instead of in-place.

from mathnet-symbolics.

Very thanks for clear and lucid explanation. Now I can get a better understanding of the overall structure of the Symbolics.

I am looking forward to new release with the NewValue.

from mathnet-symbolics.