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

*To*: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*Subject*: Re: Arithmetic issues*From*: Per Bothner <per@xxxxxxxxxxx>*Date*: Fri, 28 Oct 2005 11:24:36 -0700*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051018173639.GC13524@NYCMJCOWA2>*References*: <y9lzmp775oz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20051018173639.GC13524@NYCMJCOWA2>*User-agent*: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)

Michael Sperber wrote:

Now, the Issues section in the SRFI is pretty long. We were hoping to get some feedback on where people stand on these issues, so it'd be great if you could see it as some kind of questionnaire and just fireoff your position on the issues where you have one.

No strong opinion. However, an application shouldn't have to use diffeent arithmetic operators depending on whether they're sticking to the core language, or using the full tower. I.e. I'd like to use + porably either way. Also don't overspecify flonums - an implementation might want to only or by default use arbitrary-precision decimal arithmetic, for example. * Should a minimum precision be required for fixnums or flonums? I think it is reasonable to require 24-bit (or 28-bit?) fixnums. flonums are trickier to specify.

Well, I'm somewhat dubious of the concept of fixnum and especially a single fixnum type. Sure, if here is a reason for it. * Should the binary fixnum/flonum operations allow other than two arguments? Probably, just to avoid an confusing special case. * Should R6RS allow other inexact reals beside the flonums? Well, R6RS should allow more that type type of inexact real. An implementation might and one or more precisions of IEEE floating point and perhaps decimal arithmetic.

Yes: 4. + is defined as in R5RS.

Don't remove abs - it's shorter and beter-known than magnitude.

That seems worthwhile.

Yes, for the latter: http://www2.hursley.ibm.com/decimal/ * Should `(floor +inf.0)' return +inf.0 or signal an error instead? Former.

No. No. How/why?

Agree - get rid of it. (Ditto for "syntax" vs "library syntax".) -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/

**Follow-Ups**:**Re: Arithmetic issues***From:*Alan Watson

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

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

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