Julia: Make Base.Math a proper standard library

[musm]

Make Base.Math a proper standard library, like it is in many other languages. I'm guessing this kinda just got forgot in the julia 1.0 push.

[musm]

A bit surprised at the downvotes anyone mind expressing why they are against this?

I was thinking this would be good for several reasons.

1. Allow people to swap out math libraries easily in favor or other ones (e.g. SLEEF.jl)
2. Not all modules necessarily need the library and thus would help reduce compiled code (thinking of PackageCompiler)
3. Would share the benefits of other standard libraries having seperate versioning from Base.

[ViralBShah]

I think this is generally a good idea - the ability to make it easy to provide alternate implementations. The exact mechanism is perhaps up for debate.

[JeffBezanson]

How do you define what counts as Math? Everything is math.

[musm]

Basic elementary math functions such as

sin, cos, tan, asin, acos, atan, sincos, sinh, cosh, tanh,
asinh, acosh, atanh, log, log2, log10, log1p, ilogb, exp, exp2, exp10, expm1, ldexp, cbrt, pow

we can also take inspiration from other langs on what they choose to export from the Math library such as https://golang.org/pkg/math/

The name Math for these is up for debate, but this is what I originally had in mind.

[ViralBShah]

I thought this basically referred to the Base.Math module, making it a module in stdlib.

[musm]

I was generally reply to the
comment

How do you define what counts as Math? Everything is math.

But yes it's about making Base.Math and it's exports an stdlib just like LinearAlgebra

[JeffBezanson]

Currently I believe everything in Math is re-exported by Base, because it's so useful and universal. In fact some things are defined in Base and imported into Math. So it's not really functioning as a well-defined library right now, just a somewhat-arbitrary submodule.

Of course many people are familiar with C libm, and I suspect most languages just imitated that precedent. But I think that structure reflects a lot of bias --- those languages are primarily concerned with moving bytes around, and to them computing a cosine is some weird thing a few people maybe do on rare occasion. It's probably also left over from a world where floating-point hardware was not universal. So I think that's not the only reasonable perspective.

[ararslan]

Would share the benefits of other standard libraries having seperate versioning from Base.

Seems pretty unimportant for these functions, which almost never change aside from very, very occasional bugfixes which can be easily backported.

Allow people to swap out math libraries easily in favor or other ones (e.g. SLEEF.jl)

SLEEF.sin for example is easy enough to write, and makes it clearer that you're using an alternative, non-standard implementation.

[musm]

Of course many people are familiar with C libm, and I suspect most languages just imitated that precedent. But I think that structure reflects a lot of bias --- those languages are primarily concerned with moving bytes around, and to them computing a cosine is some weird thing a few people maybe do on rare occasion. It's probably also left over from a world where floating-point hardware was not universal. So I think that's not the only reasonable perspective.

To play devil's advocate if we look at the exports from the Base.Math module

export sin, cos, sincos, tan, sinh, cosh, tanh, asin, acos, atan,
       asinh, acosh, atanh, sec, csc, cot, asec, acsc, acot,
       sech, csch, coth, asech, acsch, acoth,
       sinpi, cospi, sinc, cosc,
       cosd, cotd, cscd, secd, sind, tand, sincosd,
       acosd, acotd, acscd, asecd, asind, atand,
       rad2deg, deg2rad,
       log, log2, log10, log1p, exponent, exp, exp2, exp10, expm1,
       cbrt, sqrt, significand,
       hypot, max, min, minmax, ldexp, frexp,
       clamp, clamp!, modf, ^, mod2pi, rem2pi,
       @evalpoly

Other than maybe max,min I'd wager that these are primarily used in mathematics based packages. For example, HDF5.jl doesn't really use any of these functions.