Re: [Rd] Free-form to fixed-form Fortran
Not knowing exactly what you mean by Free-form Fortran I couldn't say for sure, but perhaps ratfor will do the job. Worth trying, I would think. -Don At 4:36 PM +0200 8/26/05, =?iso-8859-2?Q?Ale=B9_=AEiberna?= wrote: >Hello! > >I have writen some subrutines in Free-form Fortran. I would like to includ >them in a package, which I would like to build on WinXP. I have all >suggested tools/programs for bulding R packages on Windows (except latex). > >What is the best way of using these subrutines? Does sombody mybe know any >translation tools for converting Free-form to fixed-form Fortran? > >Thanks for any suggestions, >Ales Ziberna > >__ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rounding the time: significant 0 does not appear (PR#14074)
This is not a bug, and has nothing to do with times. For example: round(1.03,1) [1] 1 Formatting is not the same as rounding. Perhaps you are assuming R formats numbers according to the concept of significant digits, but it doesn't. See the help page for the format function to get started with understanding R's rules for formatting numbers when it displays them. Maybe also some of the introductory R documents available on CRAN. -Don At 3:45 AM +0100 11/20/09, gus1...@optimizelife.com wrote: Full_Name: Gustavo Lacerda Version: 2.9.1 OS: Windows Submission from: (NULL) (137.82.157.97) I obtained 'time' by subtracting the results of two calls to sys.Time(). round(time,0) Time difference of 1 mins round(time,1) Time difference of 1 mins round(time,2) Time difference of 1.03 mins round(time,3) Time difference of 1.032 mins Note that the second command above should return "1.0 mins", rather than "1 min". __ R-devel@r-project.org mailing list https://*stat.ethz.ch/mailman/listinfo/r-devel -- ----- Don MacQueen Lawrence Livermore National Laboratory Livermore, CA, USA 925-423-1062 m...@llnl.gov __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] order() fails on a chr object of class "AsIs" with "\265" in it
Here's an example (session info at the end).
tmpv <- c('\265g/L','Bq/L')
order(tmpv)
[1] 2 1
tmpv <- I(tmpv)
order(tmpv)
Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed
foov <- gsub('\265','',tmpv)
order(foov)
[1] 2 1
str(tmpv)
Class 'AsIs' chr [1:2] "\265g/L" "Bq/L"
str(foov)
Class 'AsIs' chr [1:2] "g/L" "Bq/L"
I can easily work around this in my scripts, but shouldn't order()
succeed with such an object?
(I suppose this could be Mac-specific, but I'm assuming it's not...)
For context:
The character "\265" causes the Greek letter mu to be displayed in
various output devices. For example, the character vector eventually
gets written to an html file, which when displayed in Firefox (Mac)
is displayed as Greek mu. Also in Excel 2004 (Mac).
I first wrote these scripts 6 years ago, when "\265" was a way I
could find to display the Greek mu in output text files of various
kinds. They worked as recently as 3 months ago. Maybe there's a
better way now to display a mu in text-based contexts?
sessionInfo()
R version 2.10.1 (2009-12-14)
i386-apple-darwin8.11.1
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thanks
-Don
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] order() fails on a chr object of class "AsIs" with "\265" in it
Prof. Ripley,
Thank you for the explanation. I appreciate both understanding what's
happening, and having several options for fixing my scripts.
-Don
At 7:17 AM + 1/16/10, Prof Brian Ripley wrote:
On Fri, 15 Jan 2010, Don MacQueen wrote:
Here's an example (session info at the end).
tmpv <- c('\265g/L','Bq/L')
order(tmpv)
[1] 2 1
tmpv <- I(tmpv)
order(tmpv)
Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed
foov <- gsub('\265','',tmpv)
order(foov)
[1] 2 1
str(tmpv)
Class 'AsIs' chr [1:2] "\265g/L" "Bq/L"
str(foov)
Class 'AsIs' chr [1:2] "g/L" "Bq/L"
I can easily work around this in my scripts, but shouldn't order()
succeed with such an object?
Not in the C locale. There is no pre-defined ordering for non-ASCII
characters in that locale and the string is invalid in a strict C
locale.
(I suppose this could be Mac-specific, but I'm assuming it's not...)
No, but the handling of invalid strings in C is OS-specific.
For context:
The character "\265" causes the Greek letter mu to be displayed in
various output devices. For example, the character vector
eventually gets written to an html file, which when displayed in
Firefox (Mac) is displayed as Greek mu. Also in Excel 2004 (Mac).
I first wrote these scripts 6 years ago, when "\265" was a way I
could find to display the Greek mu in output text files of various
kinds. They worked as recently as 3 months ago. Maybe there's a
better way now to display a mu in text-based contexts?
Use UTF-8 and Unicode \u03BC (http://*www.*alanwood.net/unicode/greek.html).
The issue is that you need a xtfrm method for 'AsIs': it falls back
to comparisons via .gt and those (correctly) fail.
xtfrm.AsIs <- function(x) xtfrm(unclass(x))
would keep get you going until you fix the scripts.
sessionInfo()
R version 2.10.1 (2009-12-14)
i386-apple-darwin8.11.1
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thanks
-Don
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://*stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://*www.*stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] FYI: issue with arpa/inet.h on SunOS 5.9 (old gcc?)
This just information of my experience installing R on SunOS 5.9 today, not a request for help. (in case anyone cares, and if not, I apologize for the distraction) I am building R 2.6.0 (patched; svn revision 43319, 2007-11-01) and encountered the problem described below. I believe the problem is an old gcc (version 3.0.4, built some 5 years ago), because the warnings do not occur when I specify CC = cc in the environment before configuring, and building R succeeds. Hence I'm mailing to r-devel instead of r-bugs, as suggested in the warning messages. I don't have much information about the cc I used (I'm not the sysadmin of this or any Solaris machine), other than it resides in /opt/SUNWspro, and appears to be part of "Sun Studio 11", whatever that is. The messages from R's configure were: configure: WARNING: arpa/inet.h: present but cannot be compiled configure: WARNING: arpa/inet.h: check for missing prerequisite headers? configure: WARNING: arpa/inet.h: see the Autoconf documentation configure: WARNING: arpa/inet.h: section "Present But Cannot Be Compiled" configure: WARNING: arpa/inet.h: proceeding with the preprocessor's result configure: WARNING: arpa/inet.h: in the future, the compiler will take precedence configure: WARNING: ## --- ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## --- ## And then the same set of warnings for netdb.h netinet/in.h sys/socket.h At the very end configure reports: configure: WARNING: could not determine type of socket length Then, make fails with: In file included from /usr/include/netinet/in.h:41, from /usr/include/netdb.h:98, from ../../../R-patched/src/main/platform.c:1586: /usr/include/sys/stream.h:307: parse error before "projid_t" make[3]: *** [platform.o] Error 1 make[3]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' make[2]: *** [R] Error 2 make[2]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' make[1]: *** [R] Error 1 make[1]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src' make: *** [R] Error 1 -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA 925-423-1062 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FYI: issue with arpa/inet.h on SunOS 5.9 (old gcc?)
Of course. It was built for Solaris 2.7. (I did look at R-admin, but not carefully and thoroughly enough.) Thank you. -Don At 7:33 AM + 11/6/07, Prof Brian Ripley wrote: >What OS was that compiler built for? This happened when you had a >version of gcc built for the wrong version of the OS, as gcc >captures system headers. (There's a warning about that in the >R-admin manual.) > >The 'report to' message is autogenerated by autoconf. > >SunStudio 11 is a recent version of Sun's compilers, and much to be >preferred to gcc 3.0.4 on that platform (and probably to any version >of gcc there). > >On Mon, 5 Nov 2007, Don MacQueen wrote: > >>This just information of my experience installing R on SunOS 5.9 >>today, not a request for help. >>(in case anyone cares, and if not, I apologize for the distraction) >> >>I am building R 2.6.0 (patched; svn revision 43319, 2007-11-01) and >>encountered the problem described below. >> >>I believe the problem is an old gcc (version 3.0.4, built some 5 >>years ago), because the warnings do not occur when I specify >>CC = cc >>in the environment before configuring, and building R succeeds. >> >>Hence I'm mailing to r-devel instead of r-bugs, as suggested in the >>warning messages. >> >>I don't have much information about the cc I used (I'm not the >>sysadmin of this or any Solaris machine), other than it resides in >>/opt/SUNWspro, and appears to be part of "Sun Studio 11", whatever >>that is. >> >> >>The messages from R's configure were: >> >>configure: WARNING: arpa/inet.h: present but cannot be compiled >>configure: WARNING: arpa/inet.h: check for missing prerequisite headers? >>configure: WARNING: arpa/inet.h: see the Autoconf documentation >>configure: WARNING: arpa/inet.h: section "Present But Cannot Be Compiled" >>configure: WARNING: arpa/inet.h: proceeding with the preprocessor's result >>configure: WARNING: arpa/inet.h: in the future, the compiler will >>take precedence >>configure: WARNING: ## --- ## >>configure: WARNING: ## Report this to [EMAIL PROTECTED] ## >>configure: WARNING: ## --- ## >> >>And then the same set of warnings for >> netdb.h >> netinet/in.h >> sys/socket.h >> >>At the very end configure reports: >> >>configure: WARNING: could not determine type of socket length >> >> >>Then, make fails with: >> >>In file included from /usr/include/netinet/in.h:41, >> from /usr/include/netdb.h:98, >> from ../../../R-patched/src/main/platform.c:1586: >>/usr/include/sys/stream.h:307: parse error before "projid_t" >>make[3]: *** [platform.o] Error 1 >>make[3]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' >>make[2]: *** [R] Error 2 >>make[2]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src/main' >>make[1]: *** [R] Error 1 >>make[1]: Leaving directory `/apps/kosapps/R/R-2.6.0/build/src' >>make: *** [R] Error 1 >> > >-- >Brian D. Ripley, [EMAIL PROTECTED] >Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ >University of Oxford, Tel: +44 1865 272861 (self) >1 South Parks Road, +44 1865 272866 (PA) >Oxford OX1 3TG, UKFax: +44 1865 272595 -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA 925-423-1062 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.POSIX{ct,lt} fail on class "AsIs"
(I think this is probably appropriate for r-devel -- if my diagnosis
is correct, that is)
I have a script that I run infrequently (i.e., quarterly) that has
been working for several years. I re-ran it this morning for the
first time since updating R from 2.6.2 to 2.7.0, and encountered an
error.
I found a simple example that shows the problem:
as.POSIXct( I( '2008-01-01' ) )
Error in as.POSIXlt.default(x, tz, ...) :
do not know how to convert 'x' to class "POSIXlt"
traceback()
6: stop(gettextf("do not know how to convert '%s' to class \"POSIXlt\"",
deparse(substitute(x
5: as.POSIXlt.default(x, tz, ...)
4: as.POSIXlt(x, tz, ...)
3: as.POSIXct(as.POSIXlt(x, tz, ...), tz, ...)
2: as.POSIXct.default(I("2008-01-01"))
1: as.POSIXct(I("2008-01-01"))
class( I('2008-01-01') )
[1] "AsIs"
is.character( I('2008-01-01') )
[1] TRUE
It looks to me as though as.POSIXlt() does not recognize the object
as being also a character object
because it calls as.POSIXlt.default() instead of as.POSIXlt.character().
sessionInfo()
R version 2.7.0 (2008-04-22)
powerpc-apple-darwin8.10.1
locale:
C
attached base packages:
[1] utils stats graphics grDevices methods base
I have done some searching in r-help, r-devel, and NEWS through 2.8
Series News and not found anything that I recognized as either a fix
or an indication this is intended behavior. (Doesn't mean it isn't
there, of course...)
By way of background, I sometimes use the class "AsIs" for the reason
described in?AsIs, i.e.,
"Protecting an object by enclosing it in 'I()' in a call to
'data.frame' inhibits the conversion of character vectors to
factors..."
and that's what led to this discovery.
Thanks
-Don
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Request for consideration of small change to R documentation file names
I hesitate to spend R-core's time with such a small request, but here goes. On the Manuals page of CRAN one can download the primary R documentation in PDF format. All of the files but one have names beginning with "R-". The exception is the R Reference Index (fullrefman.pdf). This means that after downloading, all of the files but one appear together in a directory listing. It would be convenient if *all* of them appeared together. Hence, I'm requesting that R-core consider changing the name "fullrefman.pdf" to "R-fullrefman.pdf". In the interest of saving time, I don't need an email response to this request. The decision will become apparent next time I download the documentation, which I do after every update to R. Thank you, -Don -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA 925-423-1062 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] row.names in data.frame
This looks like a good proposal to me, from an end-user's point of view. I have, from time to time, wished I could set row names to NULL. Not for performance reasons, but because some aspect of my data, in combination with how R handles row names, was requiring me to explicitly manage them in situations where I was otherwise making no use of them. Admittedly, some of these occasions were quite a few R versions ago, when row names were not as carefully managed by R itself as they are now. Potential ramifications are not immediately obvious to me, but for example, will rbind() of two data frames, both of which have been assigned NULL row names, result in a data frame with NULL row names? (Would it matter?) What about one with NULL row names and one with non-NULL row names? -Don At 8:29 PM +0100 4/14/06, Prof Brian Ripley wrote: >We know from the White Book p.57 that the row names of a data frame `are >never NULL and must be unique'. R documents that row.names() returns a >character vector, and in R (much more so than on S) a long character >vector of short unique strings is expensive to store (I saw 72 bytes/row >on a 64-bit machine for 1:1e6). [Incidentally, in the White Book the >index page nos are all off by one for this item, and commonly elsewhere. >It seems to be LaTeX indexing the page on which a para finishes.] > >Last time this came up Martin Maechler asked if we could not do it more >efficiently, and reminded us recently. It would be fairly easy if >everyone used the row.names() and row.names<-() accessor functions, but >some packages (notably Design and Hmisc) access the attribute "row.names" >directly (and what that is seems to be undocumented). > >I noticed that the White Book does not appear to say that the row names >are character, and indeed says > >'If all else fails the row names are just the row numbers.' > >and it seems the author of expand.grid() took that literally, for it used >to assign integers to the row names. However, the current S-PLUS help for >both row.names and data.frame say row names are a character vector (and >that row.names<-() coerces to character). > >We can certainly differentiate between the internal representation and the >the result of row.names(). Here is my idea: > >1) The internal representation is either NULL, an integer vector or a >character vector. > >2) attr(x, "row.names") will always return either an integer vector or a >character vector, using 1:nrow(x) if the internal representation is NULL. > >3) row.names() will always return as.character(attr(x, "row.names)). > >4) attr<- and row.names<- can set NULL, integer or character. > >5) Row-indexing a data frame with NULL or integer representation will give >an integer representation. > >This would appear to be completely back-compatible for those who only work >via the accessor functions, and probably work with almost all package code >that manipulates attributes directly. Since the changes can be done >almost entirely in C code, the performance hit should be negliglible. > >The benefits will probably only be appreciable with `tall and skinny' >data frames, as even 72 bytes per row is only going to buy you 9 numeric >columns. But that is it seems a common enough case to make this >worthwhile. > >This would be a change aimed at 2.4.0, since we would need plenty of time >both for testing and to alter code to make use of the more efficient >representations. > >BTW, the maximum object length of 2^31 - 1 ensures that an integer >representation of row numbers suffices. > >-- >Brian D. Ripley, [EMAIL PROTECTED] >Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ >University of Oxford, Tel: +44 1865 272861 (self) >1 South Parks Road, +44 1865 272866 (PA) >Oxford OX1 3TG, UKFax: +44 1865 272595 > >__ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- - Don MacQueen Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] seq() function accuracy inacceptable
Another thing to notice (rather than, it would seem, assume), is that using round() doesn't do any "better": ### without rounding > print(seq(61.55, 61.59, by=.01) , digits=22) [1] 61.547 61.555 61.570 61.578 [5] 61.586 ### with rounding > print(round(seq(61.55, 61.59, by=.01),2) , digits=22) [1] 61.547 61.562 61.570 61.578 [5] 61.593 As Thomas and Henrik said, the sequence has to be calculated, and such calculations are not, and can not be, exact. -Don At 6:19 PM +0200 4/18/06, [EMAIL PROTECTED] wrote: >Full_Name: Johannes Prix >Version: 2.1.1 >OS: WinXP, SuSE Linux >Submission from: (NULL) (137.208.41.195) > > > >The seq-command produces unnescessary inaccurate results, which can >be extremely >annoying. I absolutely do not see the nescessity of numerical >garbage to appear >in the following simple case. E.g. try this: > >> seq ( 61.55 , 62.00 , by=0.01 ) - round ( seq ( 61.55 , 62.00 , by=0.01 ) , >digits=2 ) > >Output looks like: > > [1] 0.00e+00 -7.105427e-15 0.00e+00 0.00e+00 -7.105427e-15 >-7.105427e-15 0.00e+00 0.00e+00 > [9] -7.105427e-15 0.00e+00 0.00e+00 0.00e+00 -7.105427e-15 >0.00e+00 0.00e+00 -7.105427e-15 >[17] -7.105427e-15 0.00e+00 0.00e+00 -7.105427e-15 0.00e+00 >0.00e+00 -7.105427e-15 -7.105427e-15 >[25] 0.00e+00 0.00e+00 -7.105427e-15 0.00e+00 0.00e+00 >-7.105427e-15 -7.105427e-15 0.00e+00 >[33] 0.00e+00 -7.105427e-15 0.00e+00 0.00e+00 0.00e+00 >-7.105427e-15 0.00e+00 0.00e+00 >[41] -7.105427e-15 -7.105427e-15 0.00e+00 0.00e+00 -7.105427e-15 >0.00e+00 >> > >It is particularly dangerous to use such seq()-contructed lists (without >rounding) when e.g. trying to find the first time a given number >appears in the >list and the number is given without numerical garbage. > >______ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- - Don MacQueen Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: log='z' for image, contour, persp?
Yes, it does. I've needed it more often than not. -Don At 6:41 PM -0400 5/9/06, Duncan Murdoch wrote: >I've been thinking of adding the possibility of including "z" among the >axes to be logged in image, contour, and persp. In the first two, it >would only affect where the breaks were set if they are calculated >automatically; it would have a bigger effect in persp. > >For example, > >image(x, y, z, log="z") > >would set 12 colours evenly spaced on a log scale of the z values. (12 >because that's the default). > >We already support > >image(x, y, z, log="x") > >to scale the x axis (though there's a spurious warning; I'll fix that). > >image(z, log="x") > >fails because it tries to take a log of zero. > >Does it seem like a good idea for these 3D functions to support log="z" >the way 2D functions do? > >Duncan Murdoch > >______ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Project logo in SVG format
I have a file named Rlogo-5.svg, created by downloading Rlogo-5.png, opening it with Adobe Illustrator, Saving as SVG. I didn't tinker with any of Illustrator's options with regard to how, exactly, to save it, since I pretty much don't know what they mean. Whether it is of any use to anyone, or whether it is truly scalable, I have no idea. All I know is that Illustrator claims it is an SVG file. Took about 2 minutes, all together (writing this email took longer). If any R Core member (or anyone else, for that matter), wants a copy, please let me know. I don't want to burden lots of people with a file they probably don't want. I've emailed a copy separately to Lars. -Don At 8:41 AM -0400 8/31/06, Lars D. Noodén wrote: >Hi, > >I'm looking for a version of the R-Project logo in SVG format. I've found >the bitmapped versions, > http://developer.r-project.org/Logo/ > >but would prefer a scalable version as it usually looks better when >printed. > >Where may I find one? >-Lars > >Lars Nooden ([EMAIL PROTECTED]) > On the Internet, nobody knows you're a dog ... > ... until you start barking. > >__ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] png problem on Intel Mac (PR#9287)
At 10:57 PM +0200 10/10/06, [EMAIL PROTECTED] wrote: >Full_Name: Daniel F Higgins >Version: 2.4.0 >OS: Mac OS X 10.4.8 >Submission from: (NULL) (128.111.242.49) > > >When running the commands > >png(filename='aaa.jpg', width=480, height=480) >plot(c(1,2,3)) > >in the Mac OSX graphical interface window, the png file 'aaa.png' is >created if >one clicks on the 'X' icon to start the X window application first. > >However, if you enter 'R' on the command line (i.e. inside Terminal) and then >enter the same commands using the command line version of R, no png file ever >gets created (and no errors are generated). > >Note that this error does not occur on older PowerPC Mac (only on Intel Mac) > >(And it would be nice if X did not have to be running to create png or jpeg >output graphics.) See the GDD package. >__ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matplot does not work with x being POSIXt class (PR#9412)
As Peter said, matplot plots matrices. The columns of a matrix are vectors of numbers. A POSIXlt object is not a vector of numbers, it is a list. So it shouldn't work. And should not be expected to work. But with a POSIXct object it will work. x <- strptime(as.character(x), format="%Y-%m-%d") ## [1] "POSIXt" "POSIXlt" matplot( as.POSIXct(x), y) At 1:56 PM +0100 12/7/06, [EMAIL PROTECTED] wrote: >Hi, > >Matplot works with x being Date class but not POSIXt. Here is the >example with R version 2.5.0 Under development (unstable) (2006-12-06 >r40129) > >Example: > >x <- Sys.Date() - c(1:10) >y <- cbind(1:10, 10:1) >class(x) >## [1] "Date" >matplot(x, y) > >x <- strptime(as.character(x), format="%Y-%m-%d") >## [1] "POSIXt" "POSIXlt" >matplot(x, y) >Error in matplot(x, y) : 'x' and 'y' must have only 1 or the same number >of columns > >Additionally, matplot with x being Date class does not use apropriate >annotation for x axis. This is very easy to obtain: # x is a Date object matplot(x,y,xaxt='n') axis.Date(1,x) or # x is a POSIXlt object matplot( as.POSIXct(x), y,xaxt='n') axis.POSIXct(1,x) So easy, in fact, that I personally would not expect R core to spend time on it. One of the virtues of R is that the language is so rich that little tweaks like this are often very easy. > >Thank you! > >Gregor > -Don -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
