[Rd] subsetting matrix by subscript=0,x silently skips.
(e-mailing to R-bugs is intentional - the web itnerface seems to be down) > a<- cbind(c(1,2), c(3,4)) > a [,1] [,2] [1,]13 [2,]24 > a[cbind(c(2,2), c(2,1))] [1] 4 2 > a[cbind(c(2,3), c(2,1))] Error: subscript out of bounds > a[cbind(c(2,-1), c(2,1))] Error: negative values are not allowed in a matrix subscript > a[cbind(c(2,0), c(2,1))] [1] 4 Am somewhat surprised that 2,0 just silently skip over and doesn't throw an error like 2,0 and 2,-1 . Surely it should throw an error about subscript should be >= 1? > sessionInfo() R version 2.4.1 (2006-12-18) i686-redhat-linux-gnu locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] "splines" "stats" "graphics" "grDevices" "utils" "datasets" [7] "methods" "base" other attached packages: snpMatrix survival "1.0.4""2.30" > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] on.exit called on loading ?
On 1/16/2007 5:12 PM, Dirk Eddelbuettel wrote:
> On 16 January 2007 at 16:39, Duncan Murdoch wrote:
> | On 1/16/2007 4:02 PM, Dirk Eddelbuettel wrote:
> | > I just found out that an .onLoad() function such as this stylized one
> (where
> | > I just renamed some identifiers)
> | >
> | >
> | > .onLoad <- function(lib, pkg) {
> | > require(zoo, quiet=TRUE, warn.conflicts=FALSE)
> | > library.dynam("foolib", pkg, lib )
> | > if (.Platform$OS.type != "windows") {
> | > initSomeServices()
> | > }
> | > if (.Platform$OS.type != "windows") {
> | > on.exit(closeSomeServices())
> | > }
> | > }
> | >
> | > actually triggers a call of 'closeSomeServices()'. I am probably
> | > misunderstanding something here -- but I thought on.exit() would only be
> | > called on, well, exit ?
> |
> | It's the exit from the function, not the exit from the package (which
> | isn't really all that well defined -- do you mean unloading, exit from
> | R, detaching??
>
> Thanks to Robert (off-list), Henrik and Duncan -- I had indeed forgotten /
> confused what on.exit() is for. Works as advertised here, but that wasn't
> what I wanted at the time. Entirely my bad.
>
> | It's not very easy to have something be guaranteed to execute "when
> | you're done". The RODBC package does it using an external pointer,
> | which has a hook that is called when R shuts down. If it's good enough
> | to execute on unloading but skip execution on shutdown, then .onUnload
> | is available.
>
> Yes, I am dealing with a moderately more complicated situation (of
> subscribing to some stateful internal 'services') and had not found
> .onUnload to be as reliable as I had hoped. But that's another issue.
reg.finalizer is probably what you want. Since 2.4.0 it has had an
option to be called when R shuts down.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9444)
> What do the other developeRs and useRs think about this? Hi, I here reply as a R user. >> This makes me quite reluctant to >> change it: people get upset about changes to the look of their old >> scripts, because they trigger spurious check errors. > > > Is it possible to add an option to specify whether "/" operators should be > treated like "+", "-", and "*" operators or not? > Arne I naively assume that, if this is the first time in 10 years that such a problem arises, it is a rather uncommon one, or at least to scarce to add an option which would seem quite surprising to most of the R users. However, anyone meeting this problem would now be able to correct it using your patch ;-) Regards, Thibaut. -- ## Thibaut JOMBART CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive Universite Lyon 1 43 bd du 11 novembre 1918 69622 Villeurbanne Cedex Tél. : 04.72.43.29.35 Fax : 04.72.43.13.88 [EMAIL PROTECTED] http://biomserv.univ-lyon1.fr/sitelabo/pageperso.php?id_personne=178 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Emulating a REPL in frontends
A common need in R frontends is to provide some sort of read, (parse),
evaluate, print loop. However, there are also a number of points where
frontends may want to differ from the standard REPL as available e.g. in
R_ReplDLLdo1().
First some thoughts on what is needed, and what is already there, or missing.
If you want to skip over this, a short summary is provided in the second
half, below a line marked "":
Read stage:
- R_ReplDLLdo1() calls ReadConsole to fetch an input buffer. This is not well
ideally for some situations. For example, the "Console", and the R process
may be running on different machines. Or a frontend may provide several
consoles or console-alikes working on the same workspace. Or the frontend may
want to differentiate between "submitting code to the backend", and answering
requests for input from read.line().
Parse stage:
- If (due to the above mentioned aspects, or for some other reason), a
frontend does not use R_ReplDLLdo1(), it will have to use R_ParseVector() for
parsing. There's nothing wrong with that, except for the fact, that there
does not seem to be a way to get at the full error message in case of a parse
error, as parseError() is not exported.
Evaluate stage:
- Frontends may want to evaluate a sequence of statements at once, or one at a
time.
- A typical requirement of a frontend is for evaluation to be guaranteed to
return to the point of code it was called from.
- Both of this is available using R_tryEval().
Print stage:
- Frontends may want to always print the result of evaluation for some
statements, they may want to suppress printing entirely for some (internal)
statement, but most importantly, they will probably want to auto-print values
for most statements (i.e. print them if and only if R_Visible is TRUE).
- There does not seem to be a good way (from the C-API) to do auto-printing of
values outside of R_ReplDLLdo1(): R_Visible is not exported any longer, and
PrintValueEnv() is neither. Rf_PrintValue() should yield the same results as
PrintValueEnv() in most, but probably not all cases.
- From R API, withVisible() provides a way to emulate auto-printing, but with
the drawback that wrapping all statements inside withVisible() makes
potential errors harder to read (you get something like "Error in
eval.with.vis(x, parent.frame(), baseenv()) :", unless using extra magic to
convert the Error magic back to "normal").
Other things done in R_ReplDLLdo1() / other REPLs:
- Frontends may want to set R_LastValueSymbol for most (statement entered by
the user directly), but not all statements (so as to keep .Last.value
unchanged over internal operations like e.g. updating information on an
object in an object browser)
- Frontends may want to call toplevel handlers after some statements, but not
after others (probably a similar distinction).
--
In summary, it seems like many frontends can not rely on R_ReplDLLdo1() (let
alone running run_Rmainloop()), or at least not exclusively so. The
alternative, using R_ParseVector() and R_tryEval() also has drawbacks, most
importantly problems getting at parse errors, and auto-printing.
Two suggestions, which I hope are not too intrusive:
1) Make parseError() part of the public API. If there is a concern that the
details of this function may change, a wrapper like the following should be
good enough for most, if not all frontend purposes:
void Rf_parseErrorDefault()
{
parseError(R_NilValue, 0);
}
2) Add a simple function to do auto-printing to the public API. E.g.:
Rboolean Rf_doAutoPrint(SEXP exp)
{
if(R_Visible) {
printValueEnv(exp, R_GlobalEnv);
return TRUE;/* was printed */
}
return FALSE;
}
Another suggestion, which might well be seen as adding too many constraints on
future development, but provided for completeness: A more generic version of
the EPL-part of R_ReplDLLDo1() with function parameters to determine, which
steps are taken/omitted. I'm attaching a sketch of this. It is a copy with
minimal modifications of the relevant code sections from R_ReplDLLdo1() and
friends, which could then be simplified to use this function, internally.
Regards
Thomas Friedrichsmeier
/* print mode: 0: print if visible. 1: always print 2: never print */
SEXP R_DLLGenericEplDo1 (unsigned char *buffer, ParseStatus *parse_status,
Rboolean set_last_sym_value, int print_mode, Rboolean do_toplevel_callbacks)
{
int c;
ParseStatus status;
SEXP value;
SEXP rho = R_GlobalEnv;
Rboolean wasDisplayed = FALSE;
while((c = *buffer++)) {
R_IoBufferPutc(c, &R_ConsoleIob);
if(c == ';' || c == '\n') break;
}
R_PPStackTop = 0;
R_CurrentExpr = R_Parse1Buffer(&R_ConsoleIob, 0, &status);
if(parse_status) *parse_status = status;
switch(status) {
case PARSE_NULL:
R_IoBufferWriteReset(&R_ConsoleIob);
break;
case PARSE_OK:
R_IoBufferReadReset(&R_C
[Rd] Building R 2.4.1 on IRIX
Hi,
I've got the latest MIPS compilers that are C99 aware (7.4.4).
"configure" finishes with:
R is now configured for mips-sgi-irix6.5
Source directory: .
Installation directory:/afs/bi/v/@sys/apps/stats/R/2.4.1
C compiler:cc -c99 -OPT:IEEE_NaN_inf=ON -g
Fortran 77 compiler: f77 -OPT:IEEE_NaN_inf=ON -g
C++ compiler: CC -OPT:IEEE_NaN_inf=ON -g
Fortran 90/95 compiler:f90 -g
Interfaces supported: X11
External libraries:readline
Additional capabilities: PNG, JPEG, NLS
Options enabled: shared BLAS, R profiling
Recommended packages: yes
Building R 2.4.1, I stumble across the following error in
src/main/complex.c:
cc -c99 -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre
-I. -I../../src/include -I../../src/include -I/afs/bi/p/include -DHAVE_CONFIG_H
-OPT:IEEE_NaN_inf=ON -g -c complex.c -o complex.o
cc-1143 cc: ERROR File = /usr/include/complex.h, Line = 176
Declaration is incompatible with "double cabs(struct __cabs_s)" (declared at
line 667 of "/usr/include/math.h").
static inline double cabs (double complex z) {return
__c99_cabs(z); }
^
cc-1143 cc: ERROR File = /usr/include/complex.h, Line = 178
Declaration is incompatible with "long double cabsl(struct __cabsl_s)"
(declared at line 528 of "/usr/include/math.h").
static inline long double cabsl (long double complex z) {return
__c99_cabsl(z);}
^
2 errors detected in the compilation of "complex.c".
gmake[3]: *** [complex.o] Error 2
All ideas for fixing this would be welcome. I'm not subscribed to the
mailing list, so personal copies would be appreciated, but I will be
monitoring the web archives of the list to catch responses posted to
the list only.
Regards,
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Working with Sweave: inverse search?
I've now packaged up the Sweave inverse search package, and made the
prototype available on my web page
http://www.stats.uwo.ca/faculty/murdoch/software
as patchDVI_0.2.tar.gz and patchDVI_0.2.zip. I don't know of any bugs
in those, but I'd like to hear about them.
To enable the inverse search, you need an \SweaveOpts line in the .Rnw
file with "concordance=TRUE".
I normally use MikTeX, so to make my life easier I wrote a little
SweaveMiktex() function and put it in the package. Using that package
in Windows, the following batch file processes Sweave, runs latex,
patches the .dvi, and runs the previewer:
echo library(patchDVI);SweaveMiktex('%2', '%3.tex') | Rterm --slave
yap -1 -s"%1%2" %3.dvi
It needs to be called with three parameters:
%1 - the current line number in the editor; yap will jump to that location
%2 - the name of the current file in the editor; if it's *.tex, then
Sweave will be skipped, but the patching will still be done (because
some other file in the project might be a .Rnw file). If not, the file
is run through Sweave first.
%3 - the base name of the file (no extension) to send to latex.
For example, if I am on line 100 of a chapter called syntax.Rnw in a
book called programming.tex, I would call this file with args
100 syntax.Rnw programming
If you're using some other TeX package, the SweaveMiktex function might
still work, but it's likely the script to run it and the previewer would
have to change.
If you have a completely different work flow, the steps you need to
implement are these:
1. Put the \SweaveOpts{concordance=TRUE} line into your .Rnw file.
2. Run the patchDVI version of Sweave() on your file.
3. Run latex to produce a .dvi file.
4. Run the patchDVI function on the .dvi file to patch it.
5. Run your previewer, with options telling it you want to see a
particular line in the .Rnw file.
In a big project, you only need to run Sweave on those .Rnw files that
have changed; the information linking to the original source is output
in a file in the same place figures from the Sweave output would be
saved, e.g. in the example above, as "syntax-concordance.tex".
The format of the concordance is very likely to change as patchDVI
evolves, so you'll want to re-run Sweave if you update your patchDVI
package.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] subsetting matrix by subscript=0,x silently skips.
The help page for "[" says: A third form of indexing is via a numeric matrix with the one column for each dimension: each row of the index matrix then selects a single element of the array, and the result is a vector. Negative indices are not allowed in the index matrix. NA and zero values are allowed: rows of an index matrix containing a zero are ignored, whereas rows containing an NA produce an NA in the result. So, I think it is behaving as documented. -- Tony Plate Hin-Tak Leung wrote: > (e-mailing to R-bugs is intentional - the web itnerface seems to > be down) > > > a<- cbind(c(1,2), c(3,4)) > > a > [,1] [,2] > [1,]13 > [2,]24 > > > a[cbind(c(2,2), c(2,1))] > [1] 4 2 > > a[cbind(c(2,3), c(2,1))] > Error: subscript out of bounds > > a[cbind(c(2,-1), c(2,1))] > Error: negative values are not allowed in a matrix subscript > > a[cbind(c(2,0), c(2,1))] > [1] 4 > > Am somewhat surprised that 2,0 just silently skip over and doesn't > throw an error like 2,0 and 2,-1 . Surely it should throw > an error about subscript should be >= 1? > > > > > sessionInfo() > R version 2.4.1 (2006-12-18) > i686-redhat-linux-gnu > > locale: > LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C > > attached base packages: > [1] "splines" "stats" "graphics" "grDevices" "utils" "datasets" > [7] "methods" "base" > > other attached packages: > snpMatrix survival >"1.0.4""2.30" > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] subsetting matrix by subscript=0,x silently skips.
Hin-Tak Leung wrote: > (e-mailing to R-bugs is intentional - the web itnerface seems to > be down) > So is the mail interface... I have alerted our support people, but I didn't see the problem until I came back from teaching, so they may not get it fixed before tomorrow. -- 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] subsetting matrix by subscript=0,x silently skips.
(I have taken off r-bug@, as multiple e-mails hitting r-bug@ probably will result in multiple bug reports, knowing most mail server will retry) Tony Plate wrote: > The help page for "[" says: > > A third form of indexing is via a numeric matrix with the one column for > each dimension: each row of the index matrix then selects a single > element of the array, and the result is a vector. Negative indices are > not allowed in the index matrix. NA and zero values are allowed: rows of > an index matrix containing a zero are ignored, whereas rows containing > an NA produce an NA in the result. > > So, I think it is behaving as documented. Hmm, fair enough. I guess the NA one make sense (In R as a rule, NA in, NA out), but I am not sure I understand or agree with the rationale of silently ignoring (0,x) and (x,0)'s. Any reason for that? HTL > Hin-Tak Leung wrote: >> (e-mailing to R-bugs is intentional - the web itnerface seems to >> be down) >> >> > a<- cbind(c(1,2), c(3,4)) >> > a >> [,1] [,2] >> [1,]13 >> [2,]24 >> >> > a[cbind(c(2,2), c(2,1))] >> [1] 4 2 >> > a[cbind(c(2,3), c(2,1))] >> Error: subscript out of bounds >> > a[cbind(c(2,-1), c(2,1))] >> Error: negative values are not allowed in a matrix subscript >> > a[cbind(c(2,0), c(2,1))] >> [1] 4 >> >> Am somewhat surprised that 2,0 just silently skip over and doesn't >> throw an error like 2,0 and 2,-1 . Surely it should throw >> an error about subscript should be >= 1? >> >> >> >> > sessionInfo() >> R version 2.4.1 (2006-12-18) >> i686-redhat-linux-gnu >> >> locale: >> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C >> >> >> >> attached base packages: >> [1] "splines" "stats" "graphics" "grDevices" "utils" >> "datasets" >> [7] "methods" "base" >> >> other attached packages: >> snpMatrix survival >>"1.0.4""2.30" >> > >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R 2.4.1 on IRIX
Atro Tossavainen wrote:
> Hi,
>
> I've got the latest MIPS compilers that are C99 aware (7.4.4).
>
> "configure" finishes with:
>
> R is now configured for mips-sgi-irix6.5
>
> Source directory: .
> Installation directory:/afs/bi/v/@sys/apps/stats/R/2.4.1
>
> C compiler:cc -c99 -OPT:IEEE_NaN_inf=ON -g
> Fortran 77 compiler: f77 -OPT:IEEE_NaN_inf=ON -g
>
> C++ compiler: CC -OPT:IEEE_NaN_inf=ON -g
> Fortran 90/95 compiler:f90 -g
>
> Interfaces supported: X11
> External libraries:readline
> Additional capabilities: PNG, JPEG, NLS
> Options enabled: shared BLAS, R profiling
>
> Recommended packages: yes
>
> Building R 2.4.1, I stumble across the following error in
> src/main/complex.c:
>
> cc -c99 -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre
> -I. -I../../src/include -I../../src/include -I/afs/bi/p/include
> -DHAVE_CONFIG_H -OPT:IEEE_NaN_inf=ON -g -c complex.c -o complex.o
>
> cc-1143 cc: ERROR File = /usr/include/complex.h, Line = 176
> Declaration is incompatible with "double cabs(struct __cabs_s)" (declared at
> line 667 of "/usr/include/math.h").
>
> static inline double cabs (double complex z) {return
> __c99_cabs(z); }
>^
>
> cc-1143 cc: ERROR File = /usr/include/complex.h, Line = 178
> Declaration is incompatible with "long double cabsl(struct __cabsl_s)"
> (declared at line 528 of "/usr/include/math.h").
>
> static inline long double cabsl (long double complex z) {return
> __c99_cabsl(z);}
> ^
>
> 2 errors detected in the compilation of "complex.c".
> gmake[3]: *** [complex.o] Error 2
>
>
> All ideas for fixing this would be welcome. I'm not subscribed to the
> mailing list, so personal copies would be appreciated, but I will be
> monitoring the web archives of the list to catch responses posted to
> the list only.
>
It looks like two system include files are getting into a dogfight. You
might want to investigate whether you can reproduce the issue with a
smaller source file, possibly dropping some of the -I directories in
that cc command line, and submit the issue to the vendor if you get
convinced that the issue is not actually an R one.
If this is the case, your best hope is if you can make cc less picky
about such redefinitions.
--
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 2.4.1 on IRIX
Peter Dalgaard wrote:
> Atro Tossavainen wrote:
>> Hi,
>>
>> I've got the latest MIPS compilers that are C99 aware (7.4.4).
>>
>> "configure" finishes with:
>>
>> R is now configured for mips-sgi-irix6.5
>>
>> Source directory: .
>> Installation directory:/afs/bi/v/@sys/apps/stats/R/2.4.1
>>
>> C compiler:cc -c99 -OPT:IEEE_NaN_inf=ON -g
>> Fortran 77 compiler: f77 -OPT:IEEE_NaN_inf=ON -g
>>
>> C++ compiler: CC -OPT:IEEE_NaN_inf=ON -g
>> Fortran 90/95 compiler:f90 -g
>>
>> Interfaces supported: X11
>> External libraries:readline
>> Additional capabilities: PNG, JPEG, NLS
>> Options enabled: shared BLAS, R profiling
>>
>> Recommended packages: yes
>>
>> Building R 2.4.1, I stumble across the following error in
>> src/main/complex.c:
>>
>> cc -c99 -I../../src/extra/zlib -I../../src/extra/bzip2
>> -I../../src/extra/pcre -I. -I../../src/include -I../../src/include
>> -I/afs/bi/p/include -DHAVE_CONFIG_H -OPT:IEEE_NaN_inf=ON -g -c complex.c
>> -o complex.o
>>
>> cc-1143 cc: ERROR File = /usr/include/complex.h, Line = 176
>> Declaration is incompatible with "double cabs(struct __cabs_s)" (declared
>> at
>> line 667 of "/usr/include/math.h").
>>
>> static inline double cabs (double complex z) {return
>> __c99_cabs(z); }
>>^
>>
>> cc-1143 cc: ERROR File = /usr/include/complex.h, Line = 178
>> Declaration is incompatible with "long double cabsl(struct __cabsl_s)"
>> (declared at line 528 of "/usr/include/math.h").
>>
>> static inline long double cabsl (long double complex z) {return
>> __c99_cabsl(z);}
>> ^
>>
>> 2 errors detected in the compilation of "complex.c".
>> gmake[3]: *** [complex.o] Error 2
>>
>>
>> All ideas for fixing this would be welcome. I'm not subscribed to the
>> mailing list, so personal copies would be appreciated, but I will be
>> monitoring the web archives of the list to catch responses posted to
>> the list only.
>>
> It looks like two system include files are getting into a dogfight. You
> might want to investigate whether you can reproduce the issue with a
> smaller source file, possibly dropping some of the -I directories in
> that cc command line, and submit the issue to the vendor if you get
> convinced that the issue is not actually an R one.
>
> If this is the case, your best hope is if you can make cc less picky
> about such redefinitions.
>
Certainly it looks the case. It might also be worth actually looking at
the two flighting system header files - occasionally sections are
controlled by macros like this:
ifdef _XOPEN_SOURCE
extern void foo(int bar)
#else
static void foo(char bar)
#end
where alternative function prototype definitions are chosen based
on macros. It might be possible to resolve the conflict by defining
a suitable macro during ./confgure. with something like this:
CFLAGS="-D_XOPEN_SOURCE" ./configure
(in fact posting the two files somewhere or even e-mailing in
might be a good idea - I am not promising I'll look at them
in time though, but somebody else might have the time to do
it, so it might be a good idea to put it up on a URL and wait...).
HTL
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] subsetting matrix by subscript=0,x silently skips.
Hin-Tak Leung wrote: > (I have taken off r-bug@, as multiple e-mails hitting r-bug@ probably > will result in multiple bug reports, knowing most mail server will > retry) > > Tony Plate wrote: > >> The help page for "[" says: >> >> A third form of indexing is via a numeric matrix with the one column >> for each dimension: each row of the index matrix then selects a single >> element of the array, and the result is a vector. Negative indices are >> not allowed in the index matrix. NA and zero values are allowed: rows >> of an index matrix containing a zero are ignored, whereas rows >> containing an NA produce an NA in the result. >> >> So, I think it is behaving as documented. > > > Hmm, fair enough. I guess the NA one make sense (In R as a rule, > NA in, NA out), but I am not sure I understand or agree with > the rationale of silently ignoring (0,x) and (x,0)'s. Any reason for that? AFAIK, the reason is to make the behavior analogous to how regular indices are treated, e.g.: > x <- array(1:6, dim=2:3) > x[c(0,1),2] [1] 3 > x[cbind(c(0,1),2)] [1] 3 > (i.e., 0's in indices are omitted) -- Tony Plate > > HTL > >> Hin-Tak Leung wrote: >> >>> (e-mailing to R-bugs is intentional - the web itnerface seems to >>> be down) >>> >>> > a<- cbind(c(1,2), c(3,4)) >>> > a >>> [,1] [,2] >>> [1,]13 >>> [2,]24 >>> >>> > a[cbind(c(2,2), c(2,1))] >>> [1] 4 2 >>> > a[cbind(c(2,3), c(2,1))] >>> Error: subscript out of bounds >>> > a[cbind(c(2,-1), c(2,1))] >>> Error: negative values are not allowed in a matrix subscript >>> > a[cbind(c(2,0), c(2,1))] >>> [1] 4 >>> >>> Am somewhat surprised that 2,0 just silently skip over and doesn't >>> throw an error like 2,0 and 2,-1 . Surely it should throw >>> an error about subscript should be >= 1? >>> >>> >>> >>> > sessionInfo() >>> R version 2.4.1 (2006-12-18) >>> i686-redhat-linux-gnu >>> >>> locale: >>> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C >>> >>> >>> >>> attached base packages: >>> [1] "splines" "stats" "graphics" "grDevices" "utils" >>> "datasets" >>> [7] "methods" "base" >>> >>> other attached packages: >>> snpMatrix survival >>>"1.0.4""2.30" >>> > >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-bugs, was subsetting matrix by subscript=0, x silently skips.
Hin-Tak Leung wrote: > (I have taken off r-bug@, as multiple e-mails hitting r-bug@ probably > will result in multiple bug reports, knowing most mail server will > retry) > Actually, reports will fall into a deep dark hole The home dir of r-bugs had gone AWOL and this contains the forwarding file that handles incoming mail. So basically, it becomes regular incoming mail for r-bugs and I have no (easy) method for resending it from there. If it is important, I assume that people will resend. It seems that the repository is back up again now. -p __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
