From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_02DB_01C288A6.58151300
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   And so you have to deal with rounding.

Rich

  "Tony Ingenoso"  wrote in message =
news:3dce7daa{at}w3.nls.net...
  All calculations are FP internally.  Temp real has 64 significant =
bits, so it just doesn't matter in most cases.  Normally, someone doing =
financial calcs that wind up with fractions will do FRNDINT's and = FPREM's
to keep track of the missing fractions (if it matters)
    "Rich"  wrote in message news:3dce0001$1{at}w3.nls.net...
       Unless you divide or anything else that produces a non-integral =
value.  The BCD load and save still used the internal floating point =
representation.

    Rich

      "Tony Ingenoso"  wrote in message =
news:3dcdbd84{at}w3.nls.net...
      Intel NPX's back to the original 8087 are all capable of working =
with 64 bit integers and loading/storing in packed BCD format.  For
      financial work the BCD format works well and has no rounding =
errors.  All one needs do is use an implied decimal point (i.e. scale
      by 100, or 1000 if working in mills)

      There is a reason why some places won' give up their COBOL =
compilers ;->

      "Paul Ranson"  wrote in message =
news:3dcd8c7b$1{at}w3.nls.net...
      > If you're dealing with money then a class named 'Decimal' seems =
more
      > appropriate than 'Math'. FWIW.
      >
      > Paul



------=_NextPart_000_02DB_01C288A6.58151300
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








   And so
you have to deal =
with=20
rounding.
 
Rich
 

  "Tony Ingenoso" <tonyiNOSPAM{at}attglobal.net&g=">mailto:tonyiNOSPAM{at}attglobal.net">tonyiNOSPAM{at}attglobal.net&g=
t;=20
  wrote in message news:3dce7daa{at}w3.nls.net...
  All calculations are FP =
internally.  Temp=20
  real has 64 significant bits, so it just doesn't matter in most =
cases. =20
  Normally, someone doing financial calcs that wind up with fractions =
will=20
  do FRNDINT's and FPREM's to keep track of the missing fractions =
(if it=20
  matters)
  

    "Rich" <{at}> wrote in message news:3dce0001$1{at}w3.nls.net...
      
Unless you divide or =
anything else=20
    that produces a non-integral value.  The BCD load and save =
still used=20
    the internal floating point representation.
     
    Rich
     
    
      "Tony Ingenoso" <tonyiNOSPAM{at}attglobal.net&g=">mailto:tonyiNOSPAM{at}attglobal.net">tonyiNOSPAM{at}attglobal.net&g=
t;=20
      wrote in message news:3dcdbd84{at}w3.nls.net...In=
tel=20
      NPX's back to the original 8087 are all capable of working with 64 =
bit=20
      integers and loading/storing in packed BCD format.  =
Forfinancial=20
      work the BCD format works well and has no rounding errors.  =
All one=20
      needs do is use an implied decimal point (i.e. scaleby 100, or =
1000 if=20
      working in mills)There is a reason why some places won' =
give up=20
      their COBOL compilers ;->"Paul
Ranson" <paul{at}barkto.com>">mailto:paul{at}barkto.com">paul{at}barkto.com>
wrote in =
message news:3dcd8c7b$1{at}w3.nls.net...=
>=20
      If you're dealing with money then a class named 'Decimal' seems=20
      more> appropriate than 'Math'.
FWIW.>>=20
      =
Paul

------=_NextPart_000_02DB_01C288A6.58151300--

--- BBBS/NT v4.01 Flag-4