Re: [Rd] Failure to load the recommended package Matrix (Was: [R] Can one get a list of recommended packages?)

2010-06-14 Thread Ei-ji Nakama 
> And if you look at the other R-help message posted by David Kirby you
> will find a link to the trouble ticket report in Sage as
> http://trac.sagemath.org/sage_trac/ticket/9201

>From the link,...
|  kir...@t2:[~] $ echo $LD_LIBRARY_PATH
| 
/usr/local/gcc-4.4.1-sun-linker/lib:/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:/usr/local/lib

`/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9' is 64bit, it is unnecessary.
I think that this obstructs it.
-- 
EI-JI Nakama  
"\u4e2d\u9593\u6804\u6cbb"  

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Solaris build problem

2010-06-14 Thread Dominick Samperi 
Hello,

I have package that builds fine under all OS's at CRAN except Solaris, and
the Solaris problem occurs at vignette processing time: the library
command fails. So, if a package Foo has a vignette is there a problem
if an R code chunk runs library(Foo) from within a code chunk in
the vignette under Solaris?

Thanks,
Dominick

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Solaris build problem

2010-06-14 Thread Prof Brian Ripley 

On Mon, 14 Jun 2010, Dominick Samperi wrote:


Hello,

I have package that builds fine under all OS's at CRAN except Solaris, and
the Solaris problem occurs at vignette processing time: the library
command fails. So, if a package Foo has a vignette is there a problem
if an R code chunk runs library(Foo) from within a code chunk in
the vignette under Solaris?


Many other packages do it ...



Thanks,
Dominick





--
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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Solaris build problem

2010-06-14 Thread Dominick Samperi 
I guess I should have been more explicit, here is the error as it appears
in CRAN logs for package cxxPack:

checking package vignettes in 'inst/doc' ... WARNING
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> 
Execution halted
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> 
Execution halted
"testDotproduct.cpp", line 1: Error: Could not open include
file.
"testDotproduct.cpp", line 2: Error: RcppExport is not defined.
[clip]

It appears that the failure occurs at the very beginning of the vignette
where library(cxxPack) is called, since the other errors (not able to find
header files) would be expected after this error.

Could this be related to the parallel make problem that sometimes
occurs under Windows? There a bug in GNU make causes one package
to corrupt the environment of another.

Thanks,
Dominick

On Mon, Jun 14, 2010 at 9:24 AM, Prof Brian Ripley wrote:

> On Mon, 14 Jun 2010, Dominick Samperi wrote:
>
>  Hello,
>>
>> I have package that builds fine under all OS's at CRAN except Solaris, and
>> the Solaris problem occurs at vignette processing time: the library
>> command fails. So, if a package Foo has a vignette is there a problem
>> if an R code chunk runs library(Foo) from within a code chunk in
>> the vignette under Solaris?
>>
>
> Many other packages do it ...
>
>
>> Thanks,
>> Dominick
>>
>>
>>
>>
> --
> 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
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Solaris build problem

2010-06-14 Thread Uwe Ligges 



On 14.06.2010 15:53, Dominick Samperi wrote:

I guess I should have been more explicit, here is the error as it appears
in CRAN logs for package cxxPack:

checking package vignettes in 'inst/doc' ... WARNING
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch ->  tryCatchList ->  tryCatchOne ->  
Execution halted
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch ->  tryCatchList ->  tryCatchOne ->  
Execution halted
"testDotproduct.cpp", line 1: Error: Could not open include
file.
"testDotproduct.cpp", line 2: Error: RcppExport is not defined.
[clip]

It appears that the failure occurs at the very beginning of the vignette
where library(cxxPack) is called, since the other errors (not able to find
header files) would be expected after this error.

Could this be related to the parallel make problem that sometimes
occurs under Windows? There a bug in GNU make causes one package
to corrupt the environment of another.


Ha, that just by chance your package got hit under Windows by a rare bug 
of make does not mean it is not your fault if it fails on Solaris.


Uwe






Thanks,
Dominick

On Mon, Jun 14, 2010 at 9:24 AM, Prof Brian Ripleywrote:


On Mon, 14 Jun 2010, Dominick Samperi wrote:

  Hello,


I have package that builds fine under all OS's at CRAN except Solaris, and
the Solaris problem occurs at vignette processing time: the library
command fails. So, if a package Foo has a vignette is there a problem
if an R code chunk runs library(Foo) from within a code chunk in
the vignette under Solaris?



Many other packages do it ...



Thanks,
Dominick





--
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



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Failure to load the recommended package Matrix (Was: [R] Can one get a list of recommended packages?)

2010-06-14 Thread Ei-ji Nakama 
Sorry, my  bark up the wrong tree...

When LD_LIBRARY_PATH_32 is set, I think that I become it in such a state.

http://docs.sun.com/app/docs/doc/819-0690/chapter1-11192?a=view#chapter1-9

It is better when there is the following.
crle ; crle -64 ; env|grep "LD_"

2010/6/14 Ei-ji Nakama :
>> And if you look at the other R-help message posted by David Kirby you
>> will find a link to the trouble ticket report in Sage as
>> http://trac.sagemath.org/sage_trac/ticket/9201
>
> From the link,...
> |  kir...@t2:[~] $ echo $LD_
> | 
> /usr/local/gcc-4.4.1-sun-linker/lib:/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:/usr/local/lib
>
> `/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9' is 64bit, it is unnecessary.
> I think that this obstructs it.
> --
> EI-JI Nakama  
> "\u4e2d\u9593\u6804\u6cbb"  
>



