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.
Thomas Bushnell BSG <tb@xxxxxxxxxx> writes: > (with-ieee-floating-point ...) can just be syntactic sugar for a > specification of whatever options is the right set. Let's make this the default, so users know what to expect, and introduce options for hypothetical other interpretations. > Oh, I think it's already agreed that Scheme should not be mandated > to support floating point arithmetic. I can agree with this only in the sense that Scheme implementations may implement a subset of the numeric tower. I don't see the point in allowing other interpretations of the default inexact syntax. Less common formats should be chosen explicitly. > At least, I can see no advantage to such a mandate. It standarizes the status quo, so programs which rely on inexact numbers being floats are not only working in practice but also formally portable. > Do you think that mandating it will somehow change anyone's behavior > materially? No, because people already rely on it. The very example program in R5RS would make little sense if .01 meant "1/100 with the inexact bit set" and the computation was performed on vulgar fractions. > You must stop thinking of "inexact" as a synonym for "floating > point". Please. Why? Isn't it true in practice? Which implementations make some other format the default for inexact numbers? Other languages see no problem with that. Common Lisp, Haskell, the C family, Python, and probably many others not only do this in practice but have this specified in the language definition. The concept of floating point was designed a long time ago. It's not some fancy new idea which might become fashionable for a while and then go away. Hardware is converging to it, not diverging. I'm open to libraries which provide other kinds of inexact numbers. Just not make them the default, because program relying on them would be much less portable than programs relying on flonums. > I do not think that any particular combination should be mandated, > much less mandating all possible combinations. Those which do not > support them (or some combination of them) should be required to > document their behavior and behave sensibly when the cannot > implement something. So programs can only give hints, they can't rely on availability of any particular properties? Well, in this area I prefer programming based on confidence than hope. While I dislike lots of things about Java, one thing was successful: lots of core operations have well-defined meaning and work the same way everywhere. It's bad to standarize on something which is a temporary limitation of current computers and is likely to change in future. Floating point doesn't look like this. > Trig functions most certainly can be computed exactly if you have a > clever enough implementation. You aren't thinking correctly here, > because you are wedded to implementation issues. It is perfectly > possible to implement exacts reals, and make the trig functions > compute exact answers. (Have you ever played with maxima?) Scheme is not a CAS. Fancy representations are OK as long as they are not the default. Programming should be predictable. Is there any existing Scheme implementation with exact irrational numbers? Anyway, you can ignore the "(e.g. trigonometric)" part of my question. The rest of the question stands. > Perhaps we could insist on neither, and give programmers the option of > specifying the precision, and then implementations which can comply > will do so, and the others will either signal an error or (at user > preference) do the best they can. Again programming based on hope... > How to print a number is an entirely separate question from its > representation. Agreed. > For example, on a system with exact reals, the system might know > that the value of some computation is 2π; what should happen when > it's printed? Well, if it printed this as the result of (* 8 (atan 1)), then any other program reading its data would be surprised. I would prefer that a given Scheme implementation doesn't use non-standard output notation by default. >> 4. What should happen when the number being computed is getting too >> large to be conveniently represented? Return "infinity"? Signal an >> error? How an infinity is formatted into text? > > As Alan Watson pointed out, this is simply a normal case of memory > exhaustion and does not need to be discussed separately. It's a case of memory exhaustion only in the context of exact numbers. For inexact numbers you might argue that such interpretation is right too, but users will say that that it's broken and switch to others. >> 9. Should the implementation try to track inexactness of real and >> imaginary part separately, or we don't care? If the imaginary part >> comes very close to 0, should the result be indistinguishable from >> a real number, or we care about being sure whether it's real or not? > > This is an ongoing difficulty for some people. The answer is > certainly "no", it should not be tracked differently, but that's > because I think of complex numbers as numbers, not as pairs of > numbers. This philosophical standpoint doesn't explain the practical issue. It's a false dichotomy: I treat complex numbers as numbers which are isomorphic to pairs of real numbers. Both interpretations are true at the same time. Consider these numbers: -5.0 -5.0+0i -5.0-0i -5.0+0.0i -5.0-0.0i Which of them should be indistinguishable (eqv?)? FP experts would be upset if the last two were the same. (angle -5.0+0.0i) is pi, (angle -5.0-0.0i) is -pi. In my interpretation the first three are the same, other two are different from the first three and from each other. In the strict reading of R5RS all are eqv?, even though some of them can be distinguishable by arithmetic operations. This is bad, eqv? should not unify distinguishable values (this doesn't apply to distinguishing with eq?); the error is in the definition of eqv? in terms of = and exactness. It breaks also for 0.0 vs. -0.0 and 3s0 vs. 3L0. >> 10. When we ask whether the number is even, and it happens to be >> inexact, should the implementation try to answer hoping that >> inexactness did not change the value, or we prefer an error to be >> signalled? > > Perhaps we need two functions! I would be happy in making this an error. Currently it's required to answer if it looks like integer (inexactly). Even though whether it looks like integer depends on the inaccuracy introduced during computation. It's bad when the validity of a procedure call depends on floating point accuracy. That's why IEEE fp produces infinities and NaNs by default; they don't always result from arguments truly outside the domain, but from arguments which have slipped outside after rounding to fp precision. Aubrey Jaffer <agj@xxxxxxxxxxxx> writes: > Were the finiteness predicates left out of srfi-77 accidentally? I don't know. It's clear however that the semantics of R5RS predicates is unclear in the presence of special fp numbers. Are +inf.0 and +nan.0 real? Are they allowed as real and imaginary parts of complex numbers? Since the latter should be true (operations on complex number can easily produce them), I think the former should be true as well. They should not be rational? though. The questions about domains are intrinsically poorly defined for inexact numbers. That's why thinking in terms of representations is often more practical. > But mixed exactness spawns many senseless combinations. What does > 1.23+5i represent? What is senseless about it? It's a number whose real part is not known exactly (the computation has determined that it's about 1.23) but its imaginary part is 5 for sure. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/