Why am I missing 8bits of my 32bit values?

[Cobalt]

I need a second(or more) set of eyes to look at this code and tell my why I'm only getting 24 of the 32 bits of a UNSIGNED LONG integer to show up. Bits 31-8 seem to be showing up(ON state) represented by color shift from RED to BLUE, but bits 7-0 are always showing the OFF state represented by a slightly purplish GRAY(or if you prefer GREY).
I have been staring at it too long and can't see whats happening, so if somebody else could look at it, it would be a great help.

Code: QB64: [Select]

1. 'Number Guessing Game
2. 'Cobalt 2019/1/2
3.  
4. '-------------setup------------------------------
5. SCREEN _NEWIMAGE(640, 480, 32)
6. Numbers& = _NEWIMAGE(640, 480, 32)
7. _PRINTSTRING (0, 0), "0 1 2 3 4 5 6 7 8 9", Numbers&
8. DIM SHARED Pic(16, 16) AS _UNSIGNED LONG
9. '------------------------------------------------
10.  
11. '--------------side A Number---------------------
12. NumbA%% = INT(RND * 10)
13. _PUTIMAGE (32, 64)-STEP(32, 64), Numbers&, _DISPLAY, (16 * NumbA%%, 0)-STEP(8, 16)
14. '------------------------------------------------
15.  
16. '--------------Side B Number---------------------
17. NumbB%% = INT(RND * 10)
18. _PUTIMAGE (288, 64)-STEP(32, 64), Numbers&, _DISPLAY, (16 * NumbB%%, 0)-STEP(8, 16)
19. '------------------------------------------------
20.  
21. '-----Generated Random 32bit test values---------
22. FOR i%% = 1 TO 16
23.  Pic(0, i%%) = INT(RND * (2 ^ 32))
24. NEXT i%%
25. '------------------------------------------------
26.  
27. Dot_Display 0, 80, 64, 2, _RGB32(128, 128, 128)
28.  
29. '-------------Dot Matrix display-----------------
30. '32x16- 16 LONG integers
31. SUB Dot_Display (image%%, X%, Y%, Scale%%, Colr~&)
32.  FOR J%% = 1 TO 16
33.   Yloc% = Y% + (3 * Scale%%) * J%%
34.  
35.   FOR I%% = 31 TO 0 STEP -1 'Read Bits
36.    Xloc% = X% + (3 * Scale%%) * (31 - I%%)
37.  
38.    IF Pic(image%%, J%%) AND 2 ^ I%% THEN 'Dot is Lit
39.     LINE (Xloc%, Yloc%)-STEP(2 * Scale%%, 2 * Scale%%), _RGB32(8 * I%%, 8, 8 * (31 - I%%)), BF
40.    ELSE 'Dot is Off
41.     LINE (Xloc%, Yloc%)-STEP(2 * Scale%%, 2 * Scale%%), _RGB32(64, 48, 64), BF
42.    END IF
43.  
44.   NEXT I%%
45.  NEXT J%%
46. END SUB
47. '------------------------------------------------
48.  

[FellippeHeitor]

You're not missing them, you're just not generating them to begin with. Try with this:

Code: QB64: [Select]

1. '-----Generated Random 32bit test values---------
2. FOR i%% = 1 TO 16
3.     Pic(0, i%%) = _RGB32(RND * 255, RND * 255, RND * 255)
4. NEXT i%%

(Edit) Even better:

Code: QB64: [Select]

1. '-----Generated Random 32bit test values---------
2. FOR i%% = 1 TO 16
3.     Pic(0, i%%) = _RGBA32(RND * 255, RND * 255, RND * 255, RND * 255)
4. NEXT i%%

[Cobalt]

oh, so why wouldn't I be getting values from 1-255 with my

INT(RND* 2^32)

shouldn't that be generating numbers from 0 to 4294967295?

how could I be missing 1-255? I know its probably simple but its not clicking for me.