-- 
EI-JI Nakama  
"\u4e2d\u9593\u6804\u6cbb"  

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 00LOCK and nfs

2010-06-14 Thread Kasper Daniel Hansen 
Thank you very much for including this additional capability.

Our cluster is still running NFS 3 and I doubt I will be able to get
the file system upgraded.  It is nice to know that the problem is
mostly solved under NFS 4.

Kasper

On Thu, Jun 10, 2010 at 7:54 AM, Prof Brian Ripley
 wrote:
> Note that this patch is incomplete: there are three separate branches in
> install.packages() where R CMD INSTALL is used, and one already uses
> --pkglock.  (So a short-term solution for you is to set Ncpus > 1.)
>
> However, I think this request has been subsumed by a more general need to be
> able to pass options to INSTALL, and R-devel now has an INSTALL_opts
> argument to install.packages().  So I believe you could just use
> install.packages( ... , INSTALL_opts = "--pkglock") .
>
> On Tue, 1 Jun 2010, Kasper Daniel Hansen wrote:
>
>> Further experimentation using this patch to install.packages shows
>> that I sometimes have remaining 00LOCK-pkgname directories after doing
>> a massive update on a multi-user system with R installed on NFS.
>> However, I have never had install.packages/update.packages stop midway
>> because of an unremovable 00LOCK directory.  I therefore consider the
>> patch to be big improvement for people like me, having a multi-user R
>> installed on NFS.  Private followups to my original email shows that I
>> am not the only one with this problem.
>
> But I should point out that others with well-tuned NFS do not have the
> problem -- my sysadmins say that it was common with NFSv3 but they've hardly
> seen it with NFSv4.
>
>
>> I would very much like the patch (or some variant hereof) to be
>> considered for inclusion in R-devel.
>>
>> Kasper
>>
>> On Tue, May 18, 2010 at 11:59 AM, Kasper Daniel Hansen
>>  wrote:
>>>
>>> This is a follow-up to an old thread with kind of solution to the
>>> 00LOCK problem on NFS.
>>>
>>> I have made a patch to install.packages to accept a new argument
>>>  locktype = c("lock", "no-lock", "pkglock")
>>> which is passed to R CMD INSTALL.  This addition might have
>>> independent interest aside from the NFS problem, as it exposes
>>> functionality from R CMD INSTALL to install.packages and the very
>>> convenient update.packages.  Patches are at
>>>  http://www.biostat.jhsph.edu/~khansen/packages2.R-patch
>>>  http://www.biostat.jhsph.edu/~khansen/install.packages.Rd-patch
>>> (patches to files in the utils package) and both
>>>  R-devel (R version 2.12.0 Under development (unstable) (2010-05-17
>>> r52025))
>>> and
>>>  R-2.11 (R version 2.11.0 Patched (2010-05-17 r52025))
>>> passed make check-all with these two patches applied.  I thought about
>>> adding a note describing my findings below to the details section, but
>>> decided against it.
>>>
>>> Regarding the 00LOCK problem.  In my testing, using the patches above
>>> and setting locktype = "pkglock", makes it possible to deal with the
>>> NFS problem.  Specifically, I have not been able to make
>>> update.packages() fail midway, due to a un-removable 00LOCK file
>>> (which is not too surprising, as I now have a per-package lock).
>>>
>>> However, sometimes (but far less frequently than before), a
>>> 00LOCK-pkgname directory remains after update/install.packages.
>>> Sometimes this 00LOCK-pkgname directory does not contain any .nfs*
>>> files (!?) and sometimes it does. For this reason, I still precede any
>>> install/update.packages with a check for the existence of a
>>> 00LOCK-pkgname directory and an attempt to remove it.
>>>
>>> The difference between using locktype = "pkglock" and not is
>>> specifically that without, it was possible for update.packages to fail
>>> midway even though there were no 00LOCK* files at the start of the
>>> update process.
>>>
>>> Originally I hypothesized that the presence of the .nfs* files in the
>>> 00LOCK directory had to do with synchronization issues between the
>>> file server and the compute node.  In order to approach this I tried
>>> to insert a
>>>  system("sleep 10")
>>> at the beginning of
>>>  do_cleanup
>>> in
>>>  tools/R/install.R
>>> but that did not work.
>>>
>>> Since the pkglock approach described above seems to solve this issue
>>> for me, I have not pursued the synchronization issue further.
>>>
>>> Kasper
>>>
>>
>> __
>> 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, UK                Fax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Solaris build problem

