Recommendations regarding BigDecimal and double in ofbiz

[Anne Jessel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I'm making some alterations to files such as ShoppingCart.java, mostly
adding some simple methods that I hope are a little more general in
handling sales tax issues.

I notice some of the existing methods use BigDecimal internally and
return double. Others use double internally.

Those that use BigDecimal and return double do the conversion in
slightly different ways. For example getTotal() uses
            return shipItemTotal.doubleValue();
while getTotalSalesTax() uses
return totalTax.setScale(taxFinalScale, taxRounding).doubleValue();

In the first example, shipItemTotal has not had setScale called previously.

In addition, some temporary BigDecimal objects within these methods have
setScale called, and others don't.

My main question is, is there a recommended way these types of
calculations should be written? My preference would be to always use
BigDecimal internally, and always call setScale for every BigDecimal
object, but maybe there are good reasons not to?

My second question is, assuming there is a preferred way these methods
should be written in ofbiz, should I change the ones I notice to suit
the preferred way?

Cheers,
Anne.

- --
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIBv8htgv4pchABrERArIOAKDECJV78sXOS4/eP+lI/i5lAEwvlQCgyStI
4rsGKCiQvtoCSzFUqDQFssY=
=8qn1
-----END PGP SIGNATURE-----

[David E Jones]

Eventually all methods should use internally and return BigDecimal,  
but no one has done the big pass on this yet.

As for rounding, some operations are more sensitive to specific  
rounding than others, and rounding in different places is configured  
differently.

On a side note, when looking at doing tax stuff I recommend doing  
reading more than writing... most of the stuff is in there at this  
point...

-David


On Apr 17, 2008, at 1:41 AM, Anne wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> I'm making some alterations to files such as ShoppingCart.java, mostly
> adding some simple methods that I hope are a little more general in
> handling sales tax issues.
>
> I notice some of the existing methods use BigDecimal internally and
> return double. Others use double internally.
>
> Those that use BigDecimal and return double do the conversion in
> slightly different ways. For example getTotal() uses
>            return shipItemTotal.doubleValue();
> while getTotalSalesTax() uses
> return totalTax.setScale(taxFinalScale, taxRounding).doubleValue();
>
> In the first example, shipItemTotal has not had setScale called  
> previously.
>
> In addition, some temporary BigDecimal objects within these methods  
> have
> setScale called, and others don't.
>
> My main question is, is there a recommended way these types of
> calculations should be written? My preference would be to always use
> BigDecimal internally, and always call setScale for every BigDecimal
> object, but maybe there are good reasons not to?
>
> My second question is, assuming there is a preferred way these methods
> should be written in ofbiz, should I change the ones I notice to suit
> the preferred way?
>
> Cheers,
> Anne.
>
> - --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIBv8htgv4pchABrERArIOAKDECJV78sXOS4/eP+lI/i5lAEwvlQCgyStI
> 4rsGKCiQvtoCSzFUqDQFssY=
> =8qn1
> -----END PGP SIGNATURE-----

[Anne Jessel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks David. I'll go ahead and change some of the internal use of
doubles to BigDecimal.

You'll be pleased to hear I am doing a lot more reading than writing. I
am hoping to achieve what I need, and not alter the working of any
existing code, by adding a small number of extra methods that return the
numbers I need for display by calling on the existing methods. For
example, item subtotal including tax, and shipping including tax. I'm
finding it's not as easy I as hoped (especially shipping inc tax), but
it's a good way to learn my way around.

Cheers,
Anne.

David E Jones wrote:

>
> Eventually all methods should use internally and return BigDecimal, but
> no one has done the big pass on this yet.
>
> As for rounding, some operations are more sensitive to specific rounding
> than others, and rounding in different places is configured differently.
>
> On a side note, when looking at doing tax stuff I recommend doing
> reading more than writing... most of the stuff is in there at this point...
>
> -David
>
>
> On Apr 17, 2008, at 1:41 AM, Anne wrote:
> Hi
>
> I'm making some alterations to files such as ShoppingCart.java, mostly
> adding some simple methods that I hope are a little more general in
> handling sales tax issues.
>
> I notice some of the existing methods use BigDecimal internally and
> return double. Others use double internally.
>
> Those that use BigDecimal and return double do the conversion in
> slightly different ways. For example getTotal() uses
>            return shipItemTotal.doubleValue();
> while getTotalSalesTax() uses
> return totalTax.setScale(taxFinalScale, taxRounding).doubleValue();
>
> In the first example, shipItemTotal has not had setScale called
> previously.
>
> In addition, some temporary BigDecimal objects within these methods have
> setScale called, and others don't.
>
> My main question is, is there a recommended way these types of
> calculations should be written? My preference would be to always use
> BigDecimal internally, and always call setScale for every BigDecimal
> object, but maybe there are good reasons not to?
>
> My second question is, assuming there is a preferred way these methods
> should be written in ofbiz, should I change the ones I notice to suit
> the preferred way?
>
> Cheers,
> Anne.
>

- --
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFICsANtgv4pchABrERAnxEAJwPTJiHaGCPTF6VXFuCmHCsOL5a7QCghdjt
BmrctNNFVec+qBJCYqmsZv8=
=x/bp
-----END PGP SIGNATURE-----