Need help on Data Type

[Can Le]

Hi,

Please help me on data Type. My program was OK on PBDOS 3.5, but my numbers are not on PBCC 4.0. I checked help and link below:

Data Types: Numbers, Strings, Constants and Literals

http://www.powerbasic.com/support/pbforums/showthread.php?t=16997&highlight=constant+specifier

Example codes are in a sub:
1. STATIC B AS SINGLE 'output B=0
2. STATIC B AS INTEGER 'output B=-32768.000

Math: B=AnotherInteger+2 'Result should be 20

PRINT B

output:
'1. STATIC B AS SINGLE
output: B=0
'2. STATIC B AS INTEGER output
B=-32768.000

PBCC 4.0 did not show B=20 as it should be, without error code.

Thank you for helps

[Michael Mattias]

When B = -32768 it is at the limit of the range for a data type INTEGER/

You are getting a numeric overflow, in which case the results are "undefined". So I guess it's undefined differently in Pb/DOS than in PB/CC-Win.

As a general rule, INTEGER should be replaced by LONG when moving from PB/DOS to PB/CC. That WILL solve this particular problem.

FWIW, this produces an interesting result in PB/Windows....

FUNCTION TestInteger() AS LONG

   LOCAL B AS INTEGER
   LOCAL C AS LONG
   
   B = -32768%
   C = -32768&
   
   MSGBOX FORMAT$(B) & "   " & HEX$(B),,"B"
   MSGBOX FORMAT$(C) & "   " & HEX$(C),,"C"

END FUNCTION

With the integer (B) the hex comes back FFFF8000... four bytes. How you get four hex pairs from a 16-bit (2 byte) integer is kind of interesting. Maybe the folks in Florida wanted to give us some 'bonus bytes" or something.

(comes back same way with C).

Bottom line is still the 'overflow' condition, which is NOT testable in PB/CC-Win as it is in PB/DOS, so you need to police this condition yourself.


MCM

[Bob Zale]

It's called a negative number. You've heard of those???

In a 16-bit operating system, we default to a 16-bit result. In a 32-bit operating sytem, we ...

Best regards,

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

As I mentioned in my reply to the support department after they referred my bug report (with compilable example demonstrating the problem) to this forum thread, that is not a satisfactory response. I even enhanced the compilable demo demonstrating the problem to show that "FFFF8000" is not even how the compiler itself stores the value.

If it's a bug, hey, that happens. No big deal to to me, since I rarely use INTEGER data types in my WIN32 programs anyway; plus you have an excellent track record when it comes to fixing these things.

[crib sheet]
"8000" is the correct hex representation of -32768%
"FFFF8000" is the correct hex representation of -32768&
[/crib sheet]

What's really scary is the possibility someone did this on purpose and truly believes the software is correct.

But since Mr. Le's problem has been addressed, why don't we just let the bug report wend its way thru the normal process in Florida, receiveing the proper amount of consideration, deliberation and review, and work itself out that way?

MCM

[Bob Zale]

"8000" is the correct hex representation of -32768%

As explained to you privately, we disagree. If you'd care to tell us which "rule book" supports the above statement, we'd be happy to give it consideration.

The hex string returned by PowerBASIC's HEX$() function is the two's complement representation of a negative number in a 32-bit environment. This may difffer from a 16-bit environment, and is something which needs to be considered by the programmer.

Of course, this is one of the reasons that PowerBASIC offers the unique format option via the second parameter of HEX$(). You might wish to consider using it.

Best regards,

Bob Zale
PowerBASIC Inc.

[Can Le]

Thank Mr Michael Mattias and Bob Zale for your helps,

I tried to use
DIM B AS SINGLE,

for a small float number but it would not help,
however, when I used
STATIC B AS BYTE ' 0 to 255
it gave me a zero on the first run of the loop, and I finally have a new value on second itineration of the loop.

If I did not initiately print the value of the long integer before it is displayed by another print to overwrite any remote value of the svchost.exe, it would not show any value other than 0 on the first print. So I guess, we have a problem, Houston NASA!?

If the programmer estimated a value with a few extra spaces, the total spaces would be a waste of memory too, unlike Perl we can use any variable for a default integer or float and string!

I will check the rest of my formula and change data types to go along without any mouse click.

Thank you again

[Michael Mattias]

As a general rule, don't use BYTE or INTEGER data types for your "working" whole-number variables in your Win/32 programs... use LONG.

Not only is the compiler optimized for LONG, but you won't run into the exact problems you are having here.

The memory you "save" by using INTEGER or BYTE variables for "whole number" data variables first of all is not really saved, and second of all is just not enough to even worry about.

You'd need to be using about 1,094,000,000 INTEGER variables in your code before you'd run into any allocation problems at all. (That's a lot of integer variables.)