2010-06-14 Thread Prof Brian Ripley 
At one level the answer is easy: cxxPack was not installed at system 
level when that check was run, and I presume it was installed on the 
other build systems.


However, the vignette checker should be able to find the package from 
the copy installed for checking, soI need to dig deeper to find out 
why that did not happen.


On Mon, 14 Jun 2010, Dominick Samperi wrote:


I guess I should have been more explicit, here is the error as it appears
in CRAN logs for package cxxPack:

checking package vignettes in 'inst/doc' ... WARNING
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> 
Execution halted
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> 
Execution halted
"testDotproduct.cpp", line 1: Error: Could not open include
file.
"testDotproduct.cpp", line 2: Error: RcppExport is not defined.
[clip]

It appears that the failure occurs at the very beginning of the vignette
where library(cxxPack) is called, since the other errors (not able to find
header files) would be expected after this error.

Could this be related to the parallel make problem that sometimes
occurs under Windows? There a bug in GNU make causes one package
to corrupt the environment of another.

Thanks,
Dominick

On Mon, Jun 14, 2010 at 9:24 AM, Prof Brian Ripley 
wrote:
On Mon, 14 Jun 2010, Dominick Samperi wrote:

  Hello,

  I have package that builds fine under all OS's at CRAN
  except Solaris, and
  the Solaris problem occurs at vignette processing time:
  the library
  command fails. So, if a package Foo has a vignette is
  there a problem
  if an R code chunk runs library(Foo) from within a code
  chunk in
  the vignette under Solaris?


Many other packages do it ...


  Thanks,
  Dominick




--
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, UK                Fax:  +44 1865 272595






--
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__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] Prime Numbers Pkgs - Schoolmath is broken

2010-06-14 Thread Gavin Simpson 
On Mon, 2010-06-14 at 07:16 -0700, Red Roo wrote:
> Looking for a recommended package that handles prime number computations.
> 
> Tried the following unsuccessfully:
> primeFactors() in the R.basic package failed to install.
> 
> primes() and primlist are broken in Schoolmath pkg on CRAN.
> My analysis can be found here http://j.mp/9BNI9q
> Not sure what the procedure is for getting things fixed, so I've
> cross-posted to r-dev as well.

Neither place is correct. This has *nothing* to do with R. Address bug
reports directly to the package maintainer, details of which can be
found here:

http://cran.r-project.org/web/packages/schoolmath/index.html

which is what is requested in the posting guide...

HTH

G

> --njg
> 
> TAKING THE PITH OUT OF PERFORMANCE http://perfdynamics.blogspot.com/
> Follow me on Twitter http://twitter.com/DrQz
> PERFORMANCE DYNAMICS COMPANY http://www.perfdynamics.com/
> 
> __
> r-h...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

-- 
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
 Dr. Gavin Simpson [t] +44 (0)20 7679 0522
 ECRC, UCL Geography,  [f] +44 (0)20 7679 0565
 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
 Gower Street, London  [w] http://www.ucl.ac.uk/~ucfagls/
 UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Solaris build problem

2010-06-14 Thread Prof Brian Ripley 

On Mon, 14 Jun 2010, Prof Brian Ripley wrote:

At one level the answer is easy: cxxPack was not installed at system level 
when that check was run, and I presume it was installed on the other build 
systems.


However, the vignette checker should be able to find the package from the 
copy installed for checking, so I need to dig deeper to find out why 
that did not happen.


And it because you have an inst/doc/Makefile that does not arrange to 
do so.  R_LIBS should be set appropriately at that point, but since 
you are not using --vanilla to run R (unlike R CMD check), it is 
overridden by other settings.




On Mon, 14 Jun 2010, Dominick Samperi wrote:


I guess I should have been more explicit, here is the error as it appears
in CRAN logs for package cxxPack:

