Green Maths Gurus - Help!

[k brown]

Is that what the preset module in the drop-down selectors do? Their input is an integer from the selector, then it's quantized into a precise float value that's stored by the preset prim?

So, was I closer to the mark with this? I pretty much follow where you say we're off the mark, but without a concrete example to demonstrate, it remains unclear just how to do what you're saying. When you talk of integers are you speaking generically in mathmatics terms or the actual FS Integer greens? That's why I asked about the preset module in the drop-down selectors, which take integers at their inputs, but gets stored by the preset prim as a float.

[tulamide]

Is that what the preset module in the drop-down selectors do? Their input is an integer from the selector, then it's quantized into a precise float value that's stored by the preset prim?

So, was I closer to the mark with this? I pretty much follow where you say we're off the mark, but without a concrete example to demonstrate, it remains unclear just how to do what you're saying. When you talk of integers are you speaking generically in mathmatics terms or the actual FS Integer greens? That's why I asked about the preset module in the drop-down selectors, which take integers at their inputs, but gets stored by the preset prim as a float.

Yes, you were closer. But I just don't know to which selector you refer to, so I can't comment on that specific one. In your schematic the waveform selection is controlled by a knob which stores a normalized float value.

Here's an example of storing an integer with the float datatype. Switch programs, enter new integers, just don't use fractions!

[k brown]

I was referring the the generic toolbox Selector module (the earlier non-Ruby one).

I clearly don't understand what you mean by integers, because there aren't any in this example.

[deraudrl]

But if you choose a value of say 100 this gives a reciprocal of exactly 0.01 so there’s no rounding effect when divided and multiplied.

That's a misconception! A single-precision float (the ones we have to use in Flowstone) works a little different. There's a sign bit, a mantissa and an exponent. There's a specific way of storing a number. That'S why I always say it "represents a number". A float never stores a value (e.g. 0.125). Instead it converts this number into a number of instructions for certain calculations. Those calculations are then signified by bits, and its those bits that are actually stored in a float. When accessing a number, the process is inverted. The bits are read, the calculations set up accordingly and from the combinations of the calculations the original value is restored. Since there is a limit to both, the number of bits and the base of the calculation system (which is not base 10 as in our human decimal system, but base 2, representing the on/off states of bits), the results of the reconstruction of the original value can be off for any digit length of our human decimal system.
For example, you can't store 0.01 exactly. The reconstruction will be off (see here)

So, when you multiply something that is already off, you increase the error. That you didn't experience any issues doesn't mean there aren't any. You just got away with it. But it is not reliable!

The ONLY way to store a decimal number exactly is to store it as an integer up to the float's limit of 16777216 (2^24). Any integer within this range will be represented exactly by the base 2 calculations. 257 will always be reconstructed as exactly 257.

The "only" way? There's nothing wrong with Spogg's method as long as the base-2 nature of the internal calculations are taken into account: instead of using 100 in his example, just use 128. Or, generalized, pick N so that 2^N is greater than the largest integer you wish to store in the preset, divide by 2^N on output and multiply by 2^N on input. The stored value is a VST-compliant 0-to-1 and it can be exactly represented in a short(ish) string.

