Arithmetic with longs

[P.Hill]

The intent was to see if I could
make a blanket recommendation of "always use BigInteger in preference to
int so that you never have to worry about errors overflow again". I sort
of got too busy in the rest of my life though, so I never finished the
research.

I'll keep your idea to "always use BigInteger in preference to int" in
mind, but since working in biotech, banking, communication, graphics,
business, ... etc for over 20 years I have only a couple of times needed
more than a long when I required fixed-point arithmetic.

I also might suggest the more common solution for most applications:
Java long -- 9,223,372,036,854,775,807 (2^(63-1)) is a whole lot of
accurate counting and covers nearly anything outside of working with
all stars in the universe or other such not very "always" number. So
instead of just guffawing and falling out of my seat, I have to ask what
particular application area where you working in where you commonly
needed to count more than a long worth of fixed point such that you
wanted to even think of the idea of "aways using BigInteger"?

-Paul

 

[Chris Uppal]

So
instead of just guffawing and falling out of my seat, I have to ask what
particular application area where you working in where you commonly
needed to count more than a long worth of fixed point such that you
wanted to even think of the idea of "aways using BigInteger"?

I'd be more worried about overflow in intermediate expressions than any
inability to represent the values which naturally crop up in <some domain>.
For a rather silly example, comparing the volumes to two containers would
overflow a long if they had sides or the order of 2.5e6 units. For a slightly
less silly example, the only way I know to caclulate the distance from a point
to a line segment uses intermediate values to the fourth power of the inputs.

But more importantly, I don't want to have to /think/ about overflow at all --
it's a distraction I don't need. I wouldn't advocate defaulting to using Java
BigInteger/BigDecimal for numeric quantities myself, but that's mostly because
of the incredible[*] awkwardness of expressing any kind of calculation using
them.

-- chris

([*] "incredible" is something of an overstatement -- I don't find it
impossible to believe, just difficult ;-)

 

[Oliver Wong]

So
instead of just guffawing and falling out of my seat, I have to ask what
particular application area where you working in where you commonly
needed to count more than a long worth of fixed point such that you
wanted to even think of the idea of "aways using BigInteger"?

[...]

But more importantly, I don't want to have to /think/ about overflow at
all --
it's a distraction I don't need. I wouldn't advocate defaulting to using
Java
BigInteger/BigDecimal for numeric quantities myself, but that's mostly
because
of the incredible[*] awkwardness of expressing any kind of calculation
using
them.

Yeah, that's my main argument for "always use BigInteger" too: You no
longer have to worry about overflow at all.

Here's the one application I worked on where I got to try it out.

There's this dance game called In The Groove
(http://www.inthegroove.com/), which is similar to the more widely known
Dance Dance Revolution. It has a few new features, including a USB slot on
the arcade machine itself which allows you to create an account and track
various statistics on your gameplay, including an estimate of how many
calories you've burned playing the game, how many times you played, what
your scores were for each song, etc.

This data is stored as XML files on the USB key, and is digitally signed
by the machine. I think the developers of the game are open source
advocates. They've released the schema for the XML files and a public key to
check the signature to allow third parties (like myself) to play around with
those files.

Now I assume that the code for the machine is implemented in C/C++, so
*probably* the machine itself doesn't support writing an XML file that says
the player played more than 2*10^19 games (which would probably actually
take 10^14 years to accomplish), but the schema file itself doesn't put any
restriction on the count. So rather than worrying about what internal limits
the machine uses (which might change from revision to revision; the machines
are currently at Version 2 Revision 8), I just store this count as a
BigInteger.

As I predicted, the bottleneck for my application (which is basically
just a specialized viewer for the XML file, rendering charts using jGraph
showing average calories burned per day, for example) was not integer
arithmatic, but rather file-IO. So by using BigInteger, I'd never have to
worry about any of the values from the XML ever causing an overflow error in
my application, and I didn't suffer significant performance loss.

- Oliver

 

[Twisted]

...would take 10^14 years...

It may be worth noting that the current best guess as to the age of the
entire universe is around 1.37x10^10 years.

 

[P.Hill]

But more importantly, I don't want to have to /think/ about overflow
at all -- it's a distraction I don't need. I wouldn't advocate
defaulting to using Java
BigInteger/BigDecimal for numeric quantities myself, but that's mostly
because
of the incredible[*] awkwardness of expressing any kind of calculation
using
them.

Yeah, that's my main argument for "always use BigInteger" too: You no
longer have to worry about overflow at all.

So in order to draw "charts and graphs" on either your printer or screen
you are worried that somewhere for some polygon calculation or some
perpetual sum there might be an overflow or round-off error. All at
the expense of less readable thus maintainability.

Chris's example at least suggests the possibility of overflow while your
real-world values to 2D computer graphics hardly suggests a need for
more than a Long.

I didn't suffer significant performance loss.

But is performance even a concern when drawing graphs and charts?

To me, the use of BigInteger in this example values with known sizes to
accumulations in databases and graphics falls into the "You Aren't Gonna
Need It" category.

http://xp.c2.com/YouArentGonnaNeedIt.html

Hopefully your programming served as a good learning exercise for
BigInteger.

-Paul

 

[Oliver Wong]

But more importantly, I don't want to have to /think/ about overflow at
all -- it's a distraction I don't need. I wouldn't advocate defaulting
to using Java
BigInteger/BigDecimal for numeric quantities myself, but that's mostly
because
of the incredible[*] awkwardness of expressing any kind of calculation
using
them.

Yeah, that's my main argument for "always use BigInteger" too: You no
longer have to worry about overflow at all.

So in order to draw "charts and graphs" on either your printer or screen
you are worried that somewhere for some polygon calculation or some
perpetual sum there might be an overflow or round-off error. All at
the expense of less readable thus maintainability.

Chris's example at least suggests the possibility of overflow while your
real-world values to 2D computer graphics hardly suggests a need for
more than a Long.

The overflow part comes from the arbitrary integer input. For example,
your score on a song is equal to some integer. That's the mathematical
concept of an integer, not Java's 32-bit or 64-bit concept. As I mentioned
in my previous post, yes, the game engine is programmed in C/C++, and so far
all of the scores in the XML file that the machine generated were within the
32-bit range. But when the company published the XSD schema describing the
file format, they did not in any way limit the range of the integer values.
So I could either design my program to only accept a subset of all legal XML
inputs, or I could design it to accept all legal XML inputs. I went with the
latter.

But is performance even a concern when drawing graphs and charts?

The fact that performance is NOT a concern is an argument FOR using
BigInteger.

To me, the use of BigInteger in this example values with known sizes to
accumulations in databases and graphics falls into the "You Aren't Gonna
Need It" category.

http://xp.c2.com/YouArentGonnaNeedIt.html

But then how would I have had real-world data for my "Always use
BigInteger" experiment/research/whatever?

- Oliver