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.
I wrote:
> > Note that a floating point number (aside from INF and NaN) represents
> > one and precisely one rational number. Thus to perform an accurate
> > calculation with a flonum, we simply use its actual value.
John Cowan writes:
> the result of flonum addition interpreted as a rational number is *not*
> accurate.
You are correct. However, my wording must be unclear. I am not
suggesting that accurate calculations can be performed with flonum
operations. Can anyone help me out here? I read what I wrote, and it
seems to me to say what I meant. I do not know how to reword it so
that other people will not find it confusing.
John Cowan writes:
> Indeed, even without control flow as such the idea is bizarre. If x
> and y are inexact numbers, is the value of (if (< x y) "foo" "bar")
> an inexact string?
Yes. Each rational number represents one and only one number, each
string represents one and only one string. Your result is flagged as
having been calculated using approximate operations.
I wrote:
> > FAST+ always performs a fast (if perhaps inaccurate) operation --
> > returning a flonum, or a complex number made up of flonums.
John Cowan writes:
> Why a flonum? Addition of two fixnums with no overflow should be
> able to return a fixnum, no?
I agree.
Bear writes:
> 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.
No doubt.
A lot of implementors don't like CALL-WITH-CURRENT-CONTINUATION
either.
So?
Bear writes:
> 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.
What is the problem that you'd like to solve?
Bear writes:
> There seem to be no pressing engineering problem that [inexact
> strings and symbols] solve in a way that people find satisfactory.
I'm not going to advocate that contagious inexactness be a part of
R6RS. However I will point out:
* Some people want contagious inexactness.
* Some people want it badly enough that they support R5RS style
generic arithmetic, despite its well known problems.
I do argue that if contagious inexactness is going to be in R6RS, it
should:
* be done correctly
* avoid pedagogic confusion in the classrom
* not lead to pernicious bugs in production software
Bear writes:
> This has disturbing implications that I think most people aren't
> ready to embrace; namely, inexact strings and symbols.
This is a terminology issue. There's nothing distrurbing about being
given the result of a calculation and also being told that it is not
guaranteed to be accurate or reproducible, having been derived from
approximate operations.
The problem is that people are used to thinking of *numbers* as being
inexact, and then in that mindset saying that's it's nonsensical for
strings and symbols to be inexact. However, with flonums it's not the
*number* that's inexact, it's the flonum *operations* that are
inexact.
Would using a different terminology would help people understand the
concepts more easily? I'm not tied to "EXACT?" and "ACCURATE+" as
wording.
From the responses so far,
(exact? "a string")
appears to be immediately confusing to most people.
Thanks,
Andrew