Skip to content

is.na(valid_date) too often true on SGI MIPS (PR#6814)

8 messages · Brian Ripley, George N. White III

#
Full_Name: George N. White III
Version: 1.9.0
OS: Irix 6.5.21m
Submission from: (NULL) (142.176.61.212)


R-1.9.0 built using the SGI MIPSPro compilers

  Installation directory:    /usr/local

  C compiler:                c99 -OPT:IEEE_NaN_inf=ON -mips4 -n32 -O3
-OPT:Olimit_opt=on
  C++ compiler:              CC -OPT:IEEE_NaN_inf=ON -mips4 -n32 -O3
-OPT:Olimit_opt=on -LANG:std
  Fortran compiler:          f90 -OPT:IEEE_NaN_inf=ON -mips4 -n32 -O3
-OPT:Olimit_opt=on

  Interfaces supported:      X11, gnome, tcltk
  External libraries:        readline, BLAS(generic), LAPACK(generic)
  Additional capabilities:   PNG, JPEG
  Options enabled:           shared library, R profiling

  Recommended packages:      yes

"make check" fails in 2 places due to is.na(..) returning TRUE for valid dates:
[1] TRUE
[1] "1910-01-01"
[1] FALSE
[1] "1970-01-01"

Incidentally:
[1] NA
[1] NaN
#
I'm sorry, but this is completely unreproducible, and the second you say 
is true you quote as false.

d is a list, so can you tell us unclass(d) in both cases?

Also, I cannot see those examples anywhere in the R sources so can you 
please show the actual output you got.
On Fri, 23 Apr 2004 aa056@chebucto.ns.ca wrote:

            

  
    
#
On Fri, 23 Apr 2004, Prof Brian Ripley wrote:

            
Not sure what you mean -- are you saying "make check" passes on
other Irix systems?
Sure -- they look OK to me:
$sec
[1] 0
$min
[1] 0
$hour
[1] 0
$mday
[1] 1
$mon
[1] 0
$year
[1] 10
$wday
[1] 6
$yday
[1] 0
$isdst
[1] -1
$sec
[1] 0
$min
[1] 0
$hour
[1] 0
$mday
[1] 1
$mon
[1] 0
$year
[1] 70
$wday
[1] 4
$yday
[1] 0
$isdst
[1] 0
My examples are based on as.POSIXlt from datetime.R.

Here are the relevant sections of the output from the tests (if I
comment out these sections in reg-tests-1.R and base-Ex.R then
"make check" runs fine):

$ cd ~/install/R/R-1.9.0/tests
gwhite@montigo:/user/gwhite/install/R/R-1.9.0/tests
$ gmake reg-tests-1.Rout
running code in 'reg-tests-1.R' ...gmake: *** [reg-tests-1.Rout] Error 1
$ tail -20 reg-tests-1.Rout.fail
+                  NA, paste(1:29," Feb. 1960", sep=".")),
+                format = "%d. %b. %Y"))
 [1] "1930-08-06" "1925-11-03" "1959-03-28" NA           "1960-02-01"
 [6] "1960-02-02" "1960-02-03" "1960-02-04" "1960-02-05" "1960-02-06"
[11] "1960-02-07" "1960-02-08" "1960-02-09" "1960-02-10" "1960-02-11"
[16] "1960-02-12" "1960-02-13" "1960-02-14" "1960-02-15" "1960-02-16"
[21] "1960-02-17" "1960-02-18" "1960-02-19" "1960-02-20" "1960-02-21"
[26] "1960-02-22" "1960-02-23" "1960-02-24" "1960-02-25" "1960-02-26"
[31] "1960-02-27" "1960-02-28" "1960-02-29"
+           s1== summary(as.POSIXct(t1)),
+           6 == length(print(format(as.Date(s1)))) )
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
     NA      NA      NA      NA      NA      NA
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
     NA      NA      NA      NA      NA      NA
