Skip to main content

Language support for BigDecimal

8 replies [Last post]
tomia
Offline
Joined: 2003-06-13

Add operators for BigDecimal, using the methods for calculation is a real pain.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
behrangsa
Offline
Joined: 2003-09-14

Aah... you're right... Had forgotten that these classes have not fixed size internal representations.

dog
Offline
Joined: 2003-08-22

No this is not operator overloading.

This is native support for infinite precision numbers and maybe complex ones as well (might as well).

Java supports Strings and arrays with language syntax. Since business apps seem to be the major use for Java it would make sense to extend native support for inifinite precision numbers (like Lisp and Smalltalk have). A simple way to do this is adding support for BigDecimal.

This is the first idea I've seen in the new features forum that actually makes sense to make. It WOULD save a lot of headaches and complications.

behrangsa
Offline
Joined: 2003-09-14

It would be nice if there was primitive types for BigDecimal and BigInteger so we could have basic arithmetic operators for them while not making it inconsistent with the rest of the language.

- Behrang

afreije
Offline
Joined: 2004-10-14

BigInteger and BigDecimal are objects that internally have arrays. The space occupied by these objects cannot be determined at forehand. How do you expect that a primitive is treated when it is put on the stack?

patrikbeno
Offline
Joined: 2004-10-11

[i]Never mind. Should have read the post once more before posting :-)[/i]

Message was edited/deleted by: patrikbeno

opinali
Offline
Joined: 2003-06-17

I'm favourable to extra language-level operator support for critical types, like BigInteger and BigDecimal (and maybe also arrays/matrices, new J2SE classes like Complex that I'd like to have in Mustang too, etc.).

for BigDecimal, though, many operations support extra arguments for rounding mode / scale / MathContext. I guess this is a good case for annotations:

@MathContext(DECIMAL_128)
public class Test {
public BigDecimal m1 (BigDecimal a, BigDecimal b,
@MathContext MathContext m) {
return m2(a,b,m) * m3(b);
}
public BigDecimal m2 (BigDecimal a, BigDecimal b,
@MathContext MathContext m) {
return a + b;
}
public BigDecimal m3 (BigDecimal a) {
return -b;
}
}

In this example, the @MathContext tag in the class sets a default context for the entire class. The same tag, in the arguments 'mc', states that all BigDecimnal operators inside the methods m1,m2 should use that context, i.e. m3() translates to "return a.add(b, mc)". Methods not having an explicit math context (neither a parameter or variable tagged by @MathContext, nor a static @mathContext tag in the method itself), like m3(), will use the closer static @MathContext, in this case the one set in the class. If no context at all is found, then javac translates the operators to the methods that don't take a context.

patrikbeno
Offline
Joined: 2004-10-11

This is operator overloading. java intentionally avoided this feature and this is good.

But to tell the truth, I feel we should accept operator overloading at least for some well defined math operations and types (Number & co.).

So, I am for explicit operator overloading for math operations (same way as this is done for String concatenation). Should be defined as part of the JLS

But I am probably against operator overloading as a language feature. Although it can be useful...

tomia
Offline
Joined: 2003-06-13

This is the same operator overloading as it is done for the native types.
I know that a general operator overloading is a very controversial feature. For me it has it's right mainly in the arithmetic domain, so I would restrict it to that.
My main goal is a improved readability of financial calculations done e.g. with BigDecimal. Any broader support e.g. for all descendants of Number is welcome.