Division Type Inputs Incorrect

[Geotale]

Although these mishaps only tend to create missed optimizations it seems, they should still likely be fixed in case they cause more incorrect optimizations (primarily having to do with NaNs):

• canBeNaN:
  • REAL / 0 = NaN is not correct -- it should be NUMBER_ANY_ZERO / NUMBER_ANY_ZERO. Currently the right hand side is only checked to be positive 0 which causes immediate and easily replicable issues by just doing (((0) / (-0)) + (1))
• canBePos / canBeNeg:
  • Infinity checks aren't checked here, but could be checked in the NUMBER_POS_INF and NUMBER_NEG_INF cases
• canBeInfinity:
  • Infinity / 0 = Infinity should instead be NUMBER_POS / 0 -- similarly for -Infinity / -0
  • POS_REAL / NUMBER_OR_NAN ~= Infinity should instead be POS_REAL / POS_REAL -- a similar case should be done for NEG_REAL / NEG_REAL
    • This is of course because of rounding up to Infinity
  • Infinity / POS_REAL is also Infinity, similarly to -Infinity / NEG_REAL
• canBeNegInfinity:
  • -Infinity / 0 = -Infinity should instead be NUMBER_NEG / 0 -- similarly for Infinity / -0
  • NEG_REAL / NaN = -Infinity should not be included because the inputs are forced to be NUMBER, not NUMBER_OR_NAN
  • NEG_REAL / NUMBER_OR_NAN ~= -Infinity should instead be NEG_REAL / POS_REAL or POS_REAL / NEG_REAL
  • Infinity / NEG_REAL is also Infinity, similarly to -Infinity / POS_REAL

Also NUMBER_FRACT is never set with this. I don't know if that was intentional or not but it's not like the enum is used for anything as of now anyways.

[Tacodiva]

Not sure why the operator type matrix test didn't catch these. Thanks

[Tacodiva]

Also I should add that 'FRACT' types are used to differentiate the integers from the reals. The real numbers would have this bit set where the integers do not. Returning 'FRACT' without 'INT' would only make sense if we know the returned value is not an integer, which I don't think we can do, and even if we could I don't think it would be useful for any optimisations.