[groovy-user] BigDecimal NullPointerException

[James Hughes]

Hello,

I couldn't get any information on this elsewhere and I am confused. Why does x.round() throw an NPE when it's not null (see below)?

groovy> def x = 300*(365/12)
groovy> x
Result: 9125.0000000100

------

groovy> def x = 300*(365/12)
groovy> x.class
Result: class java.math.BigDecimal

-------

groovy> def x = 300*(365/12)
groovy> x.round()
Exception thrown: java.lang.NullPointerException
java.lang.NullPointerException
at Script18.run(Script18:2)




--------------------------------------------------------------------
This e-mail is intended solely for the addressee and is strictly confidential; if you are not the addressee please destroy the message and all copies. Any opinion or information contained in this email or its attachments that does not relate to the business of Kainos
is personal to the sender and is not given by or endorsed by Kainos. Kainos is the trading name of Kainos Software Limited, registered in Northern Ireland under company number: NI19370, having its registered offices at: Kainos House, 4-6 Upper Crescent, Belfast, BT7 1NT,
Northern Ireland. Registered in the UK for VAT under number: 454598802 and registered in Ireland for VAT under number: 9950340E. This email has been scanned for all known viruses by MessageLabs but is not guaranteed to be virus free; further terms and conditions may be
found on our website - www.kainos.com



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[James Hughes]

Actually, Just as I sent this I found the answer - http://markmail.org/message/wnkh5r63lt7ccfpv#query:groovy%20bigdecimal%20round%20npe+page:1+mid:wnkh5r63lt7ccfpv+state:results

Sorry for being an idiot!

________________________________

From: James Hughes [mailto:J.Hughes-fZ2kPDQGsinQT0dZR+***@public.gmane.org]
Sent: Thu 04/12/2008 13:27
To: user-i9PBDF1N6cxnkHa44VUL00B+***@public.gmane.org
Subject: [groovy-user] BigDecimal NullPointerException



Hello,

I couldn't get any information on this elsewhere and I am confused. Why does x.round() throw an NPE when it's not null (see below)?

groovy> def x = 300*(365/12)
groovy> x
Result: 9125.0000000100

------

groovy> def x = 300*(365/12)
groovy> x.class
Result: class java.math.BigDecimal

-------

groovy> def x = 300*(365/12)
groovy> x.round()
Exception thrown: java.lang.NullPointerException
java.lang.NullPointerException
at Script18.run(Script18:2)



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email





--------------------------------------------------------------------
This e-mail is intended solely for the addressee and is strictly confidential; if you are not the addressee please destroy the message and all copies. Any opinion or information contained in this email or its attachments that does not relate to the business of Kainos
is personal to the sender and is not given by or endorsed by Kainos. Kainos is the trading name of Kainos Software Limited, registered in Northern Ireland under company number: NI19370, having its registered offices at: Kainos House, 4-6 Upper Crescent, Belfast, BT7 1NT,
Northern Ireland. Registered in the UK for VAT under number: 454598802 and registered in Ireland for VAT under number: 9950340E. This email has been scanned for all known viruses by MessageLabs but is not guaranteed to be virus free; further terms and conditions may be
found on our website - www.kainos.com



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Robert Fischer]

BTW, this is why I hate null pointer exceptions and habitually code guards.

http://enfranchisedmind.com/blog/2007/06/13/nullpointerexceptions-are-not-helpful/

~~ Robert.

