tags:

views:

284

answers:

6

Hi all,

We are in a situation to handle numbers with a maximum of 15 digits. We need to parse this value from a text file, through C, store it in Informix table. There is another Java component that reads these values, does mathematical operations and computes a result.

I have been doing some research on this and found that the int8 datatype provided by Informix will be a suitable candidate for C.

With regard to Java, I plan to use the BigInteger class.

Are there any pitfalls in taking this approach. Any thoughts are appreciated.

Just for your information, this is an old application and it has been using the primitives so far. Moreover it has only been able to handle numbers within the range of the primitives.

Thanks.

A: 

If I understand you correctly, you read "small" values (fit into INT8 integers) and then make calculations in Java where you get "big" values as results; right?
As long as you don't try to squeeze the BigInteger values into the INT8 data type, it looks fine to me.
As Stephen C already noted, Java's long type also has 64bit width so this might be suitable, too.

mxp
"you read "small" values (fit into 8-bit integers) and then make calculations in Java where you get "big" values as results; right?"Not really. I may read large values too. It can extend upto 15 digits. Yes, I would not at any cost squeeze it.
prabhu
Oh, sorry I assumed int8 to be 8-bit integers. Fixing the answer...
mxp
+2  A: 

If your "huge" numbers are 15 decimal digits at most, then long may be an option. The Java long type has range -2**63 to +2**63 - 1. And 2**63 is 19 decimal digits ... if I can count :-).

If course, if any of the intermediate results of your computations are 19 digits or more, long won't work and you will probably need to use BigInteger.

There are no particular pitfalls with using BigInteger, except that they are significantly slower than primitive integer types ... and more verbose. Indeed, they have the advantage that you don't have to worry about integer overflow any more.

Stephen C
+4  A: 

As long as all of your numbers (including calculations) remain under 15 digits, a long primitive is a perfectly valid choice, and it has the advantage of performance and operators. The disadvantage of BigInteger really is the verbosity/difficulty of doing math where you have to use methods all the time (there is no operator overloading in Java and the only operator that works on an object is + for string concatenation).

In terms of performance, without knowing more about your application I can't say, but the first assumption should be that it is fine to use BigInteger until you measure otherwise.

Yishai
A: 

In C (C99, to be specific), the long long type is a 64 bit signed binary integer, so it can hold up to 18 digits.

In Java, the long type is the equivalent type, a 64-bit signed binary integer.

Loadmaster
You are right about long long, but will it not create compatibility issues while retrieving data from int8 type (on DB) and trying to assign it to a long long?
prabhu
If `INT8` means a 64-bit integer on the DB side, it should be exactly the same size as the C `long` `long` type, right?
Loadmaster
A: 

If you're just using C to parse these values from a text file, and then ship them somewhere else, you should be able to keep them as strings. You won't be able to do any math-like operations without rolling your own, but from your description you don't have to.

There's no point in spending time finding a binary representation, or a library that can do maths on these numbers, if all they are to the C program are 15-digit strings.

unwind
+1  A: 

If your version of Informix supports BIGINT and BIGSERIAL, use them in preference to INT8 and SERIAL8. For various complex reasons, INT8 and SERIAL8 actually occupy 10 bytes on disk; BIGINT and BIGSERIAL support the same range of values but only occupy 8 bytes on disk.

If your version of Informix does not support BIGINT and BIGSERIAL, consider upgrading to IDS 11.50.

If the Informix JDBC driver only support INT8, then use INT8 anyway.

Jonathan Leffler
Thank you. We are using IDS version 10.00. Guess we will have to live with INT8 till we think about upgrading. I think IBM will stop support for this version from end of Sep 2010.
prabhu
@Prabhur: that sounds like a plausible end-of-service date.
Jonathan Leffler