Code center > Bugs and fixes

Found pretty serious Integer stack bug

(1/2) > >>

EricL:
Just found and fixed a pretty serious bug having to do with the Integer stack.  It's called the integer stack, but values on it need not be integers.  Consider DNA such as

*.nrg 32000 div 20 100 div <

which checks to see if the bots nrg level is below 20% of the max of 32000.  You can see how decimal values do and should be pushed onto the "integer stack" internally.  With me so far?

Okay, what was happening is that the code was using Longs, not Singles for values pushed and popped on the stack.  VB was implicitly casting from Singles to Longs in PushIntStack() and PopIntStack(), essentially resulting in the rounding of the results of div and mult and perhaps other operations to whole numbers!!!!!!!  Pretty much any DNA that attempted operations on or relied upon the comparison of decimals may not work correctly in current builds!  

Instead of 20 100 div resulting in 0.2 being placed on the stack, you would get 0 placed on the stack.

As of 2.43b, everything uses Single typed vars internally, so things should work as they are suppose to.  Thought this was serious enough to call to people's attention.

googlyeyesultra:
I was aware of that, but I thought that was some sort of a feature. Essentially, it would make it so that 3 4 div would round to one, so that trying to do 1 3 4 div store wouldn't try to store anything in .75. Just make sure you set it up to round before it tries to store, or whatever.

EricL:
stores are protected.  The rounding/conversion occurs explicity in the store routine before a store is attempted, but in this case, the rounding wasn't explicit, it was (I think) just an unintended artifact of how argument passing was happening internally.

Seems logical to me that bot DNA should be able to implicitly compare decimal values on the stack.

Numsgil:
This wasn't a bug so much as the way things always have been.  Everything's been done using integers, for good or ill.  I dunno what I think about moving things to floating point on the stack.  I'll need to mull it over.

But bottom line, changing things like this is a feature instead of a bug fix.

EricL:
Yea, I kinda figured that.  But not really integers, longs.  Even the Wiki says something about stack values up to 20 gazillion....  So, there was already lots of code to convert to integers in the right range when needed for stores and memory references by abs, moding and range checking.  Also, there are lots of places where Singles are used for the calculation before rounding.  My change isn't that extensive.

The question really is what we want the result of something like

*.nrg 32000 div 20 100 div <

to be.  As it stands in versions prior to 2.43b, that line will ALWAYS return False independent of the nrg level since 20 100 div will always round to 0.  That strikes me as non-intuitive.

My fix seems to work fine on my machine(s) so far.  Wider testing is needed for sure, but at first blush, it does not appear to break much...

Navigation

[0] Message Index

[#] Next page