Clarify the usage of 32 bit floating point type and consider using double

[huningxin]

This issue was raised during Chromium CL review. Thanks Jiewei @wacky6 for the valuable feedback!

The WebIDL 32 bit floating point type float is widely used by WebNN spec, such as for setting min and max value of clamp operator:

dictionary MLClampOptions {
  float minValue;
  float maxValue;
};

However, WebIDL spec has a warning of using float and the recommendation is to use double.

Unless there are specific reasons to use a 32 bit floating point type, specifications should use double rather than float, since the set of values that a double can represent more closely matches an ECMAScript Number.

According to that, Jiewei suggested that the spec should mention reason of using float (at least an informative note) and propose using double instead. The reasons include (pasted from the CL thread):

• Don't see particular reasons for limiting this to fp32
• What if (in the future) we have backends that can work with fp64? In this case fp32 becomes a limitation.
• Would it be worthwhile specifying float point casting behavior in the spec? Say, if caller passes in a fp64 number (that is too large to represent in fp32/fp16), how should backend interpret this (cast to infinity, error, find closest value non-infinity, something else)?

[wchao1115]

FWIW, double is not a considered a mainstream native data type on the GPU. Although there is a shader model extension for it, it's not until recently (e.g. HLSL shader model 5)

[wchao1115]

Just an additional note that extending float attributes e.g. minValue, maxValue in the options dictionary should be straightforward. If it makes the spec more in line with the rest of WebIDL specs, I think it's reasonable. However, I have some reservations about adding support for float64 type as an operand type. I don't think it's needed. For instance, on the GPU, float64 tensor type is not widely supported. New models only tend to become smaller with lower precision and the need for a double-precision trained parameter is unheard of.

[inexorabletash]

Discussion here and elsewhere hasn't explicitly mentioned the resample2d() scales option, which is defined as sequence<float>. This isn't part of graph execution, but a convenience for calculating the integer target sizes. #474 proposes remove the option as a simplification, but if kept it should probably be changed to double.