more constants available in FrameLib

[steadykammer]

trafficstars

I find getting two like this:

...disappointing, and I request we have more constants available in FrameLib (e.g., TWOPI).

I would also like to be able to use constants in any fl.* box.

[AlexHarker]

Do you realise that under the hood this will become a constant? That's one reason I don't make loads, because you can write (1 / sqrt(2)) and the result is calculated as a constant, so I find the expansion untidy, as in a maths equation pi is the constant and any multipliers are separate multipliers.

[steadykammer]

Do you realise that under the hood this will become a constant? That's one reason I don't make loads, because you can write (1 / sqrt(2)) and the result is calculated as a constant, so I find the expansion untidy, as in a maths equation pi is the constant and any multipliers are separate multipliers.

Sure I realise. But I do not want to have to type that crap all the time. A basic subset of constants aliases like in gen~ for example would just be a nice-to-have. E.g. TWOPI, SQRT1_2, etc...

[AlexHarker]

That makes sense in a context of a language where optimisation to a constant cannot be guaranteed, but less so in one where it can.

2*pi twopi

It's also hard to argue that the second of these is longer to type when it is less characters

1/sqrt(2) sqrt(1/2) sqrt1_2

On this one there is a one character advantage to either of the other forms (assuming no spaces).

I'll put this reference here for consideration. I've perhaps more time for the ones that are multiples/divisors, but the only sensible set to consider would be those in math.h - I'll think further. In terms of constants in all framelib max (or pd) boxes the can be considered, but the question is whether there might be a circumstance in which this would prevent a user using any of those constants as a symbol (which might be a valid thing to do) - this is particularly problematic for things like selecting a constant in fl.constant~ - so it's not trivial to consider.

https://www.lemoda.net/c/maths-constants/

[steadykammer]

Sure. It is in large part a human thing rather than a logic/maths thing. What it is easy to read and/or remember. Asking a user to write "1/sqrt(2)" is pedantic, not human :-) , and even C++20 defines all these now. But really, it was just a minor suggestion/topic.

[artificiel]

FYI, C++20 does not define "all these": inv_sqrtpi is there, but 2*pi (original example of this issue) is not defined — https://en.cppreference.com/w/cpp/header/numbers.

internally FL should use std::numbers::pi instead of cmath, if only in that it will adapt to the platform resolution for float/double/long double better than an adhoc #define.

form a user perspective it seems logical to support the C++20 defines (it simplifies documentation and eliminates debate).

[AlexHarker]

Thanks. Whilst changes to the C++ standard generally improve consistency and platform support, FrameLib is designed to be C++11 compliant (as on the README.md). Whilst I might be persuaded to nudge that to C++14 or maybe even 17 for good reason, at present I wouldn't want to rely on C++20 just in order to gain access to some numerical constants.

However, the reference points of what to consider including are definitely relevant and I'll consider updating the expression and constant objects accordingly.