How can I get greater precision than Long?

[Renny Bosch]

What is the recommended method to do arithmetic that requires greater
precision than is available with the Long type? I can write my own routines
using strings to represent very long numbers, or arrays of Longs meant to be
concatenated, but if there is a method already worked out by somebody else
that would make it easier. (This is not for a business application but for
Mathematical problem solving.)

 

[Tom van Stiphout]

On Wed, 3 Mar 2010 18:55:53 -0800, "Renny Bosch" <[email protected]>
wrote:

Indeed you can use strings to work with large numbers, but VBA is
simply NOT the tool to do this. It would be MUCH slower than tools
that are dedicated to math computing such as MatLab or Mathematica.

-Tom.
Microsoft Access MVP

 

[Paul Shapiro]

I would agree with Tom that other applications are probably better suited
for this problem, but you could check Office 2010 information. Since Office
2010 will be available in a 64-bit version, it might be that VBA will have
been extended with a 64-bit integer. It's probably needed for calling 64-bit
API's. I think the release is scheduled for about 2 months from now, but you
could check that too.

 

[AG]

How about using currency data type? That is 64 bit.

 

[Tom van Stiphout]

On Thu, 4 Mar 2010 07:31:13 -0500, "Paul Shapiro"

There is indeed a 64-bit integer in A2010, uninspiredly called
LongLong.

-Tom.
Microsoft Access MVP

 

[Banana]

On Thu, 4 Mar 2010 07:31:13 -0500, "Paul Shapiro"

There is indeed a 64-bit integer in A2010, uninspiredly called
LongLong.

-Tom.
Microsoft Access MVP

This is correct. However, for inexplicable reasons, ACE does not have a
corresponding 64-bit datatype (BIGINT). I suppose one could store the
data in ACE tables as a different data type and convert to LongLong
within VBA processing but that doesn't strike me as particularly elegant.

 

[James A. Fortune]

What is the recommended method to do arithmetic that requires greater
precision than is available with the Long type? I can write my own routines
using strings to represent very long numbers, or arrays of Longs meant to be
concatenated, but if there is a method already worked out by somebody else
that would make it easier. (This is not for a business application but for
Mathematical problem solving.)

It depends on what kinds of operations you need to do. For example,
see:

http://groups.google.com/group/comp.databases.ms-access/msg/b36b2f535e1a8ac4

I suspect that it is possible to do quite extraordinary mathematical
operations on numbers stored as strings, but I have not had enough
need for such precision to flesh out the techniques for such a
mathematical framework. I wrote some input routines that used strings
for numbers back when I did some Turbo Pascal programming, but they
were not designed with the goal of increasing the precision of
operations. The last time I had to deal with precision greater than
Double on a regular basis was in one of my Numerical Analysis
classes. The IMSL library might have something, but it only supports
Fortran, Java, C, C#.NET and Python according to Wikipedia. VBA
certainly has the capability of extending the precision of operations
on numbers represented as strings, especially when enhanced with some
advanced math to provide support for more complicated operations, but
I do not currently have such a set of VBA functions ready to go. If
you only have to deal with integers, I have seen data types rolled
with two Longs that specify the upper Long and the lower Long, but
that would be limited to operations where the effect on a binomial
expression limited to the realm of Integers simplifies.

James A. Fortune
(e-mail address removed)

 

[Dirk Goldgar]

What is the recommended method to do arithmetic that requires greater
precision than is available with the Long type? I can write my own
routines using strings to represent very long numbers, or arrays of Longs
meant to be concatenated, but if there is a method already worked out by
somebody else that would make it easier. (This is not for a business
application but for Mathematical problem solving.)

How long do you need? It is conceivable that the Decimal data type would
serve your needs, but it's not unlimited. The largest possible value
(according to the help file) is +/-79,228,162,514,264,337,593,543,950,335.

 

[Banana]

How long do you need? It is conceivable that the Decimal data type
would serve your needs, but it's not unlimited. The largest possible
value (according to the help file) is
+/-79,228,162,514,264,337,593,543,950,335.

