Re: [Rd] Rtools and GCC4 problem
You seem to be assuming that the C++ code is correct and the compiler is wrong. It seems very much more plausible that the reverse is true. Gcc3 was notoriously loose in its standards conformance in C++ and Fortran. Gcc4 is better, but g++4 still allows at least 10 packages on CRAN to compile which contain invalid C++ code and which compilers such as Sun Studio 12 reject. On Tue, 11 Mar 2008, Joe Byers wrote: > >>> > > I am trying to compile rseries from Whit Armstrong and a colleague of mine > found > a problem with using GCC4 > > I get the following error when compiling rseries > g++-sjlj -Ic:/R/include -O2 -Wall -c Rutils.cpp -o Rutils.o > Rutils.cpp: In function 'double* getColPointer(SEXPREC*, int)': > Rutils.cpp:406: warning: deprecated conversion from string constant to 'char*' > g++-sjlj -Ic:/R/include -O2 -Wall -c array.cpp -o array.o > g++-sjlj -Ic:/R/include -O2 -Wall -c interface.cpp -o interface.o > In file included from interface.hpp:1, > from interface.cpp:1: > tseries.hpp: In function 'tseries* cbind(Seq >&, > bool) > ': > tseries.hpp:533: error: no matching function for call to > 'tseries::setDates(std: > :vector >&)' > tseries.hpp:112: note: candidates are: void tseries::setDates(double*) > > > I changed the BUILD=GCC3 in MkRules and rseries will compile after fixing the > isnan declaration. > > I was wondering if anyone had experienced this type of problem in other > packages > and what could be done to fix it here or if it is in Rtools. The Rtools > version > I downgraded to 26 from 27 to get the GCC3 compiler.. > > thank you > joe > > The following the output from building > C:\src\R>r CMD install rseries > installing to 'c:/src/R/R-2.5.1/library' > > > -- Making package rseries > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > making DLL ... > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c Rutils.cpp -o Rutils.o > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h: In function `std::vector > > listnames(SEXPREC*)': > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h:82: warning: '__cur' might be used uninitialized in this function > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h: In function `std::vector > > rownames(SEXPREC*)': > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h:82: warning: '__cur' might be used uninitialized in this function > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h: In function `std::vector > > colnames(SEXPREC*)': > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h:82: warning: '__cur' might be used uninitialized in this function > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c array.cpp -o array.o > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c interface.cpp -o interface.o > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c mask.cpp -o mask.o > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c math_utils.cpp -o > math_utils.o > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c ts.data.cpp -o ts.data.o > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c tseries.cpp -o tseries.o > tseries.cpp: In function `tseries linear_model(const tseries&, const > tseries&)': > tseries.cpp:1058: warning: unused variable 'trans' > tseries.cpp:1059: warning: unused variable 'nrhs' > tseries.cpp:1060: warning: unused variable 'info' > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h: In member function `std::vector std::allocator >> tseries::getColNam > es() const': > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h:82: warning: '__cur' might be used uninitialized in this function > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_vector.h: > In member function `std::vector<_Tp, _Alloc>& std::vector<_Tp, > _Alloc>::operator=(const std::vector< _Tp, _Alloc>&) [with _Tp = std::string, > _Alloc = std::allocator]': > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_vector.h:7 > 15: warning: '__result' might be used uninitialized in this function > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h:82: warning: '__cur' might be used uninitialized in this function > c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ > 3.4.5/bits/stl_uninitiali > zed.h:82: warning: '__cur' might be used uninitialized in this function > g++ -Ic:/src/R/R-2.5.1/include -Wall -O2 -c util.cpp -o util.o > windres -I c:/src/R/
Re: [Rd] NA warnings for r() {aka "patch for random.c"}
> "BAT" == Berwin A Turlach <[EMAIL PROTECTED]>
> on Wed, 12 Mar 2008 01:23:10 +0800 writes:
BAT> G'day Martin, On Tue, 11 Mar 2008 18:07:35 +0100 Martin
BAT> Maechler <[EMAIL PROTECTED]> wrote:
>> > "BAT" == Berwin A Turlach <[EMAIL PROTECTED]> >
>> on Tue, 11 Mar 2008 13:19:46 +0800 writes:
BAT> [...] The first two lines give identical results, as
BAT> one could reasonably expect.
>>
>> Yes, but I don't think a user should *rely* on the way R
>> generates these random number; though I agree for the
>> very specific case of rlnorm(..).
>>
BAT> But the other two do not and I would argue that a user
BAT> could reasonably expect that the commands in these two
BAT> lines should lead to identical results.
>>
>> They now do.
BAT> Well, actually I forgot to mention one could also put
BAT> another argument forward. As the log-mean parameter of
BAT> the lognormal distribution goes to -Inf, the
BAT> distribution degenerates to something that has mean 0
BAT> and variance 0, i.e. could be taken as the constant
BAT> zero and, hence, one might expect that rlnorm(1, -Inf)
BAT> returns 0.
yes; and that has been a consequence of the changes I did yesterday.
BAT> But as the log-mean parameter goes to Inf, the
BAT> distribution degenerates to something with infinite
BAT> mean and infinite variance. Thus, perhaps it is more
BAT> sensible for rlnorm(1, Inf) to return NaN instead of
BAT> Inf.
well. We have pretty strictly tried to follow the principle
that 'Inf' or '-Inf' should be used when there are clear limit
If lim_{x \to x_0} f(x) = +/- Inf =: M
we would set
f(x_0) = M
for x_0 in |R + {-Inf, Inf}
If we apply this principle here, clearly,
rlnorm(., Inf) := lim_{lmu -> Inf} rlnorm(., lmu) =
= lim_{lmu -> Inf} exp(rnorm(., lmu)) =
= exp(lim_{lmu -> Inf} rnorm(., lmu)) =
= exp(Inf) = Inf
{ or you directly numerically see that already
rlnorm(50, 1000) gives all Inf }
Martin
>> I don't think your change to .../R/distn.R was good,
BAT> I didn't like it either, but it was the simplest way I
BAT> could think of that would allow the C rexp() routine to
BAT> realise that a scale parameter of 0 actually came from
BAT> a rate parameter of -Inf in the R code.
>> but the others I have more or less committed together
>> with a few more similar ones.
BAT> Thanks.
BAT> BTW, I was surprised to realise that the *exp()
BAT> functions in the underlying C code use the opposite
BAT> parameterisation from the corresponding functions at R
BAT> level. Perhaps it would be worthwhile to point this
BAT> out in section 6.7.1 of the Writing R extension manual?
BAT> In particular since the manual states:
>>
BAT> Note that these argument sequences are (apart from the
BAT> names and that @code{rnorm} has no @var{n}) exactly the
BAT> same as the corresponding @R{} functions of the same
BAT> name, so the documentation of the @R{} functions can be
BAT> used.
>>
BAT> Well, as I noticed the hard way, for *exp() the
BAT> documentation of the corresponding R functions cannot
BAT> be used. ;-)
>>
>> We often also gratefully accept patches for the
>> documentation
BAT> I know, and I am always amazed that despite this policy
BAT> (or perhaps because of it?) the documentation of R is
BAT> not patchy ;-)
BAT> Cheers,
BAT>Berwin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dan.bolser has invited you to Spokeo
Hi r-devel@r-project.org, [EMAIL PROTECTED] has invited you to Spokeo, which finds your friends' updates across the Web. On average, Spokeo finds 87 friends across 30 different social networks. See what Spokeo can find for you now! Click http://www.spokeo.com/public/join?c=41a1177284ee459339c4fdf17eb7acd35d423aa7 to accept your invitation. - This invitation was sent with dan.bolser's approval. If you wish to opt out of all future emails, go to http://www.spokeo.com/optout?c=r495256575753485549 Copyright (c) 2008 Spokeo, Inc. All rights reserved. 1685 Plymouth Street #200, Mountain View, CA 94043 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Subsetting vectors/arrays using factors can be seen as misleading
Dear list,
Subsetting vectors/arrays using factors can be seen as misleading, and
I was thinking that it could be discouraged (at least by issuing a
warning).
I could not find whether this was discussed earlier, but I can be
pointed to a reference if I missed any.
The "extract" operator "[" can take as arguments either vectors of
integers or vectors of characters in order to subset a data structure.
For example:
> x <- seq(1, 5)
> names(x) <- letters[1:5]
>
> x[1]
a
1
> x["a"]
a
1
Using a factor caused some confusion to someone here, and I have to
admit that it can indeed appear misleading:
> f <- factor("a", levels=c("b", "a", "c"))
> f
[1] a
Levels: b a c
> x[f] # here the integer is used, rather than the level
b
2
The dual nature of the factor (vector of integers, with an attached
vector of levels), is not always clear to many users, especially since
factors are treated differently in other situations.
Example:
> f == 1
[1] FALSE
> f == "a" #here the level is used, not the integer
[1] TRUE
This is making me suggest that indexing using a factor could issue a
warning, and the user should explicitly wrap the vector with either
"as.integer" or "as.character".
L.
PS: All examples above were run with
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status Under development (unstable)
major 2
minor 7.0
year 2008
month 03
day12
svn rev44742
language R
version.string R version 2.7.0 Under development (unstable) (2008-03-12 r44742)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
