Denormalized numbers

# Jens Nockert (12 years ago)

There is a spelling mistake in the following section of the new draft (Page 215)

clarification of Number.MIN_Value for Arm processors (that don;t support denormalized numbers)

It should reference IEEE 754, not IEEE 764.

Also, this new section changes the semantics of arithmetic and numbers in Javascript, is this actually the intention?

It is correct that a lot of processors do not implement denormals in hardware, but is it worth breaking backwards compatibility over? It also seems to be in contradiction with 8.5 (The Number Type), which defines which values a Number is allowed to have.

# Allen Wirfs-Brock (12 years ago)

Some existing widely deployed ARM ECMAScript implementations apparently are returning 0 as Number.MIN_Value because their (non-conformant) implementations can't represent the required value. This paragraph has one specific purpose, it tells such implementations what they need to return instead and that it isn't 0.

It isn't the intent of the paragraph to imply that that full 754 binary 64-bit compliance isn't still required required for Ecma-262 conformance. Why did you draw that implication? Do you have any wording changes that you think would make it clearer? Perhaps this paragraph should be a non-normative note?

# Jens Nockert (12 years ago)

On May 8, 2012, at 6:24 PM, Allen Wirfs-Brock wrote:

Some existing widely deployed ARM ECMAScript implementations apparently are returning 0 as Number.MIN_Value because their (non-conformant) implementations can't represent the required value. This paragraph has one specific purpose, it tells such implementations what they need to return instead and that it isn't 0.

It isn't the intent of the paragraph to imply that that full 754 binary 64-bit compliance isn't still required required for Ecma-262 conformance. Why did you draw that implication? Do you have any wording changes that you think would make it clearer? Perhaps this paragraph should be a non-normative note?

Allen

I drew this conclusion from "If an implementation does not support denormalized values", because it somehow implies that you do not have to implement gradual underflow anymore if your hardware does not support it or if it has a faster flush-to-zero option.

It could be a non-normative note intended as a hint for implementations that are not intending to be fully conforming to the standard, but then that intention would need to be clear.