checking package vignettes in 'inst/doc' ... WARNING
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> 
Execution halted
Error in loadNamespace(name) : there is no package called 'cxxPack'
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> 
Execution halted
"testDotproduct.cpp", line 1: Error: Could not open include
file.
"testDotproduct.cpp", line 2: Error: RcppExport is not defined.
[clip]

It appears that the failure occurs at the very beginning of the vignette
where library(cxxPack) is called, since the other errors (not able to find
header files) would be expected after this error.

Could this be related to the parallel make problem that sometimes
occurs under Windows? There a bug in GNU make causes one package
to corrupt the environment of another.

Thanks,
Dominick

On Mon, Jun 14, 2010 at 9:24 AM, Prof Brian Ripley 
wrote:
On Mon, 14 Jun 2010, Dominick Samperi wrote:

  Hello,

  I have package that builds fine under all OS's at CRAN
  except Solaris, and
  the Solaris problem occurs at vignette processing time:
  the library
  command fails. So, if a package Foo has a vignette is
  there a problem
  if an R code chunk runs library(Foo) from within a code
  chunk in
  the vignette under Solaris?


Many other packages do it ...


  Thanks,
  Dominick




--
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, UK                Fax:  +44 1865 272595






--
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


--
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__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Failure to load the recommended package Matrix (Was: [R] Can one get a list of recommended packages?)

2010-06-14 Thread Dr. David Kirkby 

On 06/14/10 10:05 AM, Ei-ji Nakama wrote:

And if you look at the other R-help message posted by David Kirby you
will find a link to the trouble ticket report in Sage as
http://trac.sagemath.org/sage_trac/ticket/9201



From the link,...

|  kir...@t2:[~] $ echo $LD_LIBRARY_PATH
| 
/usr/local/gcc-4.4.1-sun-linker/lib:/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:/usr/local/lib

