Re: [Rd] ** operator

[Karl Ove Hufthammer]

Peter Dalgaard:

> Not really, just transcribed during the lexical analysis phase:
> 
> case '*':
> if (nextchar('*'))
> c='^';
> yytext[0] = c;
> yytext[1] = '\0';
> yylval = install(yytext);
> return c;
> 
> (There's no "->" function either...)

You can also use expression() to see what various expressions are parsed as:

  > expression(2**5)
  expression(2^5)

  > expression(3->x)
  expression(x <- 3)

-- 
Karl Ove Hufthammer

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Configure errors say to report here... (PR#11470)

[adik]

Hi,

I'm attempting to compile R 2.7.0 on my G5, which is running OSX
10.5.2. Yes, I know there is a precompiled binary, but my experience has
shown that if I hand-compile ATLAS on my machine and then link R against it
when compiling, R runs faster, hence me compiling it myself.

Anyway, I have this set of errors:

checking X11/Intrinsic.h usability... no
checking X11/Intrinsic.h presence... yes
configure: WARNING: X11/Intrinsic.h: present but cannot be compiled
configure: WARNING: X11/Intrinsic.h: check for missing prerequisite headers?
configure: WARNING: X11/Intrinsic.h: see the Autoconf documentation
configure: WARNING: X11/Intrinsic.h: section "Present But Cannot Be 
Compiled"
configure: WARNING: X11/Intrinsic.h: proceeding with the preprocessor's result 
configure: WARNING: X11/Intrinsic.h: in the future, the compiler will take 
precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
...
checking X11/Xmu/Atoms.h usability... no
checking X11/Xmu/Atoms.h presence... yes
configure: WARNING: X11/Xmu/Atoms.h: present but cannot be compiled
configure: WARNING: X11/Xmu/Atoms.h: check for missing prerequisite headers?
configure: WARNING: X11/Xmu/Atoms.h: see the Autoconf documentation
configure: WARNING: X11/Xmu/Atoms.h: section "Present But Cannot Be 
Compiled"
configure: WARNING: X11/Xmu/Atoms.h: proceeding with the preprocessor's result
configure: WARNING: X11/Xmu/Atoms.h: in the future, the compiler will take 
precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
...
checking tk.h usability... no
checking tk.h presence... yes
configure: WARNING: tk.h: present but cannot be compiled
configure: WARNING: tk.h: check for missing prerequisite headers?
configure: WARNING: tk.h: see the Autoconf documentation
configure: WARNING: tk.h: section "Present But Cannot Be Compiled"
configure: WARNING: tk.h: proceeding with the preprocessor's result
configure: WARNING: tk.h: in the future, the compiler will take precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##

...the command line item I pass to configure is this:

feta:R-2.7.0> ./configure --prefix=/usr/local --with-x --without-R-framework 
--without-aqua --with-blas="/usr/local/lib/libptf77blas.a 
/usr/local/lib/libatlas.a" --with-lapack="/usr/local/lib/liblapack.a 
/usr/local/lib/libptf77blas.a /usr/local/lib/libatlas.a" CFLAGS="-maltivec 
-mabi=altivec -mtune=970 -faltivec -O3" CXXFLAGS="-maltivec -mabi=altivec 
-mtune=970 -faltivec -O3"

...the rest of configure completes fine, though when I try to build R, I
make eventually ends up failing in this manner:

gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/sw/include
-I/usr/
local/include -DHAVE_CONFIG_H   -fPIC  -maltivec -mabi=altivec -mtune=970
-falti
vec -O3 -c cpoly.c -o cpoly.o
cpoly.c: In function 'fxshft':
cpoly.c:299: error: expected identifier or '(' before 'unsigned'
cpoly.c:310: error: 'test' undeclared (first use in this function)
cpoly.c:310: error: (Each undeclared identifier is reported only once
cpoly.c:310: error: for each function it appears in.)
cpoly.c:315: error: expected expression before '__attribute__'
cpoly.c:326: error: expected expression before '__attribute__'
cpoly.c:327: error: expected expression before '__attribute__'
cpoly.c:334: error: expected expression before '__attribute__'
cpoly.c:370: error: expected expression before '__attribute__'
cpoly.c: In function 'vrshft':
cpoly.c:394: error: two or more data types in declaration specifiers
cpoly.c:394: error: expected identifier or '(' before ',' token
cpoly.c:399: error: 'b' undeclared (first use in this function)
cpoly.c:439: error: expected expression before '__attribute__'
cpoly.c:440: error: expected expression before '__attribute__'
cpoly.c:459: error: expected expression before '__attribute__'
cpoly.c:460: error: expected expression before '__attribute__'
cpoly.c:461: error: expected expression before '__attribute__'
cpoly.c:462: error: expected expression before '__attribute__'
cpoly.c: At top level:
cpoly.c:476: error: expected ';', ',' or ')' before 'unsigned'
cpoly.c:498: error: two or more data types in declaration specifiers
cpoly.c:498: error: conflicting types for 'nexth'
cpoly.c:81: error: previous declaration of 'nexth' was here
cpoly.c: In function 'nexth':
cpoly.c:498: error: parameter name omitted
cpoly.c:506: error: expected expression before '__attribute__'
make[3]: *** [cpoly.o] Error 1
make[2]: *** [R] Error 2
make[1]: *** [R] Error 1
make: *** [R] Error 1

...the one reference to a problem like this I could find v

Re: [Rd] Configure errors say to report here... (PR#11470)

[Prof Brian Ripley]

What version are your Xcode tools?  What X11 do you have installed (I see 
/sw/include in your path, and that is not normally needed)?


Although configure says to report here, it is reporting a bug in your OS, 
not in R.  There will be more information in your config.log, (and perhaps 
some of it useful).


Where did all those gcc flags come from?  I don't see them in 'R 
Installation and Administration'. Perhaps leaving them off might solve the 
problem.


On Fri, 16 May 2008, [EMAIL PROTECTED] wrote:


Hi,

I'm attempting to compile R 2.7.0 on my G5, which is running OSX
10.5.2. Yes, I know there is a precompiled binary, but my experience has
shown that if I hand-compile ATLAS on my machine and then link R against it
when compiling, R runs faster, hence me compiling it myself.

Anyway, I have this set of errors:

checking X11/Intrinsic.h usability... no
checking X11/Intrinsic.h presence... yes
configure: WARNING: X11/Intrinsic.h: present but cannot be compiled
configure: WARNING: X11/Intrinsic.h: check for missing prerequisite headers?
configure: WARNING: X11/Intrinsic.h: see the Autoconf documentation
configure: WARNING: X11/Intrinsic.h: section "Present But Cannot Be 
Compiled"
configure: WARNING: X11/Intrinsic.h: proceeding with the preprocessor's result
configure: WARNING: X11/Intrinsic.h: in the future, the compiler will take 
precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
...
checking X11/Xmu/Atoms.h usability... no
checking X11/Xmu/Atoms.h presence... yes
configure: WARNING: X11/Xmu/Atoms.h: present but cannot be compiled
configure: WARNING: X11/Xmu/Atoms.h: check for missing prerequisite headers?
configure: WARNING: X11/Xmu/Atoms.h: see the Autoconf documentation
configure: WARNING: X11/Xmu/Atoms.h: section "Present But Cannot Be 
Compiled"
configure: WARNING: X11/Xmu/Atoms.h: proceeding with the preprocessor's result
configure: WARNING: X11/Xmu/Atoms.h: in the future, the compiler will take 
precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
...
checking tk.h usability... no
checking tk.h presence... yes
configure: WARNING: tk.h: present but cannot be compiled
configure: WARNING: tk.h: check for missing prerequisite headers?
configure: WARNING: tk.h: see the Autoconf documentation
configure: WARNING: tk.h: section "Present But Cannot Be Compiled"
configure: WARNING: tk.h: proceeding with the preprocessor's result
configure: WARNING: tk.h: in the future, the compiler will take precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##

...the command line item I pass to configure is this:

feta:R-2.7.0> ./configure --prefix=/usr/local --with-x --without-R-framework --without-aqua 
--with-blas="/usr/local/lib/libptf77blas.a /usr/local/lib/libatlas.a" 
--with-lapack="/usr/local/lib/liblapack.a /usr/local/lib/libptf77blas.a /usr/local/lib/libatlas.a" 
CFLAGS="-maltivec -mabi=altivec -mtune=970 -faltivec -O3" CXXFLAGS="-maltivec -mabi=altivec -mtune=970 
-faltivec -O3"

...the rest of configure completes fine, though when I try to build R, I
make eventually ends up failing in this manner:

gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/sw/include
-I/usr/
local/include -DHAVE_CONFIG_H   -fPIC  -maltivec -mabi=altivec -mtune=970
-falti
vec -O3 -c cpoly.c -o cpoly.o
cpoly.c: In function 'fxshft':
cpoly.c:299: error: expected identifier or '(' before 'unsigned'
cpoly.c:310: error: 'test' undeclared (first use in this function)
cpoly.c:310: error: (Each undeclared identifier is reported only once
cpoly.c:310: error: for each function it appears in.)
cpoly.c:315: error: expected expression before '__attribute__'
cpoly.c:326: error: expected expression before '__attribute__'
cpoly.c:327: error: expected expression before '__attribute__'
cpoly.c:334: error: expected expression before '__attribute__'
cpoly.c:370: error: expected expression before '__attribute__'
cpoly.c: In function 'vrshft':
cpoly.c:394: error: two or more data types in declaration specifiers
cpoly.c:394: error: expected identifier or '(' before ',' token
cpoly.c:399: error: 'b' undeclared (first use in this function)
cpoly.c:439: error: expected expression before '__attribute__'
cpoly.c:440: error: expected expression before '__attribute__'
cpoly.c:459: error: expected expression before '__attribute__'
cpoly.c:460: error: expected expression before '__attribute__'
cpoly.c:461: error: expected expression before '__attribute__'
cpoly.c:462: error: expected expression before '__attribute__'
cpoly.c: At top level:
cpoly.c:476: error: expected ';

[Rd] HoltWinters fitted level parameter not bounded between 0 and 1 (PR#11469)

[john . bodley]

Full_Name: John Bodley
Version: 2.5.1 (2007-06-27)
OS: Windows XP
Submission from: (NULL) (12.144.182.66)


I was fitting a number of time series in R using the stats::HoltWinters method
to define a single exponential smoothing model, i.e., beta = gamma = 0. 

I came across an example where the fitted value of alpha was not defined in the
[0, 1] interval which seems to violate the lower and upper bound constraints
used for the optim method. On my computer the following code returns a value of
48.87989.

R code:

x <- c(
0,
0.000843170320404722,
0,
0,
0,
0.0103773584905660,
0.00832466181061394,
0.0038560411311054,
0,
0,
0.00484966052376334,
0,
0,
0,
0.00274348422496571,
0,
0,
0,
0,
0,
0.0207064555420219,
0.0334975369458128,
0.0334975369458128,
0.00338983050847458,
0.00483675937122128,
0,
0,
0.00224971878515186,
0,
0,
0,
0.00135685210312076,
0,
0,
0,
0.0035377358490566,
0.0035377358490566,
0.00501002004008016,
0.0107632093933464,
0,
0,
0.0143329658213892,
0.0330459770114943,
0,
0,
0,
0,
0.0109890109890110,
0,
0.00118623962040332,
0.007380073800738,
0.00695410292072323,
0.0104895104895105,
0.00278551532033426,
0.00278551532033426
);

# Single exponential smoothing
m <- stats::HoltWinters(x, beta = 0, gamma = 0);
m$alpha

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] interrupting native code

[Kjell Konis]

The problem is that my package uses an external pointer to keep track  
of a structure created by the lp_solve library. If I use  
R_CheckUserInterrupt in the lp_solve abort function it leaves the  
structure in a messed-up state after an interrupt occurs. I am not  
even able to free the memory allocated in the structure. I need to be  
able to tell the lp_solve functions to interrupt themselves if I am  
going to support interrupts at all.


I took a longer look at errors.c and it seems my solution should work  
as long as neither HAVE_AQUA nor Win32 are defined. Under the  
circumstances, I think that's the best I can do.


Any suggestions for a UI independent way to check for interrupts would  
be appreciated.


Thanks,
Kjell

On 15 mai 08, at 16:41, Prof Brian Ripley wrote:


How is R_interrupts_pending going to be set?

It is set in the interrupt handler for SIGINT, but that is not the  
only way to indicate an interrupt, and it is not necessarily  
available to users of GUIs and embedded R.


Without servicing the GUIs all interaction will be dead, including  
sending an interrrupt from menus/buttons/keyboard.  See the comment  
in the code for R_CheckUserInterrupt.


On Thu, 15 May 2008, Kjell Konis wrote:


Hello,

I have some native code that I would like to allow users to  
interrupt. However, I would like to do it more gracefully than with  
R_CheckUserInterrupt(). The solution I came up with is to call the  
following abort function periodically - if it returns 1 then I  
clean up and return.


int __WINAPI RlpSolveAbortFunction(lprec *lp, void *userhandle)
{
if(R_interrupts_pending)
 return(1);

return(0);
}

This seems to work fine on Mac (sans Aqua) and Linux. Is this going  
to be portable?  Also, is there anything else I need to do?  For  
instance set R_interrupts_pending to 0 after I respond to it?


Thanks.
Kjell

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HoltWinters fitted level parameter not bounded between 0 and 1 (PR#11469)

[Prof Brian Ripley]

It doesn't do it on my system (I get a value of about 0.688 in R 2.7.0 
patched on Linux), and 2.5.1 is not current.  Does a better starting value 
help?


However, HoltWinters is using optim() in a case it is not designed for 
(one-dimensional optimization): see the note on its help page.  I think 
this could easily be changed, but as HoltWinters is contributed code 
I am Cc:ing the author for comment.


On Fri, 16 May 2008, [EMAIL PROTECTED] wrote:


Full_Name: John Bodley
Version: 2.5.1 (2007-06-27)
OS: Windows XP
Submission from: (NULL) (12.144.182.66)


I was fitting a number of time series in R using the stats::HoltWinters method
to define a single exponential smoothing model, i.e., beta = gamma = 0.

I came across an example where the fitted value of alpha was not defined in the
[0, 1] interval which seems to violate the lower and upper bound constraints
used for the optim method. On my computer the following code returns a value of
48.87989.

R code:

x <- c(
0,
0.000843170320404722,
0,
0,
0,
0.0103773584905660,
0.00832466181061394,
0.0038560411311054,
0,
0,
0.00484966052376334,
0,
0,
0,
0.00274348422496571,
0,
0,
0,
0,
0,
0.0207064555420219,
0.0334975369458128,
0.0334975369458128,
0.00338983050847458,
0.00483675937122128,
0,
0,
0.00224971878515186,
0,
0,
0,
0.00135685210312076,
0,
0,
0,
0.0035377358490566,
0.0035377358490566,
0.00501002004008016,
0.0107632093933464,
0,
0,
0.0143329658213892,
0.0330459770114943,
0,
0,
0,
0,
0.0109890109890110,
0,
0.00118623962040332,
0.007380073800738,
0.00695410292072323,
0.0104895104895105,
0.00278551532033426,
0.00278551532033426
);

# Single exponential smoothing
m <- stats::HoltWinters(x, beta = 0, gamma = 0);
m$alpha

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] interrupting native code

[Prof Brian Ripley]

On Fri, 16 May 2008, Kjell Konis wrote:

The problem is that my package uses an external pointer to keep track of a 
structure created by the lp_solve library. If I use R_CheckUserInterrupt in 
the lp_solve abort function it leaves the structure in a messed-up state 
after an interrupt occurs. I am not even able to free the memory allocated in 
the structure. I need to be able to tell the lp_solve functions to interrupt 
themselves if I am going to support interrupts at all.


I took a longer look at errors.c and it seems my solution should work as long 
as neither HAVE_AQUA nor Win32 are defined. Under the circumstances, I think 
that's the best I can do.


Any suggestions for a UI independent way to check for interrupts would be 
appreciated.


Why not use the same code as R_CheckUserInterrupt but instead of calling 
onintr, call your own interrupt routine?




Thanks,
Kjell

On 15 mai 08, at 16:41, Prof Brian Ripley wrote:


How is R_interrupts_pending going to be set?

It is set in the interrupt handler for SIGINT, but that is not the only way 
to indicate an interrupt, and it is not necessarily available to users of 
GUIs and embedded R.


Without servicing the GUIs all interaction will be dead, including sending 
an interrrupt from menus/buttons/keyboard.  See the comment in the code for 
R_CheckUserInterrupt.


On Thu, 15 May 2008, Kjell Konis wrote:


Hello,

I have some native code that I would like to allow users to interrupt. 
However, I would like to do it more gracefully than with 
R_CheckUserInterrupt(). The solution I came up with is to call the 
following abort function periodically - if it returns 1 then I clean up 
and return.


int __WINAPI RlpSolveAbortFunction(lprec *lp, void *userhandle)
{
if(R_interrupts_pending)
return(1);

return(0);
}

This seems to work fine on Mac (sans Aqua) and Linux. Is this going to be 
portable?  Also, is there anything else I need to do?  For instance set 
R_interrupts_pending to 0 after I respond to it?


Thanks.
Kjell

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HoltWinters fitted level parameter not bounded between 0 (PR#11472)

[ripley]

It doesn't do it on my system (I get a value of about 0.688 in R 2.7.0 
patched on Linux), and 2.5.1 is not current.  Does a better starting value 
help?

However, HoltWinters is using optim() in a case it is not designed for 
(one-dimensional optimization): see the note on its help page.  I think 
this could easily be changed, but as HoltWinters is contributed code 
I am Cc:ing the author for comment.

On Fri, 16 May 2008, [EMAIL PROTECTED] wrote:

> Full_Name: John Bodley
> Version: 2.5.1 (2007-06-27)
> OS: Windows XP
> Submission from: (NULL) (12.144.182.66)
>
>
> I was fitting a number of time series in R using the stats::HoltWinters method
> to define a single exponential smoothing model, i.e., beta = gamma = 0.
>
> I came across an example where the fitted value of alpha was not defined in 
> the
> [0, 1] interval which seems to violate the lower and upper bound constraints
> used for the optim method. On my computer the following code returns a value 
> of
> 48.87989.
>
> R code:
>
> x <- c(
> 0,
> 0.000843170320404722,
> 0,
> 0,
> 0,
> 0.0103773584905660,
> 0.00832466181061394,
> 0.0038560411311054,
> 0,
> 0,
> 0.00484966052376334,
> 0,
> 0,
> 0,
> 0.00274348422496571,
> 0,
> 0,
> 0,
> 0,
> 0,
> 0.0207064555420219,
> 0.0334975369458128,
> 0.0334975369458128,
> 0.00338983050847458,
> 0.00483675937122128,
> 0,
> 0,
> 0.00224971878515186,
> 0,
> 0,
> 0,
> 0.00135685210312076,
> 0,
> 0,
> 0,
> 0.0035377358490566,
> 0.0035377358490566,
> 0.00501002004008016,
> 0.0107632093933464,
> 0,
> 0,
> 0.0143329658213892,
> 0.0330459770114943,
> 0,
> 0,
> 0,
> 0,
> 0.0109890109890110,
> 0,
> 0.00118623962040332,
> 0.007380073800738,
> 0.00695410292072323,
> 0.0104895104895105,
> 0.00278551532033426,
> 0.00278551532033426
> );
>
> # Single exponential smoothing
> m <- stats::HoltWinters(x, beta = 0, gamma = 0);
> m$alpha
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] interrupting native code

[Kjell Konis]

You mean something like this (I return 1 instead of calling onintr())?  
Will HAVE_AQUA and Win32 be appropriately defined when building my  
package (I can't see how to check with R CMD config)?


int My_CheckUserInterrupt(void)
{
R_CheckStack();

#if  ( defined(HAVE_AQUA) )

  /* R_ProcessEvents() from unix/aqua.c*/

  if (ptr_R_ProcessEvents)
ptr_R_ProcessEvents();
  if (R_interrupts_pending)
return(1);

#elseif ( defined(Win32) )

  /* R_ProcessEvents() from gnuwin32/system.c */

while (peekevent()) doevent();
if (UserBreak) {
UserBreak = FALSE;
return(1);
}
R_CallBackHook();
if(R_tcldo) R_tcldo();

#else

R_PolledEvents();
if (R_interrupts_pending)
return(1);

#endif

  return(0);
}




On 16 mai 08, at 12:43, Prof Brian Ripley wrote:


On Fri, 16 May 2008, Kjell Konis wrote:

The problem is that my package uses an external pointer to keep  
track of a structure created by the lp_solve library. If I use  
R_CheckUserInterrupt in the lp_solve abort function it leaves the  
structure in a messed-up state after an interrupt occurs. I am not  
even able to free the memory allocated in the structure. I need to  
be able to tell the lp_solve functions to interrupt themselves if I  
am going to support interrupts at all.


I took a longer look at errors.c and it seems my solution should  
work as long as neither HAVE_AQUA nor Win32 are defined. Under the  
circumstances, I think that's the best I can do.


Any suggestions for a UI independent way to check for interrupts  
would be appreciated.


Why not use the same code as R_CheckUserInterrupt but instead of  
calling onintr, call your own interrupt routine?




Thanks,
Kjell

On 15 mai 08, at 16:41, Prof Brian Ripley wrote:


How is R_interrupts_pending going to be set?
It is set in the interrupt handler for SIGINT, but that is not the  
only way to indicate an interrupt, and it is not necessarily  
available to users of GUIs and embedded R.
Without servicing the GUIs all interaction will be dead, including  
sending an interrrupt from menus/buttons/keyboard.  See the  
comment in the code for R_CheckUserInterrupt.

On Thu, 15 May 2008, Kjell Konis wrote:

Hello,
I have some native code that I would like to allow users to  
interrupt. However, I would like to do it more gracefully than  
with R_CheckUserInterrupt(). The solution I came up with is to  
call the following abort function periodically - if it returns 1  
then I clean up and return.

int __WINAPI RlpSolveAbortFunction(lprec *lp, void *userhandle)
{
if(R_interrupts_pending)
return(1);
return(0);
}
This seems to work fine on Mac (sans Aqua) and Linux. Is this  
going to be portable?  Also, is there anything else I need to  
do?  For instance set R_interrupts_pending to 0 after I respond  
to it?

Thanks.
Kjell
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HoltWinters fitted level parameter not bounded between 0 and 1 (PR#11469)

[David Meyer]

I get John's value (48.8789) in 2.7.0 and R-devel (both on Ubuntu). 
Really seems to be a numeric issue:


> HoltWinters(x, beta = 0, gamma = 0)$alpha
   alpha
48.87989

> HoltWinters(x * 1.01, beta = 0, gamma = 0)$alpha
alpha
0.6881547

> HoltWinters(x * 1.001, beta = 0, gamma = 0)$alpha
   alpha
48.87989

Providing starting values seems to help, but not always:

> HoltWinters(x, beta = 0, gamma = 0, l.start = 0.1)$alpha
   alpha
48.88999
> HoltWinters(x, beta = 0, gamma = 0, l.start = 0.0001)$alpha
alpha
0.6880582

Yes, it's easy to use optimize() instead of optim() in the univariate 
cases, will do.


David.

Prof Brian Ripley wrote:
It doesn't do it on my system (I get a value of about 0.688 in R 2.7.0 
patched on Linux), and 2.5.1 is not current.  Does a better starting 
value help?


However, HoltWinters is using optim() in a case it is not designed for 
(one-dimensional optimization): see the note on its help page.  I think 
this could easily be changed, but as HoltWinters is contributed code I 
am Cc:ing the author for comment.


On Fri, 16 May 2008, [EMAIL PROTECTED] wrote:


Full_Name: John Bodley
Version: 2.5.1 (2007-06-27)
OS: Windows XP
Submission from: (NULL) (12.144.182.66)


I was fitting a number of time series in R using the 
stats::HoltWinters method

to define a single exponential smoothing model, i.e., beta = gamma = 0.

I came across an example where the fitted value of alpha was not 
defined in the
[0, 1] interval which seems to violate the lower and upper bound 
constraints
used for the optim method. On my computer the following code returns a 
value of

48.87989.

R code:

x <- c(
0,
0.000843170320404722,
0,
0,
0,
0.0103773584905660,
0.00832466181061394,
0.0038560411311054,
0,
0,
0.00484966052376334,
0,
0,
0,
0.00274348422496571,
0,
0,
0,
0,
0,
0.0207064555420219,
0.0334975369458128,
0.0334975369458128,
0.00338983050847458,
0.00483675937122128,
0,
0,
0.00224971878515186,
0,
0,
0,
0.00135685210312076,
0,
0,
0,
0.0035377358490566,
0.0035377358490566,
0.00501002004008016,
0.0107632093933464,
0,
0,
0.0143329658213892,
0.0330459770114943,
0,
0,
0,
0,
0.0109890109890110,
0,
0.00118623962040332,
0.007380073800738,
0.00695410292072323,
0.0104895104895105,
0.00278551532033426,
0.00278551532033426
);

# Single exponential smoothing
m <- stats::HoltWinters(x, beta = 0, gamma = 0);
m$alpha

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel





--
Dr. David Meyer
Department of Information Systems and Operations

Vienna University of Economics and Business Administration
Augasse 2-6, A-1090 Wien, Austria, Europe
Tel: +43-1-313 36 4393
Fax: +43-1-313 36 90 4393
HP:  http://wi.wu-wien.ac.at/~meyer/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HoltWinters fitted level parameter not bounded between 0 (PR#11473)

[david . meyer]

I get John's value (48.8789) in 2.7.0 and R-devel (both on Ubuntu). 
Really seems to be a numeric issue:

 > HoltWinters(x, beta = 0, gamma = 0)$alpha
alpha
48.87989

 > HoltWinters(x * 1.01, beta = 0, gamma = 0)$alpha
 alpha
0.6881547

 > HoltWinters(x * 1.001, beta = 0, gamma = 0)$alpha
alpha
48.87989

Providing starting values seems to help, but not always:

 > HoltWinters(x, beta = 0, gamma = 0, l.start = 0.1)$alpha
alpha
48.88999
 > HoltWinters(x, beta = 0, gamma = 0, l.start = 0.0001)$alpha
 alpha
0.6880582

Yes, it's easy to use optimize() instead of optim() in the univariate 
cases, will do.

David.

Prof Brian Ripley wrote:
> It doesn't do it on my system (I get a value of about 0.688 in R 2.7.0 
> patched on Linux), and 2.5.1 is not current.  Does a better starting 
> value help?
> 
> However, HoltWinters is using optim() in a case it is not designed for 
> (one-dimensional optimization): see the note on its help page.  I think 
> this could easily be changed, but as HoltWinters is contributed code I 
> am Cc:ing the author for comment.
> 
> On Fri, 16 May 2008, [EMAIL PROTECTED] wrote:
> 
>> Full_Name: John Bodley
>> Version: 2.5.1 (2007-06-27)
>> OS: Windows XP
>> Submission from: (NULL) (12.144.182.66)
>>
>>
>> I was fitting a number of time series in R using the 
>> stats::HoltWinters method
>> to define a single exponential smoothing model, i.e., beta = gamma = 0.
>>
>> I came across an example where the fitted value of alpha was not 
>> defined in the
>> [0, 1] interval which seems to violate the lower and upper bound 
>> constraints
>> used for the optim method. On my computer the following code returns a 
>> value of
>> 48.87989.
>>
>> R code:
>>
>> x <- c(
>> 0,
>> 0.000843170320404722,
>> 0,
>> 0,
>> 0,
>> 0.0103773584905660,
>> 0.00832466181061394,
>> 0.0038560411311054,
>> 0,
>> 0,
>> 0.00484966052376334,
>> 0,
>> 0,
>> 0,
>> 0.00274348422496571,
>> 0,
>> 0,
>> 0,
>> 0,
>> 0,
>> 0.0207064555420219,
>> 0.0334975369458128,
>> 0.0334975369458128,
>> 0.00338983050847458,
>> 0.00483675937122128,
>> 0,
>> 0,
>> 0.00224971878515186,
>> 0,
>> 0,
>> 0,
>> 0.00135685210312076,
>> 0,
>> 0,
>> 0,
>> 0.0035377358490566,
>> 0.0035377358490566,
>> 0.00501002004008016,
>> 0.0107632093933464,
>> 0,
>> 0,
>> 0.0143329658213892,
>> 0.0330459770114943,
>> 0,
>> 0,
>> 0,
>> 0,
>> 0.0109890109890110,
>> 0,
>> 0.00118623962040332,
>> 0.007380073800738,
>> 0.00695410292072323,
>> 0.0104895104895105,
>> 0.00278551532033426,
>> 0.00278551532033426
>> );
>>
>> # Single exponential smoothing
>> m <- stats::HoltWinters(x, beta = 0, gamma = 0);
>> m$alpha
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> 

-- 
Dr. David Meyer
Department of Information Systems and Operations

Vienna University of Economics and Business Administration
Augasse 2-6, A-1090 Wien, Austria, Europe
Tel: +43-1-313 36 4393
Fax: +43-1-313 36 90 4393
HP:  http://wi.wu-wien.ac.at/~meyer/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] interrupting native code

[Prof Brian Ripley]

On Fri, 16 May 2008, Kjell Konis wrote:

You mean something like this (I return 1 instead of calling onintr())? Will 
HAVE_AQUA and Win32 be appropriately defined when building my package (I 
can't see how to check with R CMD config)?


HAVE_AQUA is in Rconfig.h, and WIN32 (not Win32) is defined for a package 
on Windows.


I think R_ProcessEvents() is available to you -- certainly on Windows.



int My_CheckUserInterrupt(void)
{
  R_CheckStack();

#if  ( defined(HAVE_AQUA) )

/* R_ProcessEvents() from unix/aqua.c*/

if (ptr_R_ProcessEvents)
  ptr_R_ProcessEvents();
if (R_interrupts_pending)
  return(1);

#elseif ( defined(Win32) )

/* R_ProcessEvents() from gnuwin32/system.c */

  while (peekevent()) doevent();
  if (UserBreak) {
UserBreak = FALSE;
return(1);
  }
  R_CallBackHook();
  if(R_tcldo) R_tcldo();

#else

  R_PolledEvents();
  if (R_interrupts_pending)
return(1);

#endif

return(0);
}




On 16 mai 08, at 12:43, Prof Brian Ripley wrote:


On Fri, 16 May 2008, Kjell Konis wrote:

The problem is that my package uses an external pointer to keep track of a 
structure created by the lp_solve library. If I use R_CheckUserInterrupt 
in the lp_solve abort function it leaves the structure in a messed-up 
state after an interrupt occurs. I am not even able to free the memory 
allocated in the structure. I need to be able to tell the lp_solve 
functions to interrupt themselves if I am going to support interrupts at 
all.


I took a longer look at errors.c and it seems my solution should work as 
long as neither HAVE_AQUA nor Win32 are defined. Under the circumstances, 
I think that's the best I can do.


Any suggestions for a UI independent way to check for interrupts would be 
appreciated.


Why not use the same code as R_CheckUserInterrupt but instead of calling 
onintr, call your own interrupt routine?




Thanks,
Kjell

On 15 mai 08, at 16:41, Prof Brian Ripley wrote:


How is R_interrupts_pending going to be set?
It is set in the interrupt handler for SIGINT, but that is not the only 
way to indicate an interrupt, and it is not necessarily available to 
users of GUIs and embedded R.
Without servicing the GUIs all interaction will be dead, including 
sending an interrrupt from menus/buttons/keyboard.  See the comment in 
the code for R_CheckUserInterrupt.

On Thu, 15 May 2008, Kjell Konis wrote:

Hello,
I have some native code that I would like to allow users to interrupt. 
However, I would like to do it more gracefully than with 
R_CheckUserInterrupt(). The solution I came up with is to call the 
following abort function periodically - if it returns 1 then I clean up 
and return.

int __WINAPI RlpSolveAbortFunction(lprec *lp, void *userhandle)
{
if(R_interrupts_pending)
return(1);
return(0);
}
This seems to work fine on Mac (sans Aqua) and Linux. Is this going to 
be portable?  Also, is there anything else I need to do?  For instance 
set R_interrupts_pending to 0 after I respond to it?

Thanks.
Kjell
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] interrupting native code

[Luke Tierney]

I'm not sure you can make this work as some of the things needed
either are or should be private to the core implementation and not
available to package code.  In any case I would not recommend this
approach for two reasons.  First, details of what happens in interrupt
checking are subject to change and your code would miss those changes
unless you track them carefully.  More importantly, several things
here could generate an error that results in a longjmp and leaves your
code in an unstable state.

What is needed for this is a mechanism for detecting an interrupt but
not doing the longjmp, just returning a flag that a longjmp is needed
and enough information to allow it to be made after cleanup code has
been run.  This has been on my to do list for a while but getting the
semantics right is tricky and so it hasn't happened yet.  Hopefully it
will be in 2.8.0.  In the interim you can cobble something together
using R_ToplevelExec, interpreting all FALSE return values as user
interrupts.

Another option, also under consideration but not available yet, is a C
mechanism for registering cleanup operations if a longjmp occurs.  A
quick and dirty version of that could be provided fairly easily but a
better version, which would be preferable in the long run, requires a
rewrite of the code that implements jumps and cleanup/on.exit actions.
This may take a bit longer to implement.

Best,

luke

On Fri, 16 May 2008, Kjell Konis wrote:

You mean something like this (I return 1 instead of calling onintr())? Will 
HAVE_AQUA and Win32 be appropriately defined when building my package (I 
can't see how to check with R CMD config)?


int My_CheckUserInterrupt(void)
{
  R_CheckStack();

#if  ( defined(HAVE_AQUA) )

/* R_ProcessEvents() from unix/aqua.c*/

if (ptr_R_ProcessEvents)
  ptr_R_ProcessEvents();
if (R_interrupts_pending)
  return(1);

#elseif ( defined(Win32) )

/* R_ProcessEvents() from gnuwin32/system.c */

  while (peekevent()) doevent();
  if (UserBreak) {
UserBreak = FALSE;
return(1);
  }
  R_CallBackHook();
  if(R_tcldo) R_tcldo();

#else

  R_PolledEvents();
  if (R_interrupts_pending)
return(1);

#endif

return(0);
}




On 16 mai 08, at 12:43, Prof Brian Ripley wrote:


On Fri, 16 May 2008, Kjell Konis wrote:

The problem is that my package uses an external pointer to keep track of a 
structure created by the lp_solve library. If I use R_CheckUserInterrupt 
in the lp_solve abort function it leaves the structure in a messed-up 
state after an interrupt occurs. I am not even able to free the memory 
allocated in the structure. I need to be able to tell the lp_solve 
functions to interrupt themselves if I am going to support interrupts at 
all.


I took a longer look at errors.c and it seems my solution should work as 
long as neither HAVE_AQUA nor Win32 are defined. Under the circumstances, 
I think that's the best I can do.


Any suggestions for a UI independent way to check for interrupts would be 
appreciated.


Why not use the same code as R_CheckUserInterrupt but instead of calling 
onintr, call your own interrupt routine?




Thanks,
Kjell

On 15 mai 08, at 16:41, Prof Brian Ripley wrote:


How is R_interrupts_pending going to be set?
It is set in the interrupt handler for SIGINT, but that is not the only 
way to indicate an interrupt, and it is not necessarily available to 
users of GUIs and embedded R.
Without servicing the GUIs all interaction will be dead, including 
sending an interrrupt from menus/buttons/keyboard.  See the comment in 
the code for R_CheckUserInterrupt.

On Thu, 15 May 2008, Kjell Konis wrote:

Hello,
I have some native code that I would like to allow users to interrupt. 
However, I would like to do it more gracefully than with 
R_CheckUserInterrupt(). The solution I came up with is to call the 
following abort function periodically - if it returns 1 then I clean up 
and return.

int __WINAPI RlpSolveAbortFunction(lprec *lp, void *userhandle)
{
if(R_interrupts_pending)
return(1);
return(0);
}
This seems to work fine on Mac (sans Aqua) and Linux. Is this going to 
be portable?  Also, is there anything else I need to do?  For instance 
set R_interrupts_pending to 0 after I respond to it?

Thanks.
Kjell
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks R

[Rd] Sweave.sty problems under WinXP (English locale) with default settings

[Peter Ruckdeschel]

Hi R-devels,

I encounter the following problem when I want to build a vignette
in the package building process under Windows

platform   i386-pc-mingw32
arch   i386   
os mingw32
system i386, mingw32  
status
major  2  
minor  7.0
year   2008   
month  04 
day22 
svn rev45424  
language   R  
version.string R version 2.7.0 (2008-04-22)


TeX-Distribution: MikTeX 2.7

My R home directory is the default one:

C:\Program Files\R\R-2.7.0,

so R.home() from package tools makes out of it

   "C:\\PROGRA~1\\R\\R-27~1.0"

which does not contain spaces, but instead the special
character   ~  .

So function texi2dvi() from package tools makes texi2dvi
include the directive

  \usepackage{C:\PROGRA~1\R\R-27~1.0\share\texmf\Sweave}

into the corresponding .tex file for the vignette, and, consequently,
MikTeX throws an error (due to the ~'s).

According to

  http://developer.r-project.org/blosxom.cgi/R-devel

this is due to a change on  Apr 15.

If I am right, the use of short filenames (without spaces)
as to be found in %R_HOME% for
MikTeX (and tetex) would no longer have been necessary:

http://wiki.lyx.org/LaTeX/FilesWithSpecialChars

So an easy way out would be to revert the changes made in
R-2.7.0 and instead use a quoted version of  the full path
constructed by normalizePath().

In the mean time, of course one might simply  alert  people
to have Sweave.sty on their tex filename database / search path
and to include \usepackage{Sweave} in their .Rnw files.

Best,
Peter

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Sweave.sty problems under WinXP (English locale) with default settings

[Duncan Murdoch]

On 5/16/2008 9:22 AM, Peter Ruckdeschel wrote:

Hi R-devels,

I encounter the following problem when I want to build a vignette
in the package building process under Windows

platform   i386-pc-mingw32
arch   i386   
os mingw32
system i386, mingw32  
status
major  2  
minor  7.0
year   2008   
month  04 
day22 
svn rev45424  
language   R  
version.string R version 2.7.0 (2008-04-22)


TeX-Distribution: MikTeX 2.7

My R home directory is the default one:

 C:\Program Files\R\R-2.7.0,

so R.home() from package tools makes out of it
 
"C:\\PROGRA~1\\R\\R-27~1.0"


which does not contain spaces, but instead the special
character   ~  .

So function texi2dvi() from package tools makes texi2dvi
include the directive

   \usepackage{C:\PROGRA~1\R\R-27~1.0\share\texmf\Sweave}

into the corresponding .tex file for the vignette, and, consequently,
MikTeX throws an error (due to the ~'s).


The simplest workaround for this is to put \usepackage{Sweave} into your 
Rnw source, so that R doesn't try to add it.





According to

   http://developer.r-project.org/blosxom.cgi/R-devel

this is due to a change on  Apr 15.


See also the change on Apr 23 (to R-patched, not released yet), which 
may give another workaround.




If I am right, the use of short filenames (without spaces)
as to be found in %R_HOME% for
MikTeX (and tetex) would no longer have been necessary:

http://wiki.lyx.org/LaTeX/FilesWithSpecialChars


That page also says that ~ causes no problems, but it's talking about 
MikTeX 2.4, not 2.7.




So an easy way out would be to revert the changes made in
R-2.7.0 and instead use a quoted version of  the full path
constructed by normalizePath().

In the mean time, of course one might simply  alert  people
to have Sweave.sty on their tex filename database / search path
and to include \usepackage{Sweave} in their .Rnw files.


That shouldn't be necessary, and may not be a good idea in the long run, 
because it means that next year if you forget to update it, you'll still 
be using the R 2.7.0 version of that file.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Configure errors say to report here... (PR#11470)

[Simon Urbanek]

Adam,

this it not a bug in R, this is merely a user error. Please don't file  
self-inflicted problems as bugs (see posting guide). For Mac-related  
questions there is R-SIG-Mac. Brian's response was to the point - you  
break the compilation with the custom flags you use. See details below.


On May 16, 2008, at 12:40 AM, [EMAIL PROTECTED] wrote:


Hi,

	I'm attempting to compile R 2.7.0 on my G5, which is running OSX  
10.5.2. Yes, I know there is a precompiled binary, but my experience  
has shown that if I hand-compile ATLAS on my machine and then link R  
against it when compiling, R runs faster, hence me compiling it  
myself.




FWIW that is not necessary in general, you can plug in any BLAS by  
pointing the libRblas.dylib symlink at it (or an umbrella stub created  
for it if it's incomplete).




Anyway, I have this set of errors:

checking X11/Intrinsic.h usability... no
checking X11/Intrinsic.h presence... yes
configure: WARNING: X11/Intrinsic.h: present but cannot be compiled


This is likely a mess up of your headers and libraries. It's not  
causing the error, but still you're heading for trouble.



configure: WARNING: X11/Intrinsic.h: check for missing  
prerequisite headers?

configure: WARNING: X11/Intrinsic.h: see the Autoconf documentation
configure: WARNING: X11/Intrinsic.h: section "Present But Cannot  
Be Compiled"
configure: WARNING: X11/Intrinsic.h: proceeding with the  
preprocessor's result
configure: WARNING: X11/Intrinsic.h: in the future, the compiler  
will take precedence

configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
...
checking X11/Xmu/Atoms.h usability... no
checking X11/Xmu/Atoms.h presence... yes
configure: WARNING: X11/Xmu/Atoms.h: present but cannot be compiled
configure: WARNING: X11/Xmu/Atoms.h: check for missing  
prerequisite headers?

configure: WARNING: X11/Xmu/Atoms.h: see the Autoconf documentation
configure: WARNING: X11/Xmu/Atoms.h: section "Present But Cannot  
Be Compiled"
configure: WARNING: X11/Xmu/Atoms.h: proceeding with the  
preprocessor's result
configure: WARNING: X11/Xmu/Atoms.h: in the future, the compiler  
will take precedence

configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
...
checking tk.h usability... no
checking tk.h presence... yes
configure: WARNING: tk.h: present but cannot be compiled
configure: WARNING: tk.h: check for missing prerequisite headers?
configure: WARNING: tk.h: see the Autoconf documentation
configure: WARNING: tk.h: section "Present But Cannot Be Compiled"
configure: WARNING: tk.h: proceeding with the preprocessor's result
configure: WARNING: tk.h: in the future, the compiler will take  
precedence

configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##

...the command line item I pass to configure is this:

feta:R-2.7.0> ./configure --prefix=/usr/local --with-x --without-R- 
framework --without-aqua --with-blas="/usr/local/lib/libptf77blas.a / 
usr/local/lib/libatlas.a" --with-lapack="/usr/local/lib/liblapack.a / 
usr/local/lib/libptf77blas.a /usr/local/lib/libatlas.a" CFLAGS="- 
maltivec -mabi=altivec -mtune=970 -faltivec -O3" CXXFLAGS="-maltivec  
-mabi=altivec -mtune=970 -faltivec -O3"




Depending on your compiler this may not work, because you're forcing  
altivec constructs which introduces new keywords to the C language. R  
doesn't use any altivec commands so it will break the compilation (as  
you can see below). [This is based on my memory - I cannot reproduce  
the problem on my G5, but then I'm using more recent tools and OS, so  
your milleage may vary].


BTW: I have no idea what you're trying to achieve with those flags,  
they are essentially no-ops, because R doesn't contain any altivec  
code (and reals are "double" in R and thus AltiVec is of no use  
anyway). If you want to optimize for speed, have a look at posts by  
Jan de Leeuw and the old OptimizingR wiki page (also see -fast in gcc  
and what it implies, although you need dynamic).



...the rest of configure completes fine, though when I try to build  
R, I

make eventually ends up failing in this manner:

gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/sw/ 
include -I/usr/local/include -DHAVE_CONFIG_H   -fPIC  -maltivec - 
mabi=altivec -mtune=970 -faltivec -O3 -c cpoly.c -o cpoly.o


You're including /sw (Fink) - this is asking for trouble, because Fink  
contains incompatible versions of system libraries and headers (likely  
this causes the cpp problems above). Again, this is not the primary  
reason for the failure, but I hope you won't ask for help with that  
binary

[Rd] var/sd and NAs in R2.7.0

[McGehee, Robert]

Hello all,
I just upgraded to R 2.7.0 and found that the behavior of 'var' and 'sd'
have changed in the presence NAs (this wasn't explicit in the NEWS file,
though I see it probably has to do with the change for cor/cov). Anyway,
I just want to make sure that it was intentional to produce an error
when there was all NAs and na.rm=TRUE, rather than returning an NA (like
R 2.6.2), or NaN (like the function 'mean' does). That is, isn't the
purpose of 'na.rm=TRUE' to, in part, suppress these error messages.

Specifically,
> var(c(NA, NA, NA), na.rm=TRUE) # R2.6.2
[1] NA  
> var(c(NA, NA, NA), na.rm=TRUE) # R2.7.0
Error during wrapup: no complete observations in cov/cor

I think I can get the old behavior by setting use='p', but the 'sd'
function does not have a 'use' argument and I'd like not to get an error
here. Anyway, I'm a fan of the old behavior (not producing an error),
but if there was a reason to change this when na.rm=TRUE, I would
request that the 'sd' function be updated to be able to revert to the
old behavior as well.

FYI: I 'apply' these functions to large matrices of stock return time
series with missing values, and don't want the whole calculation to fail
just because I'm missing stock returns for one company.

Thanks,
Robert

Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



This e-mail, and any attachments hereto, are intended fo...{{dropped:11}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] var/sd and NAs in R2.7.0

[Gabor Grothendieck]

Try

var(c(NA, NA, NA), use = "pairwise.complete.obs")


On Fri, May 16, 2008 at 10:56 AM, McGehee, Robert
<[EMAIL PROTECTED]> wrote:
> Hello all,
> I just upgraded to R 2.7.0 and found that the behavior of 'var' and 'sd'
> have changed in the presence NAs (this wasn't explicit in the NEWS file,
> though I see it probably has to do with the change for cor/cov). Anyway,
> I just want to make sure that it was intentional to produce an error
> when there was all NAs and na.rm=TRUE, rather than returning an NA (like
> R 2.6.2), or NaN (like the function 'mean' does). That is, isn't the
> purpose of 'na.rm=TRUE' to, in part, suppress these error messages.
>
> Specifically,
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.6.2
> [1] NA
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.7.0
> Error during wrapup: no complete observations in cov/cor
>
> I think I can get the old behavior by setting use='p', but the 'sd'
> function does not have a 'use' argument and I'd like not to get an error
> here. Anyway, I'm a fan of the old behavior (not producing an error),
> but if there was a reason to change this when na.rm=TRUE, I would
> request that the 'sd' function be updated to be able to revert to the
> old behavior as well.
>
> FYI: I 'apply' these functions to large matrices of stock return time
> series with missing values, and don't want the whole calculation to fail
> just because I'm missing stock returns for one company.
>
> Thanks,
> Robert
>
> Robert McGehee, CFA
> Geode Capital Management, LLC
> One Post Office Square, 28th Floor | Boston, MA | 02109
> Tel: 617/392-8396Fax:617/476-6389
> mailto:[EMAIL PROTECTED]
>
>
>
> This e-mail, and any attachments hereto, are intended fo...{{dropped:11}}
>
> __
> 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] var/sd and NAs in R2.7.0

[Gerlanc, Daniel]

Perhaps _sd_ should take a ... argument.

-- Dan 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gabor Grothendieck
Sent: Friday, May 16, 2008 11:03 AM
To: McGehee, Robert
Cc: R-devel
Subject: Re: [Rd] var/sd and NAs in R2.7.0

Try

var(c(NA, NA, NA), use = "pairwise.complete.obs")


On Fri, May 16, 2008 at 10:56 AM, McGehee, Robert
<[EMAIL PROTECTED]> wrote:
> Hello all,
> I just upgraded to R 2.7.0 and found that the behavior of 'var' and
'sd'
> have changed in the presence NAs (this wasn't explicit in the NEWS
file,
> though I see it probably has to do with the change for cor/cov).
Anyway,
> I just want to make sure that it was intentional to produce an error
> when there was all NAs and na.rm=TRUE, rather than returning an NA
(like
> R 2.6.2), or NaN (like the function 'mean' does). That is, isn't the
> purpose of 'na.rm=TRUE' to, in part, suppress these error messages.
>
> Specifically,
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.6.2
> [1] NA
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.7.0
> Error during wrapup: no complete observations in cov/cor
>
> I think I can get the old behavior by setting use='p', but the 'sd'
> function does not have a 'use' argument and I'd like not to get an
error
> here. Anyway, I'm a fan of the old behavior (not producing an error),
> but if there was a reason to change this when na.rm=TRUE, I would
> request that the 'sd' function be updated to be able to revert to the
> old behavior as well.
>
> FYI: I 'apply' these functions to large matrices of stock return time
> series with missing values, and don't want the whole calculation to
fail
> just because I'm missing stock returns for one company.
>
> Thanks,
> Robert
>
> Robert McGehee, CFA
> Geode Capital Management, LLC
> One Post Office Square, 28th Floor | Boston, MA | 02109
> Tel: 617/392-8396Fax:617/476-6389
> mailto:[EMAIL PROTECTED]
>
>
>
> This e-mail, and any attachments hereto, are intended
fo...{{dropped:11}}
>
> __
> 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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] var/sd and NAs in R2.7.0

[McGehee, Robert]

I know I can get around this, I just would prefer that if R is breaking
backwards compatibility, then it's intentional (maybe it is, I just
don't know). That is, I don't want to require my entire company to
upgrade to 2.7.0 just so I can deploy a fix here, and I'd prefer not to
check the argument list of var every time I use it.

if ("use" %in% names(formals(var)))
var(x, na.rm=TRUE, use="p")
else
var(x, na.rm=TRUE)


-Original Message-
From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 16, 2008 11:03 AM
To: McGehee, Robert
Cc: R-devel
Subject: Re: [Rd] var/sd and NAs in R2.7.0

Try

var(c(NA, NA, NA), use = "pairwise.complete.obs")


On Fri, May 16, 2008 at 10:56 AM, McGehee, Robert
<[EMAIL PROTECTED]> wrote:
> Hello all,
> I just upgraded to R 2.7.0 and found that the behavior of 'var' and
'sd'
> have changed in the presence NAs (this wasn't explicit in the NEWS
file,
> though I see it probably has to do with the change for cor/cov).
Anyway,
> I just want to make sure that it was intentional to produce an error
> when there was all NAs and na.rm=TRUE, rather than returning an NA
(like
> R 2.6.2), or NaN (like the function 'mean' does). That is, isn't the
> purpose of 'na.rm=TRUE' to, in part, suppress these error messages.
>
> Specifically,
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.6.2
> [1] NA
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.7.0
> Error during wrapup: no complete observations in cov/cor
>
> I think I can get the old behavior by setting use='p', but the 'sd'
> function does not have a 'use' argument and I'd like not to get an
error
> here. Anyway, I'm a fan of the old behavior (not producing an error),
> but if there was a reason to change this when na.rm=TRUE, I would
> request that the 'sd' function be updated to be able to revert to the
> old behavior as well.
>
> FYI: I 'apply' these functions to large matrices of stock return time
> series with missing values, and don't want the whole calculation to
fail
> just because I'm missing stock returns for one company.
>
> Thanks,
> Robert
>
> Robert McGehee, CFA
> Geode Capital Management, LLC
> One Post Office Square, 28th Floor | Boston, MA | 02109
> Tel: 617/392-8396Fax:617/476-6389
> mailto:[EMAIL PROTECTED]
>
>
>
> This e-mail, and any attachments hereto, are intended
fo...{{dropped:11}}
>
> __
> 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] var/sd and NAs in R2.7.0

[McGehee, Robert]

Oops, as I just realized, var does have a 'use' argument in 2.6.2, so I
can just use Gabor's suggestion for var. Sorry for that Gabor.

-Original Message-
From: McGehee, Robert 
Sent: Friday, May 16, 2008 11:20 AM
To: 'Gabor Grothendieck'
Cc: R-devel
Subject: RE: [Rd] var/sd and NAs in R2.7.0

I know I can get around this, I just would prefer that if R is breaking
backwards compatibility, then it's intentional (maybe it is, I just
don't know). That is, I don't want to require my entire company to
upgrade to 2.7.0 just so I can deploy a fix here, and I'd prefer not to
check the argument list of var every time I use it.

if ("use" %in% names(formals(var)))
var(x, na.rm=TRUE, use="p")
else
var(x, na.rm=TRUE)


-Original Message-
From: Gabor Grothendieck [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 16, 2008 11:03 AM
To: McGehee, Robert
Cc: R-devel
Subject: Re: [Rd] var/sd and NAs in R2.7.0

Try

var(c(NA, NA, NA), use = "pairwise.complete.obs")


On Fri, May 16, 2008 at 10:56 AM, McGehee, Robert
<[EMAIL PROTECTED]> wrote:
> Hello all,
> I just upgraded to R 2.7.0 and found that the behavior of 'var' and
'sd'
> have changed in the presence NAs (this wasn't explicit in the NEWS
file,
> though I see it probably has to do with the change for cor/cov).
Anyway,
> I just want to make sure that it was intentional to produce an error
> when there was all NAs and na.rm=TRUE, rather than returning an NA
(like
> R 2.6.2), or NaN (like the function 'mean' does). That is, isn't the
> purpose of 'na.rm=TRUE' to, in part, suppress these error messages.
>
> Specifically,
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.6.2
> [1] NA
>> var(c(NA, NA, NA), na.rm=TRUE) # R2.7.0
> Error during wrapup: no complete observations in cov/cor
>
> I think I can get the old behavior by setting use='p', but the 'sd'
> function does not have a 'use' argument and I'd like not to get an
error
> here. Anyway, I'm a fan of the old behavior (not producing an error),
> but if there was a reason to change this when na.rm=TRUE, I would
> request that the 'sd' function be updated to be able to revert to the
> old behavior as well.
>
> FYI: I 'apply' these functions to large matrices of stock return time
> series with missing values, and don't want the whole calculation to
fail
> just because I'm missing stock returns for one company.
>
> Thanks,
> Robert
>
> Robert McGehee, CFA
> Geode Capital Management, LLC
> One Post Office Square, 28th Floor | Boston, MA | 02109
> Tel: 617/392-8396Fax:617/476-6389
> mailto:[EMAIL PROTECTED]
>
>
>
> This e-mail, and any attachments hereto, are intended
fo...{{dropped:11}}
>
> __
> 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] var/sd and NAs in R2.7.0

[Simon Urbanek]

Robert,

this was discussed before:
https://stat.ethz.ch/pipermail/r-devel/2007-December/047594.html

and it *is* mentioned in NEWS:

o   co[rv](use = "complete.obs") now always gives an error if there
are no complete cases: they used to give NA if
method = "pearson" but an error for the other two methods.
(Note that this is pretty arbitrary, but zero-length vectors
always give an error so it is at least consistent.)

cor(use="pair") used to give diagonal 1 even if the variable
was completely missing for the rank methods but NA for the
Pearson method: it now gives NA in all cases.

cor(use="pair") for the rank methods gave a matrix result with
dimensions > 0 even if one of the inputs had 0 columns.

[sd(..,na.rm=TRUE) -> cov(..,use="complete.obs")]

Cheers,
Simon


On May 16, 2008, at 11:19 AM, McGehee, Robert wrote:

I know I can get around this, I just would prefer that if R is  
breaking

backwards compatibility, then it's intentional (maybe it is, I just
don't know). That is, I don't want to require my entire company to
upgrade to 2.7.0 just so I can deploy a fix here, and I'd prefer not  
to

check the argument list of var every time I use it.

if ("use" %in% names(formals(var)))
var(x, na.rm=TRUE, use="p")
else
var(x, na.rm=TRUE)


-Original Message-
From: Gabor Grothendieck [mailto:[EMAIL PROTECTED]
Sent: Friday, May 16, 2008 11:03 AM
To: McGehee, Robert
Cc: R-devel
Subject: Re: [Rd] var/sd and NAs in R2.7.0

Try

var(c(NA, NA, NA), use = "pairwise.complete.obs")


On Fri, May 16, 2008 at 10:56 AM, McGehee, Robert
<[EMAIL PROTECTED]> wrote:

Hello all,
I just upgraded to R 2.7.0 and found that the behavior of 'var' and

'sd'

have changed in the presence NAs (this wasn't explicit in the NEWS

file,

though I see it probably has to do with the change for cor/cov).

Anyway,

I just want to make sure that it was intentional to produce an error
when there was all NAs and na.rm=TRUE, rather than returning an NA

(like

R 2.6.2), or NaN (like the function 'mean' does). That is, isn't the
purpose of 'na.rm=TRUE' to, in part, suppress these error messages.

Specifically,

var(c(NA, NA, NA), na.rm=TRUE) # R2.6.2

[1] NA

var(c(NA, NA, NA), na.rm=TRUE) # R2.7.0

Error during wrapup: no complete observations in cov/cor

I think I can get the old behavior by setting use='p', but the 'sd'
function does not have a 'use' argument and I'd like not to get an

error

here. Anyway, I'm a fan of the old behavior (not producing an error),
but if there was a reason to change this when na.rm=TRUE, I would
request that the 'sd' function be updated to be able to revert to the
old behavior as well.

FYI: I 'apply' these functions to large matrices of stock return time
series with missing values, and don't want the whole calculation to

fail

just because I'm missing stock returns for one company.

Thanks,
Robert

Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



This e-mail, and any attachments hereto, are intended

fo...{{dropped:11}}


__
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




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] basename/dirname produce incorrect results

[ronggui]

I have beend realized the problem of reporting with non-English
character this way. Just don't know how to do in a better way. Sorry
for that.

Now, the problem reported has been fixed ( in version (2008-05-15
r45703)). Thanks for your work.

Best

2008/5/16 Prof Brian Ripley <[EMAIL PROTECTED]>:
> I'm sorry, but that example make no sense to me -- you need to mark the
> encoding (and don't send HTML that will get stripped).
>
> This is presumably Windows, given the name.
>
> On Thu, 15 May 2008, ronggui wrote:
>
>> The incorrect result incurs when the file path contains Chinese character.
>> It seems that dirname/basename action on unit of byte instead of char, so
>> the result in the following example is half of what is expected.
>
> No, it works in widechars, that is UCS-2.
>
> I have a suspicion of what the problem is (it is related to attempts to
> handle embedded nuls), so please try tomorrow's R-patched to see if I have
> fixed it.  If that does not work, we need a reproducible example, and that
> means a message in a known encoding. (One way to do so is to attach a plain
> text message, and tell us in the body of the message the encoding you used.)
>
>>> g<-"d:\\如果含有中文\\如果含有中文.txt"
>>> dirname(g)
>>
>> [1] "d:/如果含"
>>>
>>> basename(g)
>>
>> [1] "如果含有"
>>
>>
>> --
>> HUANG Ronggui, Wincent http://ronggui.huang.googlepages.com/
>> Bachelor of Social Work, Fudan University, China
>> Master of sociology, Fudan University, China
>> Ph.D. Candidate, CityU of HK.
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595
>



-- 
HUANG Ronggui, Wincent http://ronggui.huang.googlepages.com/
Bachelor of Social Work, Fudan University, China
Master of sociology, Fudan University, China
Ph.D. Candidate, CityU of HK.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HoltWinters fitted level parameter not bounded between 0 and 1 (PR#11469)

[John Bodley]

Hi,

Thanks for the quick response. I upgraded by version of R on Windows to the
latest (2.7.0) and re-ran the analysis and get the same result of 48.87989.

The original time series was a non-regular zoo() object and I converted it
to a time series with daily granularity by setting the values of the
undefined dates to zero. I initially wondered if the zeros were maybe an
issue, i.e., I know multiplicative Holt-Winters requires non-negative
values, so I tried shifting the values, which should change the level,
though the fitted alpha values should be the same:

> delta <- 10 ^ seq(-3, 0);
> sapply(delta, function(delta) HoltWinters(x + delta, beta = 0, gamma =
0)$alpha);
 alpha  alpha  alpha  alpha
48.8798912 48.8798912 48.8798912  0.6881547

Note that by applying a shift,  I also obtained varying values of alpha,
similar to that of what David achieved by changing the initial conditions.

Thanks
-John

On Fri, May 16, 2008 at 4:20 AM, David Meyer <[EMAIL PROTECTED]>
wrote:

> I get John's value (48.8789) in 2.7.0 and R-devel (both on Ubuntu). Really
> seems to be a numeric issue:
>
> > HoltWinters(x, beta = 0, gamma = 0)$alpha
>   alpha
> 48.87989
>
> > HoltWinters(x * 1.01, beta = 0, gamma = 0)$alpha
>alpha
> 0.6881547
>
> > HoltWinters(x * 1.001, beta = 0, gamma = 0)$alpha
>   alpha
> 48.87989
>
> Providing starting values seems to help, but not always:
>
> > HoltWinters(x, beta = 0, gamma = 0, l.start = 0.1)$alpha
>   alpha
> 48.88999
> > HoltWinters(x, beta = 0, gamma = 0, l.start = 0.0001)$alpha
>alpha
> 0.6880582
>
> Yes, it's easy to use optimize() instead of optim() in the univariate
> cases, will do.
>
> David.
>
>
> Prof Brian Ripley wrote:
>
>> It doesn't do it on my system (I get a value of about 0.688 in R 2.7.0
>> patched on Linux), and 2.5.1 is not current.  Does a better starting value
>> help?
>>
>> However, HoltWinters is using optim() in a case it is not designed for
>> (one-dimensional optimization): see the note on its help page.  I think this
>> could easily be changed, but as HoltWinters is contributed code I am Cc:ing
>> the author for comment.
>>
>> On Fri, 16 May 2008, [EMAIL PROTECTED] wrote:
>>
>>  Full_Name: John Bodley
>>> Version: 2.5.1 (2007-06-27)
>>> OS: Windows XP
>>> Submission from: (NULL) (12.144.182.66)
>>>
>>>
>>> I was fitting a number of time series in R using the stats::HoltWinters
>>> method
>>> to define a single exponential smoothing model, i.e., beta = gamma = 0.
>>>
>>> I came across an example where the fitted value of alpha was not defined
>>> in the
>>> [0, 1] interval which seems to violate the lower and upper bound
>>> constraints
>>> used for the optim method. On my computer the following code returns a
>>> value of
>>> 48.87989.
>>>
>>> R code:
>>>
>>> x <- c(
>>> 0,
>>> 0.000843170320404722,
>>> 0,
>>> 0,
>>> 0,
>>> 0.0103773584905660,
>>> 0.00832466181061394,
>>> 0.0038560411311054,
>>> 0,
>>> 0,
>>> 0.00484966052376334,
>>> 0,
>>> 0,
>>> 0,
>>> 0.00274348422496571,
>>> 0,
>>> 0,
>>> 0,
>>> 0,
>>> 0,
>>> 0.0207064555420219,
>>> 0.0334975369458128,
>>> 0.0334975369458128,
>>> 0.00338983050847458,
>>> 0.00483675937122128,
>>> 0,
>>> 0,
>>> 0.00224971878515186,
>>> 0,
>>> 0,
>>> 0,
>>> 0.00135685210312076,
>>> 0,
>>> 0,
>>> 0,
>>> 0.0035377358490566,
>>> 0.0035377358490566,
>>> 0.00501002004008016,
>>> 0.0107632093933464,
>>> 0,
>>> 0,
>>> 0.0143329658213892,
>>> 0.0330459770114943,
>>> 0,
>>> 0,
>>> 0,
>>> 0,
>>> 0.0109890109890110,
>>> 0,
>>> 0.00118623962040332,
>>> 0.007380073800738,
>>> 0.00695410292072323,
>>> 0.0104895104895105,
>>> 0.00278551532033426,
>>> 0.00278551532033426
>>> );
>>>
>>> # Single exponential smoothing
>>> m <- stats::HoltWinters(x, beta = 0, gamma = 0);
>>> m$alpha
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
> --
> Dr. David Meyer
> Department of Information Systems and Operations
>
> Vienna University of Economics and Business Administration
> Augasse 2-6, A-1090 Wien, Austria, Europe
> Tel: +43-1-313 36 4393
> Fax: +43-1-313 36 90 4393
> HP:  http://wi.wu-wien.ac.at/~meyer/ 
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] k means

[cgenolin]

Hi the list

I try the flexclust, but I do not manage to see what is wrong in my 
(very simple) code...

Will you have few minutes to check it?

Thanks for your help.

Christophe
--- 8< 
data  <- rbind(c(1,2 ,NA,4 ),
  c(1,1 ,NA,1 ),
  c(2,3 ,4 ,5 ),
  c(2,2 ,2 ,2 ),
  c(3,NA,NA,6 ),
  c(3,NA,NA,3 ),
  c(2,4 ,4 ,NA),
  c(2,3 ,2 ,NA))

distTest <- rbind(c(0,0,0,0),
 c(1,1,1,1))

distNA <- function(x,centers){
   z <- matrix(0,nrow=nrow(x),ncol=nrow(centers))
   for(k in 1:nrow(centers)){
   z[,k]<- apply(x,1,function(x){dist(rbind(x,centers[k,]))})
   }
   z
}

distNA(data,distTest)

km <- kccaFamily(dist=distNA,cent=colMeans)
kcca(x=data,k=2,family=km)
kcca(x=data,k=3,family=km)

--- 8< 







On Mon, 12 May 2008 19:24:55 +0200,
cgenolin  (c) wrote:


 > Hi the devel list,
 > I am using K means with a non standard distance. As far as I see, the
 > function kmeans is able to deal with 4 differents algorithm, but not
 > with a user define distance.

 > In addition, kmeans is not able to deal with missing value whereas
 > there is several solution that k-means can use to deal with them ; one
 > is using a distance that takes the missing value in account, like a
 > distance with Gower adjustement (which is the regular distance dist()
 > used in R).

 > So is it possible to adapt kmeans to let the user gives an argument
 > 'distance to use'?

As Bill Venables already pointed out that makes not too much sense,
especially as there are already R functions for doing that. Package
flexclust implements a k-means-type clustering algorithm where the
user can provide arbitrary distance measures, have a look at

http://www.stat.uni-muenchen.de/~leisch/papers/Leisch-2006.pdf

The code you need to write for using a new distance measure is
minimal, and there are two examples in the paper describing in detail
what needs to be done.

Hope this helps,
Fritz Leisch

--
---
Prof. Dr. Friedrich Leisch

Institut für Statistik  Tel: (+49 89) 2180 3165
Ludwig-Maximilians-Universität  Fax: (+49 89) 2180 5308
Ludwigstraße 33
D-80539 München http://www.statistik.lmu.de/~leisch
---
  Journal Computational Statistics --- http://www.springer.com/180
 Münchner R Kurse --- http://www.statistik.lmu.de/R
---




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel