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

Re: Exactness

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.

Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx> writes:

> Thomas Bushnell BSG <tb@xxxxxxxxxx> writes:
>>> Why not the other way around: that the default behavior is known,
>>> and implementations may provide other fancy choices which must be
>>> turned on explicitly?
>> Nope.  We should maintain consistency over time in the meanings of the
>> functions.  It is not a decent idea to have the next RnRS standard
>> specify addition in a way which is fundamentally incompatible with its
>> predecessors.
> It's compatible with existing practice.

It's not.  There may actually be programs out there that depend on
exact division doing the mathematically right thing.  You want to
break them all?

> (The difference between fixnums and bignums should not be exposed
> except perhaps by some weird functions used as an efficiency hack.
> Other representations are important though.)

See, this is where you're wrong.  Constant-width addition is valuable
for integers too, not just floats.  But when people doing integer
arithmetic want that, it's an "efficiency hack", and when you want it
for floating point, it's Absolutely Essential.

Very well, I agree.  It *is* essential.  So, let's discuss the best
way to provide it, rather than this silly discussion.

I think the best way to provide it is by functions that cleary specify
which behavior they get, preserving backward compatibility with the
existing standard.