ConstantNode - intended values.

[JacobBeaudry]

Hi Jos,

Another quick question about the existing node types and the philosophy / intention behind them; I figured it made more sense to ask here, so that the information is recorded for others, as well.^1

In the docs, it says the type of value is any, and the examples include a decimal number and a string. This is consistent with the interface in index.d.ts:

interface ConstantNode extends MathNodeCommon {
    type: 'ConstantNode'
    isConstantNode: true
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    value: any
  }

However, 1) in the same file, the constructor is declared as:

  interface ConstantNodeCtor {
    new (constant: number): ConstantNode
  }

(where, if I'm not mistaken, constant is being used for value), which restricts the type of value to number and 2) if one parses something like:

const node = math.parse('-2') 
console.log(node)

it returns:

 Node {
      implicit: false,
      isPercentage: false,
      op: '-',
      fn: 'unaryMinus',
      args: [ Node { value: 2 } ],
      comment: ''
    }

i.e. '-2' is parsed as a unary minus node with a constant node child (vs. a constant node with value -2), which suggests that the system is reserving Constant Nodes for positive constants only.

The work I'm currently doing would be greatly simplified by having a single node type for numbers (i.e. for both negative and non-negative values); is there any reason you'd recommend against such a simplification? Specifically, I wondered if, as with Operator and Function nodes, there was a reason for returning negative constants as unary minus nodes as opposed to constant nodes?

Thanks in advance for your time and help. Hope this finds you well!

All the best,

Jacob

1: If it would be helpful to record your answer to my previous query about Operator vs. Function nodes here in the discussions, please let me know and I'll add it 😄

[gwhitney]

1. the typescript typing of the ConstantNode constructor may well be too restrictive, and if mathjs is indeed creating ConstantNode objects with, say, string values, then I don't see any reason you shouldn't submit a PR widening the typescript type and adding tests for the wider type.

2. The question of the proper parse for the string -2 is more subtle: is that the unary minus operator applied to the constant two or the constant "negative two"? I gather mathjs currently prefers the former. That's one of those changes that it's hard to know the ramifications of: maybe someone else is depending on all - symbols being captured as operator nodes... so my recommendation would be to just run a custom simplify with just a couple rules to absorb as many unary minuses into constants as possible, or just a call to map or transform might do it. That way you have the parse you want without having to go through the potentially long-winded process of a breaking change to the standard parsing. Might that work for you?

3. incidentally I have brought up to Jos the idea of collapsing OperatorNode and FunctionNode as 90+% of the code dealing with them is identical, and he didn't sound horrified at the idea, so perhaps hopefully in a future overhaul that could happen.

[JacobBeaudry]

the typescript typing of the ConstantNode constructor may well be too restrictive, and if mathjs is indeed creating ConstantNode objects with, say, string values, then I don't see any reason you shouldn't submit a PR widening the typescript type and adding tests for the wider type.

I'm not sure if mathjs is creating ConstantNode objects with anything other than number values: I'm too much of a novice to understand what is customized in our implementation vs. standard mathjs, unfortunately. Sorry I can't be of more help on this front, at the moment.

The question of the proper parse for the string -2 is more subtle: is that the unary minus operator applied to the constant two or the constant "negative two"? I gather mathjs currently prefers the former. That's one of those changes that it's hard to know the ramifications of: maybe someone else is depending on all - symbols being captured as operator nodes... so my recommendation would be to just run a custom simplify with just a couple rules to absorb as many unary minuses into constants as possible, or just a call to map or transform might do it. That way you have the parse you want without having to go through the potentially long-winded process of a breaking change to the standard parsing. Might that work for you?

Yes, working around this isn't an issue , at all; we actually never use the parser in our work. The reason I was asking was to verify whether the parser's preference for unaries over negative values reflected an intentional design decision (i.e. one that should be followed in our own work) or not. Sounds like we don't have to worry about it, thank you!

incidentally I have brought up to Jos the idea of collapsing OperatorNode and FunctionNode as 90+% of the code dealing with them is identical, and he didn't sound horrified at the idea, so perhaps hopefully in a future overhaul that could happen.

Yes, that would certainly be pleasing from a mathematical perspective 😄 while also reducing the duplicate code. Hopefully we'll be able to help with such updates, as we learn more!

Thanks for the thoughtful and detailed reply, Glenn!

[josdejong]

the idea of collapsing OperatorNode and FunctionNode as 90+% of the code dealing with them is identical

Yes that is indeed an interesting idea. We would have to think it through in detail.

The reason I was asking was to verify whether the parser's preference for unaries over negative values reflected an intentional design decision (...) or not.

There is indeed no intentional design, both are valid and useful in differing cases or "just pop up" after certain operations. When transforming and simplifying expressions there is a great benefit though when expressions would be normalized. We have some interesting discussions and ideas in that regard, not only normalizing unary minus, but also normalizing for example a*b*c, (a*b)*c, a*(b*c), and prod(a,b,c). See #2415