(Note that, for the purposes of the current problem, N is rather small. It could be as large as 24 but I really don't think anyone wants to deal with a dropdown list with more than a few hundred entries, so 8-10 is a more realistic limit.)

[tulamide]

I was referring the the generic toolbox Selector module (the earlier non-Ruby one).

I clearly don't understand what you mean by integers, because there aren't any in this example.

What? So you don't see the numbers 6, 257 and 1089, when switching the programs? Those are integers.
https://en.wikipedia.org/wiki/Integer

257 = integer
257.65 = rational

[tulamide]

But if you choose a value of say 100 this gives a reciprocal of exactly 0.01 so there’s no rounding effect when divided and multiplied.

That's a misconception! A single-precision float (the ones we have to use in Flowstone) works a little different. There's a sign bit, a mantissa and an exponent. There's a specific way of storing a number. That'S why I always say it "represents a number". A float never stores a value (e.g. 0.125). Instead it converts this number into a number of instructions for certain calculations. Those calculations are then signified by bits, and its those bits that are actually stored in a float. When accessing a number, the process is inverted. The bits are read, the calculations set up accordingly and from the combinations of the calculations the original value is restored. Since there is a limit to both, the number of bits and the base of the calculation system (which is not base 10 as in our human decimal system, but base 2, representing the on/off states of bits), the results of the reconstruction of the original value can be off for any digit length of our human decimal system.
For example, you can't store 0.01 exactly. The reconstruction will be off (see here)

So, when you multiply something that is already off, you increase the error. That you didn't experience any issues doesn't mean there aren't any. You just got away with it. But it is not reliable!

The ONLY way to store a decimal number exactly is to store it as an integer up to the float's limit of 16777216 (2^24). Any integer within this range will be represented exactly by the base 2 calculations. 257 will always be reconstructed as exactly 257.

The "only" way? There's nothing wrong with Spogg's method as long as the base-2 nature of the internal calculations are taken into account: instead of using 100 in his example, just use 128. Or, generalized, pick N so that 2^N is greater than the largest integer you wish to store in the preset, divide by 2^N on output and multiply by 2^N on input. The stored value is a VST-compliant 0-to-1 and it can be exactly represented in a short(ish) string.

(Note that, for the purposes of the current problem, N is rather small. It could be as large as 24 but I really don't think anyone wants to deal with a dropdown list with more than a few hundred entries, so 8-10 is a more realistic limit.)

True! But not as obvious. However, Spogg'S example does NOT work reliably and Integers ARE working reliably. And now your base 2 suggestion is a second possibility that IS reliable.
What I mean is, my explanation, why it didn't work is correct, as is my statement, that Spogg'S example is based on a misconception (just beacuse it is of a fixed low number of digits doesn't prevent it from errors).

[k brown]

I was referring the the generic toolbox Selector module (the earlier non-Ruby one).

I clearly don't understand what you mean by integers, because there aren't any in this example.

What? So you don't see the numbers 6, 257 and 1089, when switching the programs? Those are integers.
https://en.wikipedia.org/wiki/Integer

257 = integer
257.65 = rational

Yes I saw them; I didn't see any green Integer prims - that's why I asked if you were referring to integrs in mathmatics terms or Intergers as green prims in FS.

[tulamide]

I was referring the the generic toolbox Selector module (the earlier non-Ruby one).

I clearly don't understand what you mean by integers, because there aren't any in this example.

What? So you don't see the numbers 6, 257 and 1089, when switching the programs? Those are integers.
https://en.wikipedia.org/wiki/Integer

257 = integer
257.65 = rational

Yes I saw them; I didn't see any green Integer prims - that's why I asked if you were referring to integrs in mathmatics terms or Intergers as green prims in FS.

Doesn't make a difference. Both are integers. Wether you present them in a green integer prim or in a green float prim.

[k brown]

Makes a difference as far as what tools/parts are used to implement what you're saying.

In case all here have not figured it out already, this place is the living room of Big Bang Theory (was that show on European television?), and I'm Penny.

Much as I appreciate the attempt to help, all this theoretical back-and-forth gets me (Penny) no closer to a solution to my issue. Everything I know about math I learned in Art School. And most of what I know about FlowStone is what I figured out by thrashing about on my own and looking at the schematics others - not nearly enough to follow 85% of this, my apologies.

[tulamide]

Makes a difference as far as what tools/parts are used to implement what you're saying.

No. It doesn't matter in this case, where the integer is lower than 2^24. You can either use a green integer prim, a green float prim, a RubyEdit with either string, float or integer output, a green string prim. As long as the value that goes into the parameter prim is an integer.

I can't make it any more simple.

And yes, of course we know Big Bang Theory! And I'm Penny, too!