Supercollider: SimpleNumber.sincPi naming convention

[khoin]

I believe the naming convention for the method .sincPi for SimpleNumber from the Boost Special Function is confusing.

.sincPi is defined to be sin(x) / (x), both here and here.

And the Boost webpage justifies it further here: https://www.boost.org/doc/libs/1_62_0/libs/math/doc/html/math_toolkit/sinc/sinc_overview.html

sinc_a(x) = sin(x * pi/a) / (x* pi/a)

This makes sense if you read x.sincPi like this: "the sinus cardinal of index Pi of x"; i.e., replacing a above with pi.

However, from the same library, .cosPi and .sinPi is defined to be: cos(pi * x) and sin(pi * x). Here, you obviously see where my confusion arose:
If .cosPi and .sinPi was defined to be:
cos_a(x) = cos(x * pi/a) where a is Pi,
then this would be entirely consistent with .sincPi. But that isn't the case.

Should this be something SuperCollider would have to talk with Boost about? Or do we have full advantage on modifying the naming conventions?

Related Pings

https://github.com/supercollider/supercollider/commit/eafb87a9529941872f68939871e4063b2cbc1d2c
@mtmccrea

Environment

• SuperCollider version: 3.10
• Operating system: Windows 10

[brianlheim]

you can choose any name you want, but i don't think you're going to come up with anything that is completely unambiguous while also being usably terse. this naming has the merit of making it easy to cross-reference our implementations with the underlying library. i don't see the point in changing it.

[khoin]

Right. I agree. Changing it now would cause mass confusion, either for SuperCollider devs (since 3.10 hasn't been out (to users) for too long), or for people who use Boost.

It's a bummer that such weird naming convention was made that shows inconsistency between .sinPi and .sincPi.

[mtmccrea]

@khoin thanks for the feedback.

After finding a number of inconsistencies/confusing conventions within boost, I decided to simply stick with what has already been used in boost, for the reasons that @brianlheim mentioned.

Or do we have full advantage on modifying the naming conventions?

We do have full advantage on documentation ;) Feel free to submit useful additions to documentation, it's always appreciated. More info in docs the better IMO.