[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*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: Arithmetic issues*From*: Alan Watson <a.watson@xxxxxxxxxxxxxxxx>*Date*: Fri, 28 Oct 2005 12:36:05 -0700*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <43626CE4.4060703@xxxxxxxxxxx>*Organization*: Centro de Radioastronomía y Astrofísica UNAM*References*: <y9lzmp775oz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20051018173639.GC13524@NYCMJCOWA2> <43626CE4.4060703@xxxxxxxxxxx>*User-agent*: Mozilla Thunderbird 1.0 (X11/20050317)

* The main problem with banishing the full tower to a library is that read, write, and several other procedures must know about the external representations of all numbers.

* Should a minimum precision be required for fixnums or flonums?

* Should the range of a fixnum be restricted to a power of two? To a two's complement range?

* The fixnum operations provide efficient fixnums that "wrap." However, they do not give efficient access to the hardware facilities for carry and overflow. This would be desirable to implement efficient generic arithmetic on fixnums portably. On the other hand, there isn't much experience with formulating a portable interface to these facilities.

* Should the binary fixnum/flonum operations allow other than two arguments? Yes. * What are the semantics of "safe mode" and "unsafe mode"? Perhaps leave the semantics of "unsafe mode" to the implementation? * Should R6RS allow other inexact reals beside the flonums? At the very least, it must allow for different types of flonums. * Should the R5RS procedures for generic arithmetic (e.g. +) remain in R6RS? If R6RS does not adopt a R5RS-style model for the generic arithmetic, should it still provide more R5RS-compatible generic arithmetic as a library?

* Given that this SRFI suggests requiring all implementations to support the general complex numbers, should abs (and exabs and inabs) be removed? No. * The real?, rational?, and integer? predicates must return false for complex numbers with an imaginary part of inexact zero, as non-realness is now contagious. This causes possibly unexpected behavior: `(zero? 0+0.0i)' returns true despite `(integer? 0+0.0i)' returning false. Possibly, new predicates realistic?, rationalistic?, and integral? should be added to say that a number can be coerced to the specified type (and back) without loss.

Maybe call them realish? rationalish? and integralish? :-) * The fixnum, flonum, and inexact arithmetic come with a full deck of operations, including some that are defined in terms of integers (such as quotient+remainder, gcd and lcm), and others that are easily abused (such as fxabs). Should these be pruned? How can fxabs be abused?

the number, respectively. Should R6RS mandate the presence of such a representation (while allowing additional alternative representations), thus allowing it to more meaningfully discuss semantic issues such as branch cuts? Yes.

IEEE extended precision. Are there any such implementations? Do we expect such implementations in the near future? Others have said yes. I have nothing to add. * Should `(floor +inf.0)' return +inf.0 or signal an error instead? The former. * The bitwise operations operate on exact integers only. Should they live in the section on exact arithmetic? Should they carry ex prefixes? Or should they be extended to work on inexact integers as well? No. No. How/why? * The division between regular procedures and library procedures is somewhat arbitrary.

Regards, Alan -- Dr Alan Watson Centro de Radioastronomía y Astrofísica Universidad Astronómico Nacional de México

**Follow-Ups**:**Re: Arithmetic issues***From:*Bradley Lucier

**References**:**Arithmetic issues***From:*Michael Sperber

**Re: Arithmetic issues***From:*John.Cowan

**Re: Arithmetic issues***From:*Per Bothner

- Prev by Date:
**Re: Arithmetic issues** - Next by Date:
**Re: Arithmetic issues** - Previous by thread:
**Re: Arithmetic issues** - Next by thread:
**Re: Arithmetic issues** - Index(es):