+- Forum (https://www.boriel.com/forum)
+-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11)
+---- Forum: Bug Reports (https://www.boriel.com/forum/forumdisplay.php?fid=15)
+---- Thread: byte loops (*solved*) (/showthread.php?tid=456)
Pages:
1
2
byte loops (*solved*) - britlion - 04-19-2012
This seems to not work - skipping the loop. Surely small negative numbers shouldn't be an issue for a byte sized variable?
Code:
DIM x as byte
for x=-91 to 91
print x
next xRe: byte loops - LCD - 04-19-2012
Confirmed!Also if the loop is from -1 to 91, it exits at 70!!! This is abnormal.
Forget what I said, I forgot that in ZXBC print does not scroll but starts from top of scereen again, ovberwriting old text, I just saw "70" as lowest number :oops:
Re: byte loops - boriel - 04-19-2012
Hmm. This is a Serious bug, considering we (yes, you and me
) extensively tested this during the type-migration from 1.2.6 to 1.2.8.Will check this tonight!
Meanwhile: Can you check it with Integer and Long types? :-| I guess this is a wrong (unsigned) conversion for byte types.
Re: byte loops - britlion - 04-19-2012
boriel Wrote:Meanwhile: Can you check it with Integer and Long types? :-| I guess this is a wrong (unsigned) conversion for byte types.
I think I tested integer, and that worked, last night. I'll try to find time to squeeze some tests in, but busy at the moment
Re: byte loops - LCD - 04-19-2012
My experiments:
Code:
DIM x as byte
for x=-36 to 91
print x;" , ";
next xCode:
DIM x as byte
for x=-37 to 91
print x;" , ";
next xCode:
DIM x as Integer
for x=-20000 to 20000
print x;" , ";
next xCode:
DIM x as Integer
for x=-15000 to 15000
print x;" , ";
next xCode:
DIM x as Long
for x=-1100000000 to 1100000000
print x;" , ";
next xCode:
DIM x as Long
for x=-1000000000 to 1000000000
print x;" , ";
next xCode:
DIM x as byte
for x=-91 to 36
print x;" , ";
next xCode:
DIM x as byte
for x=-91 to 37
print x;" , ";
next x
hock:OMG, how it can be?
Re: byte loops - britlion - 04-19-2012
Interesting.
Looks to me as though it's an issue if the gap from start -> end is greater than the range of the variable that's holding them....
ie bigger than 128 for a byte
or 32767 for an integer.
Re: byte loops - LCD - 04-20-2012
Sounds logical, but it means a complete rewrite of the FOR NEXT Routine for signed types. I wonder if a loop 20 TO 140 would work with BYTE type... I'm not at home to test it...
Re: byte loops - boriel - 04-20-2012
britlion Wrote:Interesting.It's exactly that (after debugging yesterday night). Basically, when end - start overflows.
Looks to me as though it's an issue if the gap from start -> end is greater than the range of the variable that's holding them....
ie bigger than 128 for a byte
or 32767 for an integer.
This is not a bug in for, but (again :!
with relational operators ("comparators") for signed values, so (a < b) for signed should fail also. It seems a regression bug when reintroduced in 1.2.8 after the "hard refactorization II".
Re: byte loops - boriel - 04-20-2012
Okay: This is a *dangerous* bug. It happened will operators <, <=, >, >= for signed (Byte, Integer and probably Long) types.
Currently, only Long has not been tested (and fixed). So please, please, download and check it now, the new version 1.2.9s841 and tell me.
Re: byte loops - LCD - 04-21-2012
boriel Wrote:Okay: This is a *dangerous* bug. It happened will operators <, <=, >, >= for signed (Byte, Integer and probably Long) types.Okay, BYTE and INTEGER types works now, LONG does not work.
Currently, only Long has not been tested (and fixed). So please, please, download and check it now, the new version 1.2.9s841 and tell me.
Code:
dim x as long
x=-2000000000
if x<1900000000 then print "okay":end IfIt is not "dangerous", I'm still alive (
) even after testing it. But it was a serius bug.
Re: byte loops - boriel - 04-22-2012
Well, I meant not only serious, but highly probable to happen (specially for byte types). Also Fixed types where affected (they are compared as Long's). It also might affect correctly written programs (specially games) compiled in the past!
So the "danger" resides in some ZX Basic contests I've seen in some webs.I think it's already fixed. Please, try 1.2.9s852 and tell me?
Re: byte loops - britlion - 04-22-2012
Yes - this update fixed this. This program depends upon loops from -x+median to x+median.
The question now is how to get it faster. The slowest part is generating a random number for each pixel - but each time I've tried a rough and ready faster rnd, it makes it look awful
Re: byte loops - boriel - 04-22-2012
Whoa! ZX Spectrum Rendering!
hock: It will always run slow .Are you using Floats or Fixeds? Also, the RND is already optimized and produces a better random pattern than the ZX Spectrum one. You should perhaps try a random Stream generator? (I've used in cryptography: <!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/Stream_cipher">http://en.wikipedia.org/wiki/Stream_cipher</a><!-- m --> random bit generator?)
Re: byte loops (*solved*) - britlion - 05-28-2012
And in fact, if I try the xor-shift generator ( <!-- l --><a class="postlink-local" href="http://www.boriel.com/forum/post2853.html?hilit=random#p2853">post2853.html?hilit=random#p2853</a><!-- l --> ) it finishes in 19 seconds, instead of 48...
Re: byte loops (*solved*) - boriel - 05-28-2012
Yes, I overlooked the stream rnd generator. Hmmm. Too many things to include in the library!
Can you plot RND * 256, RND * 192 for about... let's say 10.000 iterations, and compare the ZX Basic RND and yours?
ZX Basic is really good, but not as fast as this one, since it uses ULong (32 bit x 32 bit = 64 bit) multiplication!