Maths constants
in [Fortran]
|
From: Luka Djigas on 21 Jan 2010 19:49 On Thu, 21 Jan 2010 19:14:45 +0000 (UTC), glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >robin <robin_v(a)bigpond.com> wrote: >(snip) > >> So, constants aren't? >> Since when did pi change? > >I suppose you never read Carl Sagan's book "Contact" where >it seems that pi can change. > >-- glen That last sentence reminds me of : <copy paste> -----Direct Quote from the Fortran manual for Xerox computers The primary purpose of the DATA statement is to give names to constants; instead of referring to PI as 3.141592653589797, at every appearance, the variable PI can be given that value with a DATA statement, and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of PI change. </copy paste> I don't know if it really was printed, or was it an internet joke but always found it funny. -- Luka
From: Gordon Sande on 21 Jan 2010 21:05 On 2010-01-21 20:49:26 -0400, Luka Djigas <ldigas@___gmail___.com> said: > On Thu, 21 Jan 2010 19:14:45 +0000 (UTC), glen herrmannsfeldt > <gah(a)ugcs.caltech.edu> wrote: > >> robin <robin_v(a)bigpond.com> wrote: >> (snip) >> >>> So, constants aren't? >>> Since when did pi change? >> >> I suppose you never read Carl Sagan's book "Contact" where >> it seems that pi can change. >> >> -- glen > > > That last sentence reminds me of : > > <copy paste> > -----Direct Quote from the Fortran manual for Xerox computers > > The primary purpose of the DATA statement is to give names to > constants; > instead of referring to PI as 3.141592653589797, at every appearance, > the variable PI can be given that value with a DATA statement, and > used instead of the longer form of the constant. This also simplifies > modifying the program, should the value of PI change. > </copy paste> > > I don't know if it really was printed, or was it an internet joke but > always found it funny. > > -- Luka Rather standard mathematical style joke. One often "hears" of things derived by diferentiating wrt 2 or some other constant. Theoretical physics often varies h, c, etc in the same way. Particularly after thay have been set to 1!
From: James Van Buskirk on 21 Jan 2010 21:50 "Giorgio Pastore" <pastgio(a)units.it> wrote in message news:4b58ef70$0$1132$4fafbaef(a)reader1.news.tin.it... > So, I guess you think that the value returned by sqrt(0.0) is also an > issue. Am I wrong? But did you have even one single exerience of sqrt(0.0) > returning something different from zero ? Again, I am looking for real > cases, not theory about what could happen. Firstly, let me point out that I am on the side of initialization expressions vs. literals. That said, C:\gfortran\clf\sqrt_challenge>type sqrt_challenge.f90 program sqrt_challenge implicit none call sub3(0.0) call sub2(0.0) end program sqrt_challenge subroutine sub1(x) implicit none real x real y y = sign(1.0,x) write(*,*) 'y = ', y end subroutine sub1 subroutine sub2(x) implicit none real x real y y = -x call sub3(y) end subroutine sub2 subroutine sub3(x) implicit none real x real y write(*,*) 'x = ', x y = sqrt(x) call sub1(y) end subroutine sub3 C:\gfortran\clf\sqrt_challenge>gfortran sqrt_challenge.f90 -osqrt_challenge C:\gfortran\clf\sqrt_challenge>sqrt_challenge x = 0.0000000 y = 1.0000000 x = -0.0000000 y = -1.0000000 -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: Giorgio Pastore on 22 Jan 2010 01:52 James Van Buskirk wrote: .... > Firstly, let me point out that I am on the side of initialization > expressions vs. literals. I am not arguing against that practice. :-) >That said, > > C:\gfortran\clf\sqrt_challenge>type sqrt_challenge.f90 .... Interesting. But in my opinion, it is just exploiting the gray zone between two things: 1. the fact that the standard does introduce a distinction between +0.0 or -0.0 when such values are the second argument of the sign function. 2. the apparenty opposite view of the sqrt root implementation considering +0.0 and -0.0 equivalent. I find interesting that point 1 (for which I can just imagine some good reason, since it is explicitely stated in the standard definition of the sign function behavior) is in clear logical contradiction with the IEEE standard requirement that +0.0 and -0.0 should compare equal. In my opinion, the Fortran standard behavior implicitly assigns a different meaning to the mathematical comparison. However, I cannot consider your interesting example as a case of inaccurate value of the sqrt function with 0.0 (positive zero literal constant) argument. Giorgio
From: Ron Shepard on 22 Jan 2010 02:16
In article <4b58ef70$0$1132$4fafbaef(a)reader1.news.tin.it>, Giorgio Pastore <pastgio(a)units.it> wrote: > > You would expect that the ACOS intrinsic returns one of these > > values. That is not required by the standard, of course, but that is > > a different issue. But which one is returned is still an issue. > > So, I guess you think that the value returned by sqrt(0.0) is also an > issue. Am I wrong? If you are making the argument that the constant 0.0 should be set in a program by computing sqrt(0.0), then yeah, I think that is probably not a good idea, just as ACOS(-1.0) is probably not the best way to set a constant equal to PI. Both probably work, at least in some situations and on some machines, but I don't think that is the best way to do it. > But did you have even one single exerience of > sqrt(0.0) returning something different from zero ? Again, I am looking > for real cases, not theory about what could happen. The multiple possible values of PI that you might get from ACOS(-1.0) are due to roundoff error. The multiple solutions for x*x=0.0 are due to underflow. I guess they are similar because they are both due to limitations of floating point representations, but they are different kinds of limitations. > > I find it hard to > > believe that someone has been programming for 30 years and has never > > seen this expression used for PI (or questioned why it is preferred > > over the alternatives). > > Maybe because who is programing from 30 years is used to check the > value returned by acos(-1.0). :-) Did you never even ponder why the 4.0*ATAN(1.0) expression is so common? > > In the end, I tend to use literals for these kinds of constants. > > These can be obtained to arbitrary precision from any number of > > sources. > > Ok. That is your favorite pet. I do not like it because at least a > couple of times in 30 years I had to spend one week each time to realize > that some student changed some decimal figures of pi just performing a > global change of numbers in one file :-( Ok, I can see that, but if a global substitution changed -1.0 to something else in the ACOS argument, you would also get incorrect results. Like the doctor said, "Don't do that." > In any case, I am just stating plainly my point of view, without trying > to convince you or Richard Maine that your programming style is wrong. I was just plainly explaining why ACOS(-1.0) and 2.0*ASIN(1.0) are problematic. They aren't wrong, they just introduce some unnecessary ambiguity into the process. > > I have to add that I do not understand why my original reply to Richard > Maine has raised so strong reactions. In the past, I had much better > experiences in this NG. It looks to me like it stimulated some good discussions. What more could you ask for? $.02 -Ron Shepard |