`/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9' is 64bit, it is unnecessary.
I think that this obstructs it.


This is not the reason. If it picked up the wrong library, then there would be a 
message that there was the wrong ELF class, but no library whatever is being found.


I've tried without the 'sparcv9' in LD_LIBRARY_PATH and it makes no difference 
whatsoever. I've tried on two SPARCs too, running different releases of Solaris 10.


Using 'crle' might work, but that is not really a good answer, as it needs root 
access. It should be possible to install an application like R without being 
root. There is something wrong if LD_LIBRARY_PATH can't be used to locate 
libraries.


I can build the whole of the Sage source code (around 300 MB) and don't see this 
failure elsewhere. Instead, there are a number of programs which link to 
libgcc_s.so.1.


I stuck some further information at

http://trac.sagemath.org/sage_trac/ticket/9201

but it basically just confirms what I've written above.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Solaris build problem

2010-06-14 Thread Dominick Samperi 
On Mon, Jun 14, 2010 at 11:23 AM, Prof Brian Ripley
wrote:

> On Mon, 14 Jun 2010, Prof Brian Ripley wrote:
>
>  At one level the answer is easy: cxxPack was not installed at system level
>> when that check was run, and I presume it was installed on the other build
>> systems.
>>
>> However, the vignette checker should be able to find the package from the
>> copy installed for checking, so I need to dig deeper to find out why that
>> did not happen.
>>
>
> And it because you have an inst/doc/Makefile that does not arrange to do
> so.  R_LIBS should be set appropriately at that point, but since you are not
> using --vanilla to run R (unlike R CMD check), it is overridden by other
> settings.
>

But you said nothing about Solaris here. Why doesn't the problem arise with
other OS's?

If I could setup an environment like the one used for Solaris I could test
out issues like this
(and reduce r-devel traffic).

Thanks,
Dominick

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] areaplot

2010-06-14 Thread Arni Magnusson 
I would like to propose adding a new plot function to the 'graphics' 
package. The new function is called areaplot() and I have implemented it 
as a generic function that supports a variety of data classes.


An area plot consists of a simple line, like plot(x, y, type="l"), except 
the area between 0 and the line is a filled polygon. Areas can be stacked 
on top of each other, like barplot(matrix(3:1)), and the data can be 
plotted as proportions, so stacked areas equal 1.


Area plots are commonly found in the scientific literature. Currently, 
drawing an area plot in R using polygon() is a hassle at best, and drawing 
a stacked area plot can be a major task for beginning users.


If you source the attached areaplot.R file, and read the help page and 
examples, you will see that I made an effort to implement the following 
features:


- the same look as standard R plots, including default xlab and ylab

- the same graphical args as standard R plots, including add=TRUE

- the same robustness to NA values as standard R plots

- a generic function that supports vectors, tables, matrices, data frames, 
lists, time-series objects, and formulas


On a technical note, I included the support for different data classes 
inside areaplot.default(), instead of implementing separate areaplot.foo() 
functions. It would be trivial to do move the if-clauses to separate 
functions, but I wasn't sure if that would improve the code or not, since 
the necessary data manipulations are minimal. It was only areaplot.formula 
that should obviously be a separate function.


Comparable functions are found in some user packages, highlighting the 
general need of an area plot function, but the existing functions do not 
follow the R plotting standards, nor do they support such a variety of 
data classes, or provide stacked and proportional area plots.


I'm looking forward to your feedback,

Arniareaplot <-

function(x, ...)

{

  UseMethod("areaplot")

}



areaplot.default <-

function(x, y=NULL, prop=FALSE, add=FALSE, xlab=NULL, ylab=NULL, col=NULL, ...)

{

  if(is.ts(x)) # ts/mts

  {

if(is.null(ylab))

  ylab <- deparse(substitute(x))

x <- data.frame(Time=time(x), x)

  }

  if(is.table(x))  # table

  {

if(is.null(ylab))

  ylab <- deparse(substitute(x))

if(length(dim(x)) == 1)

  x <- t(t(unclass(x)))

else

  x <- unclass(x)

  }

  if(is.matrix(x))  # matrix

  {

if(!is.null(rownames(x)) && 
!any(is.na(suppressWarnings(as.numeric(rownames(x))

{

  x <- data.frame(as.numeric(rownames(x)), x)

  names(x)[1] <- ""

}

else

{

  x <- data.frame(Index=seq_len(nrow(x)), x)

}

  }

  if(is.list(x))  # data.frame or list

  {

if(is.null(xlab))

  xlab <- names(x)[1]

if(is.null(ylab))

{

  if(length(x) == 2)

ylab <- names(x)[2]

  else

ylab <- ""

}

y <- x[-1]

x <- x[[1]]

  }

  if(is.null(y))  # one numeric vector passed, plot it on 1:n

  {

if(is.null(xlab))

  xlab <- "Index"

if(is.null(ylab))

  ylab <- deparse(substitute(x))

y <- x

x <- seq_along(x)

  }

  if(is.null(xlab))

xlab <- deparse(substitute(x))

  if(is.null(ylab))

ylab <- deparse(substitute(y))



  y <- as.matrix(y)

  if(is.null(col))

col <- gray.colors(ncol(y))

  col <- rep(col, length.out=ncol(y))

  if(prop)

y <- prop.table(y, 1)

  y <- t(rbind(0, apply(y, 1, cumsum)))

  na <- is.na(x) | apply(is.na(y),1,any)

  x <- x[!na][order(x[!na])]

  y <- y[!na,][order(x[!na]),]



  if(!add)

suppressWarnings(matplot(x, y, type="n", xlab=xlab, ylab=ylab, ...))

  xx <- c(x, rev(x))

  for(i in 1:(ncol(y)-1))

  {

yy <- c(y[,i+1], rev(y[,i]))

suppressWarnings(polygon(xx, yy, col=col[i], ...))

  }



  invisible(y[,-1])

}



areaplot.formula <-

function (formula, data, subset, na.action=NULL, ...)

{

  m <- match.call(expand.dots=FALSE)

  if(is.matrix(eval(m$data,parent.frame(

m$data <- as.data.frame(data)

  m$... <- NULL

  m[[1]] <- as.name("model.frame")

  if(as.character(formula[[2]]=="."))

  {

rhs <- unlist(strsplit(deparse(formula[[3]])," *[:+] *"))

lhs <- sprintf("cbind(%s)", paste(setdiff(names(data),rhs),collapse=","))

m[[2]][[2]] <- parse(text=lhs)[[1]]

  }



  mf <- eval(m, parent.frame())

  if(is.matrix(mf[[1]]))

  {

lhs <- as.data.frame(mf[[1]])

names(lhs) <- as.character(m[[2]][[2]])[-1]

areaplot.default(cbind(mf[-1],lhs), ...)

  }

  else

  {

areaplot.default(mf[2:1], ...)

  }

}



\name{areaplot}

\alias{areaplot}

\alias{areaplot.default}

\alias{areaplot.formula}

\title{Area Plots}

\description{

  Produce a stacked area plot, or add polygons to an existing plot.

}

\usage{

areaplot(x, \dots)



\method{areaplot}{default}(x, y = NULL, prop = FALSE, add = FALSE, xlab = NULL,

 ylab = NULL, col = NULL, \dots)



\method{areaplot}{formula}(formula, data, subset, na.action = NULL