You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/12/21 12:32:47 UTC

[lang] Math subpackage

I am intending to create a math subpackage of lang to store the updated
version of NumberRange, plus other primitive versions of the same class. It
also gives us scope for a MathUtils at some point.

Objections?

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] what about mutable BigInteger etc.

Posted by Ola Berg <ol...@ports.se>.
On 2002-12-27 at 03:59 Henri Yandell wrote:

> On Fri, 27 Dec 2002, Ola Berg wrote:
> > I think the word "mutable" leads wrong. The number in itself isn't
> > mutable, it is the object that is told to hold a completely different
> > number.
> 
> Doesn't this depend on the implementation? Why wouldn't they be
> implemented as Numbers themselves and not containers?

They could and should be implemented as Numbers, so that you can use them as Numbers in any generic calculation, just like a variable. But they are not _numbers_.

Note the locase, I am talking about the conceptual object here, not the implementation object. A number is a literal in the language, and a fixed entity in the abstract world of mathemathics, and you cannot change 2 to become 3. 

Saying that a number is mutable is whacky. Saying that the contents of a container can be changed is sane.

No other changes in implementation or how the object can be used is implied. Just wanting to make the name resemble the (my ;-) mind

I think would be less confusing with LongValueHolder than MutableLong, since a value itself cannot be altered.

> MutableXxx matches the (hidden) Sun API in java.math.

Good they let that be hidden. It is a very funny name to me.

But really no big deal. I think that most people will understand what we mean. 

My pro-argument in favor of calling it MutableLong would in fact be that I think it is a _funny_ name. But I might have a strange sense of humour.

> Just my tuppence,

Me to.

/O




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] what about mutable BigInteger etc.

Posted by Henri Yandell <ba...@generationjava.com>.

On Fri, 27 Dec 2002, Ola Berg wrote:

>
> On 2002-12-23 at 19:05 Stephen Colebourne wrote:
>
> > However, I would not be averse to adding mutable versions of the Number
> > classes to math. I would want to see the complete set however,
> > MutableBigDecimal, MutableBigInteger, MutableInteger, MutableLong,
> > MutableDouble, MutableFloat and MutableFraction. They would need to be
> > Number subclasses.
>
> I think the word "mutable" leads wrong. The number in itself isn't
> mutable, it is the object that is told to hold a completely different
> number.

Doesn't this depend on the implementation? Why wouldn't they be
implemented as Numbers themselves and not containers?

> What about "container" or "holder" to indicate that it is something
> that more or less resembles a variable? You can assign different
> values to it but use it just as a literal (immutable) in any
> calculation, just as a variable.

MutableXxx matches the (hidden) Sun API in java.math.

Just my tuppence,

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] what about mutable BigInteger etc.

Posted by Ola Berg <ol...@ports.se>.
On 2002-12-23 at 19:05 Stephen Colebourne wrote:

> However, I would not be averse to adding mutable versions of the Number
> classes to math. I would want to see the complete set however,
> MutableBigDecimal, MutableBigInteger, MutableInteger, MutableLong,
> MutableDouble, MutableFloat and MutableFraction. They would need to be
> Number subclasses.

I think the word "mutable" leads wrong. The number in itself isn't mutable, it is the object that is told to hold a completely different number. 

What about "container" or "holder" to indicate that it is something that more or less resembles a variable? You can assign different values to it but use it just as a literal (immutable) in any calculation, just as a variable.

/O


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] what about mutable BigInteger etc.

Posted by Henri Yandell <ba...@generationjava.com>.
MutableBigInteger does exist in JDK 1.3 in java.math, but is hidden. It'd
be worth checking that the API of the submitted version matches the API of
the hidden one, in case Sun ever made that public.

Hen

On Mon, 23 Dec 2002, Stephen Colebourne wrote:

> Immutable classes have various advantages over mutable ones, not least being
> thread-safe.
>
> However, I would not be averse to adding mutable versions of the Number
> classes to math. I would want to see the complete set however,
> MutableBigDecimal, MutableBigInteger, MutableInteger, MutableLong,
> MutableDouble, MutableFloat and MutableFraction. They would need to be
> Number subclasses.
>
> Have you got code already? (I prefer immutable, so I don't especially want
> to write the mutable classes.)
>
> Stephen
>
> ----- Original Message -----
> From: <vi...@gmxpro.net>
> > What do you think about implementing mutable
> > BigInteger and BigDecimal classes as part of a [math]
> > package?
> >
> > Using BigDecimal for financial applications comes with
> > a big drawback: for every calculation a new BigDecimal
> > object is created since BigDecimals are immutable.
> > You might even need to create two BigDecimal per
> > calculation:
> >
> >     BigDecimal result = ...
> >     result = result.plus(new BigDecimal(0.345f));
> >
> > Or is there some other library you know of?
> >
> > Victor
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] what about mutable BigInteger etc.

Posted by Stephen Colebourne <sc...@btopenworld.com>.
Immutable classes have various advantages over mutable ones, not least being
thread-safe.

However, I would not be averse to adding mutable versions of the Number
classes to math. I would want to see the complete set however,
MutableBigDecimal, MutableBigInteger, MutableInteger, MutableLong,
MutableDouble, MutableFloat and MutableFraction. They would need to be
Number subclasses.

Have you got code already? (I prefer immutable, so I don't especially want
to write the mutable classes.)

Stephen

----- Original Message -----
From: <vi...@gmxpro.net>
> What do you think about implementing mutable
> BigInteger and BigDecimal classes as part of a [math]
> package?
>
> Using BigDecimal for financial applications comes with
> a big drawback: for every calculation a new BigDecimal
> object is created since BigDecimals are immutable.
> You might even need to create two BigDecimal per
> calculation:
>
>     BigDecimal result = ...
>     result = result.plus(new BigDecimal(0.345f));
>
> Or is there some other library you know of?
>
> Victor
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


[lang] what about mutable BigInteger etc.

Posted by vi...@gmxpro.net.
Hi!

What do you think about implementing mutable 
BigInteger and BigDecimal classes as part of a [math] 
package?

Using BigDecimal for financial applications comes with 
a big drawback: for every calculation a new BigDecimal
object is created since BigDecimals are immutable.
You might even need to create two BigDecimal per 
calculation:

    BigDecimal result = ...
    result = result.plus(new BigDecimal(0.345f));

Or is there some other library you know of?

Victor


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>