quickfix-developers

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

[Steve B. <sb...@sm...>]

Hi Graham,
=20
For QFJ, doubles were used for QF JNI compatibility. In a future version
of QFJ I'd be open to the
possibility of using BigDecimals, but I'd want to do some performance
analysis first.
=20
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. ;-)
=20
Regards,
=20
Steve

=09
________________________________

	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.  Of course
arithmetic expressions are more straightforward using doubles in Java,
but you can always get around that by converting to doubles before doing
any calculations.  Sitting here next to a stock ticker, I just saw that
Ford is down .07000000000001 cents today.  That's what I'm talking
about.  Thoughts?=20
=09
	graham
=09
=09


________________________________

	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
	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.  Of course
arithmetic expressions are more straightforward using doubles in Java,
but you can always get around that by converting to doubles before doing
any calculations.  Sitting here next to a stock ticker, I just saw that
Ford is down .07000000000001 cents today.  That's what I'm talking
about.  Thoughts?=20
=09
	graham
=09
=09

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

[Steve B. <sb...@sm...>]

J=F6rg,

I've searched the SF mailing list archives for the threads you
referenced a and I didn't find them. Can you post a link to one=20
of the messages in each thread?

Thanks,

Steve Bate
Smart Trade Technologies
Phone: +33 4 42 90 03 97
http://www.smart-trade.net/
=20

> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On=20
> Behalf Of Joerg Thoennes
> Sent: Thursday, March 16, 2006 10:41 PM
> To: Oren Miller
> Cc: Graham Miller; qui...@li...
> Subject: Re: [Quickfix-developers] [qfj] double and not BigDecimal?
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> Oren Miller wrote:
> > QuickFIX Documentation:=20
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >=20
> > Did QuickFIX actually return this value to you or did you do some=20
> > calculations on it before seeing this price?
>=20
> As a side note:
>=20
> This issue has already been discussed a while ago; see the=20
> message threads:
>=20
> * QF java interface: conversion from double fields to=20
> BigDecimal give imprecise results
> * price as double
>=20
> For Java, a good default would be to use BigDecimal, but for=20
> C++ you would need a BCD lib.
> So using the underlying string directly is the safest way at=20
> the moment.
>=20
> 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
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language
> that extends applications into web and mobile media. Attend=20
> the live webcast
> and join the prime developer group breaking into this new=20
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20

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