Maths constants
in [Fortran]
|
From: glen herrmannsfeldt on 22 Jan 2010 03:20 Giorgio Pastore <pastgio(a)units.it> wrote: (snip) > 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. In Fortran 66 the ISIGN, SIGN, and DSIGN intrinsic functions were described as "transfer of sign". Since Fortran originated on (and still allows for) machines using sign magnitude representation for integers, (and popular for floating point) a bit copy operation makes a convenient implementation. A practice commonly used, but not standard, was finally added. Note that the description of SIGN does not say 'compare' so there is no contradiction with the requirement that +0. and -0. compare equal. > 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. At least some SQRT routines I know of return the argument in the case that it is zero. Negative zero would then be returned. -- glen
From: Arjen Markus on 22 Jan 2010 05:12 On 22 jan, 07:52, Giorgio Pastore <past...(a)units.it> wrote: > 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 IIRC, the distinction between positive and negative zeros is introduced by the IEEE standard and the rationale for the distinction is that functions like SQRT(), when viewed in the complex plane, require that one pays attention to the cut they introduce. So: ! negzero.f90 -- ! Try the SQRT() of a complex number with negative zero as the ! imaginary part ! program negzero complex :: x, y x = (-1.0,-0.0) y = (-1.0,0.0) write(*,*) x, sqrt(x) write(*,*) y, sqrt(y) end program negzero gives two different values: i and -i Regards, Arjen
From: robin on 22 Jan 2010 08:03 "Clive Page" <junk(a)nospam.net> wrote in message news:cNPO6jFYeCWLJwdD(a)no.domain.com... | In message <hj91lf$pd6$1(a)naig.caltech.edu>, glen herrmannsfeldt | <gah(a)ugcs.caltech.edu> writes | >I still remember when I was in high school and a friend got a | >brand new HP-55 calculator. (You can figure out how long ago that | >was, if you want to.) One that I tried on it was sin(9.999999999e99) | >in degree mode, finding that the answer was not zero. My friend | >was not convinced that was wrong, trusting in HP to always give | >the right answer. Assuming that the digits past the last nine are | >all zeros, the value is obviously a multiple of 360, and the sine | >should be zero. | | I still use my HP calculator, model 11C, and just tried the same thing. | It returns exactly zero for sin(9.999999999e99) and exactly one for cos | of it, so full marks to HP in programming their later models. | | If only the same standards if quality prevailed in their printer | division... I still use an HP 500C. The Kyocera died years ago, stripping its gears, after a short life. That HP 500C is now 15 years old.
From: robin on 22 Jan 2010 08:03 "Clive Page" <junk(a)nospam.net> wrote in message news:cNPO6jFYeCWLJwdD(a)no.domain.com... | | I still use my HP calculator, model 11C, and just tried the same thing. | It returns exactly zero for sin(9.999999999e99) and exactly one for cos | of it, so full marks to HP in programming their later models. That's better than a certain Fortran compiler, which fails. Does yours?
From: Dr Ivan D. Reid on 22 Jan 2010 15:11
On Fri, 22 Jan 2010 13:03:25 GMT, robin <robin_v(a)bigpond.com> wrote in <xmh6n.2735$pv.1095(a)news-server.bigpond.net.au>: > I still use an HP 500C. > The Kyocera died years ago, stripping its gears, after a short life. > That HP 500C is now 15 years old. I recently revived my [(hp)] HP-21, by buying a pack of two NiMH AA batteries at Poundland[1] and slotting them into the battery holder in place of the original NiCds. Works fine except the 2 key is a bit reluctant to register. I bought it second hand (with a US power-supply switchable between 115 and 230 V, and US pins, so I use a UK razor adaptor) when I was doing my PhD -- about 1975. [1] No, don't ask how much they cost... -- Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration, Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN KotPT -- "for stupidity above and beyond the call of duty". |