Re: [Rd] type.convert (PR#13646)
Hi Peter,
each of the four PCs actually has the same locale setting:
> Sys.setlocale("LC_CTYPE")
[1] "German_Austria.1252"
(all the other settings returned by invoking Sys.getlocale() are identical as
well).
Just to be sure (because it's displayed incorrectly in my browser on the
bugtracking page): the character inside the type.convert function ought to be a
"section"-sign (HTML Code § or § , in R "\247", and not a dot ".").
-Ursprüngliche Nachricht-
Von: Peter Dalgaard [mailto:p.dalga...@biostat.ku.dk]
Gesendet: Donnerstag, 09. April 2009 19:26
An: Raberger, Stefan
Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org
Betreff: Re: [Rd] type.convert (PR#13646)
s.raber...@innovest.at wrote:
> Full_Name: Stefan Raberger
> Version: 2.8.1
> OS: Windows XP
> Submission from: (NULL) (213.185.163.242)
>
>
> Hi there,
>
> I recently noticed some strange behaviour of the command "type.convert",
> depending on the startup mode used. But there also seems to be different
> behaviour on different PCs (all running the same OS and the same version of
> R).
>
> On PC1:
> When I start R in SDI mode (RGui --no-save --no-restore --no-site-file
> --no-init-file --no-environ) and try to convert, the result is
>
>> type.convert("§")
> [1] NA
>
> If I use MDI mode (RGui --no-save --no-restore --no-site-file --no-init-file
> --no-environ --no-Rconsole) instead, the result is
>
>> type.convert("§")
> [1] §
> Levels: §
>
> On PC2 it's exactly the other way round (SDI: §, MDI: NA), on PC2 the result
> is
> always NA, independent of the startup mode used, and on PC4 it's always §.
>
> What's the result I should expect R to return, and why is it different in so
> many cases?
Which locale does R think it is in in the four cases?
(Sys.setlocale("LC_CTYPE"), I think).
Might well not be a bug (so please don't file it as one).
> Any help is much appreciated!
> Regards, Stefan
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] type.convert (PR#13646)
In the NA cases, storage.mode(..) - and also typeof(..) and class(..) -
returns "logical", whereas in the other cases I get "integer"
(and class "factor").
charToRaw(..) returns a7, as you suspected.
-Ursprüngliche Nachricht-
Von: Peter Dalgaard [mailto:p.dalga...@biostat.ku.dk]
Gesendet: Freitag, 10. April 2009 11:03
An: Raberger, Stefan
Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org
Betreff: Re: AW: [Rd] type.convert (PR#13646)
Raberger, Stefan wrote:
> Hi Peter,
>
> each of the four PCs actually has the same locale setting:
>
>> Sys.setlocale("LC_CTYPE")
> [1] "German_Austria.1252"
>
> (all the other settings returned by invoking Sys.getlocale() are identical as
> well).
>
> Just to be sure (because it's displayed incorrectly in my browser on the
> bugtracking page): the character inside the type.convert function ought to be
> a "section"-sign (HTML Code § or § , in R "\247", and not a dot
> ".").
I saw it correctly. It's "\302\247" in UTF8 locales, which is of course
the reason I suspected locale settings, but I can't seem to trigger the
NA behaviour.
I'm at a loss here, but some ideas:
In the cases where it returns NA, what type is it? (I.e.
storage.mode(type.convert()))
What do you get from
> charToRaw("§")
[1] c2 a7
(a7, presumably, but better check).
-p
> -Ursprüngliche Nachricht-
> Von: Peter Dalgaard [mailto:p.dalga...@biostat.ku.dk]
> Gesendet: Donnerstag, 09. April 2009 19:26
> An: Raberger, Stefan
> Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org
> Betreff: Re: [Rd] type.convert (PR#13646)
>
> s.raber...@innovest.at wrote:
>> Full_Name: Stefan Raberger
>> Version: 2.8.1
>> OS: Windows XP
>> Submission from: (NULL) (213.185.163.242)
>>
>>
>> Hi there,
>>
>> I recently noticed some strange behaviour of the command "type.convert",
>> depending on the startup mode used. But there also seems to be different
>> behaviour on different PCs (all running the same OS and the same version of
>> R).
>>
>> On PC1:
>> When I start R in SDI mode (RGui --no-save --no-restore --no-site-file
>> --no-init-file --no-environ) and try to convert, the result is
>>
>>> type.convert("§")
>> [1] NA
>>
>> If I use MDI mode (RGui --no-save --no-restore --no-site-file --no-init-file
>> --no-environ --no-Rconsole) instead, the result is
>>
>>> type.convert("§")
>> [1] §
>> Levels: §
>>
>> On PC2 it's exactly the other way round (SDI: §, MDI: NA), on PC2 the result
>> is
>> always NA, independent of the startup mode used, and on PC4 it's always §.
>>
>> What's the result I should expect R to return, and why is it different in so
>> many cases?
>
> Which locale does R think it is in in the four cases?
> (Sys.setlocale("LC_CTYPE"), I think).
>
> Might well not be a bug (so please don't file it as one).
>
>> Any help is much appreciated!
>> Regards, Stefan
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] data argument and environments
I'm having difficulty with an environmental issue: I have an additive model fitting function with a typical call that looks like this: require(quantreg) n <- 100 x <- runif(n,0,10) y <- sin(x) + rnorm(n)/5 d <- data.frame(x,y) lam <- 2 f <- rqss(y ~ qss(x, lambda = lam), data = d) this is fine when invoked as is; x and y are found in d, and lam is found the .GlobalEnv, or at least this is how I understand it. Now, I'd like to have a function say, h <- function(lam) AIC(rqss(y ~ qss(x, lambda = lam), data = d)) but now, if I do: rm(lam) h(1) Error in qss1(x, constraint = constraint, lambda = lambda, dummies = dummies, : object "lam" not found worse, if there is a "lam" in the .GlobalEnv it is used instead of the argument specified to h(). If I remove the data=d argument in the function definition then lam is passed correctly. presumably because data defaults to parent.env(). I recognize that this is probably an elementary confusion on my part, but my understanding of environments is very limited. I did read the entry for FAQ 7.12, but I'm still unenlightened. url:www.econ.uiuc.edu/~rogerRoger Koenker email rkoen...@uiuc.edu Department of Economics vox:217-333-4558University of Illinois fax:217-244-6678Champaign, IL 61820 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data argument and environments
On 11/04/2009 6:50 PM, roger koenker wrote: I'm having difficulty with an environmental issue: I have an additive model fitting function with a typical call that looks like this: require(quantreg) n <- 100 x <- runif(n,0,10) y <- sin(x) + rnorm(n)/5 d <- data.frame(x,y) lam <- 2 f <- rqss(y ~ qss(x, lambda = lam), data = d) this is fine when invoked as is; x and y are found in d, and lam is found the .GlobalEnv, or at least this is how I understand it. Now, I'd like to have a function say, h <- function(lam) AIC(rqss(y ~ qss(x, lambda = lam), data = d)) but now, if I do: rm(lam) h(1) Error in qss1(x, constraint = constraint, lambda = lambda, dummies = dummies, : object "lam" not found worse, if there is a "lam" in the .GlobalEnv it is used instead of the argument specified to h(). If I remove the data=d argument in the function definition then lam is passed correctly. presumably because data defaults to parent.env(). I recognize that this is probably an elementary confusion on my part, but my understanding of environments is very limited. I did read the entry for FAQ 7.12, but I'm still unenlightened. Formulas have environments attached to them, and modelling functions should look there if they don't find the object in the data argument. If your h is defined exactly as you wrote it, then the environment of the y ~ qss(...) formula will automatically be the evaluation frame of h, so it should be able to find lam. You wrote rqss, right? So perhaps you aren't evaluating the variables in the formula in the right place. Do you use model.frame to do it? (See lm() for an example: it takes the original call to lm, throws away all but a few arguments, and turns it into a call to model.frame() to find the necessary variables.) model.frame() knows about environments and stuff, but assumes linear model-like data. Duncan Murdoch url:www.econ.uiuc.edu/~rogerRoger Koenker email rkoen...@uiuc.edu Department of Economics vox:217-333-4558University of Illinois fax:217-244-6678Champaign, IL 61820 __ 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
