Canonicalization over simplifies division

[allenOrangeXu]

Description

When computing A \div B, if A = B, it will be simplified to 1 during the canonicalization procedure. However, this introduce some edge cases dealing with NaN / infinity. If A and B are NaN / infinity and the value isn't ready till evaluation, A \div B should not return 1. For example, tan(90) / tan(90) should not return 1.

Steps to Reproduce

ce.box(["Divide", ["Tan", pi/2], ["Tan", pi/2]]).evaluate().print();

Actual Result

1

Expected Result

NaN or throw an error.

Environment

ComputeEngine: 0.27.0

[samueltlg]

I believe that this is amongst several inaccuracies during canonicalization; some of which span beyond 'Divide'.

@arnog, if you get round to fixing the current behaviour of some BoxedExpression methods drawing on assumptions (in ref. to discussion around https://discord.com/channels/1115702937902121111/1115702938426413251/1319682852811575386 a few weeks back), & deciding on course of action, if any, regarding canonicalization's (current behaviour) of drawing on domains, & values of symbols (constants), I'd be happy to address this and others identified (for you, over next couple of months or whatever; understandably this potentially being a big change).

I use a fork of compute-engine which slightly 'augments' it for minor personal use, & during the course of this have familiarised with the minutiae of the canonicalization/CanonicalForm process, so would be happy to hone in on any slight inaccuracies (& maybe discuss a few changes), if you'd like 👍

[samueltlg]

Feel like there are some points & questions bearing worth bringing up now / rather than later (have ended up tediously investigating this, since is very pertinent to what I'm working on currently):

• Calling (getting) the canonical variant of a boxed CanonicalForm expr. (e.g. ce.box( ['CanonicalForm', BoxedExpression, ['Form1', 'Form2',...]/* i.e. incomplete list */], { canonical: false }).canonical.isCanonical (i.e. because .canonical is the curent way to 'evaluate' CanonicalForm) always returns 'true' in spite of whether the given list of forms is a complete one (not that this would count as sufficient, anyway). Noticed that in addition to this simply being un-true, this has consequences within the 'CanonicalForm' process as well
  (My feeling on this point is that, maybe instead the current 'canonical' handler for CanonicalForm should be the/an evaluate handler? I.e., currently, to 'evaluate' CanonicalForm, one has to request the canonical variant of an expression therefore invoking the 'canonical' handler; which is properly supposed to return a fully canonical expr. (in this case, contents). Maybe this could be worked-around by instead calling 'evaluate'?)

• Confusingly, came to the discovery that CanonicalForms effectively applies 'full' canonical status/form to expressions with operators after which they are named, by means of explicitly casting operands as fully-canonical (before applying to the containing form). Not sure that this is intentional: but certainly did not expect this to be the case, with this producing unexpected results.
  (Warning: due to the aforementioned issue (ce.box(['CanonicalForm', expr, ...].canonical.isCanonical === true), note that debugging during this certainly makes things more confusing particularly whilst debugging... (together with recursive calls, it may be noticed that instances of calls to BoxedExpr.isCanonical returning 'true' when this is not so.)
  To illustrate:

let canonForms = ['Multiply'];

let input = ce.parse('x * 2 * y * z^1 * n/0 * {m+0}', { canonical: false }); // Assuming all symbols are _inferred_/first time to be used
//→Results in top-level 'Multiply' of form '[ "Multiply", "x", 2, "y", [ "Power", "z", 1, ], [ "Divide", "n", 0, ], [ "Add", "m", 0, ], ]'

const partialCanonical = ce.box(
    ['CanonicalForm', input, ...canonForms],
    { canonical: false }
  ).canonical;

partialCanonical.toString(); // →  '2 * ~oo * m * x * y * z'
//...^i.e., sub-expressions 'z^1', 'n/0', 'm+0' have been fully canonicalized

The same is not the case for 'Add', but after investigating this appears to be a consequence of the outlined bug.

I would have thought that the CanonicalForm of Multiply would only apply its own forms (recursively), and not those of 'Add' & so on to sub-expressions: or was the intention for this to be so...?
Begs the question (the answer being in the negative): should there not be two separate canonicalFormName handlers for each operator-corresponding form: example canonicalAdd and canonicalFormAdd for 'Add' ?

• Not as important as the aforementioned, but some other queries/side issues:
  • powerForm calls function BoxedExpr.pow(..) rather than canonicalPower (this change apparently being made a few months ago), this notably being the same degree of simplification as used in the full rule-list (simplify-rules.ts): not sure if this is intended, as does seem to stretch beyond bounds of canonicalization a little... ?
  • numberForm appears to be redundant currently, since current procedure is to request the canonical expr. of BoxedNumbers, but this always returns true (→from what I understand, this is intentional, on account of relatively more recent changes regarding numbers/number-values, that constructed BoxedNumbers are expected to already be in canon.-form)
  • Relating to the previous point, each of the powerForm, addForm etc. functions return a ce._fn('Operator', ...ops) expr. instance with this by default implying canonical === true.
    Depending on the answer to the previous point, should this instead be'false'?

Would appreciate much a response for the second point, since this appears to have a lot of implications!

(Worth mentioning also: beware that ASCII-string expr. serialization as it stands can be confusing if debugging canonical-form reducible expressions. E.g., serialization of '3 + 0 + 1' will serialize as '3 +0', z^1 as z, and others.)