Decimal would be a good choice if Currency isn't going to cut the
mustard. The only reason for preferring Currency over Decimal(even if
it's not for anything to do with money) is because unfortunately Decimal
has been crippled by bugs in some Access versions and lack of
counterpart type in VBA.

Allen Browne has a nice article discussing this:
http://allenbrowne.com/bug-08.html

A pity, really.

 

[Dirk Goldgar]

Decimal would be a good choice if Currency isn't going to cut the mustard.
The only reason for preferring Currency over Decimal(even if it's not for
anything to do with money) is because unfortunately Decimal has been
crippled by bugs in some Access versions and lack of counterpart type in
VBA.

Allen Browne has a nice article discussing this:
http://allenbrowne.com/bug-08.html

A pity, really.

Oh, I'm aware of the issues, but they are mostly problems with Jet, and not
with VBA (except for not being able to declare a variable directly as
Decimal). If the OP is primarily concerned with calculations done in VBA,
Decimal may work.

 

[Jeff Boyce]

Renny

Please define your terms.

When you say "precision", are you referring to the number of significant
digits, or to something else?

If Access' LongInt doesn't provide sufficient significant digits, how many
do you need?

More info, please...

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

 

[Banana]

Oh, I'm aware of the issues, but they are mostly problems with Jet, and
not with VBA (except for not being able to declare a variable directly
as Decimal). If the OP is primarily concerned with calculations done in
VBA, Decimal may work.

Right. I just wasn't sure what the OP ultimately will do with the
numbers and wanted to be sure the OP knew about those so there's no
nasty surprises later on when the OP writes a query involving those fields.

 

[David W. Fenton]

There is indeed a 64-bit integer in A2010, uninspiredly called
LongLong.

....not to be confused with the famous Chinese concert pianist,
LangLang.

(about time -- Jet/ACE has needed something for compatibility with
BigInt forever)

 

[David W. Fenton]

This is correct. However, for inexplicable reasons, ACE does not
have a corresponding 64-bit datatype (BIGINT). I suppose one could
store the data in ACE tables as a different data type and convert
to LongLong within VBA processing but that doesn't strike me as
particularly elegant.

OK, I just assumed in my previous post that a 64-bit integer would
by definition be compatible with BigInt. What's the difference
between the two?

 

[Banana]

OK, I just assumed in my previous post that a 64-bit integer would
by definition be compatible with BigInt. What's the difference
between the two?

They are the same. The issue is that there is no 64-bit integer data
type within the ACE... That is, ACE can only have {Byte, Integer (16-bit
integer), Long Integer (32-bit integer)} to choose from for an integer
data type. This mean we can do 64-bit integer processing inside VBA but
we can't store them as 64-bit integers in tables.

 

[David W. Fenton]

They are the same. The issue is that there is no 64-bit integer
data type within the ACE... That is, ACE can only have {Byte,
Integer (16-bit integer), Long Integer (32-bit integer)} to choose
from for an integer data type. This mean we can do 64-bit integer
processing inside VBA but we can't store them as 64-bit integers
in tables.

Um, yes, in current versions of ACE. But this:

There is indeed a 64-bit integer in A2010, uninspiredly called
LongLong.

....is what I was assuming meant that a 64-bit integer had been added
to the ACE for A2010.

Yes? No?

 

[Banana]

Um, yes, in current versions of ACE. But this:



...is what I was assuming meant that a 64-bit integer had been added
to the ACE for A2010.

Yes? No?

I have a 64-bit version of A2010 and I can assure you that it most
certainly does not have the 64-bit data type available in the ACE unless
they really did a job of hiding it.

LongLong is for VBA only.

 

[Larry Linson]

...not to be confused with the famous Chinese
concert pianist, LangLang.

Would it be OK to confuse it with the panda, LingLing? <GRIN>

Larry

 

[David W. Fenton]

I have a 64-bit version of A2010 and I can assure you that it most
certainly does not have the 64-bit data type available in the ACE
unless they really did a job of hiding it.

LongLong is for VBA only.

OK. I didn't catch that from Tom's post.

Too bad!

 

[David W. Fenton]

Would it be OK to confuse it with the panda, LingLing? <GRIN>

Ask the panda!