Thanks, Ben, what should I use for representing the money amounts? A boolean :)) ? Thanks for help, Pshemek -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ben Hutchings Sent: 15 April 2005 15:52 To: boost-users@lists.boost.org Subject: Re: [Boost-users] RE: Boost thread problem Sliwa, Przemyslaw (London) wrote:
Hi,
Thanks for help,
On a Linux box I have to link against libc_r too? Probably yes, but could you confirm this?
No. Just use the compiler options "-pthread -D_REENTRANT" consistently. libc_r is a BSD thing.
It seems the usage of the vector cases problems with the multithreaded programs on the multiprocessor machines. I have changed it to queue and the bug has been resolved. I cannot reproduce it now.
I think the bug might lie in the copy-assignment operator for CFXTrade. std::vector<CFXTrade> may use that whereas std::queue<CFXTrade> probably will not. By the way, what are you planning on doing with the money left over as a result of rounding errors? (Seriously, double is not a suitable type for representing amounts of money. Check your local accounting regulations.) Ben. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------
Sliwa, Przemyslaw (London) wrote:
Thanks,
Ben, what should I use for representing the money amounts? A boolean :)) ?
If you're dealing with other people's money then there are regulations that specify the required intermediate precision and rounding rules, which may vary from place to place. I believe you'll need to use fixed-point decimal fractions, perhaps implemented as integer counts of hundredths or ten-thousandths of a currency unit. I've not done this myself so I don't know the details, but I'm fairly sure that getting this wrong can put you on the wrong side of the law. Ben.
Ben is right, you simply can't use double for any serious financial/scientific calculation. And indeed I hope someday an arbitrary math precision library be part of the standard C++. Look for a standard for the place where this is going to be used. If there isn't one. Use an arbitrary math precision library anyway. Take a look at mapm: http://www.cuj.com/documents/s=8020/cuj0111ring/ http://www.tc.umn.edu/~ringx004/mapm-main.html There are other comercial alternatives, a quick google search produced this: http://www.boic.com/b1mnum.pdf http://www.boic.com/numintro.htm Hope this helps, Mauricio Gomes Pensar Digital phone: 55-11-4121-6287 mobile: 55-11-8319-9610 http://pensardigital.com On Apr 15, 2005, at 2:37 PM, Ben Hutchings wrote:
Sliwa, Przemyslaw (London) wrote:
Thanks, Ben, what should I use for representing the money amounts? A boolean :)) ?
If you're dealing with other people's money then there are regulations that specify the required intermediate precision and rounding rules, which may vary from place to place. I believe you'll need to use fixed-point decimal fractions, perhaps implemented as integer counts of hundredths or ten-thousandths of a currency unit. I've not done this myself so I don't know the details, but I'm fairly sure that getting this wrong can put you on the wrong side of the law.
Ben. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ben Hutchings wrote:
If you're dealing with other people's money then there are regulations that specify the required intermediate precision and rounding rules, which may vary from place to place.
For market risk, the amounts are very high and somewhat 'virtual', because what is evaluated is a probability of gain/loss, and therefore some imprecision is acceptable. When it is about 'real' money, imprecision is unavoidable (...change rates...), but what helps is the small number of operations (couple of additions / multiplications) in each separate transaction. When other types of financial operations implies many numbers, regulations may enforce to have specific accounts storing rounding errors (differences between the actual and expected results): Although there are rounding errors, nothing 'disappeared' from the bank's books.
participants (4)
-
Ben Hutchings -
Mauricio Gomes -
remi.chateauneu＠gmx.de -
Sliwa, Przemyslaw (London)