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