Spec defines MIN and MAX operations only for floating point types. Polyfill implements for all types.

[arunetm-zz]

Min and Max functions are implemented and validated for all types in the polyfill. However the Spec defines these functions for Floating point types only.

Should the spec be updated to be consistent? Is polyfill is correct about these functions?

[littledan]

Agreed, looks like the polyfill and tests are wrong. @billbudge maybe Deepti could fix this (I don't know her GitHub handle).

[littledan]

Or, @arunetm , a pull request from you would also be welcome.

[arunetm-zz]

Thanks.. Can someone help to understand why min and max operations are defined only for float types? Don't we have a possible use-case for min/max operations for int32x4, uint32x4, int8x16 etc?

I thought the solution was to update the spec to include min and max operations for all types, except for the boolean types may be?

[littledan]

Min and max operations are included for float types because processors provide special acceleration for them. By contrast, no special support is provided for int min and max, but it is easy to build out of the primitives already exposed--it is just a .lessThan composed with a .select.

[billbudge]

Intel at least appears to have these:
https://software.intel.com/en-us/node/583113

[johnmccutchan]

@sunfishcode Can you chime in here?

[PeterJensen]

ARM has them too:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491g/CIHJCAII.html

We should include those, IMO

[littledan]

In my opinion we could go either way here. TC39 members repeatedly said that they preferred this to be defined on integer types as well, but based on my understanding of this group's consensus, I successfully pushed back and got a non-orthogonal instruction set accepted. @johnmccutchan @sunfishcode what are your thoughts?

[sunfishcode]

x86 didn't have all the important types/signednesses covered until SSE4, which is the reason we didn't push for them initially. And, they're not prominent in the use cases we studied for the initial round of SIMD.js standardization. However, if people can point to real use cases (eg. not just "because floating point has them") that would be best to address now rather than in future iterations, perhaps we should consider them. They're not complicated to implement on pre-SSE4 hardware.

[johnmccutchan]

Concrete use cases would definitely solidify the case for keeping them. But it's hard for us to exhaustively find all use cases so I would lean towards including them. As @sunfishcode they aren't difficult to implement.