Welcome to %s forums

BrainModular Users Forum

Login Register

I can't put 67108863 value?i

I need help on a Patch
Post Reply
23fx23
Member
Posts: 2545
Contact:

Unread post by 23fx23 » 24 Feb 2009, 03:10

strange, when I try to put 67108863 in any math modules it goes to 67108864- if I put a -1 after that it return (-1) and not 67108863.

is that normal? any workaround?

bsork
Site Admin
Posts: 1334
Location: Asker, Norway
Contact:

Unread post by bsork » 24 Feb 2009, 07:59

Confirmed:
There's something about numbers over 2^24 (=16777216). I made a little test patch, and I could add 1 to numbers up to 2^23 and subtract 1 from numbers up to 2^24. Similar for negative, large numbers.

I used the A^B, A+B and A-B modules to test. The A^B worked ok to generate the large numbers (2^n), but I also stumbled across something wrong with it; it won't do anything if A<0.

Can't see any workaround...
Bjørn S

User avatar
senso
Site Admin
Posts: 4425
Location: France
Contact:

Unread post by senso » 24 Feb 2009, 10:00

Under Usine data's are stored as floats 32bits even if you enter an integer.

For example if you enter 100, usine stores 100.0
At this point no problem but if you enter a very big integer greater then 16777216 (witch is #FFFFFF) you reach the precision of 32bit-floats. So your integer is converted to nearest possible float according your CPU specification.
Try to enter 99999999 you will get 100000000 !!!

Now I have to tel you the truth: unlike most of marketing announcements of major audio softs, 32bit float means in fact a 24bit precision because 24bits is for the 'mantissa' and 8 for the exponent. I know it's a big deception...
see http://en.wikipedia.org/wiki/Significand

And after?
In most situations it's not a pb because the problems appears after $FFFFFF which is, for example, the highest available color.
The solution could be to increase the engine precision of Usine to 64bits but overall performances will be divided by 2 and memory usage multiplied by 2...Do you really want that?

It's seems stupid but I haven't any solution for the moment except to ask Intel to change their CPU conception...

bsork
Site Admin
Posts: 1334
Location: Asker, Norway
Contact:

Unread post by bsork » 24 Feb 2009, 10:11

@senso: I suspected that the 24+8 division of the 32 bits would be the culprit, but then I don't get why the A^B works (with a positive A). Is it maybe because different calculations are handled by different parts of the CPU? I remember back in the old days one could install a separate math coprocessor, and I think I've seen something when doing some hardware checks that implies that there is such a coprocessor within the new CPUs. Could it be that for instance +/1 is handled by the "normal" CPU part, while the power function is handled by the coprocessor part, or vice versa?

@23fx23: Just curious, but for what are you using such a large figure?
Bjørn S

User avatar
senso
Site Admin
Posts: 4425
Location: France
Contact:

Unread post by senso » 24 Feb 2009, 11:55

bsork but then I don't get why the A^B works
the operation 2^n will always give the good result because the CPU will round the result to the nearest 2^n value.

but if you enter 2.1^20 you get :
2782184,29446951548637196401 (double precision)
2782181,75 (single precision,like in usine)

so a difference factor of 0,0000009145 which is a 'normal' for 32bits

bsork
Site Admin
Posts: 1334
Location: Asker, Norway
Contact:

Unread post by bsork » 24 Feb 2009, 12:41

Thanks for the clarification, Olivier.
Bjørn S

23fx23
Member
Posts: 2545
Contact:

Unread post by 23fx23 » 24 Feb 2009, 13:31

I felt it was something related to bits, don't worry I can find a workaround, just wanted to understand..

yop bsork I was needing this value to make a true HSL selector, I had to have a 16777216 x 12 zone in the hue setup i founded, then subtract one because 16777216 is the max but as 0 is a color, the max become 16777215, (67108863 is 16777216x4 -1) wich was the zone for the red...but anyway I think it's a stupid idea as input faders seems to have 8bit precision,right? so I will make a 128 color selector, that's more than enough!!!!!

and yes olivier don't worry i prefer usine to stay fast than have a 64 bits precision..just interesting knowing the deal.

I was trying to make this because of my actual fear of cpu usage:

little Q: should we avoid data fow of types 1,7342250001 and try to get interger values, will it be lighter on cpu?
little more Q: any idea how to make only pass pair number (that way /2 will return interger and not floating) also didn't tried enough A^B wich might be a solution for my purposes.. but if usine always deal with float I shouldn't focus on that no?
cheers

User avatar
senso
Site Admin
Posts: 4425
Location: France
Contact:

Unread post by senso » 24 Feb 2009, 14:28

little Q: should we avoid data fow of types 1,7342250001 and try to get interger values, will it be lighter on cpu?
absolutely not!
do what you want with numbers the cpu load is the same between integers and floats.

also to to test if an integer X is 'pair' just test if (X mod 2) = 0; mod = modulo division in math modules.

23fx23
Member
Posts: 2545
Contact:

Unread post by 23fx23 » 24 Feb 2009, 15:27

ok cool, it will avoid me some headheach!!

Post Reply

Who is online

Users browsing this forum: No registered users and 41 guests