Whirlpool

I'm running into a problem where variables that I have declared as "Long" are causing an overflow as I'm trying to store the number "24159191040".

I know that instead of "Long" the variable should be declared as a "Double". But what is the maximum size for a "Long" variable and a "Double" variable?

For example, with an "Integer", the maximum size is 32767.

Will there be much of a performance hit when using a Double instead of a Long variable type?

I've googled for the maximum size's for variable types but can't find anything, does anyone know of a site that explains the maximum size for each variable type?

Thanks!

I did a google search for "vb6 variable types" and found this as the first result.

theopensourcery.com/vb03tut.htm

Thanks SimKat! I guess I was using the wrong keywords for searching.

But is there much of a performance hit when using Double instead of Long? Reading that link you provided, a Long is 4 bytes long while a Double is 8 bytes long.

Craig writes...

But is there much of a performance hit when using Double instead of Long? Reading that link you provided, a Long is 4 bytes long while a Double is 8 bytes long.

There is a significant performance hit when using Double (or Single), not because of the different number of bytes but because Doubles are floating point and use a different representation. Longs are just simple binary numbers and are much more straight forward to process.

However it depends on what you are doing as to whether it really matters to your application. If you are doing massive, complex calculations where a large part of the processing time is spent just calculating then it will make a big difference, but if it's just displaying a simple screen or reading a few rows from a database etc you won't notice any difference at all.

Would I be better declaring the variable as a Variant then instead of Long or Double, that way I'm not specifically declaring a Double when the size may not even surpass a Long?

Well, here is an interesting thing from the page SimKat found:

The trade-off with Variants is their flexibility/ease of use versus storage size cost and speed disadvantage, about 3 times slower than integer or longs, 4-6 times slower than doubles.

What I know about VB6 would fit on the back of a postage stamp, but I find that hard to believe - it implies using longs takes up to twice as much time as using doubles.

woodag writes...

...but I find that hard to believe - it implies using longs takes up to twice as much time as using doubles.

Yeah, it does sound kinda weird doesn't it. Can any Whirlpool VB6 programmers comment on that statement?

Edit: I did change from using Long to Double and didn't notice hardly any performance hit, if any.

Craig writes...

Can any Whirlpool VB6 programmers comment on that statement?

Not a VB6 programmer, but I'll have a stab. Perhaps a Variant only stores floating-point numbers, never integers. This could make Variants compare more favorably with Doubles than with Longs.

For your original problem, you could try using the Currency data type. It'll be easier to maintain precision than with Doubles.

Will there be much of a performance hit when using a Double instead of a Long variable type?

I wouldn't worry about it too much. I know the purist's will come down on me for saying this, but the reality is you can spend a lot of time writing code that will be really efficient in order to save a couple of milliseconds and maybe a meg or two of RAM. I would rather see that development time go towards better application testing and documentation.

If you are writing something that is computationally arduous, you should probably use a lower level language like C++ as opposed to Visual Basic.

Just my two cents after a longneck or two.

Foonly writes...

Perhaps a Variant only stores floating-point numbers, never integers.

Variants store a variety of native formats. With some stuff on the outside to identify what's inside.

The additional time it takes to work with variants is due to having to figure out what type the stored number is, and determining the operation for that number.

Variants can also store Decimal numbers which are effectively 64 bit binary integers (twice as long as a long).

You really don't want to store integer data as a floating point number, as this will lead to a variety of problems with inaccuracy.

Evan writes...

You really don't want to store integer data as a floating point number, as this will lead to a variety of problems with inaccuracy.

Of course not. I was just trying to think of a way that earlier statement could be justified, that a Variant is slower with respect to a Double than it is to a Long :-)

I would really hope MS had designed the Variant type so that it could store both an integer value and a floating-point value at the same time. It's interesting to consider how other languages solve this problem. Perl variables, for instance, contain separate IV, NV, PV (integer, numeric, pointer value) slots, and there's a bunch of flags to indicate which slots contain valid values, whether the IV is actually unsigned, etc.

Decimal numbers

That's the one! I knew Currency didn't sound right. The link earlier didn't mention Decimal.

drunk :p

Foonly writes...

It's interesting to consider how other languages solve this problem. Perl variables, for instance, contain separate IV, NV, PV (integer, numeric, pointer value) slots, and there's a bunch of flags to indicate which slots contain valid values, whether the IV is actually unsigned, etc.

