Re: [Quickfix-developers] [qfj] double and not BigDecimal?

[Joerg T. <Joe...@ma...>]

Hi both,

> For QFJ, doubles were used for QF JNI compatibility.

Maybe there is a nice C++ BCD arithmetic lib...

> In a future version of QFJ I'd be open to the possibility of using BigD=
ecimals, but I'd
> want to do some performance analysis first.
Steve, IMHO there no need for performance analysis. You cannot trade corr=
ectness for=20
performance. Maybe we find a way to provide both methods, though.

Recently, I read an article about floating point and Java, but this is a =
issue with=20
floating point numbers in general: They are not precise. The article in i=
s in German, so I=20
cannot post it here.

Therefore, one of the first rules I learnt in the area of financial math =
was: *Never* use=20
floating point, but use fixed point or BCD arithmetic instead.

> IIRC, all the commercial Java FIX engines I've used also represented
> price-like data as doubles.
> Of course, that doesn't make it right. ;-)

Indeed.

> 	From: qui...@li...
> [mailto:qui...@li...] On Behalf Of
> Graham Miller
> 	Sent: Thursday, March 16, 2006 9:12 PM
> 	To: qui...@li...
> 	Subject: [Quickfix-developers] [qfj] double and not BigDecimal?
> =09
> =09
> =09
> 	Why was the decision made to use doubles instead of BigDecimals
> when representing decimal data like prices?  (I guess maybe this was
> something inherited from the old Java wrapper, but then the same can be
> asked about the Javfa wrapper). It seems like the BigDecimal exact
> representations would suit the application better, as dealing with
> rounding problems associated with doubles can be a pain.

Indeed.

> Of course arithmetic expressions are more straightforward using doubles=
 in Java, but
> you can always get around that by converting to doubles before doing an=
y calculations.

In this way, you re-introduce all the hassles you wanted to avoid by usin=
g BigDecimal.

> Sitting here next to a stock ticker, I just saw that Ford is down .0700=
0000000001 cents
> today.  That's what I'm talking about.  Thoughts?

I know that kind of numbers ;-)

My first solution was:

new BigDecimal( fixData.getPrice().getValue() ) ).setScale( 6, BigDecimal=
.ROUND_HALF_DOWN );

but much better is to access the String value directly:

new BigDecimal( fixData.getString( Price.FIELD ) );

This completely skips the conversion to double and back to BigDecimal. So=
 a possible=20
solution for both QF and QF/J would be to return all floats as String, le=
aving it to the=20
user to do the appropriate conversion.

Or we could introduce the notion of a ConverterFactory(), which could be =
configured in the=20
same way as the MessageFactory(). QF would then use:

	converterFactory.getPriceConverter().convert( message.getString( tag ) )=
;

These factories and the used types could be tied to the message generatio=
n codes somehow.

Just some thoughts..

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen