[R] Logical inconsistency
Wacek Kusnierczyk
Waclaw.Marcin.Kusnierczyk at idi.ntnu.no
Sat Dec 6 22:32:09 CET 2008
Stavros Macrakis wrote:
> On Sat, Dec 6, 2008 at 5:02 AM, Wacek Kusnierczyk <
> Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
>
>
>> yepp, though (2/3)*3 not evaluating to 2 is again not a must, is it.
>>
>
>
> Why is that less a must than .3-.2 == .1? On the contrary, the computing
> convention (and for that matter the usual scientific and engineering
> convention) is that a decimal point signals an approximate number.
>
not a must, since no floating point arithmetic has to be involved here.
>
>
>> you know scheme would say (* (/ 2 3) 3) is 2
>>
>
>
> Yes, Scheme uses rational arithmetic.
>
>
>
>> , and similarly for (* (/ 2.0 3.0) 3.0)
>>
>
>
> Yes, Scheme uses standard (correctly rounded) IEEE floating point, but of
> course other cases like 15.0/22.0*22.0 are not exact.
>
(* (/ 2.0 3.0) 3.0) is not exact either, as aren't (* (/ 2.0 2.0) 2.0)
and 2.0; this was a teaser ;)
>
>
>> ...it's all about representations, but representations are typically below
>> the interface. i did not complain, or troll, about r not implementing
>> arbitrary precision, just remarked that the example and its explanation
>> expose a user to the internals.
>>
>
>
> No, I don't think that's the correct way to think about it. I believe that
> the R spec says (or should say) that "numeric" means IEEE double-precision
> floats, with all that that entails: range restrictions, precision, rounding
> rules, NaNs, etc.
>
maybe.
>
>
>> ...original question about 8.8-7.8 not being 1. the result is finely
>> explained by reference to the underlying representation, but this does break
>> the assumption of isolation from underlying details, claimed here once upon
>> a time.
>>
>>
>
> Sounds like a pretty naive claim for a language which after all doesn't even
> have a formal definition (besides the implementation). Not that formal
> definitions are a panacea -- having been a "language lawyer" in a compiler
> group many years ago, I can attest that they are not (but that is a
> different, long discussion).
>
to be fair to the referred to post, it went:
"One of the key design features of R is that it hides implementation
details from users. They are free to think about the substantive issues
with their data rather than worrying about computational trivia."
vQ
More information about the R-help
mailing list