Is there a way to do big calculations without hitting integer overflow?
-
Hi there, new to HISE and fairly new to coding so this might be a dumb question, but I'm wondering if there's any way to calculate higher numbers before they go negative?
I'm working on a program to help visualise different tuning systems; you set a tuning system and it shows you how it maps to the keyboard and gives you live information on the ratios between the notes you're playing.
However, if you use a scale which is an equal division of an interval, such as 12 divisions of the octave, the main one used for western music, the pitches are in ratios of irrational numbers. I want to show users an approximation of the closest pure ratios to these irrational intervals and I've done it like this:
Find the closest approximate fractions to the cent value of the irrational interval e.g. 1/1, 20/19, 17/13, 12/7....
Multiply the set by each unique denominator, so that they're all integers e.g. 1729, 1820, 2261, 2964...
Then display as usual, doing real-time calculation to reduce the ratios e.g. if you played the 20/19 note and the 12/17 note at the same time, 1820 and 2964 reduce to 35:57, which is more useful to look at than these huge numbers.
The problem is the multiplication step can get out of hand very quickly, especially if you have a 10+ note scale, and hits the 2 billion integer overflow quite easily.
My best fix is to limit the approximation step to smaller fractions, making less accurate approximations but more manageable numbers. Before I commit to this I just wanted to ask if I can increase the integer overflow limit, or is this a hard rule in programming?
Thanks!
-
@cynthasiser well integer overflow is pretty much fixed, so to get around it most of the time we calculate in floating point and flip to integer at the end....
-
@Lindon Okay, thank you! That's kind of what I'm doing but I guess the problem is I actually need the giant numbers because I'm working with exact integer ratios. I think I've found a better way of approaching the problem though, as I got it working with the smaller approximations and the behaviour wasn't quite what I wanted anyway.
