Move special functions to a separate module

[musm]

Would be good to separate the file to a separate folder like LinAlg to have for additional pure Julia implementations of math functions.

[yuyichao]

Again, please update/ping original PR instead of opening new ones!

[ViralBShah]

Why do all this moving? For now, can we leave things as they are until there is a larger overhaul/reason to move things?

[simonbyrne]

I can see the appeal: it does follow the pattern of other submodules whereby we put all the necessary files under 1 directory. Especially since special is already a directory.

Alternatively, there is #8536, but not much has happened on that front, and no concrete plan has emerged.

[tkelman]

There is a plan. It's #18795.

[simonbyrne]

It my be fair to call it a vague plan, but it is far from concrete.

[tkelman]

What's not concrete about it?

[musm]

it's bothersome that replutil.jl depends on the filename and location: https://github.com/musm/julia/blob/98466be678d1b5ad53de3deda8601462e9231f39/base/replutil.jl#L217
this will need to decoupled if the modules are moving out of the main julia repo.

[tkelman]

Special functions could be if someone implements it. I don't think the rest of math.jl should move as soon though as that's more widely used.

[tkelman]

some of these file locations are also listed as exceptions in contrib/add_license_to_files.jl

[simonbyrne]

In that case, why don't we move the special functions to a new module, so that they're ready to be split out?

[musm]

What happens in the future for packages that need a function like erf ? Will they all need to import the SpecialFunctions package?

IMO it might be worthy to keep some special functions in base mlib such as erf and gamma because of their fundamental importance in engineering and stats, etc. This practice is not uncommon to other mlibs, since they typically guarantee a high quality implementation for such critical functions

Thoughts ?

@simonbyrne

[ViralBShah]

Yes, we will still want some of these in base. Also, I don't see why we can't reorganize things in base until default packages happens, if there is a good reason to do them.

[tkelman]

airy, bessel, and probably dawson would be less disruptive to move in an earlier phase than erf and gamma.

[simonbyrne]

Agreed: lets move those first; others we can evaluate on a case-by-case basis.

I think the main steps would be (until it's clear what form the stdlib would take):

• move special/bessel.jl to specialfunctions/SpecialFunctions.jl, which contains a module of the same name; can optionally split this out into smaller files
• all other files under special get moved to under math as in this PR.

Does that seem reasonable?

[musm]

IMO I would keep bessel, gamma, and erf in Math (which admittedly is most of the function in special) , and move the rest to SpecialFunctions.

In case, someone has not seen this: http://www.evanmiller.org/statistical-shortcomings-in-standard-math-libraries.html (just something to consider/keep in mind)

[simonbyrne]

How is that different than your current PR?

[simonbyrne]

Bessel & Airy functions have long been marked for removal (#8536): they are the messiest to call (see all the glue code, global buffer variables and various issues about Float32, Float64 and BigFloat), and the least used. Why would you want to keep them in Base?

[musm]

I see. Seems a little arbitrary then to keep erf and gamma in Math then, no?
So the options are:

1. Move all special functions to SpecialFunctions.jl
2. Move only erf and gamma (pretty arbitrary, but w/e)
3. Move none.

[simonbyrne]

erf,erfc and gamma are defined in the C math library, so there is some precedence here. Furthermore, they're also single argument functions, and used in a lot of domains.

There is some discussion of which functions to be moved also in #4301: perhaps best to continue this there.

[ViralBShah]

It would be nice to get this merged in some shape for 0.6, even if we can't get 100% agreement on module names.

[musm]

Yes perhaps we need better names for these. Maybe Math and SpecFun are not the most suggestive. Suggestions?

[tkelman]

SpecialFunctions ?

[musm]

Ok rebased. Are these the names we want? Math for elementary functions and more core math related functions and SpecialFunctions for all the special functions? Suggestions welcome. We should try to finalize this now for #18795 .

[simonbyrne]

Any reason you closed this? AFAIK we still wanted to do this.

[musm]

It got a thumbs down and the comment with a couple thumbs up #19560 (comment)
doesn't seem like people want to do this now

[tkelman]

The recent versions of this PR were better than where it started.

[musm]

K, I'll reopen and see if there is interest in getting this in.