This is pretty much what a VB variant looks like.

That's the one! I knew Currency didn't sound right. The link earlier didn't mention Decimal.

Actually, for this purpose, using a Currency type variable would work, as a Currency is basically a integer with an assumed decimal place. But using a Decimal is better.

Variants can hold almost any type of data, including objects. In VB6 you should almost never use Variants unless there are specific reasons why you need to (e.g. you are writing a COM component that needs to be called late-bound and that has by-reference parameters). Not only is the overhead excessive, unless you specifically convert the variants to a particular type in your code then you have no control over how the runtime treats them when doing calculations and comparisons etc.

The decision as to which numeric data type you should be based on the business logic, not performance.

If you only need to store integers that will fit in 4 bytes use Long (Int is not really any faster than Long on modern processors).

If you need to store floating point numbers (i.e. decimal fractions) other than money use Double, or Single if you are sure that the accuracy and/or size required are compatible with Single.

If you need to store money use Currency (aka decimal).

Of course if you are storing your data in a database then obviously you need to take into account what data type is used in the database, in which case you don't really have a choice at the VB6 level.

What variable data type would be best suited if I wanted to store a value that could potentially be 12 or so numbers long?

The number I am using will by the size of a file in bytes, so it could potentially be up to 100GB in bytes (or more), which is 107 374 182 400 bytes.

I don't need any decimal points as it is a whole number.

I'm using Double at the moment, as Long isn't big enough.

Craig writes...

What variable data type would be best suited if I wanted to store a value that could potentially be 12 or so numbers long?

Why isn't Long big enough?

Holds signed 64-bit (8-byte) integers ranging in value from -9,223,372,036,854,775,808 through 9,223,372,036,854,775,807 (9.2...E+18).

Edit: Ah, wonderful. MS decided to redefine the sizes of the datatypes...

In that case, use Decimal instead.

Foonly writes...

In that case, use Decimal instead.

I don't think Decimal is available in VB6.

Craig writes...

I don't think Decimal is available in VB6.

Hmm, yeah, I think you're right. It appears that in VB6 the "decimal" datatype is just an odd kind of Variant. Probably should avoid it.

How about Currency?

Also, doesn't VB6 come with online help? Surely you can find out these kinds of things just by looking through that? The help that came with it is now even more valuable, since Microsoft no longer have it on their website!

Edit: Just dug out some old MSDN library CDs:

Note   At this time the Decimal data type can only be used within a Variant, that is, you cannot declare a variable to be of type Decimal. You can, however, create a Variant whose subtype is Decimal using the CDec function.

Yeah, so you probably want Currency instead.

Craig writes...

I don't think Decimal is available in VB6.

If you want to use the Decimal Type in VB6, you have to declare the variable as a Variant then use the CDec() function.

I would just use Double if I was you if you want to use numbers longer than 2,147,483,647.

See also the MSDN library online for help if you can navigate your way through it:)

Since I have access to the MSDN library on my pc, here is a some info on Data Types:


Byte 1 byte 0 to 255

Boolean 2 bytes True or False

Integer 2 bytes -32,768 to 32,767

Long
(long integer) 4 bytes -2,147,483,648 to 2,147,483,647

Single
(single-precision floating-point) 4 bytes -3.402823E38 to -1.401298E-45 for negative values; 1.401298E-45 to 3.402823E38 for positive values

Double
(double-precision floating-point) 8 bytes -1.79769313486231E308 to
-4.94065645841247E-324 for negative values; 4.94065645841247E-324 to 1.79769313486232E308 for positive values

Currency
(scaled integer) 8 bytes -922,337,203,685,477.5808 to 922,337,203,685,477.5807
Decimal 14 bytes +/-79,228,162,514,264,337,593,543,­ 950,335 with no decimal point;
+/-7.9228162514264337593543950335 ­ with 28 places to the right of the decimal; smallest non-zero number is
+/-0.0000000000000000000000000001 ­

Date 8 bytes January 1, 100 to December 31, 9999
Object 4 bytes Any Object reference

String
(variable-length) 10 bytes + string length 0 to approximately 2 billion

String
(fixed-length) Length of string 1 to approximately 65,400

Variant
(with numbers) 16 bytes Any numeric value up to the range of a Double

Variant
(with characters) 22 bytes + string length Same range as for variable-length String

User-defined
(using Type) Number required by elements The range of each element is the same as the range of its data type.

