Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi
> Ei-ji Nakama > on Thu, 1 Dec 2016 14:39:55 +0900 writes: > Hi, > i try sin, cos, and tan. >> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi) > [1] 0.5444181 0.8388140 1.5407532 > However, *pi results the following >> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45) > [1] 1 0 0 > Please try whether the following becomes all right. [..] Yes, it does -- the fix will be in all future versions of R. Thank you very much Ei-ji Nakama, for this valuable contribution to make R better! Martin Maechler, ETH Zurich > -- > Best Regards, > -- > Eiji NAKAMA > "\u4e2d\u9593\u6804\u6cbb" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi
> Martin Maechler > on Thu, 1 Dec 2016 09:36:10 +0100 writes: > Ei-ji Nakama > on Thu, 1 Dec 2016 14:39:55 +0900 writes: >> Hi, >> i try sin, cos, and tan. >>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi) >> [1] 0.5444181 0.8388140 1.5407532 >> However, *pi results the following >>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45) >> [1] 1 0 0 >> Please try whether the following becomes all right. > [..] > Yes, it does -- the fix will be in all future versions of R. oops not so quickly, Martin! Of course, the results then coincide, by sheer implementation. *BUT* it is not at all clear which of the two results is better; e.g., if you replace '1.23' by '1' in the above examples, the result of the unchnaged *pi() functions is 100% accurate, whereas R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi)) [1] -0.8847035 -0.4661541 0.5269043 is "garbage". After all, 1e45 is an even integer and so, the (2pi)-periodic functions should give the same as for 0 which *is* (1, 0, 0). For such very large arguments, the results of all of sin() , cos() and tan() are in some sense "random garbage" by necessity: Such large numbers have zero information about the resolution modulo [0, 2pi) or (-pi, pi] and hence any (non-trivial) periodic function with such a "small" period can only return "random noise". > Thank you very much Ei-ji Nakama, for this valuable contribution > to make R better! That is still true! It raises the issue to all of us and will improve the documentation at least! At the moment, I'm not sure where we should go. Of course, I could start experiments using my own 'Rmpfr' package where I can (with increasing computational effort!) get correct values (for increasingly larger arguments) but at the moment, I don't see how this would help. Martin > Martin Maechler, > ETH Zurich >> -- >> Best Regards, >> -- >> Eiji NAKAMA >> "\u4e2d\u9593\u6804\u6cbb" > __ > 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] Different results for cos,sin,tan and cospi,sinpi,tanpi
Please note that you need to report your platforms (as per the posting
guide), as the C function starts
#ifdef HAVE_COSPI
#elif defined HAVE___COSPI
double cospi(double x) {
return __cospi(x);
}
And AFAICS the system versions on Solaris and OS X behave the same way
as R's substitute.
On 01/12/2016 09:12, Martin Maechler wrote:
Martin Maechler
on Thu, 1 Dec 2016 09:36:10 +0100 writes:
Ei-ji Nakama
on Thu, 1 Dec 2016 14:39:55 +0900 writes:
>> Hi,
>> i try sin, cos, and tan.
>>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
>> [1] 0.5444181 0.8388140 1.5407532
>> However, *pi results the following
>>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
>> [1] 1 0 0
>> Please try whether the following becomes all right.
> [..]
> Yes, it does -- the fix will be in all future versions of R.
oops not so quickly, Martin!
Of course, the results then coincide, by sheer implementation.
*BUT* it is not at all clear which of the two results is better;
e.g., if you replace '1.23' by '1' in the above examples, the
result of the unchnaged *pi() functions is 100% accurate,
whereas
R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi))
[1] -0.8847035 -0.4661541 0.5269043
is "garbage". After all, 1e45 is an even integer and so, the
(2pi)-periodic functions should give the same as for 0 which
*is* (1, 0, 0).
For such very large arguments, the results of all of sin() ,
cos() and tan() are in some sense "random garbage" by
necessity:
Such large numbers have zero information about the resolution modulo
[0, 2pi) or (-pi, pi] and hence any (non-trivial) periodic
function with such a "small" period can only return "random noise".
> Thank you very much Ei-ji Nakama, for this valuable contribution
> to make R better!
That is still true! It raises the issue to all of us and will
improve the documentation at least!
At the moment, I'm not sure where we should go.
Of course, I could start experiments using my own 'Rmpfr'
package where I can (with increasing computational effort!) get
correct values (for increasingly larger arguments) but at the
moment, I don't see how this would help.
Martin
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with normalizePath()
> Evan Cortens
> on Wed, 30 Nov 2016 09:58:59 -0700 writes:
> I found this as well. At our institution, our home directories are on
> network shares that are mapped to local drives. The default, it appears,
is
> to set the location for libraries (etc) to the network share name
> (//computer//share/director/a/b/user) rather than the local drive mapping
> (H:/). Given the issue with dir.create(), this means it's impossible to
> install packages (since it tries to "create" the share, not the highest
> directory). This can be fixed in the same way Michael found, namely, set
> the environment variables to use the local mapping rather than the network
> share. But ideally, the fix would be to treat Windows network paths
> correctly.
Yes, and why shouldn't Microsoft be the institution who can best
judge how to do that, now that they sell a "Microsoft R" ??
!??!?!??!?!??!?
(trying again with BCC; next time, I'll use CC).
(a slowly increasingly frustrated)
Martin Maechler
ETH Zurich
> Best,
> Evan
> On Wed, Nov 30, 2016 at 7:16 AM, Laviolette, Michael <
> michael.laviole...@dhhs.nh.gov> wrote:
>> In researching another issue, I discovered a workaround: the network
drive
>> folder needs to be mapped to the local PC.
>>
>> setwd("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/Michael Laviolette/Stat
>> tools")
>> df1 <- readxl::read_excel("addrlist-4-MikeL.xls", 2)
>> # fails, throws same error
>> df2 <- readxl::read_excel("Z:/Stat tools/addrlist-4-MikeL.xls", 2) #
>> works
>>
>> -Original Message-
>> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
>> Sent: Friday, November 18, 2016 3:37 PM
>> To: Evan Cortens
>> Cc: Laviolette, Michael; r-devel@r-project.org
>> Subject: Re: [Rd] problem with normalizePath()
>>
>> > Evan Cortens
>> > on Thu, 17 Nov 2016 15:51:03 -0700 writes:
>>
>> > I wonder if this could be related to the issue that I
>> > submitted to bugzilla about two months ago? (
>> > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17159)
>>
>> > That is to say, could it be that it's treating the first
>> > path after the single backslash as an actual directory,
>> > rather than as the name of the share?
>>
>> > --
>> > Evan Cortens, PhD Institutional Analyst - Office of
>> > Institutional Analysis Mount Royal University 403-440-6529
>>
>> Could well be. Thank you, Evan, also for your bug report including patch
>> proposal.
>>
>> In such situations we (R core) would be really happy if Microsoft showed
>> another facet of their investment into R:
>> Ideally there should be enough staff who can judge and test such bugs and
>> bug fixes?
>>
--> I'm BCC'ing this to one place at least.
>>
>> Best,
>> Martin Maechler ETH Zurich
>>
>> > On Thu, Nov 17, 2016 at 2:28 PM, Laviolette, Michael <
>> > michael.laviole...@dhhs.nh.gov> wrote:
>>
>> >> The packages "readxl" and "haven" (and possibly others)
>> >> no longer access files on shared network drives. The
>> >> problem appears to be in the normalizePath()
>> >> function. The file can be read from a local drive or by
>> >> functions that don't call normalizePath(). The error
>> >> thrown is
>> >>
>> >> Error:
>> >> path[1]="\\Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls":
>> >> The system cannot find the file specified
>> >>
>> >> Here's my session:
>> >>
>> >> library(readxl) library(XLConnect)
>> >>
>> >> # attempting to read file from network drive df1 <-
>> >> read_excel("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls")
>> >> # pathname is fully qualified, but error thrown as above
>> >>
>> >> cat(normalizePath("//Hzndhhsvf2/data/OCPH/EPI/BHSDM/Group/17.xls"))
>> >> # throws same error
>> >>
>> >> # reading same file with different function df2 <-
>> >> readWorksheetFromFile("//Hzndhhsvf2/data/OCPH/EPI/
>> BHSDM/Group/17.xls",
>> >> 1) # completes successfully
>> >>
>> >> # reading same file from local drive df3 <-
>> >> read_excel("C:/17.xls") # completes successfully
>> >>
>> >> sessionInfo() R version 3.3.2 (2016-10-31) Platform:
>> >> x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7
>> >> x64 (build 7601) Service Pack 1
>> >>
>> >> locale: [1] LC_COLLATE=English_United States.1252
>> >> LC_CTYPE=English_United States.1252 [3]
>> >> LC_MONETARY=English_United States.1252 LC_NUMERIC=C [5]
>> >> LC_TIME=English_United States.1252
>> >>
>> >> attached base packages: [1] stats graphics grDevices
>> >> utils datasets methods base
>> >>
>> >> other attached packages: [1] readxl_0.1.1 dplyr_0.5.0
>> >> XLConnect_0.2-12 [4] XLConnectJars_0.2-12 ROracle_1.2-1
>> >> DBI_
Re: [Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi
hi,
my environment...
> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)
locale:
[1] LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC=C
[3] LC_TIME=ja_JP.UTF-8LC_COLLATE=ja_JP.UTF-8
[5] LC_MONETARY=ja_JP.UTF-8LC_MESSAGES=ja_JP.UTF-8
[7] LC_PAPER=ja_JP.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=ja_JP.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
It's not a very good example...
f0<-function(x,y)exp(complex(real=x,imag=y))
f1<-function(x,y)complex(real=exp(1)^x*cos(y),imag=exp(1)^x*sin(y))
f2<-function(x,y)complex(real=exp(1)^x*cospi(y/pi),imag=exp(1)^x*sinpi(y/pi))
f0(700,1.23)
f1(700,1.23)
f2(700,1.23)
f0(700,1.23e23)
f1(700,1.23e23)
f2(700,1.23e23)
Garbage number is required.
Thank you!
2016-12-01 18:31 GMT+09:00 Prof Brian Ripley :
> Please note that you need to report your platforms (as per the posting
> guide), as the C function starts
>
> #ifdef HAVE_COSPI
> #elif defined HAVE___COSPI
> double cospi(double x) {
> return __cospi(x);
> }
>
> And AFAICS the system versions on Solaris and OS X behave the same way as
> R's substitute.
>
>
>
>
> On 01/12/2016 09:12, Martin Maechler wrote:
>>>
>>> Martin Maechler
>>> on Thu, 1 Dec 2016 09:36:10 +0100 writes:
>>
>>
>>> Ei-ji Nakama
>>> on Thu, 1 Dec 2016 14:39:55 +0900 writes:
>>
>>
>> >> Hi,
>> >> i try sin, cos, and tan.
>>
>> >>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
>> >> [1] 0.5444181 0.8388140 1.5407532
>>
>> >> However, *pi results the following
>>
>> >>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
>> >> [1] 1 0 0
>>
>> >> Please try whether the following becomes all right.
>>
>> > [..]
>>
>> > Yes, it does -- the fix will be in all future versions of R.
>>
>> oops not so quickly, Martin!
>>
>> Of course, the results then coincide, by sheer implementation.
>>
>> *BUT* it is not at all clear which of the two results is better;
>> e.g., if you replace '1.23' by '1' in the above examples, the
>> result of the unchnaged *pi() functions is 100% accurate,
>> whereas
>>
>> R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi))
>> [1] -0.8847035 -0.4661541 0.5269043
>>
>> is "garbage". After all, 1e45 is an even integer and so, the
>> (2pi)-periodic functions should give the same as for 0 which
>> *is* (1, 0, 0).
>>
>> For such very large arguments, the results of all of sin() ,
>> cos() and tan() are in some sense "random garbage" by
>> necessity:
>> Such large numbers have zero information about the resolution modulo
>> [0, 2pi) or (-pi, pi] and hence any (non-trivial) periodic
>> function with such a "small" period can only return "random noise".
>>
>>
>> > Thank you very much Ei-ji Nakama, for this valuable contribution
>> > to make R better!
>>
>> That is still true! It raises the issue to all of us and will
>> improve the documentation at least!
>>
>> At the moment, I'm not sure where we should go.
>> Of course, I could start experiments using my own 'Rmpfr'
>> package where I can (with increasing computational effort!) get
>> correct values (for increasingly larger arguments) but at the
>> moment, I don't see how this would help.
>>
>> Martin
>
>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
--
Best Regards,
--
Eiji NAKAMA
"\u4e2d\u9593\u6804\u6cbb"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