Post by James Hughes
Actually, Just as I sent this I found the answer - http://markmail.org/message/wnkh5r63lt7ccfpv#query:groovy%20bigdecimal%20round%20npe+page:1+mid:wnkh5r63lt7ccfpv+state:results
Sorry for being an idiot!
________________________________
Sent: Thu 04/12/2008 13:27
Subject: [groovy-user] BigDecimal NullPointerException
Hello,
I couldn't get any information on this elsewhere and I am confused. Why does x.round() throw an NPE when it's not null (see below)?
groovy> def x = 300*(365/12)
groovy> x
Result: 9125.0000000100
------
groovy> def x = 300*(365/12)
groovy> x.class
Result: class java.math.BigDecimal
-------
groovy> def x = 300*(365/12)
groovy> x.round()
Exception thrown: java.lang.NullPointerException
java.lang.NullPointerException
at Script18.run(Script18:2)
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
--------------------------------------------------------------------
This e-mail is intended solely for the addressee and is strictly confidential; if you are not the addressee please destroy the message and all copies. Any opinion or information contained in this email or its attachments that does not relate to the business of Kainos
is personal to the sender and is not given by or endorsed by Kainos. Kainos is the trading name of Kainos Software Limited, registered in Northern Ireland under company number: NI19370, having its registered offices at: Kainos House, 4-6 Upper Crescent, Belfast, BT7 1NT,
Northern Ireland. Registered in the UK for VAT under number: 454598802 and registered in Ireland for VAT under number: 9950340E. This email has been scanned for all known viruses by MessageLabs but is not guaranteed to be virus free; further terms and conditions may be
found on our website - www.kainos.com
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
~~ Robert Fischer.
Grails Trainining http://www.smokejumperit.com/grails_training.html
Smokejumper Consulting http://smokejumperit.com
Enfranchised Mind Blog http://enfranchisedmind.com/blog

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Post by Robert Fischer
BTW, this is why I hate null pointer exceptions and habitually code guards.
http://enfranchisedmind.com/blog/2007/06/13/nullpointerexceptions-are-not-helpful/

in Groovy controlled code it is a bit better:

def x = null
x.foo

Post by Robert Fischer
java.lang.NullPointerException: Cannot get property 'foo' on null object

[...]

so the message at last tells you, that you tried to get a property named
"foo" on null. Or for method calls:

def x = null
x.bar()

Post by Robert Fischer
java.lang.NullPointerException: Cannot invoke method bar() on null object

[...]

Of course if you actually wanted to know about x, then this won't help ;)

bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Robert Fischer]

Yeah, I had noticed that. Thank you thank you thank you for that. That and the Elvis operator help
a LOT.

~~ Robert.

Post by Jochen Theodorou

Post by Robert Fischer
BTW, this is why I hate null pointer exceptions and habitually code guards.
http://enfranchisedmind.com/blog/2007/06/13/nullpointerexceptions-are-not-helpful/

def x = null
x.foo

Post by Robert Fischer
java.lang.NullPointerException: Cannot get property 'foo' on null object

[...]
so the message at last tells you, that you tried to get a property named
def x = null
x.bar()

Post by Robert Fischer
java.lang.NullPointerException: Cannot invoke method bar() on null object

[...]
Of course if you actually wanted to know about x, then this won't help ;)
bye blackdrag

--
~~ Robert Fischer.
Grails Trainining http://www.smokejumperit.com/grails_training.html
Smokejumper Consulting http://smokejumperit.com
Enfranchised Mind Blog http://enfranchisedmind.com/blog

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Post by Robert Fischer
Yeah, I had noticed that. Thank you thank you thank you for that. That
and the Elvis operator help a LOT.

sometimes it is the small things that help the most ;)

bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jim White]

Actually this opens another can of worms.

It seems reasonable that BigDecimal.round() should work (in addition to
BD.round(MathContext)), but your question has prompted me to look closer
at the BD -> integer conversions we are doing and I don't think they're
right.

1.9 as long
==>
1

erk.

At one level that is OK because it is the behavior defined for
BD.longValue(), which is similar to Double.longValue() in that it
truncates the decimal portion and also ignores overflow. And naturally
that is the current behavior in Groovy:

1.9f as short
==>
1

1e50f as short
==>
0

(1e50 as BigDecimal) as long
==>
-5376172055173529600

But I think the 'as' conversion should do the expected thing
arithmetically, which for BD means rounding and checking for overflow.
In Java 1.5 there are new "exact" methods to help with that
(longValueExact() et al).

I've done one small improvement in that direction already:

http://jira.codehaus.org/browse/GROOVY-3171

which changes this from Groovy 1.5.x:

1.9f as BigDecimal
===> 1.89999997615814208984375

to this in Groovy 1.6:

1.9f as BigDecimal
===> 1.9

For folks who want the non-arithmetic conversion treatment of Groovy
'as', we still have Java casts.

