Is there a best practice for creating constants in core for precise algorithms (e.g. a Pi constant)?

Ari_BirthdaySurprise · July 11

In designing high precision algorithms in core, is there anything relevant regarding difference in precision among different constant types/configurations?

Example constant types/configurations:

const
quickconst on a math module input (e.g. +/*/|x|/etc.)
quickconst on macro input / output
primary constant connected to core cell input
and any of the above constant types sent to a quickbus or distribution bus

Anyone know of any quirks in Reaktor that should lean me toward avoiding or favoring an approach?

Alternatively, is there a better unlisted way for developing a high precision constant? If so, how would you go about creating a Pi constant, for example?

colB · July 13

Kinda surprised that someone who knows that they need that level of precision can't just test it for themselves ;)

Here I did some random arithmetic in Windows calculator:

Then I copied that value and pasted it into a constant in a 64bit core cell, it was truncated by Reaktor (or rounded?.. need to test that) to 64bit aka a 'double' (you need to look in the properties pane for the constant to see the full value).

I then did the same calculation in a 64bit core cell, and the tool tip shows the resulting value to be 0

Then I deleted that '3' from the end of the constant, and the tool tip now shows the error

What is fascinating though is that if I replace the constant with a 'quick' constant and paste in the value copied directly from the calculator, I get the correct answer - 0. However, if I copy and paste the value from the properties pane of the correct value constant, I get an error of -4.44089E-16. That's a miniscule error, but does suggest that what Reaktor is showing us in the properties pane might not be what it's using in the background?

Not to worry though, if you need the kind of precision where an error of -4.44089E-16 is a problem, then Reaktor is entirely the wrong environment for you :)

colB · July 13

Kinda surprised that someone who knows that they need that level of precision can't just test it for themselves ;)

Here I did some random arithmetic in Windows calculator:

Then I copied that value and pasted it into a constant in a 64bit core cell, it was truncated by Reaktor (or rounded?.. need to test that) to 64bit aka a 'double' (you need to look in the properties pane for the constant to see the full value).

I then did the same calculation in a 64bit core cell, and the tool tip shows the resulting value to be 0

Then I deleted that '3' from the end of the constant, and the tool tip now shows the error

What is fascinating though is that if I replace the constant with a 'quick' constant and paste in the value copied directly from the calculator, I get the correct answer - 0. However, if I copy and paste the value from the properties pane of the correct value constant, I get an error of -4.44089E-16. That's a miniscule error, but does suggest that what Reaktor is showing us in the properties pane might not be what it's using in the background?

Not to worry though, if you need the kind of precision where an error of -4.44089E-16 is a problem, then Reaktor is entirely the wrong environment for you :)

colB · July 13

OK, I think what is happening is that, internally, Reaktor is truncating (or rounding?) the value in binary, but then that is converted to a text based decimal representation where it loses some precision in the base 10 rounding, so if we then cut and paste from that we lose that -4.44089E-16

Ari_BirthdaySurprise · July 16

Thanks, Colin! That was what I needed.

https://community.native-instruments.com/discussion/comment/164898#Comment_164898

I'm very new to caring about precision. =) I did do some testing and didn't understand the results, which is why I posted. All good now.

I think you're probably dead-on with your intuition about the weirdness re: consts. That was what forced me to pose the question so elaborately.

Big fan of your work!

Studiowaves · July 28

https://community.native-instruments.com/discussion/comment/164899#Comment_164899

Thanks here too. Although I rarely use 64 bit precision, I might have overlooked the fact that the core cell needs to be 64bit in order to transmit that info downstream. Will 32 bit core cells allow internal 64 bit precision though. Since you're already set up, can you change the core cell to 32bits and see if the results are the same inside the core. If so, check the outside of the core and see if the results have been truncated. Did you save the ensemble?

colB · July 28

https://community.native-instruments.com/discussion/comment/168662#Comment_168662

Since you're already set up, can you change the core cell to 32bits and see if the results are the same inside the core.

I think you can do that easily yourself ;)

Studiowaves · July 28

https://community.native-instruments.com/discussion/comment/168707#Comment_168707

I tried but there seems to be no difference. Here's two identical core cells except one is 32 bit and the other is 64. I'm not sure what I'm doing wrong, it looks right.

32 bit and 64 bit core cells for comparison.ens

Studiowaves · July 29

https://community.native-instruments.com/discussion/comment/168707#Comment_168707

I wonder if this has something to do with it. https://support.native-instruments.com/hc/en-us/articles/4402723506833-Reaktor-6-Goes-64-Bit-Only

colB · July 29

The precision of exp (and log) is selectable in properties. Maximum is 32bit. Seem odd that you would choose this rather than something simple, like division or multiplication.

Studiowaves · July 30

https://community.native-instruments.com/discussion/comment/169017#Comment_169017

I used that to generate a 64 bit value. It matched the value of the calculator on my computer. I think that makes it a 64 bit value. If so, would that mean it's actually working in 64 bit mode even though they are 32 bits. Either it is or I'm doing something wrong. I think 2^32 is a 32 bit value which is far shy of a 64 bit number. The max is 4,294,967,296 for 32 bits. My guess I'm looking at it all wrong.

colB · August 2

https://community.native-instruments.com/discussion/comment/169237#Comment_169237

hmm, I think I understand where you went wrong.

2^32 is not some value limit for a 32bit float. The maximum value for a 32bit float is 3.4028237E+38, which is a huge number. Floats only use 23+1 bits to represent the value (32 actual plus one implicit), the other bits define the sign and the exponent.

So very large, and very tiny values can be represented. The range, defined by the exponent, is divided into 2^24 individual values, so the practical limit is usually not maximum or minimum value, but instead the precision within a range is limited.

I would guess that powers of two are the most likely values to be exactly representable in a binary numeric system even where overall precision is pretty low.

Even a stopped clock shows the correct time twice a day

Studiowaves · August 2

https://community.native-instruments.com/discussion/comment/169921#Comment_169921

Seems I was on the right track just the wrong train as usual. So it's a floating point system then. Just a guess but 64 bit might end up meaning double precision floating point. I had to read up on this, that's pretty cool mathematics. https://en.wikipedia.org/wiki/Single-precision_floating-point_format

Is there a best practice for creating constants in core for precise algorithms (e.g. a Pi constant)?

Best Answer

Answers

Categories