Implement hyperbolic version of sinc: sinhc (feature request).

[dtabell]

Julia defines the function $\mathrm{sinc}(x)$ using the normalized form $\sin(\pi x)/(\pi x)$. Replacing $x$ by $\mathrm{i}x$ yields the new function $\sinh(\pi x)/(\pi x)$. Because this function also (annoyingly) has a singularity at the origin, I suggest implementing it as a new special function named $\mathrm{sinhc}$.

The notation $\mathrm{sinhc}$ has already been suggested, see Wolfram MathWorld, for the cognate function $\mathrm{sinh}(x)/x$, which is consistent with its definition of $\mathrm{sinc}(x)$ using the unnormalized form $\sin(x)/x$. The same (unnormalized) version appears also in the boost C++ special functions library, and uses the same notation.

I could, of course, implement this function myself, but it does seem the sort of function that merits inclusion in the standard set of Julia special functions. Please let me know if the Julia team is already at work extending the library of special functions, or if I should implement this function and issue a pull request.

[oscardssmith]

I believe it's generally recognized that sinc probably should be in SpecialFunctions.jl rather than Base, and should be named sincpi similarly to sinpi and friends (but it of course would be breaking to change that now), As such, sinch should probably be called sincpih and be contributed to SpecialFunctions rather than Julia.

[andreasvarga]

I recently used sinc for the first time in my codes and, without looking to the documentations, I used it as sinc(pi*x). After some testing I realized my error and corrected it. I hope that when you decide to replace sinc with sincpi and redefine sinc(x)as sin(x)/x, there will be, at least for a while, some warning in sincregarding the changed functionality.

[dtabell]

My understanding is that for $\mathrm{sinc}(x)$ mathematicians tend to prefer the definition $\sin(x)/x$, whereas engineers—especially for signal processing—tend to prefer $\sin(\pi x)/(\pi x)$. I don't see a reason to favor one community over the other, so perhaps supporting both makes sense. And of course a prominent warning would need to be emitted for at least a few releases, or until v.2.0.

And then have corresponding versions for $\mathrm{sinhc}$.

[dtabell]

@oscardssmith The current $\mathrm{sinc}$ lives in julia/base/special. Are you suggesting implementing $\mathrm{sinc}$, $\mathrm{sincpi}$, $\mathrm{sinhc}$, and $\mathrm{sinhcpi}$ in SpecialFunctions.jl and dropping sinc from julia/base/special? I took a look at SpecialFunctions, and the functions there seem, to me, far more special than do $\mathrm{sinc}$ and friends.

[oscardssmith]

I don't see a reason to favor one community over the other, so perhaps supporting both makes sense.

absolutely. My proposal is to deprecate sinc from Base, and impliment sinc, sincpi, sinch, sinchpi in SpecialFunctions.

I took a look at SpecialFunctions, and the functions there seem, to me, far more special than do sinc and friends.

some are and some aren't. sinc is around the same level of specialness as gamma for example.

[dtabell]

Does it make sense for me develop implementations in SpecialFunctions and then issue a pull request?

[andreasvarga]

I need sinc once in my package So, it is very convenient to have it in Base. Otherwise I have to load a whole package with functions which I don't need. So, I see no reasons do not have sinc/sincpi ALSO in Base.

[msmatsko]

I would think that all the operations mentioned in IEEE-754-2019 should be in base. Anything else should be in SpecialFunctions.jl. You would expect those functions to “come with” your numeric representation out of the box - without loading other packages.

[msmatsko]

Also, see We need to provide these IEEE754-2019 functions #32877 which goes along with this.