From p.dalgaard at biostat.ku.dk  Sat Sep 13 13:59:25 2003
From: p.dalgaard at biostat.ku.dk (Peter Dalgaard BSA)
Date: Sat Sep 13 14:59:30 2003
Subject: [Rd] bug or feature? (PR#4150)
In-Reply-To: <200309131137.h8DBbSJH021576@pubhealth.ku.dk>
References: <200309131137.h8DBbSJH021576@pubhealth.ku.dk>
Message-ID: <x2vfrw972c.fsf@biostat.ku.dk>

axel.benz@iao.fhg.de writes:

> Full_Name: Axel Benz
> Version: 1.7.1
> OS: Windows
> Submission from: (NULL) (137.251.33.43)
> 
> 
> This feature seems to be a basic bug:
> 
> > 1=="1"
> [1] TRUE
> > as.numeric(1)=="1"
> [1] TRUE
> > as.numeric(1)==as.character("1")
> [1] TRUE
> 
> isn't it necessary to distinguish beteen numbers and characters??

As Martin said recently, if in doubt don't file bug reports. This may
be strange, but it is S-compatible, even to the extent of cloning the
following little piece of weirdness:

S-PLUS : Copyright (c) 1988, 2000 MathSoft, Inc.
S : Copyright Lucent Technologies, Inc.
Version 6.0 Release 1 for Sun SPARC, SunOS 5.6 : 2000
Working data will be in /home/sfe/pd/MySwork
> "1"==1
[1] T
> "1"==T
[1] F
> 1==T
[1] T

The rule is that there is implicit coercion in the direction that
"always works", so the three cases above become

"1" == as.character(1)
"1" == as.character(T)
1 == as.numeric(T)

There are various other curious consequences of that rule:

> 1e-2=="0.01"
[1] TRUE
> 1e-2=="1e-2"
[1] FALSE
> "2"<10
[1] FALSE
> 2<"10"
[1] FALSE

but it *is* a feature and not a bug.
-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907


[Rd] bug or feature? (PR#4150)
Peter Dalgaard BSA