step -1
BlitzMax Forums/BlitzMax Beginners Area/step -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 |
| ||
Hmmm... a bug methinks However, using an Int will be slightly quicker than using a byte anyway. |
| ||
well, I hope it's a bug, and not intended :P btw, are ints always faster than shorts or bytes? |
| ||
but if BYTE are UNSIGNED how BlitzMax can handle a NEGATIVE step (-1). It's not a bug |
| ||
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." |
| ||
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. |
| ||
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 |
| ||
dont' worry - I'm a new to bmax too - it was a rare moment of mental lucidity - probably the only one in 2006! :) |
| ||
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 |
| ||
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 |
| ||
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. |
| ||
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 |
| ||
I'm with CS_TBL. 255-1=254. 0-1=255 255-1<>255!!! |
| ||
255-1<>255!!! Sure it is.255: %11111111 -1: %11111111 --------------- = %11111111Unsigned Byte value for %11111111 = 255 = $FF |
| ||
Signed or unsigned, a byte should be able to walk backwards from 10 to 0. |
| ||
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. |
| ||
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 Nextand 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 NextHere 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. |
| ||
Integers are faster than bytes, Ive done some tests. But the differences are only so minor. |