[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: implementation categories, exact rationals*From*: bear <bear@xxxxxxxxx>*Date*: Sun, 16 Oct 2005 11:08:17 -0700 (PDT)*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051014181146.599D01B77BB@xxxxxxxxxxxxxxxxxxxxx>*References*: <20051014181146.599D01B77BB@xxxxxxxxxxxxxxxxxxxxx>

On Fri, 14 Oct 2005, Aubrey Jaffer wrote: > What is the rationale for mandating exact rationals? Over 15 years I > have written numerical Scheme code for everything from symbolic > algebra to Galois fields to linear systems to optics simulations > without needing exact rationals. Unlimited-precision rationals are absolutely irreplaceable - when they are exactly what a given application requires. But that's mostly number-theory and related domains, which isn't very common in practice. In practice, what I've found is that unlimited-precision rationals cause straightforward calculations to explode and take unlimited memory space and time, unless you are careful to throw the appropriate exact->inexact call in a critical place or remember to type a point with the arguments that need to be inexact. And, code written to *avoid* the use of unlimited-precision, which is usually necessary, is (however trivially) more complicated than code that uses it (or winds up using it even though it contributes little, or negatively, to the code's utility). I see newbies fall into the trap, too often; they write something that should do a simple series expansion, and watch aghast as it mysteriously consumes all available resources. Or code that worked fine on one scheme implementation explodes on a different one that provides unlimited rationals, creating an unnecessary porting issue. So I see it as having conflicting design principles: "Optimize the common or most useful case" generally means avoiding unlimited-precision calculations really shouldn't be something you have to think about. Representation and operation times that expand toward infinity are anathema when you are optimizing - optimization forces you to regard numbers as representations on a (finite) physical computer with bounded processing power. "Numbers are independent of their representation and exact whenever possible" on the other hand says that rationals should be used by default, whenever possible. The fact that representation and time used quickly expand toward infinity in many common calculations is irrelevant to this principle which regards numbers as abstractions and code as merely a means for *expression* of algorithms. Finding an appropriate compromise between these principles is at best a ticklish business. We don't want to cripple scheme for people who actually need unlimited-precision rationals, but at the same time we'd like to optimize the common case, meaning that in the course of ordinary programming we shouldn't have to think about *avoiding* unlimited-precision rationals. Bear

**References**:**implementation categories, exact rationals***From:*Aubrey Jaffer

- Prev by Date:
**Re: implementation categories, exact rationals** - Next by Date:
**Re: meta-comment on typing** - Previous by thread:
**Re: implementation categories, exact rationals** - Next by thread:
**Re: implementation categories, exact rationals** - Index(es):