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

*To*: Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx>*Subject*: Re: Unifying the two generic arithmetic alternatives*From*: bear <bear@xxxxxxxxx>*Date*: Tue, 15 Nov 2005 02:11:37 -0800 (PST)*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051115001633.49A59600037@xxxxxxxxxxxxxxxxxxxxxxx>*References*: <20051115001633.49A59600037@xxxxxxxxxxxxxxxxxxxxxxx>

On Mon, 14 Nov 2005, Andrew Wilcox wrote: >Here's an idea that I hope will help unify the competing alternatives >of R5RS-style Generic Arithmetic and Generic Exact Arithmetic. > >My proposal has contagious inexactness, while also offering generic >procedures that perform the same operation across different types. Proposal consists of 'fast' operations which are guaranteed to not spend a lot of time but which are likely to give inexact results on exact arguments, and 'accurate' arguments which are guaranteed not to cause a further loss of precision but still give exact results only when arguments whose exactness may affect the outcome of the operation are exact. This is a more principled approach than we now have. And yes, it does make things expressible that aren't expressible in R5RS. I think most implementors are going to dislike it because it means they have to treat exactness as a bit independent from the representation format. "inexact" would no longer mean "float format" if it had to be possible to provide accurate ops on inexact numbers and have them give arbitrarily precise inexact results. I think that this would be a step forward in terms of letting programmers say what they mean, but it would almost certainly slow mathematics down (even so-called "fast" operations) in every scheme where it was implemented. But honestly, I think that we're not really going to have an adequate solution for this problem until the precision to which each number is known is part of the semantics of the language. Not just a bit to say whether that precision is "infinite" or not. The idea of inexact booleans keeps coming up, because they are the correct result of a comparison of inexact numbers. But as others here have said, you can't really have inexact control flow, which inexact booleans imply. One response is to keep track of where control flow is based on an inexact expression, and coerce results from such expressions to inexact, thus enforcing a more complete contagion of inexactness across expressions. And this is a more consistent and disciplined approach to inexactness than we have now. But this has disturbing implications that I think most people aren't ready to embrace; namely, inexact strings and symbols. These entities are part of a rigorous theory of exactness, but I don't think people are willing to have such entities in their computing languages at this time. There seem to be no pressing engineering problem that they solve in a way that people find satisfactory. Bear

**References**:**Unifying the two generic arithmetic alternatives***From:*Andrew Wilcox

- Prev by Date:
**Re: Unifying the two generic arithmetic alternatives** - Next by Date:
**Re: Unifying the two generic arithmetic alternatives** - Previous by thread:
**Re: Unifying the two generic arithmetic alternatives** - Next by thread:
**Re: Unifying the two generic arithmetic alternatives** - Index(es):