[Rd] R 2.1.1 slated for June 20
The next version of R will be released (barring force majeure) on June 20th, with beta versions available starting Monday. Please do check them on your system *before* the release this time... Apologies for the late announcement, but my department moved this week and I needed to be sure that my set-up survived the move. -pd -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] by should use match.fun
Gabor Grothendieck <[EMAIL PROTECTED]> writes: > On 6/12/05, Simon Urbanek <[EMAIL PROTECTED]> wrote: > > Umm.. why don't you just use > > > > by(iris, row.names(iris), `(`) > > > > In general I consider passing functions as text unnecessary - the > > only use I could think of is constructing function names from strings/ > > data and I'm not sure that is a good idea, either (it causes quite > > some performance issues) ... just my 2 pennies ... > > That's a good idea and I will change my code accordingly although it does > not change the fact that an inconsistency remains and should be > corrected. Also, match.fun takes some pains to actually give you a function, guarding the user against the (otherwise well-deserved...) consequences of storing results in an object called "summary", etc. So, good idea. Maybe not for 2.1.1 though. This close to a release we should be going strictly after actual bugs, not just inconsistencies. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
Marc Schwartz <[EMAIL PROTECTED]> writes:
> On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> >
> > > The next version of R will be released (barring force majeure) on June
> > > 20th, with beta versions available starting Monday.
> > >
> > > Please do check them on your system *before* the release this time...
> >
> > Some things which it would be particularly helpful to have tested:
>
>
> > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
> >often show up problems with bugs in the pre-release versions of
> >components such as X11 and compilers.)
>
>
> Just as a quick heads up, I installed FC4 Release ("Stentz") late
> yesterday.
>
> R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
>
> $ gcc --version
> gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
>
> and make check-all passes with no problems.
>
> I have also installed all CRAN packages that do not require other 3rd
> party drivers, etc. and there were no observed errors in those cases.
>
> So far, so good.
>
> If anything comes up, I will post a follow up.
>
> Best regards,
>
> Marc Schwartz
Yep. Just tried the same on AMD64 (I had a bit of a fight converting
my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
A couple of f95 warnings whooshed by during the compile, that was all.
By the way, I noticed that you can now "yum install R R-devel" and get
everything straight from Fedora Extras.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
Marc Schwartz <[EMAIL PROTECTED]> writes: > Prof. Ripley, > > If my read of the config.log is correct, it would appear that g77 was > used and not gfortran (which is installed): > > ... > C compiler:gcc -g -O2 > C++ compiler: g++ -g -O2 > Fortran compiler: g77 -g -O2 > ... Mine was C compiler:gcc -g -O2 C++ compiler: g++ -g -O2 Fortran compiler: f95 -g -O2 (and f95 is a link to gfortran) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
Marc Schwartz <[EMAIL PROTECTED]> writes: > On Wed, 2005-06-15 at 00:01 +0200, Peter Dalgaard wrote: > > Marc Schwartz <[EMAIL PROTECTED]> writes: > > > > > Prof. Ripley, > > > > > > If my read of the config.log is correct, it would appear that g77 was > > > used and not gfortran (which is installed): > > > > > > ... > > > C compiler:gcc -g -O2 > > > C++ compiler: g++ -g -O2 > > > Fortran compiler: g77 -g -O2 > > > ... > > > > Mine was > > > > > > C compiler:gcc -g -O2 > > C++ compiler: g++ -g -O2 > > Fortran compiler: f95 -g -O2 > > > > (and f95 is a link to gfortran) > > > Interesting. Did you do anything different on the ./configure line? > > $ ls -l /usr/bin/f95 > lrwxrwxrwx 1 root root 8 Jun 13 21:18 /usr/bin/f95 -> gfortran > > I just tried it again (having installed some FC updates) and I still get > g77... I just didn't install g77... (it's listed under "back-compatibility tools" or something like that). -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
Martyn Plummer <[EMAIL PROTECTED]> writes:
> On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
> > On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> > > Marc Schwartz <[EMAIL PROTECTED]> writes:
> > >
> > > > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > > > > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> > > > >
> > > > > > The next version of R will be released (barring force majeure) on
> > > > > > June
> > > > > > 20th, with beta versions available starting Monday.
> > > > > >
> > > > > > Please do check them on your system *before* the release this
> > > > > > time...
> > > > >
> > > > > Some things which it would be particularly helpful to have tested:
> > > >
> > > >
> > > > > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3?
> > > > > (These
> > > > >often show up problems with bugs in the pre-release versions of
> > > > >components such as X11 and compilers.)
> > > >
> > > >
> > > > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > > > yesterday.
> > > >
> > > > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> > > >
> > > > $ gcc --version
> > > > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> > > >
> > > > and make check-all passes with no problems.
> > > >
> > > > I have also installed all CRAN packages that do not require other 3rd
> > > > party drivers, etc. and there were no observed errors in those cases.
> > > >
> > > > So far, so good.
> > > >
> > > > If anything comes up, I will post a follow up.
> > > >
> > > > Best regards,
> > > >
> > > > Marc Schwartz
> > >
> > > Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> > > my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> > > A couple of f95 warnings whooshed by during the compile, that was all.
> > >
> > > By the way, I noticed that you can now "yum install R R-devel" and get
> > > everything straight from Fedora Extras.
> >
> > Yep. Tom "Spot" Callaway is the FE maintainer for R.
>
> I had a look at his RPM last night. It includes a patch for gcc4, which
> fails to build R with the fairly aggressive optimizations used by
> rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
> I'm not upgrading my work PC just yet, so I can't be sure). I folded
> this into R-patched. It's a shame he didn't send a bug report or, if he
> did, I missed it.
Thanks for looking into this. Do you know what is the time frame for
getting a new version into FC-E? Do we actually need separate CRAN
versions any more? BTW, I noticed that the Fedora RPMs depend on a
blas RPM. Do you have any inkling about what that implies? (I've never
quite understood whether there is a "right" way to use a machine
specific BLAS in concert with a packaging system).
> I also note he is using the patch that sets LANG=C, which is obsolete
> now that R supports utf-8 locales. I'll write to him (cc Marc) to let
> him know about these changes.
>
> The RedHat RPMS also use the shared library version of R. I've been
> thinking about making this change myself, despite the substantial speed
> penalty, since I've seen a growing number of people recompiling to get
> the shared library. The Red Hat choice forces my hand though: I don't
> want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
> installed packages don't work anymore. The $64,000 question is how many
> people are going to care about that 15-20% decrease in speed. Speak up
> now if it concerns you.
What is a good way to measure that? For hardcore numerics, it is
certainly much less than 15% on the AMD64:
# RPM:
> system.time(solve(matrix(rnorm(1e6),1e3)))
[1] 8.64 0.15 8.86 0.00 0.00
# My private build
[EMAIL PROTECTED] ~]$ r-patched/BUILD/bin/R -q
> system.time(solve(matrix(rnorm(1e6),1e3)))
[1] 8.49 0.15 8.64 0.00 0.00
(and there is a substantial replication variation on those numbers).
For more integer-bound stuff like
system.time(p <- replicate(1,t.test(rexp(25),mu=1)$p.value))
I get about 14.1s with the RPM and 11.7s with my build.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loess returns different standard errors for identical models (PR#7956)
[EMAIL PROTECTED] writes:
> Full_Name: Benjamin Tyner
> Version: 2.1.0, 4/18/2005
> OS: i686-redhat-linux-gnu
> Submission from: (NULL) (4.64.8.220)
>
>
> # Just run my.test() below in a newly opened R session. Once too many models
> have been fit (~20 on my system), the computed standard error jumps to a
> different value. This is (superficially) due to a different residual sum of
> squares, not a different one.delta. No other aspect of the fit is affected,
> just
> the computed value of s (I've run extensive testing with all.equal() to make
> sure). Issuing a garbage collection before doing a loess fit appears to
> "solve"
> the problem, which makes me think this is not a problem in loessc.c or
> loessf.f.
> My point is that a few loess fits in one session should not cause the
> estimated
> standard error computation go awry with no warning.
Right. Valgrind has this to say:
> my.test()
==22986== Use of uninitialised value of size 8
==22986==at 0x1C97051B: lowesb_ (loessf.f:1542)
==22986==by 0x1C95B399: loess_raw (loessc.c:98)
==22986==by 0x809C9AE: do_dotCode (dotcode.c:1709)
==22986==by 0x80B368F: Rf_eval (eval.c:405)
[1] "s = 0.857141235910414"
[1] "s = 0.857141235910414"
and that certainly fits the pattern.
Unfortunately this seems to be in the call to ehg31() in this passage
end if
setlf=(iv(27).ne.iv(25))
call ehg131(xx,yy,ww,trl,diagl,iv(20),iv(29),iv(3),iv(2),iv(5),
+ iv(17),iv(4),iv(6),iv(14),iv(19),wv(1),iv(iv(7)),iv(iv(8)),
+ iv(iv(9)),iv(iv(10)),iv(iv(22)),iv(iv(27)),wv(iv(11)),
+ iv(iv(23)),wv(iv(13)),wv(iv(12)),wv(iv(15)),wv(iv(16)),
+ wv(iv(18)),ifloor(iv(3)*wv(2)),wv(3),wv(iv(26)),wv(iv(24)),
+ wv(4),iv(30),iv(33),iv(32),iv(41),iv(iv(25)),wv(iv(34)),
+ setlf)
if(iv(14).lt.iv(6)+DBLE(iv(4))/2.D0)then
call ehg183('k-d tree limited by memory; nvmax=',
+iv(14),1,1)
(line numbers in optimized code are somewhat unreliable), so there are
quite a few items to check. Dumping out the iv and wv arrays at that
point is probably a good start if you want to chip in with a bit
of debugging. Do yourself a favour and use set.seed() with a value
that gives you a minimal repeat count when you start R in a clean state.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loess returns different standard errors for identical models (PR#7956)
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > I've seen many similar things in a report from valgrind. But they > went away when compiled without optimization: it seems optimization > often does a fetch one element off the end of an array when attempting > to keep the pipelines full. > I'd start by re-running the valgrind tests without optimization. I was going to anyway, but the reported problem did carry all the hallmarks of the use of a memory location with random content. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loess returns different standard errors for identical models (PR#7956)
Peter Dalgaard <[EMAIL PROTECTED]> writes: > Prof Brian Ripley <[EMAIL PROTECTED]> writes: > > > I've seen many similar things in a report from valgrind. But they > > went away when compiled without optimization: it seems optimization > > often does a fetch one element off the end of an array when attempting > > to keep the pipelines full. > > > I'd start by re-running the valgrind tests without optimization. > > I was going to anyway, but the reported problem did carry all the > hallmarks of the use of a memory location with random content. Still present with "-g" recompile, and a breakpoint in lowesb showed that the last call had garbage in the "iv" array. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loess returns different standard errors for identical models (PR#7956)
Peter Dalgaard <[EMAIL PROTECTED]> writes: > Peter Dalgaard <[EMAIL PROTECTED]> writes: > > > Prof Brian Ripley <[EMAIL PROTECTED]> writes: > > > > > I've seen many similar things in a report from valgrind. But they > > > went away when compiled without optimization: it seems optimization > > > often does a fetch one element off the end of an array when attempting > > > to keep the pipelines full. > > > > > I'd start by re-running the valgrind tests without optimization. > > > > I was going to anyway, but the reported problem did carry all the > > hallmarks of the use of a memory location with random content. > > Still present with "-g" recompile, and a breakpoint in lowesb showed > that the last call had garbage in the "iv" array. The latter turned out to be a red herring. Apparently a gdb bug messed up the "x/50d" command that I was using to inspect the array. The real problem was in other arguments, namely "diagl" and "trl" which are declared double precision, but passed "&zero" where "zero" is declared to be of type "Sint". Now, the 64000$ question is whether it is safe to try and fix it for 2.1.1... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion for the R Bugs web page
Marc Schwartz <[EMAIL PROTECTED]> writes: > > Note that we (well, primarily Peter Dalgaard) have considered > > complete changes to the R-bugs "system" anyway some of which > > would obliterate the e-mail interface completely IIRC. > > Bugzilla? ;-) > > JitterBug of course is no longer actively maintained by the Samba folks. X-actly. No need for the smiley. Apart from the maintenance issue, we also have the problem of spam injection, aggravated by the fact that Jitterbug is chopping headers off incoming mail, so that it looks like it comes from us. We did get blackholed at one point - the entire pubhealth department... It would be a no-brainer to switch to Bugzilla, were it not for the 3000 or so messages that are already sitting in the Jitterbug database. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion for the R Bugs web page
Marc Schwartz <[EMAIL PROTECTED]> writes: > On Wed, 2005-06-22 at 21:15 +0200, Peter Dalgaard wrote: > > Marc Schwartz <[EMAIL PROTECTED]> writes: > > > > > > Note that we (well, primarily Peter Dalgaard) have considered > > > > complete changes to the R-bugs "system" anyway some of which > > > > would obliterate the e-mail interface completely IIRC. > > > > > > Bugzilla? ;-) > > > > > > JitterBug of course is no longer actively maintained by the Samba folks. > > > > X-actly. No need for the smiley. Apart from the maintenance issue, we > > also have the problem of spam injection, aggravated by the fact that > > Jitterbug is chopping headers off incoming mail, so that it looks like > > it comes from us. We did get blackholed at one point - the entire > > pubhealth department... > > Ouch. That's not good. Fortunately, we got pulled out of the hole relatively fast, because Duncan Murdoch knew the mechanisms. And fortunately, not every recipient uses those blackhole lists. > Perhaps that's one of many reasons that the Samba folks themselves have > switched to Bugzilla? Andrew Tridgell will have known about the lack of maintenance for a while... The idea of putting a public mailing list into the loop wasn't part of the original design. The code to prevent duplicates from messages sent to both r-bugs and r-devel was a local hack. > > It would be a no-brainer to switch to Bugzilla, were it not for the > > 3000 or so messages that are already sitting in the Jitterbug > > database. > > Might the python script linked at the follow Bugzilla report be of use? > > https://bugzilla.mozilla.org/show_bug.cgi?id=124869 > > See the attachment in Comment #1: > > https://bugzilla.mozilla.org/attachment.cgi?id=69233 > > as the author's web site link appears to be offline. I don't know > python, so I would defer to others with more expertise as to whether the > above is useful "as is", or might serve as a starting point. Yes, I got the bright idea of googling for "jitterbug bugzilla" just after replying as well... It does look quite useful. Not that I speak Python either (Monty excepted), but the scheme he has been converting from - status encoded in the directory name - is quite similar to our slightly simpler Foo/Foo-fixed convention. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list.files() reorders files in R CMD INSALL
Duncan Murdoch <[EMAIL PROTECTED]> writes: > >> [1] "a" "A" "b" "B" > >> > >> which differs in order from that in R CMD INSTALL. > > > > Looks like the sorting is being done in the C locale in the first case, > > and in a different one in the second. See ?locales for how to set the > > locale to what you want. > > ... when in R, and see the R Extensions manual for setting it during the > INSTALL. However, notice that the C locale is generally enforced for a reason: Sometimes the order of files matter, e.g. the file zzz.R is designed to come last, but in en_GB it actually comes before Zeke.R and in Estonian z comes between s and t... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Objects and regex (PR#7970)
[EMAIL PROTECTED] writes: > Full_Name: Rafal Kustra > Version: 2.1.0 > OS: Linux > Submission from: (NULL) (64.229.198.89) > > > objects(pattern="^genes?$") returns "generateSigma" among other legal things. Not on my 2.1.1: > generateSigma <-1 > objects(pattern="^genes?$") character(0) > objects(pattern="^genes?") [1] "generateSigma" So. on what system did this happen? -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot by factor (Package base version 2.1.1) ( PR#7976)
"Liaw, Andy" <[EMAIL PROTECTED]> writes: > The issue is not with boxplot, but with split. boxplot.formula() > calls boxplot(split(split(mf[[response]], mf[-response]), ...), > but look at what split() returns when there are empty levels in > the factor: > > > f <- factor(gl(3, 6), levels=1:5) > > y <- rnorm(f) > > split(y, f) > $"1" > [1] 0.4832124 1.1924811 0.3657797 1.7400198 0.5577356 0.9889520 > > $"2" > [1] -1.1296642 -0.4808355 -0.2789933 0.1220718 0.1287742 -0.7573801 > > $"3" > [1] 1.2320902 0.5090700 -1.5508074 2.1373780 1.1681297 -0.7151561 > > The "culprit" is the following in split.default(): > > f <- factor(f) > > which drops empty levels in f, if there are any. BTW, ?split doesn't > mention what it does in such situation. Perhaps it should? > > If this is to be "fixed", I suppose an additional argument, e.g., > drop=TRUE, can be added, and the corresponding line mentioned > above changed to something like: > > if (drop || !is.factor(f)) f <- factor(f) > > Then this additional argument can be pass on from boxplot.formula() to > split(). Alternatively, I suspect that the intention was as.factor() rather than factor(). It does require a bit of care to fix it that way, though. There could be problems with empty levels popping up in unexpected places. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load in linux: missing libraries?
Tyler Smith <[EMAIL PROTECTED]> writes:
> Hi,
>
> I've just about got myself transferred from windowsXP to Linux (Mepis
> 3.3.1-1). I've got R 2.1.1, emacs, and ess running from the debian
> repositories. Of course, there is a hitch. I have a bit of C code in one
> of my personal functions. I have, apparently without problem, been able
> to compile it using R CMD SHLIB, but when I try to dyn.load it I get the
> following error:
>
> > dyn.load("Cfiles/Neutral/Bell2000.dll")
> Error in dyn.load(x, as.logical(local), as.logical(now)) :
> unable to load shared library
> '/home/tyler/RWorkingDirectory/Cfiles/Neutral/Bell2000.dll':
> /home/tyler/RWorkingDirectory/Cfiles/Neutral/Bell2000.dll: invalid ELF
> header
>
> I take this to mean one of the required libraries is either not loaded
> or not updated. Or, I've overlooked something. Can anyone point me to a
> solution? I tried updating my perl files, and I haven't found anything
> using the R Site Search...
Nope, the missing library is the one that you're trying to load.
Dynamic libraries are not called .dll on Linux, but rather .so...
You should probably read up on "Writing R Extensions", including the
hints on how to write portable code (use library.dynam).
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_alloc problems in R v1.11
Marie-Hélène Ouellette <[EMAIL PROTECTED]> writes:
> Dear Dr. Ripley,
Believe it or not, there are several people on this list who are not
Dr.Ripley. In fact, I suspect that he is temporarily absent these
days. Had he been present he would likely have explained that none of
us need to read the same message five times over...
> I'm using the R v1.11 on Macintoch and I seem to have a problem with the
Say what? There was never an R version with that number. Is this Mac OS X
or classic Mac?
> function R_alloc. It crashes when using the following .C function (only an
> example):
*How* does it "crash"? R shuts down? Prints an infinite stream of "salut!!!"?
What did you do to compile and did you see any warnings from the compilation?
> ///
> # include
> void Hello(int *n)
> {
> int i,x;
> for(i=1;1< *n ; i++)
> {
> Rprintf('salut!!!\n');
> }
> x = (int *) R_alloc(5,sizeof(int));
> }
>
> ///
>
> I call it in R with this line:
>
> .C('Hello',as.integer(5))
and then what happens?
> Any idea why and how I can resolve this problem?
Well, if that is really your code, x is an int that gets an int *
assigned to it, but 1 is never going to be bigger than *n, so I don't
see how you'd get that far.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave resource leak: leftover temp files (PR#7999)
Gabor Grothendieck <[EMAIL PROTECTED]> writes: > On 7/8/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > > We're planning (or in the process of?) changing the bug reporting > > system, so this is only a temporary inconvenience. > > > > I think these points have been raised before but, just in case, some > aspects of this, if its changing anyways, that would be nice to see > would be: > > - integration with svn > - expansion from bug tracking to issue, change and wishlist tracking > > Also it would be nice to have a consistent standard way to: > > - track issues, changes and wishlists in individual packages, not just in R Well, since I'm going on vacation as of *now*, it's not going to happen until August... Re. the last point, it does require that package maintainers play along. They have not been very good at closing issues in the Add-on section of the current bug repo, which is why we currently recommend users to approach the maintainer directly. As a general matter, nobody is going to do bug repository maintenance as a full-time job, so we need to go with a turnkey solution like Bugzilla. We're likely going to lose the mailing list integration as we know it -- we can probably send a copy of all bug reports to r-devel, but there's not going to be a nice way to save the followups automagically. Users will also likely be requested to obtain a password and login before submitting a bug. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
Robin Hankin <[EMAIL PROTECTED]> writes: > Hi guys > > another option would be David Gillespie's "calc", which is written > in emacs lisp. > > This is a stable system with (AFAICS) as large user base. > > Unfortunately, it doesn't seem to be actively developed, as the last > stable version (2.02f) > appears to be 1996. I don't know if this would be a contraindication. Heh. I remember trying calc when it was still relatively new. Never got to be very productive with it. I suppose that's sort of a contraindication (it might just be the user of course). The two ideas that Simon and Gabor brought up bouth sound like they might fly. Especially the existence of something with a Python interface sounds attractive, since that might not be too hard to clone or paraphrase in R. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
Rob J Goedman <[EMAIL PROTECTED]> writes:
> A really simple way to play with R & yacas is by using the examples
> in the subdir
> 'embed' of yacas-1.0.57.
>
> After building yacas (on Mac OS in my case):
>
> > res<-system("~/Projects/yacas-1.0.57/embed/example2", intern=T)
> > res
> [1] "Cos(x);"
>
> or
>
> > res<-system("~/Projects/yacas-1.0.57/embed/example1 'D(x){{Sin
> (x),Cos(x)}, {Sin(2*x),-Cos(x)}}'", intern=T)
> > res
> [1] "Input> D(x){{Sin(x),Cos(x)}, {Sin(2*x),-Cos(x)}}"
> [2] "Output> {{Cos(x),-Sin(x)},{2*Cos(2*x),Sin(x)}};"
>
> or
>
> > system("yacas -pc --execute '[Echo(D(x)Sin(x));Exit();]'")
> Cos(x)
>
> or
>
> > system("echo 'Example()' | yacas_client")
> In> Example()
> Current example : Integrate(x,a,b)Sin(x);
>
> Integrate a function.
>
> Out> Cos(a)-Cos(b)
> In>
> > system("echo 'Type(%)' | yacas_client")
> In> Type(%)
> Out> "-"
> In>
>
> This last example does show the yacas server stays alive between
> calls from R. yacas_client is a script.
> Maybe that approach also works for maxima?
>
> I wonder how difficult it would be to translate expressions back and
> forth from R to yacas in either R
> or C++. And maybe strip 'In>' and 'Out>' like parts.
You could also just do what those examples do and embed the whole
enchillada in R. The slightly bad news is that the yacas_eval
interface is text-based, which means that to handle an R expression
via yacas you're going through a deparse-parse-operate-deparse-parse
sequence. It would be nicer if you could just convert parse trees
between the two languages. The good news is that there's a Lisp route
(see example3), which should make the parser/deparser coding somewhat
easier.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
Ayal Pinkus <[EMAIL PROTECTED]> writes: > Hi, > I am the maintainer of Yacas. I decided to join this mailing list > after having heard that > the option of linking R to Yacas was being discussed. Please don't > hesitate to ask > if you have questions, I will try to find the time to help. > Ayal Interesting... Nice initiative! The thing that I wonder is whether it would be possible to embed Yacas at a lower level than via the parser. E.g. the Tcl embedding has Tcl_EvalObjEx() and friends, which operate on preparsed Tcl objects. Using this instead of Tcl_Eval() gives some efficiency gain, but more importantly, it avoids the "quoting hell" associated with the construction of the relevant command strings. Since both R and Yacas are "Lisp under the hood" languages (and Tcl too for that matter), it is a fairly good guess that their parse trees are similar, and that it would be a fairly simple task to translate back and forth between them. Well, between suitable subsets, at least. R's parse trees can in principle contain arbitrary R objects, but in this context, we might only need constants, names, operators, and function calls. It is probably not quite as easy as it sounds (is it ever?) but it could be worth it anyway. The main thing that it would require is an extended Yacas API which allows you to create Yacas objects from C code. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Computer algebra in R - would that be an idea??
Ayal Pinkus <[EMAIL PROTECTED]> writes: > Hi, > > > > > R builds fine under Windows (though you need to pay attention to > > the details > > which are in the (binary) distribution in the pdf files, in > > particular: `R > > Installation and Administration Manual', a html copy is also on the > > website; > > and the README* and INSTALL files in src/gnuwin32/ ). These > > details look > > tedious at first, and you may have to install a few things, but it > > keeps the > > sources closely tied between Windoze and the Unixish operating > > systems on > > which many of us prefer to develop. > > > > Ok. Unfortunately I work on a Mac OS X at home (I have access to > Windows, MS DevStudio > at work but want to keep work and hobby separate). I do work with > Xcode (have to > delve deeper in to Cocoa still though). Can integration also be done > on Mac OS X? > If I understood correctly you go the COM route for integration on > Windows? Whoa! Be careful there, there is no collective "you"; this is a mailing list. Søren, Dirk, Gabor, and I are four quite distinct people, and at least Dirk and I are Linux people who would rather not touch COM... Especially not when there's a perfectly fine library embedding method available. This approach usually works across all platforms although Windows and Macs tend to require a few extra twists. (I'm not up to speed on Macs. I gather that OS X managed to mess up dynamic linking somewhat but I believe it has all been sorted. You should probably have a peek at the MacOSX FAQ at http://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html and the page http://www.economia.unimi.it/R) > CrystalSpace is a 3d engine that has a COM simulation layer for Unix- > style platforms > I think (last time I looked was a few years back). It would > essentially be a thin layer > to implementations of abstract classes. > > I did download R for Mac OS X. It is quite a nice package! I wish I > had looked at it earlier. > You did a very good job on the user interface. ...and Stefano and Simon who were the main players in this development are yet another different "you". > > > Allow me to add that this sounds very exciting. > > I agree! > > I am working on a Java port at the moment. I will try to make some > time later this evening > or perhaps somewhere this week. Sounds good. I wish I had more time for this, but there's a deadline approaching... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R
Jeff Gentry <[EMAIL PROTECTED]> writes:
> I initially thought this only was the case for me on R-devel, but also
> just tested it on the current R-patched and R-2.1.1 (so perhaps this more
> belongs on R-help, but ...).
>
> I'm having an odd error with the makefiles in src/library/XXX while
> building R. When it tries to create the 'po' directory, the Makefile
> specifies:
>
> @if test -d $(srcdir)/inst/po; then \
> $(MKINSTALLDIRS) $(top_builddir)/library/$(pkg)/po; \
> cp -pr $(srcdir)/inst/po/* $(top_builddir)/library/$(pkg)/po; \
> find "$(top_builddir)/library/$(pkg)/po" -name .svn -type d
> -prune \
> -exec rm -rf \{\} \; 2>/dev/null; \
> fi
>
> However, mine dies with the error:
> make[3]: Entering directory
> `/mnt/disk2/home/jgentry/R-devel/src/library/base'
> building package 'base'
> all.R is unchanged
> make[3]: *** [all] Error 127
> make[3]: Leaving directory
> `/mnt/disk2/home/jgentry/R-devel/src/library/base'
> make[2]: *** [R] Error 1
>
> If I put an echo in between the find and the 'fi', it will no longer throw
> an error and go to the next package (where it will fail as I didn't put
> the echo in there, presumably I could go and put an echo in all of the
> base packages and my install would work though).
>
> Has anyone seen this?
>
> FWIW I'm using an AMD x86_64 machine, running RHEL WS 3.2
>
> Thanks
Hi Jeff,
Hmm, it's not happening for me on FC4/x86_64.
You seen to be building in the source directory. Could you try with a
separate builddir?
Perhaps get rid of the @ in @if and the 2>/dev/null so we get to see a
bit more of the the error messages.
What you're seeing is consistent with an error return from find, I
think. So perhaps look at the permission in the srcdir? Just a
conjecture.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Follow-Up: R on FC4
Gavin Simpson <[EMAIL PROTECTED]> writes: > > Try this again -- it is a random test. If it fails again then something > > is wrong. The tolerance on these tests is not very tight, certainly > > nowhere near rounding error. > > Thanks Thomas, > > A re-compile with the same options of R-Devel went through without > error. > > So far so good with FC4, gcc4, gfortran and R! The problem affecting the Fedora Extras RPM is still there with the new compilers though: -Wp,-D_FORTIFY_SOURCE=2 combined with -O or -O2 causes a strange printing bug: > matrix(list(pi)) [,1] [1,] (You don't have to use that option of course, but it suggests that not all is well with the optimizer. And the Fedora maintainer seem set on using it, which is a bit of a problem.) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Follow-Up: R on FC4
Peter Dalgaard <[EMAIL PROTECTED]> writes:
> Gavin Simpson <[EMAIL PROTECTED]> writes:
> > So far so good with FC4, gcc4, gfortran and R!
>
> The problem affecting the Fedora Extras RPM is still there with the
> new compilers though:
>
> -Wp,-D_FORTIFY_SOURCE=2
>
> combined with -O or -O2 causes a strange printing bug:
>
> > matrix(list(pi))
> [,1]
> [1,]
>
> (You don't have to use that option of course, but it suggests that not
> all is well with the optimizer. And the Fedora maintainer seem set on
> using it, which is a bit of a problem.)
I'm fairly sure by now that this is actually a bug in R, not gcc. We
have the same internal buffer structure used in EncodeReal and in
Rsprintf, and the return value of the former is buffer->data
which is reallocated by the latter.
That means that constructions of the form
pbuf = Rsprintf("%s", EncodeReal(REAL(tmp)[0], w, d, e, OutDec));
are playing with fire. There are quite a few other similar
constructions involving Encode*.
I suspect is is necessary to copy the result of
EncodeReal(REAL(tmp)[0], w, d, e, OutDec) to temp storage, or -
probably easier - use a separate buffer for Rsprintf.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] valgrind complains about regex.c (PR#8043)
[EMAIL PROTECTED] writes: > On Tue, Aug 02, 2005 at 07:50:54AM -0400, Duncan Murdoch wrote: > > Charlie, have you tried a recent version of R-patched? > > Now I have. The computer is my laptop and not connected to the net > so I can't upload details, but R-1.2.1-patched as of yesterday does ### This email has been a LONG time underway? ;-) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] quirky behavior from rbinom (PR#8071)
[EMAIL PROTECTED] writes: > Full_Name: Chris Paulse > Version: 2.1.1 > OS: WinXP > Submission from: (NULL) (129.98.60.134) > > > This seems strange. I have a small block of code that repeatedly calls > rbinom. > I put a break in there in case it returns NaN, as I've been having problems > with > this. Here is a transcript from the debug session: > > Browse[1]> theP > [1] 1 > Browse[1]> yleft[dataIndex] > [1] 3 > Browse[1]> rbinom(1,3,1) > [1] 3 > Browse[1]> rbinom(1,yleft[dataIndex], theP) > [1] NaN > > Strange, huh? What is "theP - 1"? > rbinom(1,3,1+1e-10) [1] NaN > 1+1e-10 [1] 1 -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] kendall tau correlation test for ties: Potential error (PR#8076)
[EMAIL PROTECTED] writes:
> } else {
> STATISTIC <- c(z = r / sqrt((4 * n + 10) / (9 * n*(n-1
> p <- pnorm(STATISTIC)
> if(exact && TIES)
> warning("Cannot compute exact p-value with ties")
> }
> }
> } else {
> // OMITTED
> }
> }
>
> if(is.null(PVAL)) # for "pearson" only, currently
> PVAL <- switch(alternative,
> "less" = p,
> "greater" = 1 - p,
> "two.sided" = 2 * min(p, 1 - p))
...
>
> Please look at the computation of the p-value for Kendalls tau. There is an
> assignment to "p" right above the warning. In the bottom of the function there
> is a comment that for the pearson case we have to use the modification and set
> PVAL.
>
> The problem is:
> * Either the comment is wrong because the modification should be done with
> kendall too, or
> * The variable PVAL has to be assigned in the kendall block.
>
> I hope this is clear so far.
I think it is the comment that is wrong. The calculation of
opposite-side one-sided and two-sided alternatives make OK sense when
the normal approximation of the test statistic is being used. It's
when you use a discrete distribution that you need to be careful.
(As brought up recently, the normal approximation itself is not too
hot in the tied case, but that's another matter.)
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in L-BFGS-B? (PR#8099)
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > Check your versions of MASS. The Windows one appears to be an outdated > version, and does different things. Forgetting to run tools/rsync-recommended during build will do that sort of thing to you, but it would seem that Berwin used a binary download. But of course he might be picking up an older version of the package from a private library. > As for the problem, yes it probably is a bug in L-BFGS-B. Fancy debugging > the code? B. might just be capable of it, but this is certainly some of the more impenetrable code in R. While he (or anyone else) is in there, there seems to be another problem in that the Hessian calculations refuse to stay within the bounds (which is pretty annoying when the objective function is undefined outside of them). Try for instance f <- function(p) sum(ifelse(p>=-1e-4,p,Inf)^2) optim(f, lower=c(0,0), par=c(5,5), method="L-BFGS-B") optim(f, lower=c(0,0), par=c(5,5), method="L-BFGS-B", hess=T) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Coding standards (was Re: bug in L-BFGS-B? (PR#8099))
Berwin A Turlach <[EMAIL PROTECTED]> writes: > The problem is, that the code produced by f2c is decrementing pointers > to simulate 1-based vectors and the C FAQ is pretty unambigious about > the fact that this provokes undefined behaviour, see > http://www.eskimo.com/~scs/C-faq/q6.17.html > > As far as I understand, this translated code mostly stems from the > time when some platforms did not have ready access to a fortran > compiler and, hence, f2c was used (extensively?). But now, with g77 > this does not seem to be an issue anymore. So I wonder whether there > are any plans of returning to the original fortran code? Or are there > plans to clean up these f2c'd code snippet to make them ANSI C > compliant? There's more to it than that. F2c has also been used in places to make Fortran code reentrant, which it is generally not. I forget whether we were ever bitten by nested calls to optim(), but we certainly was by integrate(). There is of course no argument against the fact that the pointer-decrement trick goes against the C specs, but I do wonder whether it is *actually* biting anyone these days. The remarks in the C FAQ seem to mainly refer to segmented architectures like the original IBM PC. With modern flat address spaces, it would seem quite unlikely to run into trouble. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] test for readline installation fails if installation location non-standard (PR#8104)
[EMAIL PROTECTED] writes: > Full_Name: D Kreil > Version: 2.1.1 > OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license > Submission from: (NULL) (62.178.15.60) > > > When the dependency readline is installed in a non-standard location the > installation procedure fails. > If using a non-standard installation location like > > --prefix=/bi/common --exec-prefix=/bi/arch > > the configure script default include and library paths should adapt > accordingly. > They don't (/usr/local defaults remain). > > Workaround: > > CPPFLAGS=-I/bi/common/include LDFLAGS=-L/bi/arch/lib ./configure > > This should not be necessary, I think. This is inherited from GNU autotools and apparently they think it should. It is most certainly not a bug. Presumably, the rationale is that the install target is not necessarily releated to your build tools and libraries. You could have --prefix=. or --prefix=$HOME/tools or whatever. If so, there is some danger of picking up a home-built and outdated version instead of the system one. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and Segmentation Fault
Ricardo Luiz Andrade Abrantes <[EMAIL PROTECTED]> writes: > Hello to everybody! > After reading all the C code, checking for problems, and find nothing, I > decided something a little bit different... > If my ".so" library works in a wrog way in R it should do the same in C. So > I created a C program that loads my library file and the executes the same > function R is executing. > The program worked perfectly! In fact I changed two things in my library: > The function I call now return an int, not a SEXP, and the return value is 0 > not R_NilValue. > Valgrind's output is ok too... > If .Call has no problems, and if my function works perfect when called from > a C program, where the problem lies? Why my program becomes "crazy" when I > run it from R? > I would apreciate very much your help! I don't where else I could find help > on this. Well, did you try running under a debugger? R -d gdb then "bt" after the segfault. (Make sure that things are compiled with -g option) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] update.packages forces Tcl/Tk interface despite ask=TRUE if the DISPLAY environment variable is set (PR#8115)
[EMAIL PROTECTED] writes: > Full_Name: Robert King > Version: 2.1.1 > OS: Linux (debian stable, with backport R) > Submission from: (NULL) (142.58.147.28) > > > update.packages documentation (and code, from what I can make out) says: > > ask: logical indicating whether to ask user before packages are > actually downloaded and installed, or the character string > '"graphics"', which brings up a widget to allow the user to > (de-)select from the list of packages which could be updated. >The latter only works on systems with a GUI version of > 'select.list', and is otherwise equivalent to 'ask = TRUE'. > > But, if I try ask=TRUE, it tries loading the Tcl/Tk interface (which I found > out > because I'm doing this remotely and it crashed. > > > update.packages(ask=TRUE) > --- Please select a CRAN mirror for use in this session --- > Loading Tcl/Tk interface ... Error in fun(...) : Tcl already loaded > Error: .onLoad failed in 'loadNamespace' for 'tcltk' > > On the other hand, if I log out and ssh back with X forwarding turned off, it > does the right thing, This is unrelated to ask=TRUE. It is during the choice of CRAN site that R is trying to fire up a Tk listbox (it might be debated whether this is a good idea, but it _is_ intentional). If you set the repository yourself, this won't happen. The error looks a bit odd though. The logic is supposed to be that either you have Tcl/Tk capabilities and you get the popup, or you don't and get a text menu. So something appears not right with your Tcl/Tk configuration. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
Jennifer Lai <[EMAIL PROTECTED]> writes: > Hi, > I built R with Portland Group compiler, but I noticed one thing that > when I ran configure for the first time on AMD machine, I got the > following error: > > > checking whether the C compiler works... configure: error: cannot run C > compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details. > > > > so I tried to set host=x86_64-unknown-linux-gnu, which seems to work, > except what puzzles me is that there is warning messages indicating C > longs are 4 bytes. > > *** > % configure --host=x86_64-unknown-linux-gnu > . > . > . > R is now configured for x86_64-unknown-linux-gnu > > Source directory: . > Installation directory:/usr/local/R.pgcc > > C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g -O2 > -mieee-fp > C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g > Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 > > Interfaces supported: X11 > External libraries:readline > Additional capabilities: PNG, JPEG, MBCS, NLS > Options enabled: R profiling > > Recommended packages: yes > > configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu > configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu > configure: WARNING: you cannot build info or html versions of the R manuals > > > Am I defining a wrong host? You're not doing yourself a favour, anyway. 4-byte longs are definitely not a good idea on Linux. What is worse, you are building a cross-target, which means that configure is not even going to try running any compiled programs, not that they work any better than before. The thing to do is to look inside config.log and see what causes configure to conclude that you cannot run C compiled programs. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build Portland Group Compiler
Jennifer Lai <[EMAIL PROTECTED]> writes: > I can't duplicate the error message. After running "configure > --host=x86_64-unknow-linux-gnu" for the first time, I was able to run > configure without providing --host argument. Even start with a fresh > copy of R-devel didn't help me to get the original error. Is the host > info been cached somewhere in R? Not that I know of... Back in the old days we had config.cache playing tricks on people, but it shouldn't be there anymore. If you're not already doing so, do yourself a favour and build in a separate directory, keeping the sources untouched. It's much easier to clean up and start over that way. > >>Hi, > >>I built R with Portland Group compiler, but I noticed one thing > >> that when I ran configure for the first time on AMD machine, I got > >> the following error: > >> > >> > >> checking whether the C compiler works... configure: error: cannot > >> run C compiled programs. > >>If you meant to cross compile, use `--host'. > >>See `config.log' for more details. > >> > >> > >> > >> so I tried to set host=x86_64-unknown-linux-gnu, which seems to > >> work, except what puzzles me is that there is warning messages > >> indicating C longs are 4 bytes. > >> > >>*** > >>% configure --host=x86_64-unknown-linux-gnu > >>. > >>. > >>. > >>R is now configured for x86_64-unknown-linux-gnu > >> > >> Source directory: . > >> Installation directory:/usr/local/R.pgcc > >> > >> C compiler:/usr/pgi/linux86-64/6.0/bin/pgcc -g > >> -O2 -mieee-fp > >> C++ compiler: /usr/pgi/linux86-64/6.0/bin/pgCC -g > >> Fortran compiler: /usr/pgi/linux86-64/6.0/bin/pgf77 -O2 > >> > >> Interfaces supported: X11 > >> External libraries:readline > >> Additional capabilities: PNG, JPEG, MBCS, NLS > >> Options enabled: R profiling > >> > >> Recommended packages: yes > >> > >>configure: WARNING: assuming C ints are 4 byte on x86_64-unknown-linux-gnu > >>configure: WARNING: assuming C longs are 4 byte on x86_64-unknown-linux-gnu > >>configure: WARNING: you cannot build info or html versions of the R manuals > >> > >> > >>Am I defining a wrong host? > >> > > > >You're not doing yourself a favour, anyway. 4-byte longs are > >definitely not a good idea on Linux. What is worse, you are building a > >cross-target, which means that configure is not even going to try > >running any compiled programs, not that they work any better than > >before. > > > >The thing to do is to look inside config.log and see what causes > >configure to conclude that you cannot run C compiled programs. > > > > > > > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.2.0 slated for October 6
We plan to release R version 2.2.0 on October 6. Daily alpha releases
will be available after the "Grand feature" freeze on September 8 and
beta releases from September 22. The full schedule is available on
http://developer.r-project.org (pending propagation delay from
https://svn.r-project.org/R-dev-web/trunk/index.html).
As usual, it is strongly preferred if bugs are discovered prior to the
release and not immediately afterwards! Please do try the
alpha/beta releases and report back any errors.
On behalf of the R Core Team
Peter Dalgaard
--
O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
"Milton Lopez" <[EMAIL PROTECTED]> writes: > I appreciate the update. We will consider using Linux, which leads me to > one more question: what is the maximum RAM that R can use on each > platform (Linux and Windows)? > > Thanks again for your prompt responses. On Win32, something like 3GB. Maybe a little more on Linux32, but there's a physical limit at 4GB. On Linux 64, the motherboards set the limit in practice, 32GB systems have been reported working and I think at least 64GB should be possible. I seem to recall that the maximum _virtual_ memory is not quite 2^64, but it will be pretty huge (2^48, 256TB)?. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
Martin Maechler <[EMAIL PROTECTED]> writes: > >>>>> "PD" == Peter Dalgaard <[EMAIL PROTECTED]> > >>>>> on 02 Sep 2005 18:48:24 +0200 writes: > > PD> "Milton Lopez" <[EMAIL PROTECTED]> writes: > > >> I appreciate the update. We will consider using Linux, > >> which leads me to one more question: what is the maximum > >> RAM that R can use on each platform (Linux and Windows)? > >> > >> Thanks again for your prompt responses. > > PD> On Win32, something like 3GB. Maybe a little more on > PD> Linux32, but there's a physical limit at 4GB. > > for a *single* object, yes. However (and Peter knows this > probably better than me ..), R's workspace can be very much > larger which makes it realistically possible to start *using* R > functions on objects of around 4GB. Notice that I said "Linux32" there The single-object size limit is of course relevant on 64 bit systems, so thanks for the reminder. > PD> On Linux 64, the motherboards set the limit in practice, > PD> 32GB systems have been reported working and I think at > PD> least 64GB should be possible. I seem to recall that the > PD> maximum _virtual_ memory is not quite 2^64, but it will > PD> be pretty huge (2^48, 256TB)?. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and Segmentation Fault
Ricardo Luiz Andrade Abrantes <[EMAIL PROTECTED]> writes:
> Hello there!
> I almost don't deal with SEXPs. The function's name is main() it returns a
> SEXP wich is R_NilValue, thats all I use of SEXPs. This function call an
> optimization packge and the output goes all to a text file.
> Well, I followed Mr. Lumley's hint and used gdb with R and my program.
> Together with a friend we could find the problem.
> Inside the Fortran optimization package there's a subroutine called cg(...),
> and for some wierd reason this subroutine is never called (so, some
> variables are not correctly initialized) and the program becomes crazy.
> I did this small example to show you what happens:
>
> File: prog.f
> -
> subroutine cg()
> write(*,*) 'Just a simple test'
> end
>
> subroutine program()
> write(*,*) 'Calling the function...'
> call cg()
> end
>
> File test.h
>
> #include "cfortran.h"
>
> PROTOCCALLSFSUB0(PROGRAM,program)
> #define program() CCALLSFSUB0(PROGRAM,program)
>
>
> File test.c
>
> #include
> #include
> #include
> #include "test.h"
>
>
> SEXP simple_program(){
> program();
> return R_NilValue;
> }
>
>
> I compile the C and Fortran souces into a shared lib. I open R, do a
> dyn.load("lib's name") and then a .Call("simple_program").
> What I got?
> Calling the function...
> Segmentation fault
>
> What if I change the cg function's name to pp? My Fortran code is now:
>
> File: prog.f
> -
> subroutine pp()
> write(*,*) 'Just a simple test'
> end
>
> subroutine program()
> write(*,*) 'Calling the function...'
> call pp()
> end
>
> And the output from R is:
>
> Calling the function...
> Just a simple test
> NULL
>
> Can anyone explain this? Is there a way to solve it? The optimization
> package I use has the "cg" function, and I cannot change it's name!
H Did you ever tell us
1) Exactly what your platform is
2) How you generated the shared library (R CMD SHLIB, or?)
3) What you did to load it into R
?
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C macros and Makevars/package building
Kasper Daniel Hansen <[EMAIL PROTECTED]> writes: > Hi > > We are currently embedding a rather large C++ library in R (BioC), > and we want some comments on the portability of how we have approach > this. > > First of, we are not really able to do much about the portability of > the basic library, which of course is the main question :) We have an > approach which seems to work, I just want a bit of feedback on it > > The way we integrate it into R is simply by having a subdirectory / > src/sdk together with a Makevars file. This file basically looks like > > PKG_CPPFLAGS+=\ >-imacros R_affx_constants.h\ >-Isdk/files\ > (... + a lot of other -I statements telling CPP to include > subdirectories of src/sdk) > > Then we have a > > SOURCES.SDK = \ >sdk/files/FileIO.cpp \ >(... + a lot of other .cpp files) > SOURCES.OURS = \ >R_affx_cdf.cpp > > and then finally a > > OBJS=$(SOURCES.SDK:.cpp=.o) $(SOURCES.OURS:cpp:.o) > > We seem to need the last statement since it seems that .cpp is not > automatically a C++ suffix (but is it done the "right" way for > portability?). Er, I don't think it has to do with .cpp being a known suffix or not. If it wasn't, you would use SUFFIXES and a .cpp.o rule. The last line comes from specifying sources, rather than objects. Traditional make style would be OBJS.SDK = \ sdk/files/FileIO.o \ (... + a lot of other .cpp files) OBJS.OURS = \ R_affx_cdf.o OBJS = $(OBJS.SDK) $(OBJS.OURS) from which the suffix rules would deduce the source files. > We need the -imacro statement in order to include some > macros from Rconfig.h (big endian checks) which are then translated > from the WORDS_BIGENDIAN used in R to the IS_BIG_ENDIAN used in the > library. > > Comments on the portability? > > Kasper > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nls fails to return correlation matrix (PR#8127)
[EMAIL PROTECTED] writes: > Full_Name: Carsten Urbach > Version: 2.1.1 (2005-06-20) > OS: Linux > Submission from: (NULL) (141.34.5.241) > > > I observed one case where nls failed to return the correlation matrix, while > the > parameter estimates were computed correctly. In the follwing I include all the > commands leading to this problem. R was started with 'R --vanilla': . > > Residual standard error: 0.001722 on 1 degrees of freedom > > Correlation of Parameter Estimates: > a b c d > b 1 > c , , 1 > d * , 1 > e . , * * > attr(,"legend") > [1] 0 0.3 . 0.6 , 0.8 + 0.9 * 0.95 B 1 And the problem was??? You may not like the graphical representation, but it is not a bug. Just use print(summary(fit),symbolic.cor=FALSE) to get rid of it. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in model.matrix
"Whit Armstrong" <[EMAIL PROTECTED]> writes: > Is this a bug, or have I misunderstood the proper use of lm? Dunno. It appears that logicals like factors are not supposed to have matrix structure. What actually happens is that setting contrasts strips dimension attributes Browse[1]> debug: for (nn in namD[isF]) if (is.null(attr(data[[nn]], "contrasts"))) contrasts(data[[nn]]) <- contr.funs[1 + isOF[nn]] Browse[1]> zz <- data[["y"]] Browse[1]> contrasts(zz) <- contrasts(zz) Browse[1]> zz [1] TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE FALSE TRUE FALSE [13] FALSE TRUE TRUE TRUE FALSE TRUE FALSE TRUE TRUE FALSE FALSE TRUE [25] TRUE TRUE FALSE FALSE FALSE FALSE TRUE FALSE FALSE TRUE TRUE FALSE [37] FALSE FALSE FALSE TRUE TRUE TRUE TRUE FALSE FALSE FALSE TRUE .. [85] TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE [97] TRUE TRUE TRUE FALSE Levels: FALSE TRUE which in turn comes from if (is.logical(x)) x <- factor(x, levels = c(FALSE, TRUE)) and the fact that factor() throws away dimensions. *If* it's a bug, I don't think it is easily fixable > Thanks, > Whit > > > code: > x <- rnorm(50) > y <- matrix(as.logical(round(runif(100),0)),ncol=2) > NROW(x)==NROW(y) > lm(x~y) > > > > > x <- rnorm(50) > > y <- matrix(as.logical(round(runif(100),0)),ncol=2) > > NROW(x)==NROW(y) > [1] TRUE > > lm(x~y) > Error in "[[<-.data.frame"(`*tmp*`, nn, value = c(2, 1, 2, 1, 1, 1, 2, > : > replacement has 100 rows, data has 50 > > > > > However, the call to lm works if the matrix is a numeric instead of > logical: > x <- rnorm(50) > y <- matrix(runif(100),ncol=2) > NROW(x)==NROW(y) > lm(x~y) > > > Seems to be a problem in model.matrix.default: > > debug: for (nn in namD[isF]) if (is.null(attr(data[[nn]], "contrasts"))) > contrasts(data[[nn]]) <- contr.funs[1 + > isOF[nn]] > Browse[1]> > Error in "[[<-.data.frame"(`*tmp*`, nn, value = c(1, 2, 2, 2, 2, 2, 2, > : > replacement has 100 rows, data has 50 > > > > > > R.Version() > $platform > [1] "i686-pc-linux-gnu" > > $arch > [1] "i686" > > $os > [1] "linux-gnu" > > $system > [1] "i686, linux-gnu" > > $status > [1] "alpha" > > $major > [1] "2" > > $minor > [1] "2.0" > > $year > [1] "2005" > > $month > [1] "09" > > $day > [1] "12" > > $"svn rev" > [1] "35558" > > $language > [1] "R" > > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.data.frame segfaults on large lists (PR#8141)
[EMAIL PROTECTED] writes: > Full_Name: Ulrich Poetter > Version: 2.1.1 > OS: i686-pc-linux-gnu FC2 > Submission from: (NULL) (134.147.95.187) > > > as.data.frame() segfaults on lists with very many elements: > > > dfn <- rep(list(rep(0,2)),198000) > > test <- as.data.frame.list(dfn) > > Process R segmentation fault at Sun Sep 18 17:06:02 2005 Not for me on FC4. The process size grows to about 180M and the system thrashes badly, but the calculation runs to completion. It's not unlikely that we are ignoring a failed allocation somewhere, but there's not much hope of finding it from the available information. You could try running under gdb and see where things go wrong for you. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Martyn Plummer <[EMAIL PROTECTED]> writes: > > The 'recompile with -fPIC' is bullsh*t. The problem is that is is looking > > in /usr/lib64/liblapack.a rather than /usr/lib64/liblapack.so.3 both of > > which > > exist. Some searching for this error message on Google shows a lot of > > questions about this problem but no solution that I found other than > > > > rm /usr/lib64/liblapack.a > > > > which I don't consider a solution. It will link with the .so as the bottom > > of the script shows > You would need to modify the LDFLAGS and CPPFLAGS environment variables, > as these default to -L/usr/local/lib and -I/usr/local/include > respectively. See Appendix B.3.3 of the R Installation and > Administration manual, which gives a warning about 64-bit systems. > > You can also use the --with-readline configure flag to specify the exact > location of the readline library you wish to use. How did _readline_ get into this? As a curiosity, I tried looking at what Fedora Core 4 does with this. So I looked for liblapack.a with locate, and it found one in /usr/lib (on a 32bit system). Then I went to have a closer look at the library and it turned out not to be there -- apparently the recent update to lapack had wiped it out, but the locate database was not yet rebuilt... This sort of suggests to me that removing the .a file might actually be a sensible thing to do on SuSE as well. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
José Matos <[EMAIL PROTECTED]> writes:
> Martyn Plummer wrote:
>
> > Fedora have just split off a separate lapack-devel package containing
> > the static library and the symlink liblapack.so. (Mandrake/Mandriva has
> > been doing this for some time. I don't know about SuSE). The up2date
> > service will recognize that it needs to update lapack, but I guess that
> > it won't install lapack-devel, as it doesn't know you need it.
>
> You are right.
>
> > It might have been better to do this in the next release, rather than as
> > an update to FC4, but there you go. Better install lapack-devel
> > manually.
>
> lapack belongs to Extras and not to Core. Extras is a rolling release.
>
> The change was necessary to allow atlas to compile and interact with
> lapack.
>
> atlas is on the queue to Fedora Extras, it is in the review phase now.
Hmm. Doesn't look like it is actually working, though. Install
lapack-devel, configure --with-lapack, and make check dies with
running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1
make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples'
make[3]: *** [test-Examples-Base] Error 2
[EMAIL PROTECTED] BUILD]$ tail tests/Examples/base-Ex.Rout.fail
> kappa(x2 <- cbind(x1,2:11))# high! [x2 is singular!]
[1] 8.351867e+16
>
> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
> sv9 <- svd(h9 <- hilbert(9))$ d
> kappa(h9)# pretty high!
[1] 728289254735
> kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DGEBRD' gave error code -10
Execution halted
This happens on both x86_64 and x86 installs of FC4.
I have a strong sense of deja vu regarding this error.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > Which confirms the wisdom of our advice not to use --with-lapack > unless you have to (a few systems do). (Quote from the R-admin manual > > this is definitely *not* recommended > > . Perhaps this needs to say `use at your own risk and do not report > problems with it'!) > > There are far too many rogue LAPACK builds out there in distros. Right, and I did of course know about the warning and the reason for it. I just thought that when yet another distro saw fit to put a liblapack out, the least we could do was to test it... > BTW, I don't understand how a Linux distro can supply ATLAS tuned to > my CPU/FPU. Dr Goto has had about ten versions of his optimized BLAS > covering just a small subset of i686 CPUs. So although a distro's > ATLAS may be better than a generic BLAS, it seems that it is likely to > be suboptimal, and perhaps disastrous (I've seen that with mobile > Pentium chips using ATLAS tuned on desktop machines). So the > recommendation must remain to tune ATLAS on your specific hardware. I don't think an RPM is restricted to contain only one version of the binaries, so in principle, the post-installer could adapt the installed version to your hardware, if it could narrow the choice down to a dozen versions or so. It's not easy though, since not only the CPU/FPU types factor in, but also cache sizes and memory speeds. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Assigning a zero length vector to a list (PR#8157)
Duncan Murdoch <[EMAIL PROTECTED]> writes: > After foo<-list(), foo$bar is NULL, so we can simplify this. > > Here's a simpler version: > > # These work, which is a bit of a surprise, but there is some > inconsistency: one x becomes a list, the other is numeric: > > x <- NULL > > x[[1]] <- 1:10 > > x > [[1]] > [1] 1 2 3 4 5 6 7 8 9 10 > > > x <- NULL > > x[[1]] <- 1 > > x > [1] 1 > > > # This generates the same bug as the above: > > x <- NULL > > x[[1]] <- numeric(0) > > x > [1] 4.250083e-314 > > It looks like we're trying to be too clever with handling assignments to > components of NULL. Wouldn't it make more sense for those to generate > an error? Once upon a time, we had pairlists, and NULL was the empty list. This looks like it might be a relic. If so, it likely also predates consistent handling of zero-length vectors, so something is getting confused. I think it would be reasonable to expect similar results to this: > x<-list() > x[[1]] <- numeric(0) > x [[1]] numeric(0) S-PLUS also tries to handle NULL as a zero length list, with some anomalies: > x <- NULL > x[[1]] <- numeric(0) > x $value: numeric(0) > x <- list() > x[[1]] <- numeric(0) > x [[1]]: numeric(0) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] looks in liblapack.a not liblapack.so
José Matos <[EMAIL PROTECTED]> writes:
> Peter Dalgaard wrote:
>
> > Hmm. Doesn't look like it is actually working, though. Install
> > lapack-devel, configure --with-lapack, and make check dies with
> >
> > running code in 'base-Ex.R' ...make[4]: *** [base-Ex.Rout] Error 1
> > make[4]: Leaving directory `/home/pd/r-devel/BUILD/tests/Examples'
> > make[3]: *** [test-Examples-Base] Error 2
> >
> > [EMAIL PROTECTED] BUILD]$ tail tests/Examples/base-Ex.Rout.fail
> >> kappa(x2 <- cbind(x1,2:11))# high! [x2 is singular!]
> > [1] 8.351867e+16
> >>
> >> hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
> >> sv9 <- svd(h9 <- hilbert(9))$ d
> >> kappa(h9)# pretty high!
> > [1] 728289254735
> >> kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
> > Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DGEBRD' gave error code
> > -10 Execution halted
> >
> > This happens on both x86_64 and x86 installs of FC4.
>
> I am sorry Peter, I am trying really hard to replicate this bug but I have
> not been able to see the same result, no matter what I try.
>
> I have download the latest tar ball and then I run:
>
> $ ./configure --with-lapack="-llapack -lblas"
> ...
> R is now configured for x86_64-unknown-linux-gnu
>
> Source directory: .
> Installation directory:/usr/local
>
> C compiler:gcc -g -O2
> C++ compiler: g++ -g -O2
> Fortran compiler: gfortran -g -O2
>
> Interfaces supported: X11
> External libraries:readline
> Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
> Options enabled: R profiling
>
> Recommended packages: yes
>
> $ make -j8
> $ make check
>
> It works.
>
> OTOH I am not sure that configure is accepting my options. Looking into
> config.log I don't see that value being used, and I noticed that the lapack
> module it is still being built.
>
> I read docs/manual/R-admin.html but without any difference. I have tried
> different forms:
>
> --with-lapack
> --with-lapack="-llapack -lcblas"
> --with-lapack="-llapack -lblas"
>
> What am I missing?
-L/usr/lib64 I think. I have
#LAPACK_LIBS="-L/usr/lib64 -llapack"
(commented out now) in config.site.
../R/configure --with-lapack="-L/usr/lib64 -llapack"
seems to work with FC4/Opteron (even with the configure line, you
still need to have at least "--with-lapack" on the command line, which
is a bit of a bug -- or will be one, once we stop advising against
using external lapack libs in the first place...).
A line like
External libraries:readline, BLAS(ATLAS), LAPACK(generic)
shows that R is not using the internal versions of BLAS/LAPACK. (Of
course, the ATLAS bit required more work...)
The latest updates to lapack seem not to have worked.
> > I have a strong sense of deja vu regarding this error.
>
> Thanks,
> --
> José AbÃlio
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] by() processing on a dataframe
Duncan Murdoch <[EMAIL PROTECTED]> writes:
> I want to calculate a statistic on a number of subgroups of a dataframe,
> then put the results into a dataframe. (What SAS PROC MEANS does, I
> think, though it's been years since I used it.)
>
> This is possible using by(), but it seems cumbersome and fragile. Is
> there a more straightforward way than this?
>
> Here's a simple example showing my current strategy:
>
> > dataset <- data.frame(gp1 = rep(1:2, c(4,4)), gp2 = rep(1:4,
> c(2,2,2,2)), value = rnorm(8))
> > dataset
>gp1 gp2 value
> 1 1 1 0.9493232
> 2 1 1 -0.0474712
> 3 1 2 -0.6808021
> 4 1 2 1.9894999
> 5 2 3 2.0154786
> 6 2 3 0.4333056
> 7 2 4 -0.4746228
> 8 2 4 0.6017522
> >
> > handleonegroup <- function(subset) data.frame(gp1 = subset$gp1[1],
> + gp2 = subset$gp2[1], statistic = mean(subset$value))
> >
> > bylist <- by(dataset, list(dataset$gp1, dataset$gp2), handleonegroup)
> >
> > result <- do.call('rbind', bylist)
> > result
> gp1 gp2 statistic
> 11 1 0.45092598
> 11 1 2 0.65434890
> 12 2 3 1.22439210
> 13 2 4 0.06356469
>
> tapply() is inappropriate because I don't have all possible combinations
> of gp1 and gp2 values, only some of them:
>
> > tapply(dataset$value, list(dataset$gp1, dataset$gp2), mean)
> 1 23 4
> 1 0.450926 0.6543489 NA NA
> 2 NANA 1.224392 0.06356469
>
>
>
> In the real case, I only have a very sparse subset of all the
> combinations, and tapply() and by() both die for lack of memory.
>
> Any suggestions on how to do what I want, without using SAS?
Have you tried aggregate()?
Alternatively, you migth split on interaction(, drop=TRUE)
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Option "installWithVers" seems to impact new.packages() badly?
"A.J. Rossini" <[EMAIL PROTECTED]> writes: > Also, I don't know what this has to do with BioC. This is core R, so > pertinent to this list. Otherwise, perhaps it should be taken out? ... > > > The issue is that installed.packages() has never been taught about > > > versioned installs, and you might like to take that up with your BioC > > > colleagues who added the idea. Brian can of course speak for himself, but I think his point was just that the request for the feature came from BioC, not that the discussion was on the wrong list. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes for large formulas in lm() (PR#8180)
"Ken Knoblauch" <[EMAIL PROTECTED]> writes: > Oops, sorry. I didn't notice the ^2... > Nevermind. You could still have a point, but with 255^2 terms (all but 255 of which will be redundant since x^2 == x:x == x in modeling language). Presumably someone thought that noone in their right mind would specify 65000 terms... > > Have you considered that 8 variables will give you > sum(choose(8,1:8)) > [1] 255 > terms. > That's a suspicious number. Have you checked whether there is a limit in > the code? > > - > Full_Name: Hallgeir Grinde > Version: 2.1.1 > OS: Windows XP > Submission from: (NULL) (144.127.1.1) > > > While using lm(y~(x*z*c*...*v)^2) R crashes/closes if the numbers of > variables > are at least 8. > -- > Ken Knoblauch > Inserm U371 > Cerveau et Vision > Dept. of Cognitive Neuroscience > 18 avenue du Doyen Lépine > 69500 Bron > France > tel: +33 (0)4 72 91 34 77 > fax: +33 (0)4 72 91 34 61 > portable: +33 (0)6 84 10 64 10 > http://www.lyon.inserm.fr/371/ > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ad: Re: R crashes for large formulas in lm() (PR#8180)
[EMAIL PROTECTED] writes: > Dette er en melding med flere deler i MIME-format. > --=_alternative 004613C000257091_= > Content-Type: text/plain; charset="US-ASCII" > > And some more informastion I forgot. > R does not crash if I write out the formula: > > set.seed(123) > x1 <- runif(1000) > x2 <- runif(1000) > x3 <- runif(1000) > x4 <- runif(1000) > x5 <- runif(1000) > x6 <- runif(1000) > x7 <- runif(1000) > x8 <- runif(1000) > y <- rnorm(1000) > fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) > -> R crashes > > fit <- lm(y~x1+x2+x3+x4+x5+x6+x7+x8 > +x1:x2+x1:x3+x1:x4+x1:x5+x1:x6+x1:x7+x1:x8 > +x2:x3++x2:x4+x2:x5+x2:x6+x2:x7+x2:x8 > +x3:x4+x3:x5+x3:x6+x3:x7+x3:x8 > +x4:x5+x4:x6+x4:x7+x4:x8 > +x5:x6+x5:x7+x5:x8 > +x6:x7+x6:x8 > +x7:x8) > -> R does not crash > This is the same formula, at least it should be. It isn't and it shouldn't. (Try it for smaller values of 8) y~(x1+x2+x3+x4+x5+x6+x7+x8)^2 should be same as the second formula, modulo the syntax error. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R in Spanish?
Kenneth Cabrera <[EMAIL PROTECTED]> writes: > Hi R developers: > > I want to ask if there is a Spanish R installation, http://developer.r-project.org/TranslationTeams.html doesn't seem to have a Spanish team. > if not, why not, well, someone has to write it I have been wondering about it, since Spanish is one of the Worlds' largest languages (if not _the_ largest), with a substantial proportion of non-English speakers. > and how can I help to > make the Spanish version, There's a fairly elaborate set of beginners instructions to .po files and all that, here: http://developer.r-project.org/Translations.html > if you tell me how > I am willing to help with it. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation of R-2.2.0 under SUSE 10
Rainer M Krug <[EMAIL PROTECTED]> writes: > Hi > > I hope this is the right list for the question. > I want to install R from source under SUSE 10. When executing ./Configure, I > get the following error message: > > checking for xmkmf... /usr/X11R6/bin/xmkmf > configure: WARNING: I could not determine FPICFLAGS. > configure: error: See the file INSTALL for more information. > > and it taborts. Consequently, make does not work. > > Any ideas? You probably want to look into config.log and see what caused the FPICFLAGS message. It could be an oblique way of telling you that you haven't installed a Fortran compiler. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation of R-2.2.0 under SUSE 10
Rainer M Krug <[EMAIL PROTECTED]> writes:
> Could you give me a hint what I should look for? I am quite new to Linux.
>
> Rainer
As long as you can see where it goes wrong, just ask again, citing the
relevant bit of the log. Finding this is a bit convoluted for the
FPICFLAGS issue because the failing test is just for whether the
variable was set earlier, which AFAICS should happen here:
## Step 2. GNU compilers.
if test "${GCC}" = yes; then
cpicflags="-fPIC"
shlib_ldflags="-shared"
fi
if test "${G77}" = yes; then
fpicflags="-fPIC"
fi
if test "${GXX}" = yes; then
cxxpicflags="-fPIC"
shlib_cxxldflags="-shared"
fi
Now, the natural guess is that ${G77} wasn't set earlier on, so look
for the place where it figures out the Fortran compiler.
>
> On Friday 14 October 2005 14:19, Peter Dalgaard wrote:
> > Rainer M Krug <[EMAIL PROTECTED]> writes:
> > > Hi
> > >
> > > I hope this is the right list for the question.
> > > I want to install R from source under SUSE 10. When executing
> > > ./Configure, I get the following error message:
> > >
> > > checking for xmkmf... /usr/X11R6/bin/xmkmf
> > > configure: WARNING: I could not determine FPICFLAGS.
> > > configure: error: See the file INSTALL for more information.
> > >
> > > and it taborts. Consequently, make does not work.
> > >
> > > Any ideas?
> >
> > You probably want to look into config.log and see what caused the
> > FPICFLAGS message. It could be an oblique way of telling you that you
> > haven't installed a Fortran compiler.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation of R-2.2.0 under SUSE 10
Detlef Steuer <[EMAIL PROTECTED]> writes: > Hi, > > most probably you are missing xorg-devel packages. > But there is another problem: > At least the downloadable version of 10.0 does not contain _any_ fortran > compiler. At least I´m unable to find one. > I don`t know about the retail box. > > Still looking for an easy way to build an rpm package for 10.0 using some > additional yast sources. Hmm. What's wrong with http://ftp.opensuse.org/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/x86_64/gcc-fortran-4.0.2_20050901-3.x86_64.rpm ? -p > Hope that helps > Detlef > > On Fri, 14 Oct 2005 14:48:26 +0200 > Rainer M Krug <[EMAIL PROTECTED]> wrote: > > > Could you give me a hint what I should look for? I am quite new to Linux. > > > > Rainer > > > > > > On Friday 14 October 2005 14:19, Peter Dalgaard wrote: > > > Rainer M Krug <[EMAIL PROTECTED]> writes: > > > > Hi > > > > > > > > I hope this is the right list for the question. > > > > I want to install R from source under SUSE 10. When executing > > > > ./Configure, I get the following error message: > > > > > > > > checking for xmkmf... /usr/X11R6/bin/xmkmf > > > > configure: WARNING: I could not determine FPICFLAGS. > > > > configure: error: See the file INSTALL for more information. > > > > > > > > and it taborts. Consequently, make does not work. > > > > > > > > Any ideas? > > > > > > You probably want to look into config.log and see what caused the > > > FPICFLAGS message. It could be an oblique way of telling you that you > > > haven't installed a Fortran compiler. > > > > __ > > 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 > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hiccup in installing R 2.2.0
Rolf Turner <[EMAIL PROTECTED]> writes:
> Yesterday I downloaded R-2.2.0.tar.gz, gunzipped and untarred, and
> did the usual ./configure and make. Everything seemed to go smoothly
> until it got to the bit about installing recommended packages. It
> got past ``spatial'' but turned up a fatal error in respect of the
> ``boot'' package.
>
> Here is some of what appeared on the screen:
>
> ===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===
> .
> .
> .
> trls.influencetexthtmllatex example
> trmat texthtmllatex example
> variogram texthtmllatex example
> ** building package indices ...
> * DONE (spatial)
> begin installing recommended package boot
> * Installing *source* package 'boot' ...
> mkdir: cannot create directory `/tmp/Rtmp9726': File exists
> ERROR: cannot create temporary R session directory
> ERROR: installing package DESCRIPTION failed
> /home/faculty/rolf/Rinst/R-2.2.0/bin/INSTALL: test: argument expected
> *** Error code 1
> make: Fatal error: Command failed for target `boot.ts'
> Current working directory
> /homes/faculty/rolf/Rinst/R-2.2.0/src/library/Recommended
> *** Error code 1
> make: Fatal error: Command failed for target `recommended-packages'
> Current working directory
> /homes/faculty/rolf/Rinst/R-2.2.0/src/library/Recommended
> *** Error code 1
> make: Fatal error: Command failed for target `stamp-recommended'
> ===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===
>
> The system I am working on is a ``sparc'' (from Sun) running
> Solaris 2.9.
>
> I checked on /tmp, and there was indeed a directory (empty) named
> Rtmp9726, owned by another user on our system. (It was dated October
> 7, 2005, i.e. about a week ago.) Fortunately (???) I have superuser
> priviledges, so I was able to remove this (empty) directory. I then
> tried ``make'' again, and this time it ran to completion. So I'm
> alright, Jack. It would seem however that something is not
> ***quite*** as it should be in the installation procedure. I thought
> I'd just draw this to youse guys' attention. :-)
This looks like it would be a generic issue, not particularly related
to installation. The code in question should be this:
#ifdef HAVE_MKDTEMP
sprintf(tmp1, "%s/RtmpXX", tm);
tmp = mkdtemp(tmp1);
if(!tmp) R_Suicide(_("cannot mkdir R_TempDir"));
#else
sprintf(tmp1, "rm -rf %s/Rtmp%u", tm, (unsigned int)getpid());
R_system(tmp1);
sprintf(tmp1, "%s/Rtmp%u", tm, (unsigned int)getpid());
res = mkdir(tmp1, 0755);
if(res) {
/* Try one more time, in case a dir left around from that
process number from another user */
sprintf(tmp1, "rm -rf %s/Rtmp%u-%d", tm, (unsigned int)getpid(),
rand() % 1000);
R_system(tmp1);
inside src/unix/sys-unix.c. I don't think Solaris has mkdtemp (ours
don't anyway), and the name of the conflicting dir indicates that the
code never went inside the if(res){...} so the conclusion would seem
to be that mkdir fails to fail when it should.
(Notice, BTW, that the name of the dir is keyed to the process ID of
R, so removing the exising directory doesn't really help you. The
thing that might help would be to remove all the Rtmp* directories at
boot and periodically before PID wraparound.)
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] drop() and "["(), and apply()
Dan Davison <[EMAIL PROTECTED]> writes: > I have two queries about the behaviour of drop() and apply() regarding the > dimnames and names(dimnames) of the answer. I would appreciate any > comments on this behaviour. I will submit any of this as a bug report if I > am encouraged to do so. > > The first query, concerning drop(), seems to me to be a bug in ?drop, and > possibly also in the function. > > ?drop: > [...] Any accompanying 'dimnames' attribute is adjusted and returned with > 'x'. > > > x <- array(dim=c(3,2,1), dimnames=list(A=NULL, B=NULL, C=NULL)) > > > attributes(drop(x)) > $dim > [1] 3 2 > > > attributes(x[,,]) > $dim > [1] 3 2 > > I expected a dimnames attribute equivalent to list(A=NULL, B=NULL). I > think ?drop is misleading. Is the behaviour intended? I think the logic is that if all dimnames are NULL, they are discarded from the result. This probably predates the use of named dimnames. Named NULL dimnames were not anticipated then, nor since... > ### > > I am less confident that the second query, concerning apply(), is a bug in > anything. But I would appreciate an explanation of the behaviour. > > > x <- array(dim=c(3,2), dimnames=list(A=1:3, B=1:2)) > > > apply(x, 1, function(row) row) > A > 1 2 3 >1 NA NA NA >2 NA NA NA > > > attributes(apply(x, 1, function(row) row)) > $dim > [1] 2 3 > > $dimnames > $dimnames[[1]] > [1] "1" "2" > > $dimnames$A > [1] "1" "2" "3" > > What has happened to the name of the first element of the list of dimnames > of the answer? It seems arguable that if the rows of the answer are > allowed to keep their names, then the name of that dimension should also > be preserved. Should the behaviour be better documented in ?apply (which > only discusses the effect on the dim attribute AFAICS). > > > Thanks for any comments. Please let me know if I should submit any bug > reports concerning any of the above. I think this happens because vectors cannot have named dimnames. Basically this happens because there's no obvious place to put it: > dput(c(a=1)) structure(1, .Names = "a") i.e., the names are in a vector, not a list. This is a bit of a bother (and forces the use of 1D arrays in some places, which in turn confuses code that expects a vector), but implementing code that carries an extra "name-name" attribute through all possible calculations have been considered unattractive... So, the function inside your apply() construct returns a vector with the right names, but loses the name of the names, at which point there is no way to retrieve them. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] BIC doesn't work for glm(family=binomial()) (PR#8208)
[EMAIL PROTECTED] writes: > Full_Name: Ju-Sung Lee > Version: 2.2.0 > OS: Windows XP > Submission from: (NULL) (66.93.61.221) > > > BIC() requires the attribute $nobs from the logLik object but the logLik of a > glm(formula,family=binomial()) object does not include $nobs. Adding > attr(obj,'nobs') = value, seems to allow BIC() to work. > > Reproducing the problem: > library(nmle); > BIC(logLik(glm(1~1,family=binomial(; It is not clear to me that "nobs" is a well-defined concept for arbitrary likelihood functions. In particular, binomial models are tricky: Is "13 successes in 79 trials" one (binomial) observation or 79 (Bernoulli) ones?? So BIC may not be defined. In which sense is this a bug, anyway? The BIC function is defined inside the nlme package which is not designed to work with anything but continuous data. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
erimental wxPython R package. However, it is still alpha, there are > > problems to finalize it, and his author is not continuing its > > development for reasons that are personal to him. So, I am not sure we > > will have a usable version available soon to integrate wxWidgets with R > > and use it for a R GUI. > > > > 3) JAVA. There is a good R GUI written in JAVA: JGR. Moreover, something > > like the Eclipse platform is a very promizing environment for a > > rich-featured R IDE. JAVA specialists in my University say such a GUI, > > written in JAVA will be relatively slow compared to other solutions. > > However, JGR is a good actual counter-example. > > > > 4) GTK2. Great widgets... but forgets Windows. I installed and used Gimp > > under Windows. This is certainly the best demonstration on what can be > > done with GTK2 under Windows. I must admit I am very disappointed as a > > Windows user: look&feel is very different, and irritating in several > > aspects. > > > > So, a long mail to conclude that, if I still haven't started to > > implement the platform-independent version of SciViews-R, it is because > > I am not convinced that any of the currently available R + rich-featured > > and platform-independent widgets solutions available is the one that > > will make it possible to reimplement SciViews-R in a streamless and > > relatively bug-free manner. To summarize, the currently best candidate > > is R + tcltk + tcltk2. I am convinced that R + Python + wxWidgets is by > > far a much better solution, but it is still in alpha development. > > Eclipse + JGR looks promising, and GTK2 is there too, but not enough > > integrated under Windows for me to start using such a solution, as a > > Windows user. > > > > I don't have much time to dedicate to SciViews-R and to the Sciviews R > > GUI API for the moment, and I will certainly focus on four hot topics: > > (1) developing the actual SciViews-R as a better teaching aid (I use and > > need it for my own courses!), (2) contributing to the development of > > Tinn-R, (3) further integrating R Commander with SciViews-R, and (4) > > integrating Rpad with SciViews-R. However, I will have various contracts > > in 2006-2007 where the development of SciViews-R is a part of the job. > > So, I will have the opportunity to hire one or two developers, and this > > will hopefully speed up SciViews-R development in a directly that will > > satisfy more users. > > > > Otherwise, I am open to any suggestion, and more importantly, to any > > idea of collaboration with other R GUI developers, as it is currently > > the case with John Fox (R Commander integration with SciViews-R), > > Jose-Claudio Faria (Tinn-R developement and Tinn-R compatibility with > > SciViews-R), and Tom Short (Rpad developments and compatibility with > > SciViews-R). I think it is important to insist on this, in a world > > populated with a myriad of slowly developed, half finished, half > > featured R GUIs, made by people that look too individualist in my view > > to be able of working all together and to write a single R GUI that has > > any chance to be full-featured, well-documented, reasonnably bug-free, > > truly platform-independent, in a near future. > > > > Best, > > > > Philippe Grosjean > > > > ..<°}))>< > > ) ) ) ) ) > > ( ( ( ( (Prof. Philippe Grosjean > > ) ) ) ) ) > > ( ( ( ( (Numerical Ecology of Aquatic Systems > > ) ) ) ) ) Mons-Hainaut University, Pentagone (3D08) > > ( ( ( ( (Academie Universitaire Wallonie-Bruxelles > > ) ) ) ) ) 8, av du Champ de Mars, 7000 Mons, Belgium > > ( ( ( ( ( > > ) ) ) ) ) phone: + 32.65.37.34.97, fax: + 32.65.37.30.54 > > ( ( ( ( (email: [EMAIL PROTECTED] > > ) ) ) ) ) > > ( ( ( ( (web: http://www.umh.ac.be/~econum > > ) ) ) ) ) http://www.sciviews.org > > ( ( ( ( ( > > .. > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ___ > R-SIG-GUI mailing list > R-SIG-GUI@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/r-sig-gui > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mauchly.test (instead of mauchley.test) ?
Tobias Verbeke <[EMAIL PROTECTED]> writes: > Wherever I look up the following reference > the name of the author is spelled Mauchly > contrary to the naming of the R function. > > Mauchly, J.W., > Significance test for sphericity > of a normal $n$-variate distribution, > Annals of mathematical statistics, 11(1940), > p. 204-209. > > Is this a typo on the original article (which > R Core has corrected) or is it a typo in the > function name ? The latter... Thanks. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] calling fortran from C
"James Bullard" <[EMAIL PROTECTED]> writes: > Hello, I had a question about calling some of R's fortran routines from C. > Specifically, I would like to call: dqrfit from some C code which will be > bundled as an R package. I was hoping someone knew of an example in some > of R's code which does something like this (any fortran call from R's C > would probably be a sufficient guide). So far I can only find locations > where R calls the Fortran directly, but this is not an option for me. > > Also, I am trying to gauge the overhead of making this call, does anyone > have any knowledge of whether there might be some non-trivial constant > time penalty on making such a call. > > Thanks in advance, Jim The penalty is no bigger than on ordinary C calls. The main issue is to get the naming convention right (HAVE_F77_UNDERSCORE, etc) and call dqrfit_() if required -- all in a portable way. The whole thing is described in the Writing R Extensions manual, section 5.6 specifically. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] md5sum for R-2.2.0-win32.exe ??
"Charles C. Berry" <[EMAIL PROTECTED]> writes: > I get > > c1279b77fcccf40379f59a83523a440e *R-2.2.0-win32.exe > > but I see > > e8bdf765fe8013129045314c8e2605fd *rw2011.exe > > on several USA mirrors. > > I hope the latter is merely in need of a replacement and not an > indication of a problem with the web sites. Are you saying that you'd expect different versions of R to have the same md5sum?... ;-) CRAN master has the old md5sum.txt as well, so I guess that the Windows maintainer just forgot to update it. Incidentally, I don't think it's all that smart to have the md5sum in the same location as the binary. If one is tampered with, the other one could be too. For the main release, I always send the md5sums via the mailing lists. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Single vs. dual CPUs
"Milton Lopez" <[EMAIL PROTECTED]> writes: > I've posted this earlier and have not heard much so far. I'd really > appreciate any guidance on this as we are about to order new hardware. > > We are buying Dell workstations with Red Hat Linux and 64-bit Xeon > CPUs to run R. We could add a second processor to each system, or > buy slightly faster single CPU systems. Is it possible to make a > generalized statement as to what kind of performance improvement we > would see with a single vs. dual processors when running R on these > systems? Well, if you ask that way, the answer is probably no... It depends on the usage pattern. If you run multiple CPU-bound processes in parallel without too much coordination (parallel make is a good example, simulations another), then you get close to double up from a dual. For a single R process, you can get something like 40% improvement in large linear algebra problems, using a threaded ATLAS. For other problems the speedup is basically nil. There is some potential in threading R or (much easier) some of its vector operations, but that is not even on the drawing board at this stage. Also, these days you might want to consider another factor: noise. Duals tend to be server machines with little emphasis on quietness, where the single-CPU machines have heatpipes and whatnot. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)
[EMAIL PROTECTED] writes: > Full_Name: Hin-Tak Leung > Version: R 2.2.0 > OS: x86 linux > Submission from: (NULL) (131.111.126.242) > > > Rgnome depends libglade 0.x and libxml 1.x . > > They are no longer shipped with Redhat EL4. > (I know they are still in fedora core 4). > > Just a wish-list. But what is the wish? You mean get it upgraded to xml2 and glade2? Patches would likely be accepted... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error from make: gcc -shared -L/usr/local/lib64 ... relocation R_X86_64_32...
Dick Beyer <[EMAIL PROTECTED]> writes: > I hope someone can point me, a newcomer to building R as well as 64-bit R, in > a useful direction. I have a dual Opteron 275 box running RedHat EL4. I ran > configure successfully, and, then, get the following error while running make: > > make[4]: Entering directory `/tmp/R-2.2.0/src/modules/lapack' > g77 -fPIC -g -O2 -ffloat-store -c dlamc.f -o dlamc.lo > g77 -fPIC -g -O2 -c dlapack0.f -o dlapack0.lo > g77 -fPIC -g -O2 -c dlapack1.f -o dlapack1.lo > g77 -fPIC -g -O2 -c dlapack2.f -o dlapack2.lo > g77 -fPIC -g -O2 -c dlapack3.f -o dlapack3.lo > g77 -fPIC -g -O2 -c cmplx.f -o cmplx.lo > g77 -fPIC -g -O2 -c cmplxblas.f -o cmplxblas.lo > gcc -shared -L/usr/local/lib64 -o libRlapack.so dlamc.lo dlapack0.lo > dlapack1.lo dlapack2.lo dlapack3.lo cmplx.lo cmplxblas.lo -lg2c -lm -lgcc_s > > /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/libg2c.a(s_cat.o): > relocation R_X86_64_32 against `a local symbol' can not be used when making a > > shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-redhat-linux/3.4.4/libg2c.a: could not read symbols: Bad > value > collect2: ld returned 1 exit status > make[4]: *** [libRlapack.so] Error 1 > > > I am confused by the error message "recompile with -fPIC" since it looks like > > all the lapack routines are already being compiled with -fPIC. I did struggle > with getting all the right development packages installed, so maybe I am > missing some critical package? > > Any help, suggestions, or pointers to 64-bit RedHat EL4 would be greatly > appreciated. I have a faint bell ringing in the distance... The proximate cause is that the static libg2c.a is being picked up and it is likely not -fPIC compiled (which is important on 64bit but AFAIR you get away with it on 32bit). Now why is it that this happens... Is there a libg2c.so around? - O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error from make: gcc -shared -L/usr/local/lib64 ... relocation R_X86_64_32...
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > It is libg2c.a you are being told to recompile. > > There ought to be a lib2gc.so* on your system. On FC3 > > gannet% rpm -q --whatprovides /usr/lib/libg2c.so.0 > libf2c-3.4.4-2.fc3 > gannet% rpm -q --filesbypkg libf2c-3.4.4-2.fc3 > libf2c/usr/lib/libg2c.so.0 > libf2c/usr/lib/libg2c.so.0.0.0 > > which looks like the problem if it is missing. *ding* Yup, that's it. It's actually the same on FC4, my pattern recognizer just had a temporary defect: [EMAIL PROTECTED] ~]$ rpm -qf /usr/lib/libg2c.so.0.0.0 compat-libf2c-32-3.2.3-47.fc4 [EMAIL PROTECTED] ~]$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/libg2c.a compat-gcc-32-g77-3.2.3-47.fc4 (Notice that they're not the same...) So the point is to install the libf2c thingie, whatever the name is on RHEL4. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R patched for Windows missing
Gabor Grothendieck <[EMAIL PROTECTED]> writes: > R patched for Windows seems to be missing. If one clicks on > R-2.2.0pat-win32.exe at, say, > >http://stat.ethz.ch/CRAN/bin/windows/base/rpatched.html > > then an error occurs. I tried it at several mirror sites with the same > result. The web page in question says: > > This directory contains a Windows binary build of R including patches > up to 2005-10-24. Looks like an HTML issue. Almost all links on that page go to files in the server root, and likewise for r-devel. The .exe files themselves seem to be quite happily sitting alongside the release binary at e.g. http://cran.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe The source for the link table in r-patched.html is currently looking like this: README.R-2.2.0pat Installation and other instructions. CHANGES New features of this Windows version. NEWS New features of all versions. R-2.2.0pat-win32.exe Setup program (about 25 megabytes). Please download this from a http://cran.r-project.org/mirrors.html";>mirror near you. This corresponds to the file named SetupR.exe or rw.exe in pre-2.2.0 releases. < -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected '[<-.data.frame' result
"Charles C. Berry" <[EMAIL PROTECTED]> writes:
> Is this a bug?
>
> If not, I am curious to know why '[<-.data.frame' was designed to yield
> a.frame$y != a.frame$z rather than refusing to carry out the operation at
> all.
>
> > a.frame <- data.frame( x=letters[1:5] )
> > a.frame[ 2:5, "y" ] <- letters[2:5]
> > a.frame[[ "z" ]][ 2:5 ] <- letters[2:5]
> > a.frame
>xyz
> 1 ab
> 2 bcb
> 3 cdc
> 4 ded
> 5 e e
It sure looks like a bug, and we're not even prototype-compatible:
turmalin:~/>Splus
S-PLUS : Copyright (c) 1988, 2003 Insightful Corp.
S : Copyright Lucent Technologies, Inc.
Version 6.2.1 for Linux 2.4.18 : 2003
Working data will be in /home/bs/pd/MySwork
> a.frame <- data.frame( x=letters[1:5] )
> a.frame[ 2:5, "y" ] <- letters[2:5]
> a.frame
x y
1 a
2 b b
3 c c
4 d d
5 e e
(S-PLUS doesn't know about character NA, so it's not surprising that
you get an empty cell, but it does fill in the right rows of y).
Why would you expect the operation to be refused?
The problem is not, BTW, restricted to character column indexing:
> a.frame
x y V3
1 a bb
2 b bc
3 c cd
4 d de
5 e e
The problem would seem to be the else clause in
if (jj <= nvars) {
if (length(dim(x[jj])) != 2)
x[[jj]][iseq] <- vjj
else x[[jj]][iseq, ] <- vjj
}
else {
length(vjj) <- nrows
x[[jj]] <- vjj
}
which I think wants to be
else {
x[[jj]] <- vjj[FALSE]
length(x[[jj]]) <- nrows
x[[jj]][iseq] <- vjj
}
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of type conversion (PR#8256)
[EMAIL PROTECTED] writes: > Where is my error?? > I have a strange behaviour in R, looks like type conversions are messed = > up. > Maybe i just make a stupid mistake, but help would be appreciated. > > To reproduce: > > expected: > > typeof(3) > [1] "double" > > > as.integer(3) > [1] 3 > > > typeof((0.3/0.1)) > [1] "double" > > strange: > > as.integer((0.3/0.1)) > [1] 2 > > also for trunc: > >trunc(c(5,7)) > [1] 5 7 > > >c(0.5,0.7)/c(0.1,0.1) > [1] 5 7 > > and now watch: > >trunc((c(0.5,0.7)/c(0.1,0.1))) > [1] 5 6 None of this is bugs. Please read up on floating point representations on a binary computer. Specifically: > 0.3/0.1 - 3 [1] -4.440892e-16 > 0.7/0.1 - 7 [1] -8.881784e-16 > 0.5/0.1 - 5 [1] 0 > My R-Version: > platform i386-pc-mingw32 > arch i386 =20 > os mingw32 =20 > system i386, mingw32 =20 > status =20 > major2 =20 > minor1.1 =20 > year 2005 =20 > month06=20 > day 20=20 > language R > > > Cheers, > Grischa T=F6dt > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] unvectorized option for outer()
Thomas Lumley <[EMAIL PROTECTED]> writes: > On Sun, 30 Oct 2005, Jonathan Rougier wrote: > > > I'm not sure about this. Perhaps I am a dinosaur, but my feeling is > > that if people are writing functions in R that might be subject to > > simple operations like outer products, then they ought to be writing > > vectorised functions! > > I would agree. How about an oapply() function that does multiway (rather > than just two-way) outer products. Basing the name on "apply" would > emphasize the similarity to other flexible, not particularly optimized > second-order functions. In fairness, it should probably be said that not all problems vectorize naturally. One example is ssd <- function(A,alpha) sum((Y - A*exp(-alpha*t))^2) However, it should be worth noting that with the mapply() function at hand, it is pretty easy to turn a non-vectorized function into a vectorized one. SSD <- function(A,alpha) mapply(ssd, A, alpha) (Anybody want to try their hand on writing a general Vectorize() function? I.e. one that allowed outer(Avec, alphavec, Vectorize(ssd)) to work.) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure error under FC 4 64 bit (PR#8276)
[EMAIL PROTECTED] writes: > Full_Name: Rob James > Version: 2.2.0 > OS: Fedora Core 4 64 Bit > Submission from: (NULL) (24.79.225.106) > > > Attempting to run the configure script yields the following inscrutable error: > > > configure: error: --with-readline=yes (default) and headers/libs are not > available > > > This occurs at the following point in the processing of the configure script: > > checking for readline/history.h... no > checking readline/readline.h usability... no > checking readline/readline.h presence... no > checking for readline/readline.h... no > checking for rl_callback_read_char in -lreadline... no > checking for main in -lncurses... yes > checking for rl_callback_read_char in -lreadline... no > checking for history_truncate_file... no > > > Any suggestions? Yes. (a) read http://cran.r-project.org/doc/manuals/R-admin.html, especially the section C1, platform notes for Linux (b) also read the section on what is a bug and what is not a bug in http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html#R%20Bugs (c) If you are that new to compiling R on FC4, why not use the RPMs from Fedora Extra? -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
[EMAIL PROTECTED] writes: > We do not usually put features in R which are specific to just some > distributions of some OSes, and in this case to one editor on those. > We do not for example include the ESS mode for the much-more-widely-used > Emacs family of editors. > > This looks as if it might be appropriate to the Linux binary packages for > R, so I suggest you contact their maintainers. But my understanding is > that this is an issue for gedit and not for R. Indeed .R is just a > convention (one of many choices, including .r and .q) for R itself. > > I do wonder why you concentrated on .R files and not .Rd files, where I > find syntax highlighting more useful. Mime-types shouldn't be distribution-specific or even editor-specific, should they? The whole point is that they can be used for things like email attachments that pass from one OS to the other. It might be useful to have the mime-type definitions for R (and Rd) files centralized in R core, with the appropriate OS conventions systematized. But I think we need to know more. Who keeps track of mime-types? Can we just grab text/x-R (and text/x-Rd and application/x-Rdata)? To which extent the XML format a standard; is it only used by particular applications? > On Thu, 3 Nov 2005 [EMAIL PROTECTED] wrote: > > > Full_Name: Vaidotas Zemlys > > Version: 2.1.1 > > OS: Ubuntu 05.10 > > Submission from: (NULL) (213.197.173.50) . > > > > Vaidotas Zemlys > > NB: signature missing Er, it came in via the rbugs web interface. We don't usually get .sig's added to those. We had dozens of messages from VZ on the regular mail lists, all without a formal .sig, so this would seem to be the least appropriate time to complain. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
[EMAIL PROTECTED] writes: > Hi, > > On 03 Nov 2005 12:41:53 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wr= > ote: > > [EMAIL PROTECTED] writes: > > > > > We do not usually put features in R which are specific to just some > > > distributions of some OSes, and in this case to one editor on those. > > > We do not for example include the ESS mode for the much-more-widely-use= > d > > > Emacs family of editors. > > > > > > This looks as if it might be appropriate to the Linux binary packages f= > or > > > R, so I suggest you contact their maintainers. But my understanding is > > > that this is an issue for gedit and not for R. Indeed .R is just a > > > convention (one of many choices, including .r and .q) for R itself. > > > > > > I do wonder why you concentrated on .R files and not .Rd files, where I > > > find syntax highlighting more useful. > > > > Mime-types shouldn't be distribution-specific or even editor-specific, > > should they? The whole point is that they can be used for things like > > email attachments that pass from one OS to the other. > > > > It might be useful to have the mime-type definitions for R (and Rd) > > files centralized in R core, with the appropriate OS conventions > > systematized. But I think we need to know more. Who keeps track of > > mime-types? Can we just grab text/x-R (and text/x-Rd and > > application/x-Rdata)? To which extent the XML format a standard; is it > > only used by particular applications? > > > > > As far as I know, at least in Debian, the mimetypes are tracked by > shared-mime-info package. The upstream is freedesktop.org. I do not > know about oficial standarts, but Gnome and KDE tries to adher to some > of the freedesktop.org standarts. I can confirm that mimetypes > provided by shared-mime-info are widely used in Gnome, for some time > now. One further thought about this: On SUSE, rpm -qif /usr/share/mime/ points at http://www.freedesktop.org/wiki/Software_2fshared_2dmime_2dinfo So I guess that the proper tree to bark at is the upstreams maintainers of http://freedesktop.org/~jrb/shared-mime-info-*.tar.gz Instructions there say to submit new XML files to https://bugs.freedesktop.org/buglist.cgi?product=shared-mime-info&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED It would likely be a good idea to send them first to R-devel for review. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
Vaidotas Zemlys <[EMAIL PROTECTED]> writes: > Hi, > > On 04 Nov 2005 13:51:56 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > > > One further thought about this: > > > > On SUSE, > > > > rpm -qif /usr/share/mime/ > > > > points at > > > > http://www.freedesktop.org/wiki/Software_2fshared_2dmime_2dinfo > > > > So I guess that the proper tree to bark at is the upstreams > > maintainers of > > > > http://freedesktop.org/~jrb/shared-mime-info-*.tar.gz > > > > Instructions there say to submit new XML files to > > > > https://bugs.freedesktop.org/buglist.cgi?product=shared-mime-info&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED > > > > It would likely be a good idea to send them first to R-devel for review. > > > > I already barked at upstream. The upstream barked back. The result is here: > > https://bugs.freedesktop.org/show_bug.cgi?id=1782 Aha... This is pretty weird, in light of the prescription on the website: << Shared MIME database package The core database and the update-mime-database program for extending it are available from the [WWW]software pages. If you have added types that should go in the common freedesktop.org base list of types, you should create an enhancement request on [WWW]the MIME bugtracker with your new XML file. >> If the procedure is different, perhaps we should ask them what it is? I don't think we have a real problem with maintaining a "freedesktop" subdir somewhere in the sources since it appears to cover quite a wide range of systems, but we don't seem to know what to do with it. The procedure appears to be different between Linuxen: On SUSE, I get viggo:~/>rpm -qf /usr/share/mime/text/x-texinfo.xml shared-mime-info-0.15.cvs20050321-3 whereas FC4 has [EMAIL PROTECTED] ~]$ rpm -qf /usr/share/mime/text/x-texinfo.xml file /usr/share/mime/text/x-texinfo.xml is not owned by any package (and likewise 60-odd other .xml files). So it seems that SUSE collects all this stuff in a single RPM and FC4 lets it be handled by the post-install mechanism (on each package or by "exploding" freedesktop.org.xml ??) > There you can find xml file for R scripts. I've made it from some > example. It is really only a proof of a concept. But it would not be > very difficult to produce xml files for mimetypes of all R related > files. We must only decide which R related files would benefit from > having mimetypes. > > My proposal is > 1. R source code, R scripts. Files with extensions .R, .r and others > (.q?, .s?, .S?). Mimetypes text/x-R, text/x-Rsrc My inclination would be to stick with .R, possibly adding .r to guard against Windows case-folding issues, but .r used to be Ratfor files. .q/.s/.S are used by some people supporting both R and S-PLUS, but I don't think they care how such files are displayed by Nautilus and Konqueror... > 2. R documentation files. File extension .Rd. Mimetype text/x-Rd OK, modulo case-fold > 3. RData files. File extension .RData, files which at beginning have > RDX2. Mimetype application/x-RData. Why the RDX2 bit?? We do have .RDA from windows, too. > 4. Rhistory files. File extension .Rhistory. Mimetype text/x-Rhistory OK. > 5. R transcript files from ESS/Emacs. File extension .Rt. Mimetype > text/x-Rtranscript .Rout, please. Also .Rout.save and .Rout.fail. (And it's not just ESS that creates them). Also 6. Rprofile files .Rprofile or Rprofile. > The relevant xml code could be pushed upstream to end up in > freedesktop.org.xml, or it could be distributed with R linux package, > and installed into relevant subdirectory of /usr/share/mime. With a > bit more work the result could be, that people using for example > Nautilus (graphical Gnome browser) could see R related files displayed > with R logo, and clicking them could result in various appropriate > actions. For example for .RData R process could be iinvoked and > relevant .RData file could be loaded. Some fun potential with gedit/Kate plugins too (ESS for the 21st century anyone?) > I could write and test the xml code. But first we have to agree on > which files benefit from having mimetypes and how the mimetypes should > be named. Feel free to suggest. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
Paul Roebuck <[EMAIL PROTECTED]> writes: > On Fri, 4 Nov 2005, Peter Dalgaard wrote: > > > Vaidotas Zemlys <[EMAIL PROTECTED]> writes: > > > > > [SNIP] > > > > > > > Also > > > > 6. Rprofile files .Rprofile or Rprofile. > > > > .Renviron? Yes, but you seem to have forgotten to keep r-devel in the circuit... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] # symbol in input data (PR#8296)
[EMAIL PROTECTED] writes: > Full_Name: Richard L Lozes > Version: 2.1.1 > OS: Win XP > Submission from: (NULL) (69.107.18.35) > > > "#" appearing in a quoted string in input causes further input of that line to > be ignored. > Can be cured by escaping (i.e., "\#"), but in big data sets it is onerous to > find. > > # should not be "special" inside a quoted string. > > Here is a small input file. Read it with read.csv(). > > Title1, Title2, cHdr1, cHdr2, cHdr3 > "xyz","abc",1.0,2.0,3.0 > "xyy","ab#c",4.0,5.0,6.0 > "zyx","abc",7.0,8.0,9.0 ...and what do you think the comment.char argument is for? This is no bug. > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Recursive dependencies(Rcmdr)
Something might have slipped by me, but I got into the following situation
installing Rcmdr:
< install.packages("Rcmdr",depend=TRUE) >
Oodles of Output, until:
* Installing *source* package 'multcomp' ...
** R
** data
** inst
** preparing package for lazy loading
Error in dyn.load(x, as.logical(local), as.logical(now)) :
unable to load shared library
'/home/bs/pd/Rlibrary/mvtnorm/libs/mvtnorm.so':
/home/bs/pd/Rlibrary/mvtnorm/libs/mvtnorm.so: cannot open shared object file:
No such file or directory
Execution halted
Several oodles more for remaining packages
** building package indices ...
* DONE (strucchange)
The downloaded packages are in
/tmp/RtmpF23254/downloaded_packages
Warning messages:
1: installation of package 'multcomp' had non-zero exit status in:
install.packages("Rcmdr", depend = TRUE)
2: cannot create HTML package index in: tools:::unix.packages.html(.Library)
OK, so we start Rcmdr
> library(Rcmdr)
Loading required package: tcltk
Loading required package: car
it then detects that multcomp is missing and asks for permission to
install it, giving the same result.
The thing appears to be that multcomp depends on mvtnorm, but the
extra dependency goes undetected. Manual installation of the two
works.
A workaround is that John adds mvtnorm to the Suggested list for
Rcmdr, but I wonder if we couldn't do something smarter.
> version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major2
minor2.0
year 2005
month10
day 06
svn rev 35749
language R
> .libPaths()
[1] "/home/bs/pd/Rlibrary" "/usr/lib64/R/library"
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Malformed package name (PR#8314)
[EMAIL PROTECTED] writes: > Full_Name: L. Petrák > Version: 2.2 > OS: w2k > Submission from: (NULL) (193.109.177.11) > > > # rcmd build Translation-it > * checking for file 'Translation-it/DESCRIPTION' ... OK > * preparing 'Translation-it': > * checking DESCRIPTION meta-information ... ERROR > Malformed package name > > See the information on DESCRIPTION files in section 'Creating R > packages' of the 'Writing R Extensions' manual. > > = > char "-" is not alowed in package name (bug in 'build' script or 'utils.R' or > 'manuals/R-ext') Why is that a bug? The documentation clearly says what is allowed and this isn't: The Package and Version fields give the name and the version of the package, respectively. The name should consist of letters, numbers, and the dot character and start with a letter. The version is a sequence of at least two (and usually three) non-negative integers separated by single . or - characters. The canonical form is as shown in the example, and a version such as 0.01 or 0.01.0 will be handled as if it were 0.1-0. If we allowed "-" in names, the first thing that would happen is that we get bug reports that library(Translation-it) causes weird error messages. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with fitdistr for gamma in R 2.2.0
i/MR/ggorjan > > Zootechnical Department mail: gregor.gorjanc bfro.uni-lj.si > > Groblje 3 tel: +386 (0)1 72 17 861 > > SI-1230 Domzale fax: +386 (0)1 72 17 888 > > Slovenia, Europe > > -- > > "One must learn by doing the thing; for though you think you know it, > > you have no certainty until you try." Sophocles ~ 450 B.C. > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > Peter Ehlers > University of Calgary > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mapply() gives seg fault (PR#8332)
[EMAIL PROTECTED] writes: > --KsGdsel6WgEHnImy > Content-Type: text/plain; charset=iso-8859-1; format=flowed > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > > Hi, people. Wandering in R archives, and seeing the message attached > below, I noticed that: > >mapply(rep,times=1:4, MoreArgs=42) > > still segfaults on R 2.2.0, and thought I should be a good citizen and > report it, even if I do not have an actual problem with this. :-) Looks like Brian already fixed it in r-patched. Seems like this was after your message, so I'd better skip the snide remark about how to be an even better citizen ;-) > > version > _ > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major2 > minor2.0 > year 2005 > month10 > day 06 > svn rev 35749 > language R > > (By the way, in the output of "R.version", should all the spurious > whitespace be kept at end of lines?) > > -- > François Pinard http://pinard.progiciels-bpi.ca > > --KsGdsel6WgEHnImy > Content-Type: message/rfc822 > Content-Disposition: inline > > From: [EMAIL PROTECTED] (Roger D. Peng) > Date: Tue Oct 14 18:10:52 2003 > Subject: [R] mapply() gives seg fault > In-Reply-To: <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > I get this too on the released version. I guess the problem is that the > value passed to MoreArgs is not a list. Maybe, > > mapply(rep, times = 1:4, MoreArgs = list(42)) > > produces what you want? At any rate, R shouldn't segfault so it looks > like bug somewhere. > > -roger > > Robin Hankin wrote: > > > Hello everybody. > > > > I've been experimenting with mapply(). Does anyone else have problems > > with: > > > > R> mapply(rep,times=1:4, MoreArgs=42) > > > > (I get a seg fault). > > > > robin > > > > > > > > R> R.version > > _ > > platform powerpc-apple-darwin6.6 > > arch powerpc > > os darwin6.6 > > system powerpc, darwin6.6 > > status beta > > major1 > > minor8.0 > > year 2003 > > month10 > > day 02 > > language R > > > >> > > > > __ > > R-help@stat.math.ethz.ch mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-help > > > > --KsGdsel6WgEHnImy-- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] x[1,], x[1,,], x[1,,,], ...
Henrik Bengtsson <[EMAIL PROTECTED]> writes:
> Hi,
>
> is there a function in R already doing what I try to do below:
>
> # Let 'x' be an array with *any* number of dimensions (>=1).
> x <- array(1:24, dim=c(2,2,3,2))
> ...
> x <- array(1:24, dim=c(4,3,2))
>
> i <- 2:3
>
> ndim <- length(dim(x))
> if (ndim == 1)
>y <- x[i]
> else if (ndim == 2)
>y <- x[i,]
> else if (ndim == 3)
>y <- x[i,,]
> else ...
>
> and so on. My current solution is
>
> ndim <- length(dim(x))
> args <- rep(",", ndim)
> args[1] <- "i"
> args <- paste(args, collapse="")
> code <- paste("x[", args, "]", sep="")
> expr <- parse(text=code)
> y <- eval(expr)
>
> ndim <- length(dim(x))
> args <- rep(",", ndim)
> args[1] <- "i"
> args <- paste(args, collapse="")
> code <- paste("x[", args, "]", sep="")
> expr <- parse(text=code)
> y <- eval(expr)
>
> Is there another way I can do this in R that I have overlooked?
I think this should work:
x <- array(1:24, dim=c(3,2,2,2)) # not c(2,2,3,2)
i <- 2:3
ndim <- length(dim(x))
ix <- as.list(rep(TRUE, ndim))
ix[[1]] <- i
do.call("[", c(list(x), ix))
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Infinite recursion in S3 methods crashes R on windows (related to PR#8203?)
Rich FitzJohn <[EMAIL PROTECTED]> writes:
> Hi,
>
> Infinite recursion in S3 methods seem to crash R on Windows 2000 (R
> terminating with the ("Rgui.exe has generated errors...") message,
> rather than throwing an error. This happens with both Rgui and Rterm.
>
> The following toy example triggers this:
> myf <- function(x, ...)
> UseMethod("myf")
>
> myf.default <- function(x, ...)
> myf(x)
>
> myf(1)
> ...R crashes...
>
> Which I would expect to terminate with the usual "evaluation nested
> too deeply: infinite recursion" or protect stack overflow message.
>
> This may be related to the reported bug 8203 - apologies if this has
> been fixed. I couldn't find specific mention of this in the NEWS
> file.
>
> This does not happen on R 2.1.0 on Windows 2000 (same machine), or on
> R 2.2.0 on Linux. R/Machine version below.
This is presumably an issue of C stack size. We increased
options("expressions") in 2.2.0 from 500 to 5000, thinking that
"machines are bigger than that these days", but apparently not.
So for 2.2.0 patched we have
o options("expressions") has been reduced to 1000: the limit
of 5000 introduced in 2.1.0 was liable to give crashes from C
stack overflow.
and in R-devel
o options(expressions) reverts to the default of 5000 now
stack checking is in place.
> Cheers,
> Rich
>
> 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 2000 Professional (build 2195) Service Pack 4.0
>
> Locale:
> LC_COLLATE=English_New Zealand.1252;LC_CTYPE=English_New
> Zealand.1252;LC_MONETARY=English_New
> Zealand.1252;LC_NUMERIC=C;LC_TIME=English_New Zealand.1252
>
> Search Path:
> .GlobalEnv, package:methods, package:stats, package:graphics,
> package:grDevices, package:utils, package:datasets, Autoloads,
> package:base
>
>
> --
> Rich FitzJohn
> rich.fitzjohn gmail.com |http://homepages.paradise.net.nz/richa183
> You are in a maze of twisty little functions, all alike
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv ignores 'row.names'
Roger Peng <[EMAIL PROTECTED]> writes: > Okay, upon further examination, it appears that it works fine if you set > 'row.names = FALSE' as opposed to 'row.names = F'. Nope. It's still a bug and you're quite right that eval() is needed. We can't have that an argument only works when supplied as an explicit constant. > -roger > > Roger Peng wrote: > > Upon replying to this email, I took a look at 'write.csv()' and noticed > > something interesting. I remember there being a discussion sometime in > > the past about letting 'write.csv()' accept the 'row.names' argument. > > However, I get the following error: > > > > > write.csv(airquality, file = "myfile.csv", row.names = F) > > Error in write.table(airquality, file = "myfile.csv", row.names = F, > > col.names = NA, : > > col.names = NA makes no sense when row.names = FALSE > > > > > > > In 'write.csv()' there is > > > > rn <- Call$row.names > > Call$col.names <- if (is.logical(rn) && !rn) > > TRUE > > > > but is.logical(rn) is always FALSE because even if 'row.names' is > > specified (non-NULL), it is of class "name". Perhaps something like > > > > rn <- eval(Call$row.names) > > > > would suffice? I can't tell if that would break anything. > > > > -roger > > > > Sven Schaltenbrand wrote: > > > >> hallo, > >> > >> i have a problem by writing a csv file > >> the first colum is filled with index numbers from 1 to n. > >> i have to unique two csv files once a week while one file is always the > >> same. > >> can anybody tell me, how to write the dataset into a csv file without the > >> first row of the indexnumbers. > >> x[,-1] does not wok as it eliminates the first "interesting" colum. > >> col.names is not accepted by r (do i habe to start a package first? which > >> one?) > >> > >> thx > >> > >> sven > >> > >> [[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 > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] multinom crashes (when I do something stupid) (PR#8358)
[EMAIL PROTECTED] writes:
> Full_Name: Rob Foxall
> Version: 2.2.0
> OS: Windows XP
> Submission from: (NULL) (149.155.96.5)
>
>
> I was using multinom from nnet package, when I did something stupid -- I
> entered
> in an incorrect factor variable as response. This factor had only one level.
> Instead of R telling me not to be so dumb, it crashed, clicking on debug
> coming
> up with the message "An exception 'Unhandled Win32 Exception' has occurred in
> Rgui.exe." This has happened on both my laptop and desktop (it took me a while
> to see my mistake!). It can be easily reproduced with made-up data, e.g.
>
> library(nnet)
> set.seed(1) # not really needed, but definitely crashes for this!
> temp_g <- as.factor(rep("level1",10))
> temp_x <- rnorm(10)
> multinom(temp_g ~ temp_x)
Thanks for the reproducible example, but the general directive is to
send reports on packages directly to the package maintainer. (He'll
see it here, so don't worry about resending.)
The fault comes here:
# weights: 3 (0 variable)
initial value 0.00
final value 0.00
converged
*** glibc detected *** free(): invalid next size (fast): 0x0172ce20 ***
Program received signal SIGABRT, Aborted.
0x2b059e79 in raise () from /lib64/tls/libc.so.6
(gdb) bt
#0 0x2b059e79 in raise () from /lib64/tls/libc.so.6
#1 0x2b05b48f in abort () from /lib64/tls/libc.so.6
#2 0x2b08e5d3 in __libc_message () from /lib64/tls/libc.so.6
#3 0x2b093153 in malloc_printerr () from /lib64/tls/libc.so.6
#4 0x2b0948a7 in free () from /lib64/tls/libc.so.6
#5 0x2acb43ec in R_chk_free () from /usr/lib64/R/lib//libR.so
#6 0x2bfa3c0d in VR_unset_net ()
from /usr/lib64/R/library/nnet/libs/nnet.so
#7 0x2ac5c3ac in do_dotCode () from /usr/lib64/R/lib//libR.so
#8 0x2ac7e712 in Rf_eval () from /usr/lib64/R/lib//libR.so
I.e. it is within internal C code from the nnet package, so the error
most likely belongs to the package, not R at large.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] computing the variance
Martin Maechler <[EMAIL PROTECTED]> writes:
> It seems Insightful at some point in time have given in to
> this user request, and S-plus nowadays has
> an argument "unbiased = TRUE"
> where the user can choose {to shoot (him/her)self in the leg and}
> require 'unbiased = FALSE'.
> {and there's also 'SumSquraes = FALSE' which allows to not
> require any division (by N or N-1)}
>
> Since in some ``schools of statistics'' people are really still
> taught to use a 1/N variance, we could envisage to provide such an
> argument to var() {and cov()} as well. Otherwise, people define
> their own variance function such as
> VAR <- function(x,) .. N/(N-1)*var(x,...)
> Should we?
Using the biased variance just because it is the MLE (if that is the
argument) seems confused to me. However, there's another point:
> var(sample(1:3, 10, replace=TRUE))
[1] 0.6680556
i.e. if we are considering x as the entire population, then the
variance when sampling from it is indeed 1/N*E(X-EX)^2, which is why
some presentations distinguish between the "population" and "sample"
variances. We might want to support this distinction somehow.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.2.1 scheduled for Dec 20.
Dear testers, We plan to release version 2.2.1 on December 20. Beta tarballs will be available daily, starting tomorrow. As usual, we strongly prefer to hear about bugs before release rather than after. -pd -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] qt for df < 1
roger koenker <[EMAIL PROTECTED]> writes: > I was experimenting yesterday with a binomial make.link option > for estimating student t binary response models, tentatively > called gossit, and I noticed eventually that the R qt function doesn't > like df < 1. Vaguely recalling that Splus didn't seem to mind such > weirdness, I checked on our soon to be defunct Splus6.2 and > sure enough, it produced plausible answers instead of R's NA's. > Of course, I have no way of judging the quality of these answers, > but I'm curious about whether someone has already looked into > this can of worms. Well the help page has: For 'qt' only values of at least one are currently supported. and someone must have written that... R does have pt for df < 1, so a temporary fix using uniroot() seems doable. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] data.frame() size
Hin-Tak Leung <[EMAIL PROTECTED]> writes: > Prof Brian Ripley wrote: > > Data frames have unique row names *by definition* (White Book p.57). > > Yes - I happened to have the White Book on my desk (not mine...) > - indeed, the first sentence on page 57 is (quote verbatim, the > "never" is in italic in the book, which I have added the "*" before > and after): > > If all else fails, the row names are just the row numbers. They > are *never* null and must be unique. > > So patching data.frame.R is quite wrong. However, the rowname/colname > overhead is definitely an issue for processing of large data sets, > both for speed and amount of memory consumed. So it is probably best > to extend the data.frame class and call it something else instead, > for those who needs to go that route. Exactly. I recall from the Insightful people at the DSC in Seattle that something is going to happen with the rownames in S-PLUS or has happened in the latest release, but I don't remember exactly how they did it, and if and how it had to do with their "big dataframe" code. We might want R to follow suit in this respect. Other options might include doing something about the string-storage of rownames, which is quite wasteful in R (every string is an R object, a string vector is really a list of CHARSXP objects). Either one could improve on the internal storage format, or one could allow rownames to be integers with semantics like "virtual strings" so that x["123",] still works. > (What I am doing is already called a different name so it isn't > affected by this argument). > > Hin-Tak > > > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0/1 vector for indexing leads to funny behaviour (PR#8389)
[EMAIL PROTECTED] writes:
> Full_Name: Axel Rasche
> Version: 2.2.0
> OS: Linux
> Submission from: (NULL) (141.14.21.81)
>
>
> Dear Debuggers,
>
> This is not a serious problem. Are 0/1 vectors intended to be used as index
> vectors? If yes, there is a bug. If not, it leads just to some funny behaviour
> rather than an error message.
>
> In the appendix is some simple code to reproduce the problem. A logical vector
> as.logic(a) helps by indexing the vector b. The 0/1 vector a just returns the
> first value "a". But as many times as there is a 1 in a.
Yes, that is completely as intended. Zeros in a numerical index vector
produce nothing and ones produce the first element. The documentation
could arguably be better on this point though.
> Best regards,
> Axel
>
>
> Appendix:
>
> b = c("a","b","c","d")
> a = c(0,1,1,0)
> b[as.logical(a)]
> b[a]
> a = c(1,0,1,0)
> b[as.logical(a)]
> b[a]
> a = c(0,1,1,1)
> b[as.logical(a)]
> b[a]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R with f2c - still needed?
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > Does anyone have a need to use f2c rather than a Fortran compiler to build > R? > > It is yet one more thing to test, and as it only works on 32-bit platforms > it is something that I will shortly no longer be able to test. The only candidate that I can think of is the PDA scene, which R has been just a little too hard to build for till now (Linux based Zaurus excepted). For those platforms you could be stuck with only a C/C++ compiler, but probably also without all the rest of the toolchain, so building will be a major headache anyway. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN task view: Multivariate
"Paul Hewson" <[EMAIL PROTECTED]> writes: > Hello, > > I've assembled a Multivariate ctv (with a lot of help from Achim Zeleis, > who has now posted the view on CRAN). > > I'd be grateful for comments regarding missing packages / functions. > Opinions on the organisation of the view would also be appreciated, as > well as having any errors pointed out. I've adopted a rather broad and > vague definition of "multivariate", which may not be optimal. Anova.mlm and mauchley.test from stats seem conspicuously absent. > Thanks > > Paul > > -=-=-=-=-=-=-=-=-=-=-=-= > Paul Hewson > Senior Lecturer in Statistics > School of Mathematics and Statistics > University of Plymouth > Drake Circus > Plymouth PL4 8AA > > tel (01752) 232778 (Campus) > tel (01752) 764437 (Tamar Science Park) > fax (01752) 232780 > > email: [EMAIL PROTECTED] > web: http://www.plymouth.ac.uk/staff/phewson > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0/1 vector for indexing leads to funny behaviour (PR#8389) (maybe a documentation deficiency?)
t; on that.
> >>
> >> -- Tony Plate
> >>
> >> [EMAIL PROTECTED] wrote:
> >>
> >>> Full_Name: Axel Rasche
> >>> Version: 2.2.0
> >>> OS: Linux
> >>> Submission from: (NULL) (141.14.21.81)
> >>>
> >>>
> >>> Dear Debuggers,
> >>>
> >>> This is not a serious problem. Are 0/1 vectors intended to be used as
> >>> index
> >>> vectors? If yes, there is a bug. If not, it leads just to some funny
> >>> behaviour
> >>> rather than an error message.
> >>>
> >>> In the appendix is some simple code to reproduce the problem. A
> >>> logical vector
> >>> as.logic(a) helps by indexing the vector b. The 0/1 vector a just
> >>> returns the
> >>> first value "a". But as many times as there is a 1 in a.
> >>>
> >>> Best regards,
> >>> Axel
> >>>
> >>>
> >>> Appendix:
> >>>
> >>> b = c("a","b","c","d")
> >>> a = c(0,1,1,0)
> >>> b[as.logical(a)]
> >>> b[a]
> >>> a = c(1,0,1,0)
> >>> b[as.logical(a)]
> >>> b[a]
> >>> a = c(0,1,1,1)
> >>> b[as.logical(a)]
> >>> b[a]
> >>>
> >>> __
> >>> 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
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN and R v2.2.1 for Windows
Henrik Bengtsson <[EMAIL PROTECTED]> writes: > Thanks for the new updates in v2.2.1. > > I just noticed a few "problems" on > http://cran.r-project.org/bin/windows/base/. > > 1) The CHANGES and NEWS files for v2.2.1 does not include info on v2.2.1 > but only details up until v2.2.0, cf. > http://cran.r-project.org/src/base/NEWS They have info for "R 2.2.0 patched" and 2.2.1 is just a frozen version of that. I.e., the only problem is that we forgot to change the heading (and that nobody bothered to check for this sort of thing in the 2-week beta period!). I noticed the issue just after building the release, but decided that it wasn't worth messing with the SVN tags for something as small as this. > 2) The patched version is now denoted "beta" (files and installation > directory), which I believe is misleading since it is a patch of the > "stable" version. "2.2.0 Patched" is changed to "2.2.1 beta" during the beta period. The release script ends with cd $SRCDIR echo $REL "Patched" > VERSION svn commit -m "setup patch version" so I believe this is a temporary situation and that r-patched will become "2.2.1 Patched" next time around. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] random output with sub(fixed = TRUE)
"Roger D. Peng" <[EMAIL PROTECTED]> writes:
> I've noticed what I think is curious behavior in using 'sub(fixed = TRUE)'
> and
> was wondering if my expectation is incorrect. Here is one example:
>
> v <- paste(0:10, "asdf", sep = ".")
> sub(".asdf", "", v, fixed = TRUE)
>
> The results I get are
>
> > sub(".asdf", "", v, fixed = TRUE)
> [1] "0" "1\0st\0\0" "2\0\001\0\0" "3\0\001\0\0"
> [5] "4\0mes\0""5\0\001\0\0" "6\0\0\0\0\0" "7\0\0\0m\0"
> [9] "8\0\0\0t\0" "9\0\0\0\0" "10\0\0\0\0\0"
> >
>
> I expected "0" in the first entry and everything else would be unchanged.
> Your
> results may vary since every time I run 'sub()' in this way, I get a slightly
> different answer in entires 2 through 11.
>
> As it turns out, 'gsub(fixed = TRUE)' gives me the answer I *actually*
> wanted,
> which was to replace the string in every entry. But I still think the
> behavior
> of 'sub(fixed = TRUE) is a bit odd.
>
> > version
> _
> platform x86_64-unknown-linux-gnu
> arch x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status
> major2
> minor2.1
> year 2005
> month12
> day 20
> svn rev 36812
> language R
> >
Argh...
year 2005
month12
day 21
and something like this gets discovered. It's a ritual, I tell ya, a ritual!
If you look at the output and terminate all strings at the embedded
\0, it looks much more sensible, so it should be fairly easy to spot
the cause of this bug...
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-bugs e-mail {was ... (Debian Bug 344248): ...}
hadley wickham <[EMAIL PROTECTED]> writes: > > PLEASE, PLEASE: > > do use > > [EMAIL PROTECTED] > > and nothing else > > Perhaps > http://bugs.r-project.org/cgi-bin/R > should be updated then? > > Hadley That's internal to the bug repository. It does everything by email, and at some point messages need to reach the program invoked by the mail server. Sending things to Zurich and back seems a bit silly -p -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-bugs e-mail {was ... (Debian Bug 344248): ...}
Peter Dalgaard <[EMAIL PROTECTED]> writes: > hadley wickham <[EMAIL PROTECTED]> writes: > > > > PLEASE, PLEASE: > > > do use > > > [EMAIL PROTECTED] > > > and nothing else > > > > Perhaps > > http://bugs.r-project.org/cgi-bin/R > > should be updated then? > > > > Hadley > > That's internal to the bug repository. It does everything by email, > and at some point messages need to reach the program invoked by the > mail server. Sending things to Zurich and back seems a bit silly > > -p Oops. You were talking about the email address on the front page? I'll fix that one to point to Zurich. -p -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crash with complex matrix algebra when using EISPACK=TRUE
"Ole F. Christensen" <[EMAIL PROTECTED]> writes: > Brain, Thank you very much for your help. * You seem to be using call-by-value semantics rather than call-by-name... -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multiplication (PR#8466)
Thomas Lumley <[EMAIL PROTECTED]> writes: > On Fri, 6 Jan 2006, [EMAIL PROTECTED] wrote: > > > hi - in version 2.1 the command > > > > >-2^2 > > > > gives > > > > -4 > > > > as the answer. (-2)^2 is evaluated correctly. > > So is -2^2. The precedence of ^ is higher than that of unary minus. It > may be surprising, but it *is* documented and has been in S for a long > time. Pretty much standard too, for languages that have an exponentiation operator. AFAICS Fortran, Perl, SAS all have ** at higher precedence than unary minus (or equal, but evaluate right to left). Stata seems like it might be the exception. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen()
Robin Hankin <[EMAIL PROTECTED]> writes: > Hi > > I am having difficulty with eigen() on R-devel_2006-01-05.tar.gz > > Specifically, in R-2.2.0 I get expected behaviour: > > > > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > [1] 5.208398e+02+0.00e+00i -1.583980e+01+0.00e+00i > [3] -4.805412e-15+0.00e+00i 1.347691e-15+4.487511e-15i > [5] 1.347691e-15-4.487511e-15i -4.269863e-16+0.00e+00i > [7] 1.364748e-16+0.00e+00i -1.269735e-16+0.00e+00i > [9] -1.878758e-18+5.031259e-17i -1.878758e-18-5.031259e-17i > > > > > The same command gives different results in the development version: > > > > eigen(matrix(1:100,10,10),FALSE,TRUE)$values > [1] 3.903094e-118 -3.903094e-118 -2.610848e-312 -2.995687e-313 > -2.748516e-313 > [6] -1.073138e-314 -1.061000e-314 -1.060998e-314 4.940656e-324 > 0.00e+00 > > R.version() > Error: attempt to apply non-function > > R.version Strange and semi-random results on SuSE 9.3 as well: > eigen(matrix(1:100,10,10))$values [1] -5.393552e+194 3.512001e-68 0.00e+00 0.00e+00 0.00e+00 [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > eigen(matrix(1:100,10,10))$values [1] 1.526259e-311 -1.041529e-311 1.181720e-313 0.00e+00 0.00e+00 [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > eigen(matrix(1:100,10,10))$values [1] -9.338774e+93 0.00e+00 0.00e+00 0.00e+00 0.00e+00 [6] 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.00e+00 > eigen(matrix(1:100,10,10))$values [1] 5.4e-311+ 0.0e+00i -2.5e-311+3.7e-311i -2.5e-311-3.7e-311i [4] 2.5e-312+ 0.0e+00i -2.4e-312+ 0.0e+00i 3.2e-317+ 0.0e+00i [7] 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i 0.0e+00+ 0.0e+00i [10] 0.0e+00+ 0.0e+00i -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