So we'ld still have:

(long) 1.9
==>
1

Don't have more time for this at the moment. If there's any support for
this improvement, I'll create a JIRA.

Jim

Post by James Hughes
Actually, Just as I sent this I found the answer - http://markmail.org/message/wnkh5r63lt7ccfpv#query:groovy%20bigdecimal%20round%20npe+page:1+mid:wnkh5r63lt7ccfpv+state:results
Sorry for being an idiot!
________________________________
Sent: Thu 04/12/2008 13:27
Subject: [groovy-user] BigDecimal NullPointerException
Hello,
I couldn't get any information on this elsewhere and I am confused. Why does x.round() throw an NPE when it's not null (see below)?
groovy> def x = 300*(365/12)
groovy> x
Result: 9125.0000000100
------
groovy> def x = 300*(365/12)
groovy> x.class
Result: class java.math.BigDecimal
-------
groovy> def x = 300*(365/12)
groovy> x.round()
Exception thrown: java.lang.NullPointerException
java.lang.NullPointerException
at Script18.run(Script18:2)

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Post by Jim White
Actually this opens another can of worms.
It seems reasonable that BigDecimal.round() should work (in addition to
BD.round(MathContext)), but your question has prompted me to look closer
at the BD -> integer conversions we are doing and I don't think they're
right.
1.9 as long
==>
1

[...]

Post by Jim White
1.9f as short
==>
1
1e50f as short
==>
0
(1e50 as BigDecimal) as long
==>
-5376172055173529600
But I think the 'as' conversion should do the expected thing
arithmetically, which for BD means rounding and checking for overflow.
In Java 1.5 there are new "exact" methods to help with that
(longValueExact() et al).

If we do it for BigDecimal, then we should do it for Double and Float as
well...

Post by Jim White
http://jira.codehaus.org/browse/GROOVY-3171
1.9f as BigDecimal
===> 1.89999997615814208984375
1.9f as BigDecimal
===> 1.9

which is fine for me, since we convert here from floating point to
floating point number...

Post by Jim White
For folks who want the non-arithmetic conversion treatment of Groovy
'as', we still have Java casts.
(long) 1.9
==>
1
Don't have more time for this at the moment. If there's any support for
this improvement, I'll create a JIRA.

it should handle Double and Float then as well... but what value would
the long get? would you say 2 or would you give an error, that the long
couldn't be converted? I mean it kind of looks wrong if 1.5 as long is 2
and 1.499999999999999999999999999999 is 1

And about giving here an exception... do we really want that? Especially
since we have no overflow-exception-arithmetics. An alternative
mathematics module with overflow-exception arithmetics could be an
interesting thing to do... But I would use a different number class for
that...

bye
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jim White]

Post by Jochen Theodorou

Post by Jim White
Actually this opens another can of worms.
It seems reasonable that BigDecimal.round() should work (in addition
to BD.round(MathContext)), but your question has prompted me to look
closer at the BD -> integer conversions we are doing and I don't think
they're right.
1.9 as long
==>
1

[...]

Post by Jim White
1.9f as short
==>
1
1e50f as short
==>
0
(1e50 as BigDecimal) as long
==>
-5376172055173529600
But I think the 'as' conversion should do the expected thing
arithmetically, which for BD means rounding and checking for overflow.
In Java 1.5 there are new "exact" methods to help with that
(longValueExact() et al).

If we do it for BigDecimal, then we should do it for Double and Float as
well...

Yes, of course.

Post by Jochen Theodorou

Post by Jim White
http://jira.codehaus.org/browse/GROOVY-3171
1.9f as BigDecimal
===> 1.89999997615814208984375
1.9f as BigDecimal
===> 1.9

which is fine for me, since we convert here from floating point to
floating point number...

Post by Jim White
For folks who want the non-arithmetic conversion treatment of Groovy
'as', we still have Java casts.
(long) 1.9
==>
1
Don't have more time for this at the moment. If there's any support
for this improvement, I'll create a JIRA.

it should handle Double and Float then as well... but what value would
the long get? would you say 2 or would you give an error, that the long
couldn't be converted? I mean it kind of looks wrong if 1.5 as long is 2
and 1.499999999999999999999999999999 is 1

