Good morning,
A minor spelling buglet in files.Rd
Index: trunk/src/library/base/man/files.Rd
===
--- trunk/src/library/base/man/files.Rd (revision 48691)
+++ trunk/src/library/base/man/files.Rd (working copy)
@@ -100,7 +100,7 @@
}
Martin Maechler wrote:
[...]
> vQ> the first question is, why does ER return the string as const? it
> vQ> appears that the returned pointer provides the address of a buffer
> used
> vQ> internally in ER, which is allocated *statically*. that is, each call
> vQ> to ER operates
Tim Bergsma wrote:
Hi.
I'm maintaining a package that creates an object that is essentially a
classed version of numeric. I updated recently from 2.7.1 to 2.9.0,
and merges involving my class suddenly took a huge performance hit.
I've traced the problem to something near rank(). From NEWS, it
Dear Stavros,
On Sat, May 30, 2009 at 11:59 AM, Stavros Macrakis
wrote:
> The current implementation is column-wise...
Thanks for pointing that out, and solving the mystery for me. :-)
Jay
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/m
On Sat, May 30, 2009 at 10:58 AM, Tim Bergsma wrote:
> Hi.
>
> I'm maintaining a package that creates an object that is essentially a
> classed version of numeric. I updated recently from 2.7.1 to 2.9.0,
> and merges involving my class suddenly took a huge performance hit.
> I've traced the probl
Hi.
I'm maintaining a package that creates an object that is essentially a
classed version of numeric. I updated recently from 2.7.1 to 2.9.0,
and merges involving my class suddenly took a huge performance hit.
I've traced the problem to something near rank(). From NEWS, it seems
rank() etc. cha
use the option -lgfortran
John Nolan-3 wrote:
>
>
> I recently upgraded to Rtools28 to build a package under
> Windows. I see that g77 is no longer in Rtools, but it
> does have gfortran, and it uses version:
>GNU Fortran (GCC) 4.2.1-sjlj (mingw32-2)
>
> I am compiling some old fortran
> "vQ" == Wacek Kusnierczyk
> on Sat, 30 May 2009 11:16:43 +0200 writes:
vQ> Martin Maechler wrote:
>> Hi Waclav (and other interested parties),
>>
>> I have committed my working version of src/main/coerce.c
>> so you can prepare your patch against that.
>>
Since R is object-oriented, data frame set operations should be the natural
operations for their class. There are, I suppose, two natural ways: the
column-wise (variable-wise) and the row-wise (observation-wise) one. The
row-wise one seems more natural and more useful to me.
The current implemen
On Sat, May 30, 2009 at 8:50 AM, Stavros Macrakis wrote:
> It seems to me that, abstractly, a dataframe is just as
> straightforwardly a sequence of tuples/observations as a vector is a
> sequence of scalars. R's convention is that a 1-vector represents a
> scalar, and similarly, a 1-dataframe can
2009/5/30 Wacek Kusnierczyk :
> Martin Maechler wrote:
>> Hi Waclav (and other interested parties),
>>
>> I have committed my working version of src/main/coerce.c
>> so you can prepare your patch against that.
>>
>
> Hi Martin,
>
> One quick reaction (which does not resolve my original complaint):
Wacek Kusnierczyk wrote:
Martin Maechler wrote:
Hi Waclav (and other interested parties),
I have committed my working version of src/main/coerce.c
so you can prepare your patch against that.
some further investigation and reflections on the code in StringFromReal
(henceforth SFR), src/ma
It seems to me that, abstractly, a dataframe is just as
straightforwardly a sequence of tuples/observations as a vector is a
sequence of scalars. R's convention is that a 1-vector represents a
scalar, and similarly, a 1-dataframe can represent a tuple (though it
can also be represented as a list).
Martin Maechler wrote:
> Hi Waclav (and other interested parties),
>
> I have committed my working version of src/main/coerce.c
> so you can prepare your patch against that.
>
some further investigation and reflections on the code in StringFromReal
(henceforth SFR), src/main/coerce.c:315 (as in
14 matches
Mail list logo
