[R] Logical inconsistency
Wacek Kusnierczyk
Waclaw.Marcin.Kusnierczyk at idi.ntnu.no
Sun Dec 7 21:09:36 CET 2008
Berwin A Turlach wrote:
> G'day Wacek,
>
g'evening.
> On Sat, 06 Dec 2008 10:49:24 +0100
> Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
>
> [....]
>
>>>> there is, in principle, no problem in having a high-level language
>>>> perform the computation in a logically consistent way.
>>>>
>>> Is this now supposed to be a "Radio Eriwan" joke? As another saying
>>> goes: in theory there is no difference between theory and practice,
>>> in practice there is.
>>>
>> no joke, sorry to disappoint you.
>>
>
> Apparently it is, you seem to be a comedian without knowing it. :)
>
> "Radio Eriwan" jokes are a class of jokes in which a question was posed
> to the announcer of "Radio Eriwan", a fictive radio station. The
> answer was always "In principle yes, but..." or "In principle no,
> but..."; the part that came after the but contradicted the initial
> answer. If you know a little bit of German, google for "Radio Eriwan"
> and you will find out more about these jokes.
>
>
c'mon, a person from central europe can't possibly be unaware of this
joke. i know of a 60-page book collecting radio erewan jokes. deadly
serious.
> So your posting would be a classical "Radio Eriwan" answer to a yet
> to specify question: "In principle, no problem of having a
> high-level language perform the computation in a logcally consistent
> way, but [...] i do not claim that r should implement arbitrary
> precision floating point arithmetic [and] if you have involving
> computations on floats it would make little sense to implement
> arbitrary precision."
>
> Classical Radio Eriwan stuff, and I thought this class of jokes have
> died out.....
>
apparently not, as long as there are people able to find them in
whatever they read.
>
>> [...] the point was, the user was surprised, and the answer pointed
>> her, if indirectly, to an article which is addressed to computer
>> scientists and discusses low-level representational details, but the
>> user was presumably interested in stats, not computer science. so
>> the answer felt like lacking a justification.
>>
>
> First, I think it is a rather ambitious jump in logic that a user is
> interested in stats because the user wants to see whether "8.3 - 7.3 >
> 1" is true. The only indication of the user being interested in
> stats would be that the user used R, which is used primarily for
> statistical analysis;
that was my reasoning, good god!
> though some people apparently use it also as a
> scripting language instead of Perl or Python.
oh my.
> If the user had typed
> this into matlab/octave/scilab/YouNameIt, would would you have thought
> that the user is interested in?
>
> Secondly, that the FAQ points to an article that is addressed to
> computer scientists is coincidental and not really of any importance.
> There is a Wiley & Sons book called "Numerical Issues in Statistical
> Computing for the Social Scientist", plenty of books on numerical
> analysis, plenty of books for numerical analysis or numerical linear
> algebra for statisticians that discuss issues that arise when you start
> to do calculations in finite precision arithmetic. You could probably
> write papers entitled "What Every XXXX Scientist Should Know About
> Floating-Point Arithmetic" for every possible XXXX. It just so happens
> that the article by Goldberg is one that is freely available on the
> internet and it is much better to point people to this article than to
> any of the myriads of books that exist on this topic but which they
> would first have to get from the library.
>
> If you know of any other freely available article that discusses these
> issues, and that you think is more appropriate for pointing useRs to,
> feel free to suggest to the FAQ maintainers to change the citation.
>
>
unfortunately, i only have quite a couple of books on the subject, none
of which is freely available. at least, not in a way their publishers
would gladly accept.
i'd agree that it's not a drawback to know how arithmetic is actually
done on computers (but hey, there is no unique standard here). but many
people i know (which certainly makes a poor statistic) would prefer to
be abstracted away from having to know that 8.8-7.8 > 1 is true, less so
why it is true.
>>> But you are wrong here, R performs logically *in the logic of finite
>>> precision arithmetic*. The problem is that you are using finite
>>> precision arithmetic but expect that the rules and logic of infinite
>>> precision arithmetic hold. If you want to use have infinite
>>> precision arithmetic, then use a tool that (supposedly) implements
>>> it.
>>>
>> well, it clearly depends what you regard as logical. you can have r
>> say '1==0' is true, and argue that it's correct by the logic adopted.
>>
>
> Either infinite precision arithmetic or finite precision arithmetic, in
> neither of this would "1==0" being true be logical.
>
not difficult at all to define an arithmetic where 1==0 is true,
document it in a man page, and refer to it when complaints come.
surely, an exotic example.
> Though, I once read that Kahan managed to get Mathematica to believe
> that 1==0. It must have been some time ago, so probably was an old
> version of Mathematica. Kahan started with two expressions that were
> logically, in infinite precision arithmetic, identical, so Mathematica
> agreed that they were the same. But when then asked to evaluate both
> expression numerically, Mathematica evaluated one expression to 1 and
> the other to 0 and, thus, started to believe that 1==0.
>
>
>> fine. the issue is, if you assume your users are statisticians, not
>> computer scientists, you should not be surprised the logic some of
>> them assume differs from the one you implement.
>>
>
> If I assume that my users are statisticians, then I would assume that
> they have learned during their training about finite precision
> arithmetic and know about these problems. Though, they might have
> forgotten about having learned about it..
i know of cs guys who either have forgotten, or have never learned (!).
assuming familiarity with these representational-computational issues
among statisticians seems a bit too strong to me, but i am not a
statistician myself, so it's easy to misjudge. you say.
vQ
More information about the R-help
mailing list