ROUND_HALF_UP, is the one that would give that result, and is what I
think is usually expected when rounding a fractional part to a whole.

http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigDecimal.html#ROUND_HALF_UP

Groovy 1.5 (well, just Java actually):

sprintf("%.0f", 1.49f)
==> 1
sprintf("%.0f", 1.5f)
==> 2
sprintf("%.0f", 1.49)
==> 1
sprintf("%.0f", 1.5)
==> 2

There are very specific arithmetic rules for various kinds of rounding
and for particular applications folks may choose them. The motivation
for considering this change is that truncation (ROUND_DOWN) is not what
is commonly expected for ordinary usage.

Post by Jochen Theodorou
And about giving here an exception... do we really want that? Especially
since we have no overflow-exception-arithmetics. An alternative
mathematics module with overflow-exception arithmetics could be an
interesting thing to do... But I would use a different number class for
that...

We do have a number of arithmetic exceptions such as divide-by-zero and
we also get exceptions on numeric conversions when parsing a string for
example. By making it easy to get a safe conversion (that is catching
overflow in things like 'BD as long') we become groovier because it is
better to have no result than an erroneous result. And if someone
doesn't want the exception they can still use a conversion that doesn't
throw one.

To me the big question is whether changing this behavior (which is a
breaking change for applications that worry about getting this right and
did what they had to in Groovy 1.5) is too disruptive. People who've
dealt with this in Java already are familiar with the truncation and so
have dealt with it (adding 0.5 and so forth).

That's enough interest that I'll open a JIRA later so this can be
discussed further.

Jim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jim White schrieb:
[...]

Post by Jim White
There are very specific arithmetic rules for various kinds of rounding
and for particular applications folks may choose them. The motivation
for considering this change is that truncation (ROUND_DOWN) is not what
is commonly expected for ordinary usage.

commonly expected in what context. As a programmer I am very used to 1.9
becoming 1 if converted to integer. In most algorithms I wrote I did
either not have to convert to an integer or the rounding mode did
matter... in fact truncation as what I used most of the time.

On the other hand we are a talking here about something that maybe is
usually not done itself.

Post by Jim White

Post by Jochen Theodorou
And about giving here an exception... do we really want that?
Especially since we have no overflow-exception-arithmetics. An
alternative mathematics module with overflow-exception arithmetics
could be an interesting thing to do... But I would use a different
number class for that...

We do have a number of arithmetic exceptions such as divide-by-zero and
we also get exceptions on numeric conversions when parsing a string for
example. By making it easy to get a safe conversion (that is catching
overflow in things like 'BD as long') we become groovier because it is
better to have no result than an erroneous result. And if someone
doesn't want the exception they can still use a conversion that doesn't
throw one.

I thought also of things like int i=Integer.MAX_VALUE, i++. There are
three implementations here that I know of... one is the overflow Java
uses, one is throwing an exception and one is enlarging the number as
needed. But there is no explicit type conversion involved, so "as" can't
be used for things like that. Also I wonder about the value of "1.9 as
int" throwing an exception at the moment... finally what "erroneous"
means depends on the definition ;)

bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Russel Winder]

Post by Jochen Theodorou
[...]

Post by Jim White
There are very specific arithmetic rules for various kinds of rounding
and for particular applications folks may choose them. The motivation
for considering this change is that truncation (ROUND_DOWN) is not what
is commonly expected for ordinary usage.

commonly expected in what context. As a programmer I am very used to 1.9
becoming 1 if converted to integer. In most algorithms I wrote I did
either not have to convert to an integer or the rounding mode did
matter... in fact truncation as what I used most of the time.
On the other hand we are a talking here about something that maybe is
usually not done itself.

Probably best not to use you personal perceptions alone to determine
behaviours. As Jim has said there are many rounding algorithms,
truncation and rounding to the nearest integer are the two obvious ones.
When working with values (as opposed to thinking about the behaviour of
computers), I always want the default to be round to the nearest integer
since it better reflect the value. If I want truncation I use floor.
The real question is what do the majority of Groovy programmers want the
behaviour to be.

