Handle NaN in min/max/minBy/maxBy

[marklam]

Some caveats:

• I think there's still a problem with Infinity
• minBy/maxBy mapping functions can't change the type of the type (ie they're ^T->^T)
• Performance will be affected, maybe the float/single versions need to be separate code from the integers?

[marklam]

This should fix Issue #21 (provided it doesn't hurt performance too badly)

[jackmott]

I'm wondering if it is a good idea to compromise performance to handle nan/infinity the same as the standard lib functions. I'll do some testing to see how big the effect is.

[jackmott]

What do you think about just modifying the comments to say that NaN and infinity are handled differently? I'm not sure how users of the lib would prefer things.

[jackmott]

This is really nice. I feel like there might be some casting trick we could pull to let minBy and maxBy still return ^U. The bits would work, just need to convince the compiler =)

[marklam]

I wouldn't mind if the results for NaN/infnity were different - I'd be upset about having them in the data in the first place :-) And it's not like the change from Array.max -> Array.SIMD.max is silent.

I think that losing the ^U mapping is necessary when the Vector.Count is different for ^T and ^U.

Not sure why that last commit won't build on the CI though, it built fine on my machine (debug and release).

[jackmott]

Yeah even if we kept the ^T and ^U I would need to add a runtime check for the Count being the same.

I'll merge this and see if it builds for me.

[jackmott]

does't build on my machine either, MinValue.Invoke() returns an object, and then the compiler doesn't know what to do with Vector< ^T>(minValue)

[jackmott]

looks like just needs type annotations.

[marklam]

I wonder what the difference is - that I'm using the Visual F# nightly, maybe?

[jackmott]

possibly F# 4.1 can handle it but not 4.0?

[jackmott]

I pushed up a fix