Re: [Rd] mosaicplot() update and clarification
>
> All,
>
> Again, my apologies for seeming to claim credit for
> your other mosaic implementation. However, there are two
> sources of this confusion, and I hope the following helps.
>
> 1. "my" implementation (e.g. the one originally written for
> and included in S-Plus, then modified and improved for R
> by "KH") appears to have been included in a package
> called "vcd" at some point in time. This was one of the
> first hits when I used googled "vcd". See, for example:
>
> http://www.maths.lth.se/help/R/.R/library/vcd/html/mosaicplot.html
>
> 2. Once I load library(vcd) and do ?mosaicplot, the top of the
> help page does, in fact, say "package:vcd" although it credits me
> as the author?! This was downloaded today from CRAN. This most
> certainly is not my fault, nor do I want to take credit for
> something that isn't mine. If {vcd} uses R:base's mosaicplot(),
> then, of course, everything is fine, but I gather from your email
> that this is not the case. So perhaps the {vcd} package needs to
> update its documentation. If I am misunderstanding something,
> again, I apologize.
`mosaicplot' is a function in package `graphics' (and lists you as the
author) and `mosaic' is a function in package `vcd'. There _was_ a
function `vcd::mosaicplot' in older versions of the `vcd' package masking
`graphics::mosaicplot: `update.packages("vcd")' will update the package
and documentation on your system :-)
Best,
Torsten
>
> Anyway, the more interested people we have improving
> our graphics tools, the better! !_)
>
> Cheers,
>
> Jay
>
>
> On Mon, 7 Nov 2005, Achim Zeileis wrote:
>
> > Jay:
> >
> > > Thanks, I'll send the code with the few changes marked
> > > with something obvious like,
> > >
> > > # JWE changed previous line,
> > >
> > > etc...
> > >
> > > I wasn't aware of the {vcd} implementation. It looks like it
> > > is built on my original S-Plus code, too.
> >
> > Nope, everything written from scratch using Paul's wonderful grid
> > graphics. The internals look completely different and David's
> > implementation provides not only mosaic plots but also association and
> > sieve plots within the same framework.
> >
> > > Always nice to get the citation!
> >
> > ...give credit where credit is due...:-)
> > Best,
> > Z
> >
> > > Jay
> > >
> > >
> > > On Mon, 7 Nov 2005, Prof Brian Ripley wrote:
> > >
> > > > Jay,
> > > >
> > > > Having your code change to know exactly what you are suggesting
> > > > would be helpful.
> > > >
> > > > There is an enhanced version of mosaicplot called mosaic in package
> > > > vcd, and you might like to talk to its maintainers (if the facility
> > > > is not already there, as at a quick glance it seemed not to be).
> > > >
> > > > Brian
> > > >
> > > > On Mon, 7 Nov 2005, John W Emerson wrote:
> > > >
> > > > >
> > > > > Hi --
> > > > >
> > > > > I've found a need for an additional option to mosaicplot(), to
> > > > > suppress the labels. It's not difficult, obviously, a minor
> > > > > thing.
> > > > >
> > > > > Would you like me to submit my revised code (I'll use your code
> > > > > rather than my original source code which was adapted for S-Plus
> > > > > and R)? Or it might be a 5-minute change for the appropriate
> > > > > person. No problem either way, just let me know.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Jay
> > > > >
> > > > > John Emerson
> > > > > Assistant Professor of Statistics
> > > > > Yale University
> > > > >
> > > > > __
> > > > > R-devel@r-project.org mailing list
> > > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > > > >
> > > > >
> > > >
> > > > --
> > > > 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
> > >
> >
>
> __
> 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] mosaicplot() update and clarification
Torsten, thanks for pointing this out.
Jay, just to expand a little on this explanation:
> `mosaicplot' is a function in package `graphics' (and lists you as the
> author) and `mosaic' is a function in package `vcd'. There _was_ a
> function `vcd::mosaicplot' in older versions of the `vcd' package
> masking`graphics::mosaicplot: `update.packages("vcd")' will update the
> package and documentation on your system :-)
The reason for these changes in vcd is the following: When we started
the project we just extended the mosaicplot() function from graphics
(which is based on your code) in a few directions but keeping it
upwardly compatible. Therefore, we decided that it's ok to overload the
graphics function.
Rather soon we wanted something based on grid and something which can be
more easily modified and extended and we've written about three (I
think) new implementations in grid. As the interface needed to be quite
different from the original one, we decided that it wouldn't be
appropriate to overload the graphics function and hence chose a new
function name mosaic(). The corresponding man page still has Emerson
(1998) in the references but does not mention you as the author (as it
is enitrely new code).
Best,
Z
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dgamma error condition?
thanks. would you like a patch? (seems easy enough but I thought I'd offer) looks like library/stats/R/distn.R and nmath/rgamma.c need fixing; looks like qgamma may not check for scale<0 in C code either ... Ben Bolker Prof Brian Ripley wrote: > On Fri, 4 Nov 2005, Ben Bolker wrote: > >> >> There's an apparent inconsistency between the >> behavior of d(pqr)gamma and other distribution >> functions for "bad" parameter values. Specifically, >> most distributions give NaN and a warning for bad >> parameters (e.g. probabilities <0 or >1). In contrast, >> d(pqr)gamma actually gives an error and stops when shape<0. >> I don't see why it has to be this way -- the internal >> C code is set up to detect shape<0 (or scale<0) and >> return NaN and a warning, and none of the other >> distribution functions in that bit of the code have >> similar behavior. >> >> It would seem more consistent (and would be more >> convenient for me -- the error-instead-of-warning >> is making me have to jump through additional hoops) >> if dgamma just returned NaN and a warning. >> >>Any thoughts? > > > No one has come up with any, so let us remove the errors in R-devel. > > Note that rgamma is not protected at C level: try rgamma(10, -2), or > (worse) rgamma(10, -20) after removing the stop() call. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-2.2.0: malloc probelm in regex code (PR#8287)
Full_Name: Gordon Lack Version: 2.2.0 OS: OSF1/Tur64 Submission from: (NULL) (193.128.25.20) R-2.2.0 fails to build on OSF1 systems. . make[4]: Leaving directory `/R-2.2.0/src/library/tools/src Error in list.files(path, pattern, all.files, full.names, recursive) : invalid 'pattern' regular expression Execution halted make[3]: *** [all] Error 1 . I've tracked down the problem to change (somewhere) in 2.2.0 vs. 2.1.1 which has resulted in re_node_set_alloc() (in src/main/regex.c) being called with a size of 0. Whereas some system (Solaris, Linux, ...) return a valid pointer to a zero-size allocation, OSF1 returns a NULL pointer on a 0 allocation request (documented as such, and the Open Group Base Specifications Issue 6 documents that either may happen). The calling code treats a NULL return as a ESPACE error. In R-2.1.1 this code was not asked to allocate 0 sizes, so I suspect that it shouldn't be happening here either. A workaround is to add: if (size==0) size=1; /* OSF1 (at least) returns NULL on 0 alloc */ before the re_malloc (int, size) line in re_node_set_alloc(), which just means you allocate a small space (which shodul be free()d soon anyway). The actual regex whcih triggers this during the build is: ^tools($|_) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R build under mandriva 10.2
After upgrading from mandrake 10.1 to mandriva 10.2 I can't build shared archive with R 2.2.0 [EMAIL PROTECTED] src]$ R CMD SHLIB main.f sub.f wrapper.c gcc -shared -L/usr/local/lib -o main.so main.o sub.o wrapper.o -lg2c -lm -lgcc_s /usr//bin/ld: cannot find -lg2c collect2: ld returned 1 exit status make: *** [main.so] Erreur 1 I guess the information in http://finzi.psych.upenn.edu/R/Rhelp01/archive/5146.html are not relevant any longer. What is missing ? Gilles __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.2.0: malloc probelm in regex code (PR#8287)
Please try R-patched, as this has already been reported for AIX and addressed in R-patched and R-devel. On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > Full_Name: Gordon Lack > Version: 2.2.0 > OS: OSF1/Tur64 > Submission from: (NULL) (193.128.25.20) > > > R-2.2.0 fails to build on OSF1 systems. > > . > make[4]: Leaving directory `/R-2.2.0/src/library/tools/src > Error in list.files(path, pattern, all.files, full.names, recursive) : >invalid 'pattern' regular expression > Execution halted > make[3]: *** [all] Error 1 > . > > > > I've tracked down the problem to change (somewhere) in 2.2.0 vs. 2.1.1 which > has > resulted in re_node_set_alloc() (in src/main/regex.c) being called with a size > of 0. Whereas some system (Solaris, Linux, ...) return a valid pointer to a > zero-size allocation, OSF1 returns a NULL pointer on a 0 allocation request > (documented as such, and the Open Group Base Specifications Issue 6 documents > that either may happen). The calling code treats a NULL return as a ESPACE > error. > > In R-2.1.1 this code was not asked to allocate 0 sizes, so I suspect that it > shouldn't be happening here either. > > A workaround is to add: > > if (size==0) size=1; /* OSF1 (at least) returns NULL on 0 alloc */ > > before the re_malloc (int, size) line in re_node_set_alloc(), which just means > you allocate a small space (which shodul be free()d soon anyway). > > The actual regex whcih triggers this during the build is: > > ^tools($|_) > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- 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
[Rd] bug in windows GUI/script editor (PR#8288)
Full_Name: Roberto Ugoccioni Version: 2.2.0 OS: Windows 2000 Submission from: (NULL) (193.203.232.5) Running Windows 2000 Professional, all patches up to nov 8, 2005. > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major2 minor2.0 year 2005 month10 day 06 svn rev 35749 language R How to reproduce the bug: 1. launch Rgui.exe 2. menu File->open script 3. close editor clicking on X 4. clicking menu File now generates the fatal error (omitting memory addresses): An instruction referred to a memory location which could not be "read" Clicking on OK in the error message window causes R to consume 100% CPU and not to respond - must be terminated from task manager. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in windows GUI/script editor (PR#8288)
On 11/8/2005 11:51 AM, [EMAIL PROTECTED] wrote: > Full_Name: Roberto Ugoccioni > Version: 2.2.0 > OS: Windows 2000 > Submission from: (NULL) (193.203.232.5) > > > Running Windows 2000 Professional, all patches up to nov 8, 2005. > > >>version > > _ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major2 > minor2.0 > year 2005 > month10 > day 06 > svn rev 35749 > language R > > How to reproduce the bug: > > 1. launch Rgui.exe > 2. menu File->open script > 3. close editor clicking on X > 4. clicking menu File now generates the fatal error (omitting memory > addresses): > > An instruction referred to a memory location which could not be "read" > > Clicking on OK in the error message window causes R to consume 100% CPU and > not > to respond - must be terminated from task manager. I don't see this, but it sounds like something that was fixed before the release of 2.2.0, so maybe there's another way to generate the same problem. Could you give more detail: - are you running in the default MDI mode (one big window containing the console, editor, etc.) or SDI mode (separate windows)? - does it matter what was in the file you opened? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [OTAnn] Feedback
I was interested in getting feedback from current mail group users. We have mirrored your mail list in a new application that provides a more aggregated and safe environment which utilizes the power of broadband. Roomity.com v 1.5 is a web 2.01 community webapp. Our newest version adds broadcast video and social networking such as favorite authors and an html editor. It?s free to join and any feedback would be appreciated. S. Broadband interface (RIA) + mail box saftey = http://R_Project_Development_List.roomity.com";>R_Project_Development_List.roomity.com *Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131474907254~~ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R thread safe
On Mon, Nov 07, 2005 at 07:57:28PM +0100, [EMAIL PROTECTED] wrote: > I would like to accelerate my R computation by using parallel OpenMP > compilers (e.g from Pathscale) on a 2-processor AMD server and I > would like to know whether R is a tread safe library. The main R is not thread safe, but others will have to tell you just how and why not and what needs to be done to fix that (I don't know). Does OpenMP require thread support, or can it alternately use multiple processes plus System V shared memory? Perhaps the latter would still be an option even in R's currently non-thread-safe state. Your approach is interesting. Why do you want to do shared memory parallel programming with OpenMP, rather than say message passing via MPI or PVM? Do you have a particularly fine-grained problem for which message passing would be unsuitable? Or are you just hoping to automatically take advantage of both CPUs of your dual CPU workstation without having to write any extra message passing code? I haven't heard of anyone else doing shared memory programming with R. But if instead you are interested in message passing, there are lots of different tools and projects in R for that: http://cran.us.r-project.org/src/contrib/Descriptions/Rmpi.html http://cran.us.r-project.org/src/contrib/Descriptions/rpvm.html http://cran.us.r-project.org/src/contrib/Descriptions/papply.html http://cran.us.r-project.org/src/contrib/Descriptions/snow.html http://www.aspect-sdm.org/Parallel-R/ http://cran.us.r-project.org/src/contrib/Descriptions/RScaLAPACK.html http://cran.us.r-project.org/src/contrib/Descriptions/taskPR.html http://cran.us.r-project.org/src/contrib/Descriptions/biopara.html http://www.omegahat.org/download/R/packages/CORBA.tar.gz -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD Sd2Rd a.sgml > a.Rd does not recognize tag (PR#8289)
I'm trying:
R CMD Sd2Rd file.sgml > file.Rd
If file.sgml contains
x
this should be translated to
\code{x}
in the .Rd file, but is not.
It should be treated the same as the old
x
I'm using:
Cygwin (uname gives: CYGWIN_NT-5.1) (installed 10 Oct 05)
Perl 5.8.7 build 813(installed 7 Nov 05)
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 2.0
year = 2005
month = 10
day = 06
svn rev = 35749
language = R
Windows XP Professional (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD Rdconv file.Rd --type=Ssgm \code{x} should use (PR#8290)
I'm trying:
R CMD Rdconv file.Rd --type=Ssgm
If file.Rd contains
\code{x}
then this is currently translated as
x
I suggest instead translating to
x
(provided that R CMD Sd2Rd is changed to support the
tag; I just submitted that bug separately).
Note that this is an enhancement, not a bug.
This change would give functionally-equivalent but prettier sgml files.
I'm using:
Cygwin (uname gives: CYGWIN_NT-5.1) (installed 10 Oct 05)
Perl 5.8.7 build 813(installed 7 Nov 05)
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 2.0
year = 2005
month = 10
day = 06
svn rev = 35749
language = R
Windows XP Professional (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads, package:base
| Tim Hesterberg Research Scientist |
| [EMAIL PROTECTED] Insightful Corp.|
| (206)802-23191700 Westlake Ave. N, Suite 500 |
| (206)283-8691 (fax) Seattle, WA 98109-3012, U.S.A. |
| www.insightful.com/Hesterberg |
Download the S+Resample library from www.insightful.com/downloads/libraries
Two Research Scientist positions:
data mining
frailty/mixed effects
http://www.insightful.com/company/jobs.asp
Speak out about biased science in Washington D.C.
http://home.comcast.net/~timhesterberg/ScientificIntegrity.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
