Re: sorry .09 instead of .08

Thomas Hawtin <usenet@xxxxxxxxxxxxxxxxx> wrote in
news:43dd574f$0$1460$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxx:

> zero wrote:
>>
>> BigDecimal will be slower though. If the values are all currency
>> values, with only 2 numbers after the decimal point, ints are a good
>> choice.
>
> They are slower. However, is it going to make your program noticeably
> slower. Almost certainly not. Better to keep it safe than prematurely
> optimise.
>
> Using ints is full of traps. No good for a billionaire companies,
> although longs should do for storage. Operations such as
> multiplication become tricky. Without treating it as a type in its own
> right, you can easily get into trouble.
>
> Tom Hawtin

BigDecimal has its own problems, beside the speed. If you initialize a
BigDecimal with a double constant, you're in the same boat as using a
normal double when it comes to rounding errors.

I would suggest int or long for financial calculations, and BigDecimal if
you're dealing with more numbers after the decimal point.
.

Relevant Pages

  • Re: sorry .09 instead of .08
    ... >> BigDecimal will be slower though. ... If the values are all currency ... >> values, with only 2 numbers after the decimal point, ints are a good ... too lazy and wanted to keep the message short ...
    (comp.lang.java.help)
  • Re: sorry .09 instead of .08
    ... slower. ... Better to keep it safe than prematurely optimise. ... Using ints is full of traps. ...
    (comp.lang.java.help)
  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... I ask why WOULD it be slower? ... the extra instruction is small compared to the time to execute the move. ... Micro Focus' efficiency advice is exactly the same on every platform, ... becomes zero, rather than incrementing the counter from zero to n. ...
    (comp.lang.cobol)
  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... iteration showing that the PERFORM structure used more time than the ... might have changed either the subscript or the DO item, so it recomputes the subscript for ... I ask why WOULD it be slower? ... becomes zero, rather than incrementing the counter from zero to n. ...
    (comp.lang.cobol)
  • Re: Cobol Myth Busters
    ... Do you think adding 5 is slower than adding 1? ... *subtracting* 5 from a register is certainly slower than subtracting 1 ... Intel has an INC instruction to add 1. ... the other is decrementing the counter to zero. ...
    (comp.lang.cobol)