[R] Logical inconsistency

[Wacek Kusnierczyk]

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