Add customization point to replace math functions for platform independent results

[LarsSkiba]

Hello Angus,

i'd would like to achieve platform and compiler independent results with Clipper2. One important aspect is that different compiler implementations of common math functions produce different results. Putting these functions in a common header provides a convenient way to replace them with custom functions and does not have side effects.

[AngusJohnson]

Thanks for the suggested changes but my C++ skills aren't sufficient to meaningfully comment on how widely useful they will be.
So unless they get enthusiastic endorsement from other contributors, I'll probably pass on them.

Also, WRT potential overflows you're suggesting in the existing Hypot function, I don't think overflows are possible there given that the function is only used internally on coordinate values, so the passed double values will have a rather limited range (since converted from int64_t).

[LarsSkiba]

Thanks for you response,

it is specific to software (component) vendors who provide software for a variety of computer architectures and would like to have exactly comparable results on different machines, but i don't think the PR has negative side effects except one addition header.

Maybe you could leave the PR dangling for a bit to see if we get other opinions on this topic.

Regarding hypot, you're correct and i just did not spend a lot thoughts about it and just wanted to add comments because i saw two differents usages: Maybe you could also gain a bit of performance by also replacing hypot with the "unsafe" version in GetUnitNormal l.47?

[AngusJohnson]

Maybe you could leave the PR dangling for a bit to see if we get other opinions on this topic.

That was my intention 😁.

Regarding hypot, you're correct and i just did not spend a lot thoughts about it and just wanted to add comments because i saw two differents usages: Maybe you could also gain a bit of performance by also replacing hypot with the "unsafe" version in GetUnitNormal l.47?

I agree that calling std::hypot() in GetUnitNormal is unnecessarily time costly and I've now moved the Hypot function to address that. And here's the amended comment in Hypot ...

static inline double Hypot(double x, double y)
{
	// given that this is an internal function, and given the x and y parameters
	// will always be coordinate values (or the difference between coordinate values),
	// x and y should always be within INT64_MIN to INT64_MAX. Consequently, 
	// there should be no risk that the following computation will overflow
	// see https://stackoverflow.com/a/32436148/359538
	return std::sqrt(x * x + y * y);
}