From: "Tony Ingenoso" 

This is a multi-part message in MIME format.

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

Most people will probbly want chop for financial stuff.  As you said, it =
only occurs with divisions.
  "Rich"  wrote in message news:3dcea80e$1{at}w3.nls.net...
     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_00C3_01C288D9.31345830
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Most people will probbly want chop for =
financial=20
stuff.  As you said, it only occurs with divisions.

  "Rich" <{at}> wrote in message news:3dcea80e$1{at}w3.nls.net...
     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=20
      else that produces a non-integral value.  The BCD load and =
save still=20
      used 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. =20
        Forfinancial work the BCD format works well and has no =
rounding=20
        errors.  All one needs do is use an implied decimal point =
(i.e.=20
        scaleby 100, or 1000 if working in
mills)There is a =
reason=20
        why some places won' give up their COBOL compilers =
;->"Paul=20
        Ranson" <paul{at}barkto.com>=20">mailto:paul{at}barkto.com">paul{at}barkto.com>=20
        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_00C3_01C288D9.31345830--

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