step -1

BlitzMax Forums/BlitzMax Beginners Area/step -1

CS_TBL(Posted 2006) [#1]
Perhaps it was mentioned already somewhere, but I spend hours figuring out why my code-intentions didn't happen, only to find out that it was my forloop that didn't do anything..

And why was that..?

Local t:Byte
For t=10 to 0 Step -1
Next

=problem!

Negative Steps only work with signed variables, not unsigned.., COME ON :D


Perturbatio(Posted 2006) [#2]
Hmmm... a bug methinks

However, using an Int will be slightly quicker than using a byte anyway.


CS_TBL(Posted 2006) [#3]
well, I hope it's a bug, and not intended :P

btw, are ints always faster than shorts or bytes?


degac(Posted 2006) [#4]
but if BYTE are UNSIGNED how BlitzMax can handle a NEGATIVE step (-1). It's not a bug


EOF(Posted 2006) [#5]
btw, are ints always faster than shorts or bytes?
From the BlitzWiki ..

"Integers are quicker than bytes. Since 32bit CPU's operate on 32bit integers there is an overhead in changing bytes to ints. You should therefore only use bytes when you have a very large array or are dealing with external functions which use bytes."


Dreamora(Posted 2006) [#6]
Yepp, a negative step with a format that does not know what negative is can logically not work ... because the stepping would be

i + step ... but -1 isn't an existing step in byte thus the reaction you saw which is correct.


CS_TBL(Posted 2006) [#7]
hm.. I'm only taking first steps into bmax, so I'm perhaps not the right one to judge on things yet, but in other languages negative steps/deltas aren't linked to the variable-type.. so whether all this is good or bad is an interesting question. :P


degac(Posted 2006) [#8]
dont' worry - I'm a new to bmax too - it was a rare moment of mental lucidity - probably the only one in 2006! :)


Dreamora(Posted 2006) [#9]
good or bad is always a subjective thing.
But it is for sure a secure way to prevent for local i:byte 10 to -10 step -1 constructions which would come up for quite sure, don't you thing? ;)
Most here even don't understand the difference between int and unsigned int or have the least knowledge of the maximum values etc of the data types


CS_TBL(Posted 2006) [#10]
In that case i should just nicely wrap around to 255.
Those same ppl who don't understand those var differences prolly auto-use ints in non-strict mode.. so that 'protection' wouldn't really be necesarry.

I still think it's just plain weird that the Step is related to the var-type.., the compiler could at least give warnings for stupid things, like forloops that aren't ever executed, because of these kinda quircks. :D


ImaginaryHuman(Posted 2006) [#11]
also some people might be expecting that they are using the byte, that it is unsigned, that it cannot handle the negative numbers, and be okay with it.


Curtastic(Posted 2006) [#12]
so this shouldn't work?
Local a:Byte
a=10
a=a+(-1)
Print a




just to complicate things:
this should execute once but it doesn't
oh and it adds -1 perfectly fine!
Local t:Byte
For t=10 To 10 Step -1
Print t
Next



Damien Sturdy(Posted 2006) [#13]
I'm with CS_TBL.

255-1=254.
0-1=255

255-1<>255!!!


FlameDuck(Posted 2006) [#14]
255-1<>255!!!
Sure it is.
255: %11111111
 -1: %11111111
---------------
 =   %11111111
Unsigned Byte value for %11111111 = 255 = $FF


Warren(Posted 2006) [#15]
Signed or unsigned, a byte should be able to walk backwards from 10 to 0.


Scienthsine(Posted 2006) [#16]
In ASM you've got a subtraction call that is for unsigned, and one that is for signed. You have to convert one of the two arguements for this to work, and then the result might not be what you expect. It's all in how that last bit it represented/treated.


Floyd(Posted 2006) [#17]
Keep in mind that "Step -1" is not subtraction. It ADDS -1 to the loop variable.

There is no number -1 for a byte, so -1 is replaced by the equivalent 255. The original example becomes
Local t:Byte
For t=10 to 0 Step 255     ' used to be -1
Next
and the loop is never entered.

You can also get bizarre results with ordinary integers by using an inappropriate step size.
Local n:Int

For n = 1 To 2000000000 Step 600000000
    Print n
Next
Here the problem is that we step past the final value while wrapping around to negative numbers. The loop doesn't terminate until we land on a suitably large positive number.


Regular K(Posted 2006) [#18]
Integers are faster than bytes, Ive done some tests. But the differences are only so minor.