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

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

-----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-----