Re: [Rd] Inverting a square... (PR#13762)
Yes=2C Peter=2E I did look at it=2C but not carefully enought to catch = that=2E Thanks=2C Ravi=2E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ravi Varadhan=2C Ph=2ED=2E Assistant Professor=2C Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins University Ph=2E (410) 502-2619 email=3A rvaradhan=40jhmi=2Eedu - Original Message - From=3A Peter Dalgaard =3CP=2EDalgaard=40biostat=2Eku=2Edk=3E Date=3A Thursday=2C June 18=2C 2009 9=3A15 am Subject=3A Re=3A =5BRd=5D Inverting a square=2E=2E=2E (PR=2313762) To=3A rvaradhan=40jhmi=2Eedu Cc=3A R-bugs=40r-project=2Eorg =3E Refiling this=2E The actual fix was slightly more complicated=2E Wi= ll soon =3E be committed to R-Patched (aka 2=2E9=2E1 beta)=2E =3E = =3E -p =3E = =3E rvaradhan=40jhmi=2Eedu wrote=3A =3E =3E Full=5FName=3A Ravi Varadhan =3E =3E Version=3A 2=2E8=2E1 =3E =3E OS=3A Windows =3E =3E Submission from=3A (NULL) (162=2E129=2E251=2E19) =3E =3E = =3E =3E = =3E =3E Inverting a matrix with solve()=2C but using LAPACK=3DTRUE=2C g= ives erroneous =3E =3E results=3A =3E = =3E Thanks=2C but there seems to be a much easier fix=2E =3E = =3E Inside coef=2Eqr=2C we have =3E = =3E coef=5Bqr=24pivot=2C =5D =3C- =3E =2ECall(=22qr=5Fcoef=5Freal=22=2C qr=2C y=2C PACKAGE =3D =22base=22= )=5Bseq=5Flen(p)=5D =3E = =3E which should be =5Bseq=5Flen(p)=2C=5D =3E = =3E (otherwise=2C in the matrix case=2C the RHS will recycle only the 1= st p =3E elements=2C i=2Ee=2E=2C the 1st column)=2E =3E = =3E =3E = =3E =3E Here is an example=3A =3E =3E = =3E =3E hilbert =3C- function(n) =7B i =3C- 1=3An=3B 1 / outer(i -= 1=2C i=2C =22+=22) =7D =3E =3Eh5 =3C- hilbert(5) =3E =3Ehinv1 =3C- solve(qr(h5)) =3E =3Ehinv2 =3C- solve(qr(h5=2C LAPACK=3DTRUE)) = =3E =3Eall=2Eequal(hinv1=2C hinv2) =23 They are not equal =3E =3E = =3E =3E Here is a function that I wrote to correct this problem=3A =3E =3E = =3E =3Esolve=2Elapack =3C- function(A=2C LAPACK=3DTRUE=2C tol=3D1=2Ee= -07) =7B =3E =3E=23 A function to invert a matrix using =22LAPACK=22 or =22LIN= PACK=22 =3E =3E if (nrow(A) !=3D ncol(A)) stop(=22Matrix muxt be square= =22) =3E =3E qrA =3C- qr(A=2C LAPACK=3DLAPACK=2C tol=3Dtol) =3E =3E if (LAPACK) =7B =3E =3Eapply(diag(1=2C ncol(A))=2C 2=2C function(x) solve(qrA=2C x)) = =3E =3E =7D else solve(qrA) =3E =3E=7D =3E =3E = =3E =3E hinv3 =3C- solve=2Elapack(h5) =3E =3Eall=2Eequal(hinv1=2C hinv3) =23 Now=2C they are equal =3E =3E = =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3E R-devel=40r-project=2Eorg mailing list =3E =3E = =3E = =3E = =3E -- = =3E O=5F=5F Peter Dalgaard =D8ster Farimagsgade 5=2C= Entr=2EB =3Ec/ /=27=5F --- Dept=2E of Biostatistics PO Box 2099=2C 1014 C= ph=2E K =3E (*) =5C(*) -- University of Copenhagen Denmark Ph=3A (+45)= 35327918 =3E =7E=7E=7E=7E=7E=7E=7E=7E=7E=7E - (p=2Edalgaard=40biostat=2Eku=2Edk)= FAX=3A (+45) 35327907 =3E = =3E __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Floating point precision / guard digits? (PR#13771)
Full_Name: D Kreil Version: 2.8.1 and 2.9.0 OS: Debian Linux Submission from: (NULL) (141.244.140.179) Group: Accuracy I understand that most floating point numbers are approximated due to their binary storage. On the other hand, I thought that modern math CPUs used guard digits to protect against trivial underflows. Not true? # integers, no problem > 1+1+1==3 [1] TRUE # binary floating point approximation underflows > .1+.1+.1==.3 [1] FALSE > .1+.1+.1==.3 [1] FALSE # binary floating point exact for certain numbers > .1+.1==.2 [1] TRUE I know that safe code should not test for quality of floats. Still, is R underutilizing the power of the underlying hardware? Grateful for comments, David. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-project mailing lists (and SVN) - timeout Sunday 21 June
Dear R users, unfortunately, tomorrow Sunday will be a longish timeout of our mail services, notably affecting the R- and R-SIG- mailing lists @r-project.org , i.e., hosted by the Stats / Math Department of ETH, stat.math.ethz.ch. Note that also the svn.r-project.org will suffer from the timeout. This should be a "once in 8 years" event, hopefully, and we are sorry for any inconvenience. Well, enjoy Sunday off-work :-) --official-text -- There will be upcoming maintenance work of the central computer services in our server room : Sunday, 21st June, 9 a.m. - 5 p.m. (MEST = GMT+2) During this time, we have to switch off all of our servers since the main power supply will be turned off. Services like email or web will be down. This interrupt will probably take less than 8 hours. Please check the website http://www.math.ethz.ch As soon as this site is up again, all the servers and dervices should be back online (within a small delay). - Martin Maechler, ETH Zurich http://stat.ethz.ch/people/maechler Seminar für Statistik, ETH Zürich, SWITZERLAND __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Floating point precision / guard digits? (PR#13771)
a) this is not a bug, so this is the wrong list b) 'underflow' does not mean what you think it means. c) guard digits and sticky bits do improve rounding behavior, but floating point will always remain approximate. d) if it is important to your application to perform exact arithmetic on rational numbers (and I suspect it is not), you might want to use that instead of floating-point. But even if implemented in R, most R calculations cannot use it. You may want to study up on floating-point arithmetic some more, though. -s On 6/19/09, rbug...@kreil.org wrote: > Full_Name: D Kreil > Version: 2.8.1 and 2.9.0 > OS: Debian Linux > Submission from: (NULL) (141.244.140.179) > > > Group: Accuracy > > I understand that most floating point numbers are approximated due to their > binary storage. On the other hand, I thought that modern math CPUs used > guard > digits to protect against trivial underflows. Not true? > > # integers, no problem >> 1+1+1==3 > [1] TRUE > # binary floating point approximation underflows >> .1+.1+.1==.3 > [1] FALSE >> .1+.1+.1==.3 > [1] FALSE > # binary floating point exact for certain numbers >> .1+.1==.2 > [1] TRUE > > I know that safe code should not test for quality of floats. Still, is R > underutilizing the power of the underlying hardware? > > Grateful for comments, > David. > > __ > 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
[Rd] Special characters in Rd example section will cause errors
Hi (Duncan?),
The other day I noticed some characters will cause errors in R CMD
CHECK because of parse_Rd(), and AFAIK, these chars include '%', '{'
and '}'. For example, note the comments in the example section:
%~~~%
\name{testfun}
\Rdversion{1.1}
\alias{testfun}
\title{
A Test
}
\description{
A test
}
\usage{
testfun()
}
\value{
NULL
}
\author{
Yihui Xie
}
\examples{
# special characters in comments
# what if a bracket '{' here?
}
\keyword{ misc }
%~~~%
## error occurs
> tools:::parse_Rd('testfun.Rd')
Error in tools:::parse_Rd("testfun.Rd") :
testfun.Rd:23:1: unexpected section header
23: }
24: \keyword
^
If I remove the '{', the Rd file can be parsed successfully. When you
put a code line with "%" in it, there will also be an error, e.g. you
put this in the example section
sprintf("%s", letters[1])
and you'll get
> tools:::parse_Rd('testfun.Rd')
Error in tools:::parse_Rd("testfun.Rd") :
Unexpected end of input (in " quoted string opened at testfun.Rd:23:10)
In addition: Warning message:
In tools:::parse_Rd("testfun.Rd") :
newline within quoted string at testfun.Rd:24
Rd_parse() will parse the Rd file incorrectly either.
> tools:::Rd_parse('testfun.Rd')
$meta
$meta$aliases
[1] "testfun"
$meta$concepts
character(0)
$meta$keywords
[1] "misc"
$meta$doc_type
character(0)
$meta$encoding
character(0)
$data
valstags
1 testfunname
2 1.1 Rdversion
3 \nA Test\n title
4 \nA test\n description
5 \ntestfun()\n usage
6\nNULL\n value
7 \nYihui Xie\n author
8 \n# special characters in comments\n# what if 'examples
$rest
examples
"'? or ''\n\n}\n"
Here is my session info:
> sessionInfo()
R version 2.9.0 (2009-04-17)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.
1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 9.0
year 2009
month 04
day17
svn rev48333
language R
version.string R version 2.9.0 (2009-04-17)
Regards,
Yihui
--
Yihui Xie
Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
Mobile: +86-15810805877
Homepage: http://www.yihui.name
School of Statistics, Room 1037, Mingde Main Building,
Renmin University of China, Beijing, 100872, China
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Special characters in Rd example section will cause errors
I've noticed this as well. I recently had a % in an Rd file that caused
me problems.
On Sat, Jun 20, 2009 at 10:18 AM, Yihui Xie wrote:
> Hi (Duncan?),
>
> The other day I noticed some characters will cause errors in R CMD
> CHECK because of parse_Rd(), and AFAIK, these chars include '%', '{'
> and '}'. For example, note the comments in the example section:
>
> %~~~%
> \name{testfun}
> \Rdversion{1.1}
> \alias{testfun}
> \title{
> A Test
> }
> \description{
> A test
> }
> \usage{
> testfun()
> }
> \value{
> NULL
> }
> \author{
> Yihui Xie
> }
> \examples{
> # special characters in comments
> # what if a bracket '{' here?
> }
> \keyword{ misc }
> %~~~%
>
> ## error occurs
>> tools:::parse_Rd('testfun.Rd')
> Error in tools:::parse_Rd("testfun.Rd") :
> testfun.Rd:23:1: unexpected section header
> 23: }
> 24: \keyword
> ^
>
> If I remove the '{', the Rd file can be parsed successfully. When you
> put a code line with "%" in it, there will also be an error, e.g. you
> put this in the example section
>
> sprintf("%s", letters[1])
>
> and you'll get
>
>> tools:::parse_Rd('testfun.Rd')
> Error in tools:::parse_Rd("testfun.Rd") :
> Unexpected end of input (in " quoted string opened at testfun.Rd:23:10)
> In addition: Warning message:
> In tools:::parse_Rd("testfun.Rd") :
> newline within quoted string at testfun.Rd:24
>
> Rd_parse() will parse the Rd file incorrectly either.
>
>> tools:::Rd_parse('testfun.Rd')
> $meta
> $meta$aliases
> [1] "testfun"
>
> $meta$concepts
> character(0)
>
> $meta$keywords
> [1] "misc"
>
> $meta$doc_type
> character(0)
>
> $meta$encoding
> character(0)
>
>
> $data
> vals tags
> 1 testfun name
> 2 1.1 Rdversion
> 3 \nA Test\n title
> 4 \nA test\n description
> 5 \ntestfun()\n usage
> 6 \nNULL\n value
> 7 \nYihui Xie\n author
> 8 \n# special characters in comments\n# what if ' examples
>
> $rest
> examples
> "'? or ''\n\n}\n"
>
>
> Here is my session info:
>
>> sessionInfo()
> R version 2.9.0 (2009-04-17)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.
> 1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>> R.version
> _
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major 2
> minor 9.0
> year 2009
> month 04
> day 17
> svn rev 48333
> language R
> version.string R version 2.9.0 (2009-04-17)
>
>
> Regards,
> Yihui
> --
> Yihui Xie
> Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
> Mobile: +86-15810805877
> Homepage: http://www.yihui.name
> School of Statistics, Room 1037, Mingde Main Building,
> Renmin University of China, Beijing, 100872, China
>
> __
> 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] Floating point precision / guard digits? (PR#13771)
Dear Stavros, Thank you for your fast reply! So if I request a calculation of "0.3-0.1-0.1-0.1" and I do not get 0, that is not an issue of rounding / underflow (or whatever the correct technical term would be for that behaviour)? I thought that guard digits would mean that 0.3-0.1*31 should be calculated in higher precision than the final representation of the result, i.e., avoiding that this is not equal to 0? I am sorry if I am not from the field and although I have had some basic background in numerics that has been more than a decade ago. If you can suggest an online resource to help me use the right vocabulary and better understand the fundamental concepts, I am of course grateful. Best regards, David. 2009/6/20 Stavros Macrakis : > a) this is not a bug, so this is the wrong list > > b) 'underflow' does not mean what you think it means. > > c) guard digits and sticky bits do improve rounding behavior, but > floating point will always remain approximate. > > d) if it is important to your application to perform exact arithmetic > on rational numbers (and I suspect it is not), you might want to use > that instead of floating-point. But even if implemented in R, most R > calculations cannot use it. > > You may want to study up on floating-point arithmetic some more, though. > > -s > > On 6/19/09, rbug...@kreil.org wrote: >> Full_Name: D Kreil >> Version: 2.8.1 and 2.9.0 >> OS: Debian Linux >> Submission from: (NULL) (141.244.140.179) >> >> >> Group: Accuracy >> >> I understand that most floating point numbers are approximated due to their >> binary storage. On the other hand, I thought that modern math CPUs used >> guard >> digits to protect against trivial underflows. Not true? >> >> # integers, no problem >>> 1+1+1==3 >> [1] TRUE >> # binary floating point approximation underflows >>> .1+.1+.1==.3 >> [1] FALSE >>> .1+.1+.1==.3 >> [1] FALSE >> # binary floating point exact for certain numbers >>> .1+.1==.2 >> [1] TRUE >> >> I know that safe code should not test for quality of floats. Still, is R >> underutilizing the power of the underlying hardware? >> >> Grateful for comments, >> David. >> >> __ >> 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
[Rd] Flag '#' in sprintf() format string "%#x"?
Hi, this is a bit of FYI, but also a question.
Is flag '#' in sprintf() format string "%#x" fully supported across
platforms? Can that be assumed? I discovered thanks to the r-forge
service, that this was not the case for OSX with "R version 2.9.0
Under development (unstable) (2009-01-13 r47593)", where R CMD check
reports the following:
Error in sprintf("%#x", values) :
use format %d, %i, %x or %X for integer objects
where values <- as.integer(1:5). Note it works well on other
platforms; I don't know about newer R version on OSX. Should I
consider this a glitch in an old version of R (newer R version do a
much better validation here), or should I simply avoid '#'?
Thanks,
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Flag '#' in sprintf() format string "%#x"?
On Jun 20, 2009, at 5:44 PM, Henrik Bengtsson wrote:
Hi, this is a bit of FYI, but also a question.
Is flag '#' in sprintf() format string "%#x" fully supported across
platforms? Can that be assumed? I discovered thanks to the r-forge
service, that this was not the case for OSX with "R version 2.9.0
Under development (unstable) (2009-01-13 r47593)", where R CMD check
reports the following:
Error in sprintf("%#x", values) :
use format %d, %i, %x or %X for integer objects
where values <- as.integer(1:5). Note it works well on other
platforms; I don't know about newer R version on OSX. Should I
consider this a glitch in an old version of R (newer R version do a
much better validation here), or should I simply avoid '#'?
Thanks,
/Henrik
Henrik,
Using:
R version 2.9.0 Patched (2009-06-05 r48712)
on a fully updated OSX 10.5.7 MacBook Pro:
values <- 1:5
> sprintf("%#x", values)
[1] "0x1" "0x2" "0x3" "0x4" "0x5"
Note that the as.integer() is not needed, as ':' will return integers
if both from and to values are integers:
> str(values)
int [1:5] 1 2 3 4 5
The only comment that I see in NEWS that may be relevant here for
2.9.0 is:
o sprintf() does stricter error checking on input formats to
avoid passing invalid formats to the OS (which have a tendency
to crash under such inputs).
HTH,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Special characters in Rd example section will cause errors
On 20/06/2009 10:18 AM, Yihui Xie wrote:
Hi (Duncan?),
The other day I noticed some characters will cause errors in R CMD
CHECK because of parse_Rd(), and AFAIK, these chars include '%', '{'
and '}'. For example, note the comments in the example section:
This is documented in the reference on the parse_Rd man page. Since
yesterday, that document is slightly out of date for R-devel, but it is
intended to be correct for 2.9.x. If you notice any behaviour there
that contradicts the documentation I'd consider it a bug, either in the
behaviour or the docs. I'd like to hear about both. But I don't think
what you say below contradicts the documented behaviour.
Duncan Murdoch
%~~~%
\name{testfun}
\Rdversion{1.1}
\alias{testfun}
\title{
A Test
}
\description{
A test
}
\usage{
testfun()
}
\value{
NULL
}
\author{
Yihui Xie
}
\examples{
# special characters in comments
# what if a bracket '{' here?
}
\keyword{ misc }
%~~~%
## error occurs
tools:::parse_Rd('testfun.Rd')
Error in tools:::parse_Rd("testfun.Rd") :
testfun.Rd:23:1: unexpected section header
23: }
24: \keyword
^
If I remove the '{', the Rd file can be parsed successfully. When you
put a code line with "%" in it, there will also be an error, e.g. you
put this in the example section
sprintf("%s", letters[1])
and you'll get
tools:::parse_Rd('testfun.Rd')
Error in tools:::parse_Rd("testfun.Rd") :
Unexpected end of input (in " quoted string opened at testfun.Rd:23:10)
In addition: Warning message:
In tools:::parse_Rd("testfun.Rd") :
newline within quoted string at testfun.Rd:24
Rd_parse() will parse the Rd file incorrectly either.
tools:::Rd_parse('testfun.Rd')
$meta
$meta$aliases
[1] "testfun"
$meta$concepts
character(0)
$meta$keywords
[1] "misc"
$meta$doc_type
character(0)
$meta$encoding
character(0)
$data
valstags
1 testfunname
2 1.1 Rdversion
3 \nA Test\n title
4 \nA test\n description
5 \ntestfun()\n usage
6\nNULL\n value
7 \nYihui Xie\n author
8 \n# special characters in comments\n# what if 'examples
$rest
examples
"'? or ''\n\n}\n"
Here is my session info:
sessionInfo()
R version 2.9.0 (2009-04-17)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.
1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 9.0
year 2009
month 04
day17
svn rev48333
language R
version.string R version 2.9.0 (2009-04-17)
Regards,
Yihui
--
Yihui Xie
Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
Mobile: +86-15810805877
Homepage: http://www.yihui.name
School of Statistics, Room 1037, Mingde Main Building,
Renmin University of China, Beijing, 100872, China
__
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
