Clean up updated hypot function

[musm]

@cfborges Looks like you forgot to delete the existing code (ref #31922)

[musm]

I think we should actually have hypot(x::T, y::T) where {T<:Number} = hypot(float(x), float(y) and remove the Integer method case.

[oscardssmith]

Won't that break bigfloats et. al?

[musm]

No it won't actually. hypot has specialized methods in MPFR.

[oscardssmith]

To me this still feels fishy as it means hypot will convert custom number types into floats if they don't specifically define a hypot function.

[musm]

We already define mathfunction(x::Real) = mathfunction(float(x)) for numerous elementary math functions, such as exp.

[cfborges]

@cfborges Looks like you forgot to delete the existing code (ref #31922)

Actually, I purposely deferred that to someone else because of my previously demonstrated unfamiliarity with git (I commented on that somewhere in the original thread). I didn't want to make a mess out of it and waste everyone's time. But your point is excellent, the old code should come out.

[fredrikekre]

julia> hypot(3, 4im)
ERROR: StackOverflowError:
Stacktrace:
 [1] hypot(::Complex{Float64}, ::Complex{Float64}) at ./math.jl:550 (repeats 80000 times)

[musm]

@cfborges Got it, thanks for the clarification.
Should the method signature be restricted to IEEEFloat, instead of the more generic AbstractFloat? Does the algorithm explicitly depend upon the representation of IEEE float? Glancing at the code I don't see anything that manipulates the bit field so assume it should be okay for all AbstractFloats, but it does depend on eps and I think the conditionals that depend on eps and floatmin may not hold for other more 'generic' AbstractFloats types?

[cfborges]

@cfborges Got it, thanks for the clarification.
Should the method signature be restricted to IEEEFloat, instead of the more generic AbstractFloat? Does the algorithm explicitly depend upon the representation of IEEE float? Glancing at the code I don't see anything that manipulates the bit field so assume it should be okay for all AbstractFloats, but it does depend on eps and I think the conditionals that depend on eps and floatmin may not hold for other more 'generic' AbstractFloats types?

It should extend to any floating point system that uses round to nearest. The only things that really depend on the IEEE formats are the parts that prevent overflow/underflow. If someone has an abstract FPS that does something weird (like variable length significands) then it would have to be analyzed further to verify the accuracy. But at worst it would still be better than the previously existing hypot.

[musm]

Thanks for the review @stevengj . Fixed up the latest commit to change it to T<:Real, just as we do with other elementary functions instead of <:Number, since we need a specialized method for ::Complex anyways.

This should we good to go now.

[musm]

good to merge?