Maths constants
in [Fortran]
|
From: James Van Buskirk on 22 Jan 2010 21:09 "Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message news:ron-shepard-E3EBB7.18545622012010(a)news60.forteinc.com... > The exact derivative of COS(theta) for > theta=PI/2 is zero, so it is a second-order function in that > neighborhood. [?] (d/d theta)(COS(theta)) = -SIN(theta) -SIN(PI/2) = -1. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: glen herrmannsfeldt on 22 Jan 2010 21:27 Dr Ivan D. Reid <Ivan.Reid(a)brunel.ac.uk> wrote: (snip) > Close. Isopropanol, or iso-propyl alcohol. Used as swabs before > injections, etc, etc. I thought you guys called it rubbing alcohol, but my > Chambers suggests rubbing alcohol is methylated spirits (denatured ethanol); > maybe there's a transAtlantic schism there. You can get both denatured ethanol and isopropanol, usually 70%, as rubbing alcohol in the US, with isopropanol somewhat easier to find. Also, I see more and more 99% isopropanol. -- glen
From: glen herrmannsfeldt on 22 Jan 2010 21:53 Richard Maine <nospam(a)see.signature> wrote: (snip) > Seems to me that the necessity for special-casing illustrates the point. > I presume this means that if someone implements it without such > special-casing, the value is likely to be inaccurate. The documentation for the current glibc2 mentions using acos(-1), so it might be special cased just for that reason. Among the nice properties of many functions is that they be not too discontinuous in places where the mathematical function isn't, and that they be monatonic in places where the mathematical function is. As it is difficult to get a polynomial expansion to work over the full range, it is usual to use identities and transform the input (as I explained previously). In that case, the library designer should be careful at the crossover points, but also it is more likely that values like atan(1) and acos(-1) are the origin of a series expansion. The one I wonder more about is CORDIC, which might have very different properties than polynomial expansions. > No, I haven't run into concrete examples of this one failing. Of course, > that's partly because I don't use it, so I wouldn't have run into such > failures in any case. (snip) > Although I don't use the trig functions methods for pi myself, I thought > that the 4*atan(1) method mentioned elsethread was more the "usual" one > to use. That is at a numerically "nice" point in the atan curve. From the same library where I previously posted the ACOS comments: * ARCTANGENT FUNCTION (SHORT) * 1. REDUCE THE CASE TO THE 1ST OCTANT BY USING * ATAN(-X)=-ATAN(X), ATAN(1/X)=PI/2-ATAN(X). * 2. REDUCE FURTHER TO THE CASE /X/ LESS THAN TAN(PI/12) * BY ATAN(X)=PI/6+ATAN((X*SQRT3-1)/(X+SQRT3). * 3. FOR THE BASIC RANGE (X LESS THAN TAN(PI/12)), USE * A FRACTIONAL APPROXIMATION. In this case, it looks like ATAN(1.) will come out as PI/6+ATAN((SQRT3-1)/(SQRT3+1)) so at the end of the polynomial, not at the expansion point. If the function is continuous that should be close to PI/12, and PI/6+PI/12 should be close to PI/4, but, it seems to me, less likely than the PI/2+PI/2 of ACOS(-1.) This is, of course, just one library. I should probably look at glibc2. -- glen
From: James Van Buskirk on 22 Jan 2010 23:10 "Giorgio Pastore" <pastgio(a)units.it> wrote in message news:4b57a0e3$0$1144$4fafbaef(a)reader1.news.tin.it... > Nobody is asking you to try different compilers or to have kept records > from the past. I was just asking if you ever had *direct experience* of > inaccurate pi from acos(-1.0). I was trying to create an example but failed: C:\gfortran\clf\sqrt_challenge>type acos_challenge.f90 program acos_challenge implicit none call sub1(0.0) call sub1(-0.0) end program acos_challenge subroutine sub1(x) implicit none real x complex y complex z y = cmplx(-1.0,x) write(*,*) 'y = ', y z = acos(y) write(*,*) 'z = ', z end subroutine sub1 C:\gfortran\clf\sqrt_challenge>gfortran acos_challenge.f90 -oacos_challenge C:\gfortran\clf\sqrt_challenge>acos_challenge y = ( -1.0000000 , 0.0000000 ) z = ( 3.1415927 , -0.0000000 ) y = ( -1.0000000 , -0.0000000 ) z = ( 3.1415927 , -0.0000000 ) But I found it interesting that the same compiler (actually runtime library) crashed when confronted with a nearby value: C:\gfortran\clf\sqrt_challenge>type acos_challenge1.f90 program acos_challenge implicit none call sub1(0.0) call sub1(-0.0) write(*,*) cos((3.1415927,4.88281250E-04)) end program acos_challenge subroutine sub1(x) implicit none real x complex y complex z y = cmplx(nearest(-1.0,-1.0),x) write(*,*) 'y = ', y z = acos(y) write(*,*) 'z = ', z end subroutine sub1 C:\gfortran\clf\sqrt_challenge>gfortran acos_challenge1.f90 -oacos_challenge1 C:\gfortran\clf\sqrt_challenge>acos_challenge1 y = ( -1.0000001 , 0.0000000 ) z = ( NaN, -0.0000000 ) y = ( -1.0000001 , -0.0000000 ) z = ( NaN, -0.0000000 ) ( -1.0000001 , 4.26869061E-11) -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: Ron Shepard on 22 Jan 2010 23:14
In article <hjdlpo$4qb$1(a)news.eternal-september.org>, "James Van Buskirk" <not_valid(a)comcast.net> wrote: > "Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message > news:ron-shepard-E3EBB7.18545622012010(a)news60.forteinc.com... > > > The exact derivative of COS(theta) for > > theta=PI/2 is zero, so it is a second-order function in that > > neighborhood. > > [?] > (d/d theta)(COS(theta)) = -SIN(theta) > -SIN(PI/2) = -1. Yes, this is right. What the heck was I thinking? The rest of my post, about rounding modes, I think does apply to this discussion. $.02 -Ron Shepard |