[Guillaume Laforge]

On Tue, Dec 9, 2008 at 3:43 PM, Russel Winder

Post by Russel Winder
[...]
Probably best not to use you personal perceptions alone to determine
behaviours. As Jim has said there are many rounding algorithms,
truncation and rounding to the nearest integer are the two obvious ones.
When working with values (as opposed to thinking about the behaviour of
computers), I always want the default to be round to the nearest integer
since it better reflect the value. If I want truncation I use floor.
The real question is what do the majority of Groovy programmers want the
behaviour to be.

Since Groovy is used a lot in finantial applications, they care a lot
about rounding with BigDecimal.
So if ever we were to make some changes in this area, we should not
commit those changes before we get in touch with such persons with
such use cases.
Otherwise, they'll loose million dollars because of new rounding
differences compared to before...
--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[J***@public.gmane.org]

+1. with Guillaume. Our application calculates insurance rates and
premiums and we rely on the decimal precision provided in Groovy by
default. When we want something rounded we use the setScale() method on
the BigDecimal class.

Joel Brewster
Mutual Of Omaha
joel.brewster-iVe1qmVFPPDiwZoFZTs6tAC/***@public.gmane.org
402.351.6989



"Guillaume
Laforge"
<***@gmail.c To
om> user-i9PBDF1N6cxnkHa44VUL00B+***@public.gmane.org
cc
12/09/2008 08:46
AM Subject
Re: [groovy-user] Smarter
arithmetic for 'as'? (was 'Re:
Please respond to [groovy-user] BigDecimal
user-i9PBDF1N6cxiRUdI4B+***@public.gmane.org NullPointerException)
aus.org









On Tue, Dec 9, 2008 at 3:43 PM, Russel Winder

Post by Russel Winder
[...]
Probably best not to use you personal perceptions alone to determine
behaviours. As Jim has said there are many rounding algorithms,
truncation and rounding to the nearest integer are the two obvious ones.
When working with values (as opposed to thinking about the behaviour of
computers), I always want the default to be round to the nearest integer
since it better reflect the value. If I want truncation I use floor.
The real question is what do the majority of Groovy programmers want the
behaviour to be.

Since Groovy is used a lot in finantial applications, they care a lot
about rounding with BigDecimal.
So if ever we were to make some changes in this area, we should not
commit those changes before we get in touch with such persons with
such use cases.
Otherwise, they'll loose million dollars because of new rounding
differences compared to before...

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email







This e-mail and any files transmitted with it are confidential and are solely for the use of the addressee. It may contain material that is legally privileged, proprietary or subject to copyright belonging to Mutual of Omaha Insurance Company and its affiliates, and it may be subject to protection under federal or state law. If you are not the intended recipient, you are notified that any use of this material is strictly prohibited. If you received this transmission in error, please contact the sender immediately by replying to this e-mail and delete the material from your system. Mutual of Omaha Insurance Company may archive e-mails, which may be accessed by authorized persons and may be produced to other parties, including public authorities, in compliance with applicable laws.



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jim White]

Post by J***@public.gmane.org
+1. with Guillaume. Our application calculates insurance rates and
premiums and we rely on the decimal precision provided in Groovy by
default. When we want something rounded we use the setScale() method on
the BigDecimal class.

Which is a good thing and won't be affected by the proposed change which
only is going to be for folks converting decimal values to integer by
using 'as'.

In your case you're doing everything in BigDecimal and adjusting as
needed. Never going to get in trouble that way.

Post by J***@public.gmane.org

Post by Russel Winder
...
Probably best not to use you personal perceptions alone to determine
behaviours.

yes, but that was not really my point... my point is more that I really
cannot know what the majority of the users expect here if they expect
here something else then what a normal cast would do. That also includes
that I already know what a cast would do too. And if they know that,
would they expect "as" to behave here different than a cast?

Post by Russel Winder
As Jim has said there are many rounding algorithms,
truncation and rounding to the nearest integer are the two obvious ones.

I've fielded pleas for help from many Java programmers over the years
confused by decimal conversions and inexact representation in floating
point. What they are almost 100% of the time confounded by is why they
don't get the same results as 'sprintf' (or in the case of former BASIC
programmers, PRINT).

That means they expect rounding half up so that insignificant and
inexact digits don't appear in the result.

While some might consider it debatable whether 1.5 should become 1 or 2,
in almost every case folks will say that 1.999 should become 2 and
currently we get 1. Similarly they'll want 1.001 to become 1. That
means rounding half up (the dividing line has to go *somewhere* and
Solomon split's it right in the middle).

Post by J***@public.gmane.org
[...]

Post by Russel Winder
[...]
We do have a number of arithmetic exceptions such as divide-by-zero
and we also get exceptions on numeric conversions when parsing a
string for example. By making it easy to get a safe conversion (that
is catching overflow in things like 'BD as long') we become groovier
because it is better to have no result than an erroneous result. And
if someone doesn't want the exception they can still use a conversion
that doesn't throw one.

I thought also of things like int i=Integer.MAX_VALUE, i++. There are
three implementations here that I know of... one is the overflow Java
uses, one is throwing an exception and one is enlarging the number as
needed. But there is no explicit type conversion involved, so "as" can't
be used for things like that. Also I wonder about the value of "1.9 as
int" throwing an exception at the moment... finally what "erroneous"
means depends on the definition ;)

The 'as' conversion can already throw exceptions if we don't have a
correct way to convert to the target type. Trying to convert a too big
number to another type with a smaller range should result in an exception.

As for overflow, that's why Groovy uses BigDecimal/BigInteger by
default, rather than Double/Long (the tradition going back all the way
from Java clear to FORTRAN and Algol), in the first place. Folks are
more concerned with correctness than speed when using Groovy.

Jim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jim White schrieb:
[...]

Post by Jim White
While some might consider it debatable whether 1.5 should become 1 or 2,
in almost every case folks will say that 1.999 should become 2 and
currently we get 1. Similarly they'll want 1.001 to become 1. That
means rounding half up (the dividing line has to go *somewhere* and
Solomon split's it right in the middle).

it gets really interesting for -1.5 ;)

[...]

Post by Jim White
As for overflow, that's why Groovy uses BigDecimal/BigInteger by
default, rather than Double/Long (the tradition going back all the way
from Java clear to FORTRAN and Algol), in the first place. Folks are
more concerned with correctness than speed when using Groovy.

1 is in Groovy as in Java a int/Integer, where 1.0 is in Groovy a
BigDecimal and a double in Java.

bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Post by Russel Winder

Post by Jochen Theodorou
[...]

Post by Jim White
There are very specific arithmetic rules for various kinds of rounding
and for particular applications folks may choose them. The motivation
for considering this change is that truncation (ROUND_DOWN) is not what
is commonly expected for ordinary usage.

commonly expected in what context. As a programmer I am very used to 1.9
becoming 1 if converted to integer. In most algorithms I wrote I did
either not have to convert to an integer or the rounding mode did
matter... in fact truncation as what I used most of the time.
On the other hand we are a talking here about something that maybe is
usually not done itself.

Probably best not to use you personal perceptions alone to determine
behaviours.

yes, but that was not really my point... my point is more that I really
cannot know what the majority of the users expect here if they expect
here something else then what a normal cast would do. That also includes
that I already know what a cast would do too. And if they know that,
would they expect "as" to behave here different than a cast?

Post by Russel Winder
As Jim has said there are many rounding algorithms,
truncation and rounding to the nearest integer are the two obvious ones.

take a look at the table at

http://java.sun.com/j2se/1.5.0/docs/api/java/math/RoundingMode.html

and now tell me why I should prefer one mode over the other one through
"as". Every of these modes makes sense in a certain context.

Post by Russel Winder
When working with values (as opposed to thinking about the behaviour of
computers), I always want the default to be round to the nearest integer
since it better reflect the value.

what is the nearest integer for 1.5? 1 and 2 have both the same
distance, so there is no single nearest integer.

Post by Russel Winder
If I want truncation I use floor.
The real question is what do the majority of Groovy programmers want the
behaviour to be.

true, but how do we get an answer to this? I think the majority of the
users will not be influenced by this. And surely we can't make it right
for all of them

bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email