Boriel Basic Forum
byte loops (*solved*) - Printable Version

+- Boriel Basic Forum (https://forum.boriel.com)
+-- Forum: Compilers and Computer Languages (https://forum.boriel.com/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://forum.boriel.com/forumdisplay.php?fid=11)
+---- Forum: Bug Reports (https://forum.boriel.com/forumdisplay.php?fid=15)
+---- Thread: byte loops (*solved*) (/showthread.php?tid=456)

Pages: 1 2

byte loops (*solved*) - britlion - 2012-04-19

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 x


Re: byte loops - LCD - 2012-04-19

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 - 2012-04-19

Hmm. This is a Serious bug, considering we (yes, you and me Tongue) 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 - 2012-04-19

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 Smile

Re: byte loops - LCD - 2012-04-19

My experiments:
Code:
DIM x as byte

for x=-36 to 91
print x;" , ";
next x
Works well, but if startts wits -37:
Code:
DIM x as byte

for x=-37 to 91
print x;" , ";
next x
It does not work anymore, so 37 is a magic number.
Code:
DIM x as Integer

for x=-20000 to 20000
print x;" , ";
next x
did not work too.
Code:
DIM x as Integer

for x=-15000 to 15000
print x;" , ";
next x
Works well
Code:
DIM x as Long

for x=-1100000000 to 1100000000
print x;" , ";
next x
does not work
Code:
DIM x as Long

for x=-1000000000 to 1000000000
print x;" , ";
next x
Works

Code:
DIM x as byte

for x=-91 to 36
print x;" , ";
next x
Works
Code:
DIM x as byte

for x=-91 to 37
print x;" , ";
next x
DOES NOT WORK!!! Confusedhock:
OMG, how it can be?

Re: byte loops - britlion - 2012-04-19

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 - 2012-04-20

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 - 2012-04-20

britlion Wrote: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.
It's exactly that (after debugging yesterday night). Basically, when end - start overflows.
This is not a bug in for, but (again :!Smile 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 - 2012-04-21

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 - 2012-04-21

boriel Wrote: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.
Okay, BYTE and INTEGER types works now, LONG does not work.
Code:
dim x as long
x=-2000000000
if x<1900000000 then print "okay":end If
did not work too.
It is not "dangerous", I'm still alive ( Big Grin ) even after testing it. But it was a serius bug.

Re: byte loops - boriel - 2012-04-22

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! Sad 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 - 2012-04-22

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 Smile

Re: byte loops - boriel - 2012-04-22

Whoa! ZX Spectrum Rendering! Confusedhock: It will always run slow Big Grin.
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 - 2012-05-28

And in fact, if I try the xor-shift generator ( <!-- l --><a class="postlink-local" href="https://forum.boriel.com/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 - 2012-05-28

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!