Note: At this time the Decimal data type can only be used within a Variant, that is, you cannot declare a variable to be of type Decimal. You can, however, create a Variant whose subtype is Decimal using the CDec function.

one-dev writes...

I would just use Double if I was you if you want to use numbers longer than 2,147,483,647.

Sure, if you don't care about precision. 12-digit numbers might be OK, but if you're multiplying and dividing them a lot, you're going to get inaccurate results. If you're doing integer maths, there's really no excuse not to use an integer datatype.

you could really use longs instead of integers! when using VB now

theres no way someones going to run your code on a 16bit cpu anymore!

and when you use integer you waste 2 bytes because they cant be used.

memory chunks are 32bit/64bit

int is only 16 and long is 32!

Craig writes...

did change from using Long to Double and didn't notice hardly any performance hit, if any.

the fpu is alot faster these days than it used to be so its about the same performance! depending on how ur code is written! as it may be able to pipe some of them together!

Foonly writes...

It appears that in VB6 the "decimal" datatype is just an odd kind of Variant. Probably should avoid it.

Actually, Decimal is exactly what you want to use.

Declare it as Variant, use CDec() to move numbers into it.

I'm using a Double and it seems fine. If I run into problems I will go the Decimal way.

Evan writes...

Actually, Decimal is exactly what you want to use.

Why would you choose Decimal over Currency, if it means you'll incur the variant overhead? Craig wants to store 12-digit integers, not 20-digit integers. 12-digit integers fit comfortably within the limits of Currency.

Foonly writes...

Why would you choose Decimal over Currency, if it means you'll incur the variant overhead?

For the application that it sounds like he is writing, the overhead is miniscule. Currency will work, though.

Craig wants to store 12-digit integers, not 20-digit integers. 12-digit integers fit comfortably within the limits of Currency.

And I always use longs, regardless of how small the numbers being stored are. Makes writing and maintenance much easier.

And, unless you are doig some serious number crunching (in VB6 no less), then the overhead will not even be noticed.

Just so I know, how many numeric digits can a Double and a Single hold?

Foonly writes...

Why would you choose Decimal over Currency, if it means you'll incur the variant overhead?

They have different precision. See forum-replies.cfm?t=660843#r19

Currency is an inbuilt data type. "Decimal" is actually a COM data type that is supported in VB6 through using variants. It's not a "native" data type, but if you need really big numbers, or really small numbers with no rounding errors, then you need to use decimals (or, preferably, a different language altogether).

Since OP only needs to store large integers I would use Singles, since they are faster and smaller than Currency or Double. I doubt he's going to see too many files that are larger than 1.0E38 bytes.

woodle writes...

Since OP only needs to store large integers I would use Singles, since they are faster and smaller than Currency or Double. I doubt he's going to see too many files that are larger than 1.0E38 bytes.

Hi Woodle. Looking at this page ( theopensourcery.com/vb03tut.htm ) it reads: "Double is much more accurate and even runs about 10-20% faster than Single." Is this true, is it really 10-20% faster using Double than Single?

How do I determine how many numeric digits a Double can store if it's maximum is "1.79769313486232E308". I don't understand this number, why does it have an E in it?

Foonly writes...

Ah, wonderful. MS decided to redefine the sizes of the datatypes...

Looks like the range was expanded with VB2005. VB6 data type is the same as VB5:

Long (long integer) variables are stored as signed 32-bit (4-byte) numbers ranging in value from -2,147,483,648 to 2,147,483,647. The type-declaration character for Long is the ampersand (&).

The OP should be checking the help file to save some mucking around next time.

Craig writes...

How do I determine how many numeric digits a Double can store if it's maximum is "1.79769313486232E308". I don't understand this number, why does it have an E in it?

That is computerese for 1.79769313486232 × 10³⁰⁸. For the origin of this number, have a read of the IEEE 754 standard.

As to "how many numeric digits" this is... well, that's an interesting question. Computers generally use "floating-point" arithmetic to represent non-integers, and floating-point numbers have a "precision". This determines how many digits are significant in the number. According to the IEEE 754 spec, double-precision numbers (the Double type in VB) have a precision of 53 bits, which is approximately 15 digits. So in that sense, a Double can only store up to 15 digits.

Put simply, the double-precision numbers:

1234567890123456711111
   and
1234567890123456799999

are "exactly the same", as far as the computer is concerned -- there is only enough precision to represent the left-most 15 digits accurately.