Quoting Prof Brian Ripley :
On 27/03/2012 22:01, Ben Goodrich wrote:
In case anyone is concerned that this regression will affect them, the
code was reverted to the 2.14.x behavior by
r58842 | ripley | 2012-03-26 08:12
lel")
> }
>
> Contrary to the comment, I have found that if I specify xdr = TRUE, I
> get the expected (non-corrupted X slot) behavior in 2.16.0, even
> though it is forking locally on my 64bit Debian laptop with a little
> endian i7 processor, whose specs are
>
with a little
endian i7 processor, whose specs are
goodrich@CYBERPOWERPC:/tmp/serialization$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
stepping: 7
microcode : 0
Full_Name: Ben Goodrich
Version: 2.9.0
OS: Linux (Debian unstable)
Submission from: (NULL) (128.103.220.16)
row(x), col(x), and functions that call them like lower.tri(x) and upper.tri(x)
do not retain the rownames or colnames of x in the matrix that is returned.
Example from R version 2.9.0
two different repositories for GPL like
> licensed pkg and other packages.
>
> Christophe
>
> Le 24 avr. 09 à 18:20, Gabor Grothendieck a écrit :
>
>> On Fri, Apr 24, 2009 at 11:44 AM, Ben Goodrich
>> wrote:
>>> Kurt Hornik wrote:
>>>> AG
Kurt Hornik wrote:
> AGPL, unfortunately, allows supplements, and hence cannot fully be
> standardized. We've been thinking about extending the current scheme to
> indicate a base license plus supplements, but this is still work in
> progress.
This would be helpful. I would just reemphasize that
Gabor Grothendieck wrote:
> On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich
> wrote:
>> Dirk Eddelbuettel debian.org> writes:
>>> As a non-exhautive list with possible misclassifications, cran2deb currently
>>> has these packasges as 'maybe not free'
Dirk Eddelbuettel debian.org> writes:
> As a non-exhautive list with possible misclassifications, cran2deb currently
> has these packasges as 'maybe not free' and does not build them:
>
> BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
> alphahull,ash,asypow,caMassCl
Gabor Grothendieck wrote:
> If you place an .Rbuildignore file in the top level of
> your package with this line single line as its contents:
>
> [.]bzr$
>
> then the .bzr file will not be included.
Thank you for the suggestion. In order to remove both the .bzr/
directory and the .bzrignore file
Gabor Grothendieck wrote:
> If you place an .Rbuildignore file in the top level of
> your package with this line single line as its contents:
>
> [.]bzr$
>
> then the .bzr file will not be included.
Thank you for the suggestion. In order to remove both the .bzr/
directory and the .bzrignore file
Full_Name: Ben Goodrich
Version: 2.6.1
OS: Debian
Submission from: (NULL) (128.103.222.166)
bzr is another version control system and adds a .bzr folder to the top-level
directory of a package, similar to .svn and .git for subversion and git
respectively. However, while R CMD build removes
[I was overlooked on the CC. Hopefully this message does not create a
new bug report.]
> Prof Brian Ripley wrote:
> I would say this was user error (insisting on editing non-existent
> rownames), although the argument is documented. You could argue that
> there are implicit rownames, but they wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Prof Brian Ripley wrote:
> Why do you consider this might be a bug in R rather than in your
> expectations? Your 'expected' is not what others have expected
Thank you for this response. I did consider at the time that this
unexpected result coul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
<>
Reproduced on Debian and Windows ...
On 2.4.x if you execute
set.seed(12345)
t.1 <- rt(n = 1000, df = 20)
set.seed(12345)
t.2 <- rt(n = 1000, df = 20, ncp = 0)
all.equal(t.1, t.2) ## Not close to true
This appears to be due to the fact that in
14 matches
Mail list logo
