I am more than 'a little disappointed' that you expect a detailed
explanation of the problems with your 'bug' report, especially as you did
not provide any explanation yourself as to your reasoning (nor did you
provide any credentials nor references).
Note that
1) Your report did not make clea
Thank you very much, that was very helpful. Now I think I understand
(parts of) the protection mechanism.
/Kasper
On May 23, 2006, at 9:03 PM, Prof Brian Ripley wrote:
> On Tue, 23 May 2006, Kasper Daniel Hansen wrote:
>
>> Thank you very much. I think I do have a clearer understanding,
>> b
On Tue, 23 May 2006, Kasper Daniel Hansen wrote:
> Thank you very much. I think I do have a clearer understanding, but I have a
> few questions
>
> On May 23, 2006, at 12:55 AM, Prof Brian Ripley wrote:
>
>> On Tue, 23 May 2006, Prof Brian Ripley wrote:
>>
>>> On Mon, 22 May 2006, Kasper Daniel
Thank you very much. I think I do have a clearer understanding, but I
have a few questions
On May 23, 2006, at 12:55 AM, Prof Brian Ripley wrote:
> On Tue, 23 May 2006, Prof Brian Ripley wrote:
>
>> On Mon, 22 May 2006, Kasper Daniel Hansen wrote:
>>
>>> I have a few simple questions about the
In time-aligning the two series there will be missing values, and you
cannot compute a ccf for series with missing values, hence the problem.
ccf(x, y, na.action=na.contiguous) works.
I guess that using ts.intersect rather than ts.union would be a simple
workaround for this by automatically trim
This is R 2.3.0 from CRAN, windows XP.
The following looks like a bug in ccf():
> x <- ts(rnorm(100), start=1)
> y <- ts(rnorm(120), start=3)
> ccf(x,y)
Erro en na.fail.default(ts.union(as.ts(x), as.ts(y))) :
missing values in object
> ccf(x,y, na.action=na.pass)
Erro en na.fail.defa
> This may be related to the problems with "greedy" search for inherited
> methods discussed previously on this list (or may not, it's a bit
> different).
Thank you very much for your explanation --- at least this is not a silly
fault from our side!
> In any case, the likely fix will be a subst
Yes, if this processing does not exist on japanese locale
will fall.
2006/5/23, Prof Brian Ripley <[EMAIL PROTECTED]>:
> Is this necessary to avoid LC_CTYPE="C"? If so, I stopped that at C level
> yesterday (it was already disallowed when starting R).
>
> On Tue, 23 May 2006, Ei-ji Nakama wrote:
On Tue, May 23, 2006 at 12:21:18AM -0400, Gabor Grothendieck wrote:
> I currently put my NEWS file in ./inst as the build procedure will
Yes, but for what I suggested we need standardized location as well as
format to permit automatic extraction, formatting, processing, ... off-line.
For just one
This may be related to the problems with "greedy" search for inherited
methods discussed previously on this list (or may not, it's a bit
different).
In any case, the likely fix will be a substantial cleaning up of generic
functions hoped for in the next release.
Meanwhile, "Keep it simple" is
Is this necessary to avoid LC_CTYPE="C"? If so, I stopped that at C level
yesterday (it was already disallowed when starting R).
On Tue, 23 May 2006, Ei-ji Nakama wrote:
> It clash similarly in the Japanese locale.
>
> localeCP!= GetACP() .
> It dies from msvcrt (mb*) the case where NULL is spe
It clash similarly in the Japanese locale.
localeCP!= GetACP() .
It dies from msvcrt (mb*) the case where NULL is specified.
diff -ruN R-2.3.0.orig/src/gnuwin32/graphapp/buttons.c
R-2.3.0/src/gnuwin32/graphapp/buttons.c
--- R-2.3.0.orig/src/gnuwin32/graphapp/buttons.cMon Apr 10 07:20:00 2
On Tue, 23 May 2006, Prof Brian Ripley wrote:
> On Mon, 22 May 2006, Kasper Daniel Hansen wrote:
>
>> I have a few simple questions about the usage of PROTECT, more
>> specifically how careful one needs to be. Simple yes/no answers are
>> fine.
>
> (Except that in the last case they would be misle
> McGehee, Robert writes:
> I was recently browsing through CRAN's Finance task view to remind
> myself of the publicly available packages relevant to my work. As the
> reference manuals are all online, I am able to flip through the
> available functions to get an idea of the package's scope b
> Dirk Eddelbuettel writes:
> On 22 May 2006 at 23:24, Gabor Grothendieck wrote:
> | This would certainly be nice.
> |
> | Note that the BioConductor package vignettes are online:
> |http://www.bioconductor.org/docs/vignettes.html
> | but there is nothing comparable for CRAN.
> |
> | In
On Mon, 22 May 2006, Kasper Daniel Hansen wrote:
> I have a few simple questions about the usage of PROTECT, more
> specifically how careful one needs to be. Simple yes/no answers are
> fine.
(Except that in the last case they would be misleading.)
> Most of the uses I have seen do protection wh
16 matches
Mail list logo
