Variable stuck on 24 bits

[DimColby]

Hello all. I have a problem that has been plaguing me in my QB64 adventure. If I have a variable, and I increment it, by just the number 1 in a loop, when it gets to 1.677722E+07 (24 bits) it just stops and increments no more. Doesn't matter if I use LONG or _INTEGER64 data types, or don't declare a type at all. 

Sounds like it has to be a bug, and a weird one. Why 24 bits? Anyone else see this?

[mnrvovrfc]

Welcome to the forums.

You are expecting help but do not post source code. So we have to guess what you are trying to do.

Are you using `PRING USING` to output the variable's value? This is one of the biggest offenders.

If you are incrementing by one, make sure it is `1` as integer, and it's not floating point. Because QB64 sometimes needs the programmer's help by type-casting like must be done regularly in C/C++.

Otherwise 24 bits should easily fit into a `LONG` (32-bit) variable.

[bplus]

Yeah I am not seeing it:

Code: (Select All)

Dim i As _Integer64
i = 16777000
While i < 16800000
    i = i + 1
    Print i
Wend

Welcome, may I ask what version QB64 you are using?

[SMcNeill]

1.677722E+07 is floating point, and you're at max single digit precision.

16777220 <-- this is what the value above translates to.
16777221 <-- add one
1.677722E+07 <-- and the above still rounds to the same value.

You're doing floating point math, not integer addition.

[SMcNeill]

If you're dimming your variable as long or integer64, be certain it's SHARED if you use it in SUB/FUNCTIONs, or else specify the type in your parameters.

SUB foo (var AS LONG)

[DimColby]

1.677722E+07 is floating point, and you're at max single digit precision.

16777220 <-- this is what the value above translates to.
16777221 <-- add one
1.677722E+07 <-- and the above still rounds to the same value.

You're doing floating point math, not integer addition.

Thank you, I think that fixed it. It turns out that declaring it with a DIM didn't really do it, but not declaring it and using the & suffix did. 

Those two things must not be exactly the same.

[DimColby]

Yeah I am not seeing it:

Code: (Select All)

Dim i As _Integer64
i = 16777000
While i < 16800000
    i = i + 1
    Print i
Wend

Welcome, may I ask what version QB64 you are using?

Current one, just downloaded from the Github.

[SMcNeill]

1.677722E+07 is floating point, and you're at max single digit precision.

16777220 <-- this is what the value above translates to.
16777221 <-- add one
1.677722E+07 <-- and the above still rounds to the same value.

You're doing floating point math, not integer addition.

Thank you, I think that fixed it. It turns out that declaring it with a DIM didn't really do it, but not declaring it and using the & suffix did. 

Those two things must not be exactly the same.

Can you share some code with the glitch?  & suffix is the same as DIM AS LONG.  I imagine you're seeing an issue with your variable's scope.

[SMcNeill]

Code: (Select All)

DIM i AS LONG

i = 1.677722E+07 + 1

PRINT i

Works as advertised for me with the above.

[DimColby]

1.677722E+07 is floating point, and you're at max single digit precision.

16777220 <-- this is what the value above translates to.
16777221 <-- add one
1.677722E+07 <-- and the above still rounds to the same value.

You're doing floating point math, not integer addition.

Thank you, I think that fixed it. It turns out that declaring it with a DIM didn't really do it, but not declaring it and using the & suffix did. 

Those two things must not be exactly the same.

Can you share some code with the glitch?  & suffix is the same as DIM AS LONG.  I imagine you're seeing an issue with your variable's scope.

I see what I did. I was misusing the DIM...AS... statement with a variable list. It's something I remember from way back, using that with lists of variables can give unexpected results and it's safer and no more difficult to declare variables one at a time. Thanks again!