if I add a +1, +2 ... +128  then those dots start lighting up, I've added a Randomize timer and ran it a few dozen times and those never light with out the afore mentioned + values

[FellippeHeitor]

No idea. INT() could be capping them. Doing math with RND and such high numbers could be capping them. I have no idea, really.

Try dealing with floats like

Code: QB64: [Select]

1. RND * 4294967295##

That lit up some lower bytes here. Not sure if the math is proper though.

[FellippeHeitor]

But really, the _RGBA32 method for random 32bit values is spot on. Go with it.

[Cobalt]

I also noticed something else, changed the following code,
from:

Code: QB64: [Select]

1. '-----Generated Random 32bit test values---------
2. FOR i%% = 1 TO 16
3.  Pic(0, i%%) = INT(RND * (2 ^ 32))
4. NEXT i%%
5. '------------------------------------------------
6.  
7. Dot_Display 0, 80, 64, 2, _RGB32(128, 128, 128)
8.  
9.  

To:

Code: QB64: [Select]

1. '-----Generated Random 32bit test values---------
2. DO
3.  LINE (80, 64)-(272, 168), _RGB32(0, 0, 0), BF
4.  FOR i%% = 1 TO 16
5.   Pic(0, i%%) = INT(RND * (2 ^ 32))
6.  NEXT i%%
7.  '------------------------------------------------
8.  Dot_Display 0, 80, 64, 2, _RGB32(128, 128, 128)
9.  _DELAY .05
10. LOOP UNTIL INKEY$ = CHR$(27)
11.  

and let that run, Besides looking kind of neat, tell me if you notice that none of the lit boxes after 20 change (so from bit 21 to 32 where it starts to go blue) as they never change for me. I'll try taking out the INT and see if that works on my side.

[Cobalt]

Well the result is repeated in QB45 so, if you set the 2^ to values  < 25 the first 8 bits show but as you increase from 25-32 you start to get the missing bits, like RND can only handle 24bit (3 byte) values max

in this example speed isn't an issue but isn't _RGBA32 going to be a major speed issue if I were to have several hundred or thousand point values to randomly change?

[FellippeHeitor]

Both _RGB32 and _RGBA32 are inline C++ functions which should mean they'll be quite effective. Not to be confused with _RGB() and _RGBA(), both of which have quite the overhead to them.

[FellippeHeitor]

Have a look at this:

Code: QB64: [Select]

1. DIM lng AS _UNSIGNED LONG
2. lng = RND * 1000
3. lng = (lng / 1000) * 4294967295

[Cobalt]

finally found a use for my _SHL\_SHR

Code: QB64: [Select]

1.   High~& = (RND * (2 ^ 16)) 'upper 16 bits
2.   Low~% = (RND * (2 ^ 16)) 'lower 16 bits
3.   Pic(0, i%%) = _SHL(High~&, 16) + Low~%
4.  

 

anyway, would RNDs inability to return an _UNSIGNED LONG be a limitation or a bug? as it does imitate QB45 correctly(as far as I can tell since QB45 doesn't allow for unsigned values).

[FellippeHeitor]

anyway, would RNDs inability to return an _UNSIGNED LONG be a limitation or a bug? as it does imitate QB45 correctly(as far as I can tell since QB45 doesn't allow for unsigned values).

I'll wait for my more knowledgeable peers to evaluate this scenario.

[Cobalt]

I'll wait for my more knowledgeable peers to evaluate this scenario.

I agree. Need to know if its only supposed to work with up a 24bits. A quick search on it didn't yield anything useful.

But thanks Fellippe.

[Bert22306]

I agree. Need to know if its only supposed to work with up a 24bits. A quick search on it didn't yield anything useful.

But thanks Fellippe.

I recall Galleon saying that RND is only good for 24 bits. And in testing, I discovered that the seed value is only good to about 22 bits of resolution. So no, this is not a bug. It's just not the best PRNG out there, that's all. But within its limits, in tests I've done, it works well.