Why do you consider this might be a bug in R rather than in your
expectations? Your 'expected' is not what others have expected
In 2.4.1 rt(ncp) operates continuously as ncp is varied through 0.
That is different from saying that you want a central t (omitting ncp).
BTW, reports to R-bugs
> "goodrich" == goodrich <[EMAIL PROTECTED]>
> on Tue, 19 Dec 2006 22:45:33 +0100 (CET) writes:
goodrich> Reproduced on Debian and Windows ...
goodrich> On 2.4.x if you execute
goodrich> set.seed(12345)
goodrich> t.1 <- rt(n = 1000, df = 20)
goodrich> set.seed(1
-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
On 12/19/2006 11:44 PM, Duncan Murdoch wrote:
> A few days ago Brian Ripley pointed out a bug with the design of this,
> so I've changed it. See the notes below if you were trying to work with it.
>
> On 11/25/2006 1:51 PM, Duncan Murdoch wrote:
>> I have just committed some changes to R-devel (
A few days ago Brian Ripley pointed out a bug with the design of this,
so I've changed it. See the notes below if you were trying to work with it.
On 11/25/2006 1:51 PM, Duncan Murdoch wrote:
> I have just committed some changes to R-devel (which will become R 2.5.0
> next spring) to add source
On Saturday 16 December 2006 4:41 pm, Martin Maechler wrote:
>
> Correction: the problems show on both platforms;
>
> one is in mgcv, gam(), an error in [[ <- -- pretty clearly linked to your
> changes but not reproducible when tried isolatedly
> interactively,
>
> the other one is a seg.fault "me
On Thu, 14 Dec 2006, Prof Brian Ripley wrote:
> On Thu, 14 Dec 2006, Barry Rowlingson wrote:
>
> [Silently discarding the answer to his question, and breaching
> 'fair use' copyright provisions.]
>
> >> So the problem is that you needed rather
> >>
> >> #include
> >> #ifdef USING_R
> >> x = rand_
Thanks! It seems the 'volatile' declaration is exactly what was needed.
Ben
Prof Brian Ripley wrote:
> In C, declaring a value as 'volatile' should force it to be stored in
> a 64-bit memory location. There is no known way to do this in Fortran:
> compilers and numeric software have been playin
On Tue, 19 Dec 2006, Duncan Murdoch wrote:
> On 12/19/2006 4:16 PM, Benjamin Tyner wrote:
>> Thanks; I'm on 32-bit linux, but it's good to know the behavior on
>> Windows. Do you know a way to force "floor" to use this reduced precision?
>
> Force the value to be stored to a "double" and it will g
Byron Ellis gmail.com> writes:
>
> He wants to specify arguments to AIC that act like the "k" argument
> and is thinking of faking it by, essentially, doing another round of
> argument matching on ...
>
> I think that if you define an S4 generic that only dispatches on the
> first argument you
On 12/19/2006 4:16 PM, Benjamin Tyner wrote:
> Thanks; I'm on 32-bit linux, but it's good to know the behavior on
> Windows. Do you know a way to force "floor" to use this reduced precision?
Force the value to be stored to a "double" and it will get the reduced
precision. You can do this by ass
Thanks; I'm on 32-bit linux, but it's good to know the behavior on
Windows. Do you know a way to force "floor" to use this reduced precision?
Ben
Duncan Murdoch wrote:
> On Windows, it's fairly common for runtime libraries to switch the
> precision from 80 bit to 64 bit. R on Windows tries to
On 12/19/2006 1:58 PM, Benjamin Tyner wrote:
> I'm trying to figure out why the presence of a Fortran call affects the
> result of a floating-point operation. I have C functions
On Windows, it's fairly common for runtime libraries to switch the
precision from 80 bit to 64 bit. R on Windows trie
I'm trying to figure out why the presence of a Fortran call affects the
result of a floating-point operation. I have C functions
void test1(int *n, double *f){
int outC;
double c0;
c0 = (double) *n * *f;
outC = floor(c0);
printf("when f computed by R, C says %d by itself\n",outC);
}
Hi,
I have sparse (tridiagonal) matrices, and I use the Matrix package for
handling them. For certain computations, I need to either set the
first row to zero, or double the last row. I find that neither
operation preserves sparsity, eg
> m <- Diagonal(5)
> m
5 x 5 diagonal matrix of class "ddi
Pascal A. Niklaus wrote:
> BTW, the error only occurs if netdb.h is included *after* config.h. Not sure
> if this helps...
Google have the answer :-). It looks like the gcc folks and some
HP engineers know about this issue but cannot settle on what to do
with it - see this thread:
http://gcc.gn
Giampiero Salvi wrote:
> Hi Hin-Tak Leung,
> thank you for your help. Paul and I had solved the problem off-line.
> Here is the solution: the encoding file contained in the tipa package
> is not in adobe format and therefore causes the problem. The default
> encoding, however, seems to work well. I
On Tuesday 19 December 2006 12:35, Hin-Tak Leung wrote:
> Hmm, HP-UX on IA64 is 64-bit or not? It looks as if it can operate
> in 32-bit mode or run 32-bit binaries. It would be useful if you run
> this:
>
> gcc -E -dM - < /dev/null > /tmp/macrolist
>
> and post the compiler's internal macro list.
Hmm, HP-UX on IA64 is 64-bit or not? It looks as if it can operate
in 32-bit mode or run 32-bit binaries. It would be useful if you run
this:
gcc -E -dM - < /dev/null > /tmp/macrolist
and post the compiler's internal macro list.
Pascal A. Niklaus wrote:
>> _APP32_64BIT_OFF_T gets defined in sys/
> _APP32_64BIT_OFF_T gets defined in sys/stdsyms.h:
> (I've put the file at http://azug.minpet.unibas.ch/~pascal/R/stdsyms.h)
>
> # ifdef _FILE_OFFSET_BITS
> # if _FILE_OFFSET_BITS == 64
> #define _FILE64 /* _FILE64 is obsolescent; don't use it */
> #define __64BIT_OFF_T
> #i
> > This sits in the include file: We have unconditional declarations
> >extern sbsize_t sendfile __((int, int, off_t, bsize_t,
> >const struct iovec *, int));
> >extern sbsize_t sendpath __((int, char *, off_t, bsize_t,
> >con
Hi Hin-Tak Leung,
thank you for your help. Paul and I had solved the problem off-line.
Here is the solution: the encoding file contained in the tipa package
is not in adobe format and therefore causes the problem. The default
encoding, however, seems to work well. In case of fonts corresponding
to
Tnx all for the interesting (and all working) suggestions!
Best regards,
Antonio.
2006/12/19, Gabor Grothendieck <[EMAIL PROTECTED]>:
> Here is one possibility. It does not use the second argument in your function
> call but instead assumes the arguments of the output function are
> those variab
23 matches
Mail list logo
