From ... From: Erik Naggum Subject: Re: Would COMPILER-MACRO cut it? Date: 2000/01/27 Message-ID: <3157981207714177@naggum.no>#1/1 X-Deja-AN: 578409858 References: <388A867A.E233262C@fisec.com> <3157713765421792@naggum.no> <388E9D51.D1B9D45@fisec.com> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 948997986 753 195.0.192.66 (27 Jan 2000 18:33:06 GMT) Organization: Naggum Software; +47 8800 8879 or +1 510 435 8604; fax: +47 2210 9077; http://www.naggum.no User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 27 Jan 2000 18:33:06 GMT Newsgroups: comp.lang.lisp * Christopher Browne | Using floats for something that is inherently rational seems to me to | be fundamentally irrational. (And there are too many puns there to | feel comfortable...) the machine representation of a floating point number _is_ a rational! specifically, M*2^E, for Mantissa (an integer) and Exponent (an integer), usually with a separate sign, but that's beside the point. contrary to common beliefs, floating point numbers _are_ exact, they just aren't the numbers we'd _like_ to be exact, because we stupidly cling to decimal instead of hexadecimal or octal. | The *problem* with using floats for financial operations is that this | causes you to enter into all the numerical stability issues that are | rampant in FP math. this is sheer nonsense. the reason we run into numerical stability issues in floating point arithmetic operations is that we're asking the system to find the representable (exact) number that is closest to the (exact, but unrepresentable) result of a computation. as long as the result is representable, floating point arithmetic cannot but remain exact and stable. | | Common Lisp probably needs to have a BCD numeric representation for | this purpose. | supporting BCD numeric representation only makes sense when the hardware also supports it. for all common, relevant purposes, arbitrary-precision integers suffice. #:Erik