byte loops (*solved*)

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


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

[boriel]

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.

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

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!!!
OMG, how it can be?

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.

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

[boriel]

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 ) 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".

[boriel]

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: 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 ( ) even after testing it. But it was a serius bug.

[boriel]

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?

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

[boriel]

Whoa! ZX Spectrum Rendering! 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: http://en.wikipedia.org/wiki/Stream_cipher random bit generator?)

And in fact, if I try the xor-shift generator ( post2853.html?hilit=random#p2853 ) it finishes in 19 seconds, instead of 48...

[boriel]

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!