Error in if (!(is.logical(r <- eval(ll[[i]])) && all(r))) stop(paste(deparse(mc[[i +  :
        missing value where TRUE/FALSE needed
Execution halted
$ cd Examples
$ gmake base-Ex.Rout
running code in 'base-Ex.R' ...
Execution halted
$ tail -4 base-Ex.Rout.fail
Error in fromchar(x) : character string is not in a standard unambiguous format
Execution halted
--
George N. White III  <aa056@chebucto.ns.ca>
  Head of St. Margarets Bay, Nova Scotia, Canada
#
On Fri, 23 Apr 2004, George N. White III wrote:

            
We don't have an Irix system on which they fail _AND_ your examples 
are not in the R sources. N.B. as.Date and is.na(strptime()) are not the 
same code, and your second example is still not explained.

However, you reported to R bugs, not to Irix bugs, and no other R system 
has shown this behaviour.  So the finger is pointing elsewhere.

  
    
#
On Fri, 23 Apr 2004, Prof Brian Ripley wrote:

            
I assume the second example refers to the NA+NaN vs NaN+NA, evidence that
the system is not doing arithmetic the same way it is done by mainstream
platforms.
It would be surprising if this isn't another of many SGI foibles, but the
sad reality is that SGI goes their own way and you either find a way to
live with them or switch to a less idiosyncratic platform.  I'd be
grateful for a hint as to which compilers/options work for Irix.

SGI doesn't compete in the mainstream market, and would certainly be out
of business if it was easy to move code between Irix and the mainstream --
the only reason we continue to use Irix is legacy applications created on
Irix.

--
George N. White III  <aa056@chebucto.ns.ca>
  Head of St. Margarets Bay, Nova Scotia, Canada
#
On Sat, 24 Apr 2004, George N. White III wrote:

            
No. You claimed `"make check" fails in 2 places' and said the second was
[1] FALSE
[1] "1970-01-01"

and that is not an example of
dates:

since 

1) It is not in make check  (nor is your first example)
2) The date is valid
3) is.na returns FALSE.

In short, I cannot see anything wrong about that example, and it 
seems it is you and not Irix and not R who has a problem with it.
4 days later
#
On Fri, 23 Apr 2004, Prof Brian Ripley wrote:

            
I apologize for wasting your time.

The reason "make check" failed is because I somehow thought that SGI had
adopted Arthur Olson's tz data <ftp://elsie.nci.nih.gov/pub/> (see also:
<http://cspry.co.uk/computing/Indy_admin/TIMEZONE.html>).

After installing Olson's tz library and data and
adding '-L/usr/local/lib -ltz' to the list of libraries,
"make check" succeeds.

It would be helpful to sprinkle a few reminders of the existence of
Olson's data in the documentation.

--
George N. White III  <aa056@chebucto.ns.ca>
  Head of St. Margarets Bay, Nova Scotia, Canada
#
On Wed, 28 Apr 2004, George N. White III wrote:

            
database in the "feature" stream (e.g., 6.5.Nf, N>2).  The machines I use
have 6.5.19m and 6.5.21m, but two systems with 6.5.22m have Olsen's
database (see: "man zdump").

$ /sbin/uname -aR
IRIX64 [...] 6.5 6.5.22m 10070055 IP30
$ showfiles eoe.sw.base | grep TZ
f 11649 20003 eoe.sw.base             usr/lib/locale/TZ/africa
f 45578 26997 eoe.sw.base             usr/lib/locale/TZ/asia
f 11309 27954 eoe.sw.base             usr/lib/locale/TZ/australasia
f 56271  2985 eoe.sw.base             usr/lib/locale/TZ/backward
f 37003  1687 eoe.sw.base             usr/lib/locale/TZ/etcetera
f 21755 88582 eoe.sw.base             usr/lib/locale/TZ/europe
f 38515   311 eoe.sw.base             usr/lib/locale/TZ/factory
f 25667 35826 eoe.sw.base             usr/lib/locale/TZ/northamerica
f  4425  1107 eoe.sw.base             usr/lib/locale/TZ/pacificnew
f 15976 19159 eoe.sw.base             usr/lib/locale/TZ/solar87
f 39829 19177 eoe.sw.base             usr/lib/locale/TZ/solar88
f 32211 19453 eoe.sw.base             usr/lib/locale/TZ/solar89
f 29073 15106 eoe.sw.base             usr/lib/locale/TZ/southamerica

I can't seem to find this mentioned in the announcments, so I'm not
sure if these two systems were switched from "f" to "m" at some
point or if SGI put a little gift into 6.5.22m.  I suppose
configure needs to check for a decent tz database, but maybe it
is enough to add a little note to the Irix section of the install.

--
George N. White III  <aa056@chebucto.ns.ca>
  Head of St. Margarets Bay, Nova Scotia, Canada