Re: [R] foreign package read.spss() and NA levels
Hi Uwe,
Thank you so much for your reply, I am sorry to waste your time, but after
another look, the error seemed to be caused with how I had created the '.sav'
file I was using. It was converting one of the factor levels which wasn't NA to
the factor level "NA", but the problem was in the dataset as I said.
Many Thanks,
Justin
Justin Allen
Housing Consultant, BRE<https://bregroup.com/>
T: 07807122647
From: Uwe Ligges
Sent: 04 June 2021 10:57
To: Allen, Justin ; R-help@r-project.org
Cc: Whiteley, Jonathon ; Foster, Helen
Subject: Re: [R] foreign package read.spss() and NA levels
On 27.05.2021 12:27, Allen, Justin wrote:
> Hi All,
>
> Wanted to report what may be a bug or possibly an oversight, but I am unsure,
> in the "foreign" packages in the read.spss() command,
> https://cran.r-project.org/web/packages/foreign/index.html. When running the
> following code,
>
> input <- read.spss("[.sav file location]", to.data.frame = TRUE)
> str(input)
>
> The read.spss() seems to be applying addNA() to factors so NA is being set as
> a level, and there seems to be no way to get read.spss() to bring factors in
> without doing this. This seems to be a recent change as read.spss() was not
> doing this as of a few months ago. None of the arguments in read.spss() seem
> to also stop this behaviour. I am currently on the most recent version of
> both R and the package, as of 27/05/21, and am using RStudio Version 1.4.1106.
Within R (I do not use RStudio) and even with the most recent R-devel, I see
(sav <- system.file("files", "electric.sav", package = "foreign"))
dat <- read.spss(file=sav, to.data.frame=TRUE)
table(dat$DAYOFWK)
# SUNDAY MONDAY TUESDAY WEDNSDAY THURSDAY FRIDAY SATURDAY
# 19 11 19 17 15 13 16
table(dat$DAYOFWK, useNA="always")
# SUNDAY MONDAY TUESDAY WEDNSDAY THURSDAY FRIDAY SATURDAY
# 19 11 19 17 15 13 16 130
So exactly what you expected?
If you rather use
dat <- read.spss(file=sav, to.data.frame=TRUE, use.missings=FALSE)
table(dat$DAYOFWK, useNA="always")
you see the NA values are converted to a factor level called "MISSING".
If it is different on your end, pelase try in plain R, tell us the
version of R / foreign and show an example data file where this happens.
Best,
Uwe Ligges
>
> Any thoughts?
>
> Many Thanks,
>
> Justin Allen
>
> p.s. your continued maintenance and additions to R and its packages have been
> infinitely useful in my work and life and thank for that.
>
> Justin Allen
> Housing Consultant, BRE<https://bregroup.com/>
> T: 07807122647
>
>
> Follow BRE on Twitter: @BRE_Group<http://twitter.com/BRE_Group>
>
> Privileged and confidential information and/or copyright material may be
> contained in this e-mail. If you are not the intended addressee you may not
> copy or deliver it to anyone else or use it in any unauthorised manner. To do
> so is prohibited and may be unlawful. If you have received this e-mail by
> mistake, please advise the sender immediately by return e-mail and destroy
> all copies. Thank you.
>
> Building Research Establishment Ltd, Registered under number 3319324 in
> England and Wales. VAT Registration No GB 689 9499 27
> www.bregroup.com<http://www.bregroup.com>
> BRE Global Limited, Registered under number 8961297 in England and Wales.
> www.breglobal.com<http://www.breglobal.com>
> Building Research Establishment and BRE Global are subsidiaries of the BRE
> Trust.
> BRE Trust is a company limited by guarantee, Registered under number 3282856
> in England and Wales, and registered as a charity in England (no. 1092193)
> and in Scotland (no. SC039320).
> www.bretrust.org.uk<http://www.bretrust.org.uk>
> Registered Offices: Bucknalls Lane, Garston, Watford, Hertfordshire WD25 9XX
> - Travelling to BRE: see
> www.bregroup.com/contact/directions/<http://www.bregroup.com/contact/directions/<http://www.bregroup.com/contact/directions/<http://www.bregroup.com/contact/directions/>>
>
>
>[[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
Follow BRE on Twitter: @BRE_Group<http://twitter.com/BRE_Group>
_
Re: [R] foreign package read.spss() and NA levels
On 27.05.2021 12:27, Allen, Justin wrote:
Hi All,
Wanted to report what may be a bug or possibly an oversight, but I am unsure, in the
"foreign" packages in the read.spss() command,
https://cran.r-project.org/web/packages/foreign/index.html. When running the following
code,
input <- read.spss("[.sav file location]", to.data.frame = TRUE)
str(input)
The read.spss() seems to be applying addNA() to factors so NA is being set as a
level, and there seems to be no way to get read.spss() to bring factors in
without doing this. This seems to be a recent change as read.spss() was not
doing this as of a few months ago. None of the arguments in read.spss() seem to
also stop this behaviour. I am currently on the most recent version of both R
and the package, as of 27/05/21, and am using RStudio Version 1.4.1106.
Within R (I do not use RStudio) and even with the most recent R-devel, I see
(sav <- system.file("files", "electric.sav", package = "foreign"))
dat <- read.spss(file=sav, to.data.frame=TRUE)
table(dat$DAYOFWK)
# SUNDAY MONDAY TUESDAY WEDNSDAY THURSDAY FRIDAY SATURDAY
# 19 11 19 17 15 13 16
table(dat$DAYOFWK, useNA="always")
# SUNDAY MONDAY TUESDAY WEDNSDAY THURSDAY FRIDAY SATURDAY
# 19 11 19 17 15 13 16 130
So exactly what you expected?
If you rather use
dat <- read.spss(file=sav, to.data.frame=TRUE, use.missings=FALSE)
table(dat$DAYOFWK, useNA="always")
you see the NA values are converted to a factor level called "MISSING".
If it is different on your end, pelase try in plain R, tell us the
version of R / foreign and show an example data file where this happens.
Best,
Uwe Ligges
Any thoughts?
Many Thanks,
Justin Allen
p.s. your continued maintenance and additions to R and its packages have been
infinitely useful in my work and life and thank for that.
Justin Allen
Housing Consultant, BRE
Privileged and confidential information and/or copyright material may be
contained in this e-mail. If you are not the intended addressee you may not
copy or deliver it to anyone else or use it in any unauthorised manner. To do
so is prohibited and may be unlawful. If you have received this e-mail by
mistake, please advise the sender immediately by return e-mail and destroy all
copies. Thank you.
Building Research Establishment Ltd, Registered under number 3319324 in England and
Wales. VAT Registration No GB 689 9499 27
www.bregroup.com
BRE Global Limited, Registered under number 8961297 in England and Wales.
www.breglobal.com
Building Research Establishment and BRE Global are subsidiaries of the BRE
Trust.
BRE Trust is a company limited by guarantee, Registered under number 3282856 in
England and Wales, and registered as a charity in England (no. 1092193) and in
Scotland (no. SC039320). www.bretrust.org.uk
Registered Offices: Bucknalls Lane, Garston, Watford, Hertfordshire WD25 9XX -
Travelling to BRE: see
www.bregroup.com/contact/directions/
[R] foreign package read.spss() and NA levels
Hi All,
Wanted to report what may be a bug or possibly an oversight, but I am unsure,
in the "foreign" packages in the read.spss() command,
https://cran.r-project.org/web/packages/foreign/index.html. When running the
following code,
input <- read.spss("[.sav file location]", to.data.frame = TRUE)
str(input)
The read.spss() seems to be applying addNA() to factors so NA is being set as a
level, and there seems to be no way to get read.spss() to bring factors in
without doing this. This seems to be a recent change as read.spss() was not
doing this as of a few months ago. None of the arguments in read.spss() seem to
also stop this behaviour. I am currently on the most recent version of both R
and the package, as of 27/05/21, and am using RStudio Version 1.4.1106.
Any thoughts?
Many Thanks,
Justin Allen
p.s. your continued maintenance and additions to R and its packages have been
infinitely useful in my work and life and thank for that.
Justin Allen
Housing Consultant, BRE
Privileged and confidential information and/or copyright material may be
contained in this e-mail. If you are not the intended addressee you may not
copy or deliver it to anyone else or use it in any unauthorised manner. To do
so is prohibited and may be unlawful. If you have received this e-mail by
mistake, please advise the sender immediately by return e-mail and destroy all
copies. Thank you.
Building Research Establishment Ltd, Registered under number 3319324 in England
and Wales. VAT Registration No GB 689 9499 27
www.bregroup.com
BRE Global Limited, Registered under number 8961297 in England and Wales.
www.breglobal.com
Building Research Establishment and BRE Global are subsidiaries of the BRE
Trust.
BRE Trust is a company limited by guarantee, Registered under number 3282856 in
England and Wales, and registered as a charity in England (no. 1092193) and in
Scotland (no. SC039320). www.bretrust.org.uk
Registered Offices: Bucknalls Lane, Garston, Watford, Hertfordshire WD25 9XX -
Travelling to BRE: see
www.bregroup.com/contact/directions/
