Re: The Crisis with Remailers
At 17:44 1996-05-21 +0200, bryce@digicash.com wrote:
Matts, you don't want to do floating point for money, because floating point doesn't give you good control of precision.
Yes I do. Several major currency traders in Sweden keep all their money in 64 bit floating point storage. I think that DigiCash will go floating point (get real?) when you start doing currency. If you sell 1 DEM, you don't want to get paid in cents, you want to get paid in 10-15 decimal places. That's where the currency action is right now, and before Ecash(tm) is fully deployed we'll probably see traders going for 15-20 decimal places. Floating point is the way to do it, but are your accountants ready for it?
Keep in mind that only Ecash(tm) Mints can create Ecash(tm) coins and choose what values the coins have.
Sorry, I thought that the client created the coins and the mint just signed them. I guess I should go back to RTFAPI. Regards, Matts
-----BEGIN PGP SIGNED MESSAGE----- Matts Kallionieme <matts@pi.se> wrote:
At 17:44 1996-05-21 +0200, bryce@digicash.com wrote:
Matts, you don't want to do floating point for money, because floating point doesn't give you good control of precision.
Yes I do. Several major currency traders in Sweden keep all their money in 64 bit floating point storage. I think that DigiCash will go floating point (get real?) when you start doing currency. If you sell 1 DEM, you don't want to get paid in cents, you want to get paid in 10-15 decimal places. That's where the currency action is right now, and before Ecash(tm) is fully deployed we'll probably see traders going for 15-20 decimal places. Floating point is the way to do it, but are your accountants ready for it?
Matts, _floating_ point numbers are numbers in which the decimal place moves ("floats") around depending on the value of the number. Floating point numbers are convenient if you want to handle a number that isn't going to be too large, and that isn't going to need a great deal of precision. They are _not_ useful if you want to handle a number with a lot of precision, nor indeed, if you want to be able to _know_ the precision! If you have a number that represents money, you want to know the precision! As an aside, there are rare cases when you will use a floating point number to _represent_ a fixed-point number just because the floating point math is faster on your hardware. As far as I know, this only happens on certain supercomputers. I shall try to refrain from taking umbrage at your comment that DigiCash is "not real". Also that DigiCash doesn't "do" currency. What could you possibly mean by that?
Keep in mind that only Ecash(tm) Mints can create Ecash(tm) coins and choose what values the coins have.
Sorry, I thought that the client created the coins and the mint just signed them. I guess I should go back to RTFAPI.
I'm sorry-- I didn't speak clearly. _Kinds_ of coins, including such things as the currency and base value (i.e. smallest possible coin) are created by Mints. We call these "coinages". They are analogous to new kinds of coin or paper notes in traditional currency. The individual coins are generated by the Ecash(tm) client, but those coins are worthless until they are stamped by the Mint, giving them a currency and denomination (i.e., is this a 5-dollar-cent coin, a 10-dollar-cent coin, a 100-Finnish-Mark coin, etc.). For further reading material as well as <a href="http://www.digicash.com/api"> the API </a>, I can recommend <a href="http://www.digicash.com/ecash/faq.html"> the Ecash(tm) FAQ </a>, <a href="http://www-ugrad.cs.colorado.edu/~wilcoxb/faq"> the Bryce (not speaking for DigiCash on these pages) FAQ </a>, the somewhat out-dated <a href="http://www.digicash.com/ecash/protocol.html"> Ecash(tm) protocol description </a>, and Ian Goldberg's <a href="http://www.cs.berkeley.edu/~iang/ecash/"> Ecash(tm) pages </a>. For further reading on floating point and other representations of numbers in computing, I recommend any good introductory university text on mathematical computing. Sorry I don't have mine handy or I'd give you a specific reference. Regards, Bryce - -----BEGIN GOODTIMES VIRUS INNOCULATION----- Copy me into your .sig for added protection! - ----- END GOODTIMES VIRUS INNOCULATION----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.1b2 iQB1AwUBMaLlGkjbHy8sKZitAQFNmwMAzoYmjg8XQ5lG+Uq8vEzpwTe8TWWcGx6Z zsc02WNMRAzT9iu/upK14bW8kdtAr5f50z3FSpUdbtOr9YbNi8akdZaWYH2w03Xg VivCG3FzfyT03vZtyMEPN1+eEcWSrCt7 =aa73 -----END PGP SIGNATURE-----
Matts Kallioniemi writes:
At 17:44 1996-05-21 +0200, bryce@digicash.com wrote:
Matts, you don't want to do floating point for money, because floating point doesn't give you good control of precision.
Yes I do. Several major currency traders in Sweden keep all their money in 64 bit floating point storage.
I have trouble believing you. None of the forex accounting I know of in the U.S. is done in floating point. It simply isn't accurate enough. It is true enough that *rates* can be stored as floats if you want, but never actual sums. Perry
-----BEGIN PGP SIGNED MESSAGE-----
It is true enough that *rates* can be stored as floats if you want, but never actual sums.
Perry
That's interesting. Because rates never approach 2^23, and because you never need that much precision with rates? It seems like a bad idea to me anyway. Why not just use an Int32 if you don't need that much precision? Regards, Bryce -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.1b2 iQB1AwUBMaNKIUjbHy8sKZitAQFohwL/TnGoBAD2qi+zCf43FqhhPijFf6vNq3Ca ddhNsCKQTML3V7MtQ7TkeMNZqSGexITkXqppxaiFY/uPLqz3b5NDv0JV7xl0bFh9 AiqS4vz1uxeBON5jCJXZI4Cu7HhDf0j0 =pmvp -----END PGP SIGNATURE-----
bryce@digicash.com writes:
It is true enough that *rates* can be stored as floats if you want, but never actual sums.
That's interesting. Because rates never approach 2^23, and because you never need that much precision with rates? It seems like a bad idea to me anyway. Why not just use an Int32 if you don't need that much precision?
I only report the news. I have occassionally seen floats in rates, I have never seen them used in accounting. I will also note that rates do indeed get astonishingly precise -- five significant figures. In any case, however, I have never seen accounts done as floats -- never. .pm
participants (3)
-
bryce＠digicash.com -
Matts Kallioniemi -
Perry E. Metzger