Found pretty serious Integer stack bug

[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...

[Numsgil]

Usually if there's any problem with fractions, you can just multiply everything by 100 or 1000, do your calculations, and then divide by 100 or 1000.  Sort of a manual floating point.

If we go this way, I think we should find a way to do fixed point.  Hard limit the number of decimals to 3 or 4.  If you thought your example was unintuitive, imagine someone banging their head against a wall because of floating point inaccuracies.  That was one nice thing about integers.  You could do an "a = b" test.  You can't really do that with floating point numbers.

So I dunno.  On the one hand, floating point numbers are a whole can of worms I'm not sure we want to open.  On the other, it eliminates problems with integer truncation.

[googlyeyesultra]

I'd recommend re-rerunning all of leagues under it without the spiffy speed features and see if any of the bots aren't able to operate.

Oh, and you should never leave calculations of constants to a program. Get out your calculator and do it, and reduce that to .2.

[EricL]

I'm going to back this out for now.  There are implications in things like bitwise operators and such that I just don't want to have to test or explore.

[Jez]

I'd recommend re-rerunning all of leagues under it without the spiffy speed features and see if any of the bots aren't able to operate.

I've tried that, causes problems.

I now stick by the tried and tested 'It can cheat to get a place in the league and if that cheat is fixed the bot keeps its place!'