Fortran - WMS FORTRAN: what are SIND, COSD, etc?

Author

WMS FORTRAN: what are SIND, COSD, etc?

2005-12-05, 7:04 pm

Hi,

I'm trying to compile a VMS FORTRAN program on Linux, and the g77 says the
SIND, COSD, etc are not implemented. I thought these functions are just SIN
or COS accepting degree as argument, but is there something more complicated
so that g77 would rather not get into it???

Thanks in advance for your comments.

Owen

Jim

2005-12-05, 7:04 pm

<wob96@yahoo.com> wrote in message
news:dn2apr$95s$1@news-srv1.vanderbilt.edu...
> Hi,
>
> I'm trying to compile a VMS FORTRAN program on Linux, and the g77 says the
> SIND, COSD, etc are not implemented. I thought these functions are just
> SIN or COS accepting degree as argument, but is there something more
> complicated so that g77 would rather not get into it???
>
> Thanks in advance for your comments.
>
> Owen
>
No, they just left those functions out.
Jim

Richard Maine

2005-12-05, 7:04 pm

<wob96@yahoo.com> wrote:

> I'm trying to compile a VMS FORTRAN program on Linux, and the g77 says the
> SIND, COSD, etc are not implemented. I thought these functions are just SIN
> or COS accepting degree as argument, but is there something more complicated
> so that g77 would rather not get into it???

They aren't part of the standard. You can't generally expect things that
aren't part of the standard to be implemented everywhere. It isn't just
a matter of how hard they are. There are an infinite number of functions
that are easy to do, but aren't part of the standard.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

John Doe

2005-12-05, 7:04 pm

Jim

2005-12-05, 9:58 pm

"John Doe" <jdoe@company.com> wrote in message
news:Jr4lf.3695$ME5.752@twister.nyroc.rr.com...
> wob96@yahoo.com wrote:
>
>
> Been there, not complicated, just make your own using what you have.
>
> real function sind(x)
> sind=sin(x/180.0*3.141592)
> return
> end
Which is probably the way that the VMS folks implemented these functions.
There might be some special cases that don't need this much translation.
Jim

John Harper

2005-12-05, 9:58 pm

In article <rd6lf.23537$BZ5.5678@newssvr13.news.prodigy.com>,
Jim <j.n@nospam.com> wrote:
>
>Which is probably the way that the VMS folks implemented these functions.

Don't forget what should have been line 2:
real,intent(in) :: x
and if you want double precision don't forget 180.0d0 and a suitable
value of pi.

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

robert.corbett@sun.com

2005-12-06, 3:57 am

> Been there, not complicated, just make your own using what you have.
>
> real function sind(x)
> sind=sin(x/180.0*3.141592)
> return
> end

Often OK, but don't expect any relative accuracy for arguments near
multiples of 180 other than zero.

If accuracy near multiples of 180 counts, first reduce the argument to
the range -90 to _90. The result still won't be as good as a good
implementation of SIND, but the error will now be in the low order
bits instead of the high order bits.

Bob Corbett

Bob Corbett

robert.corbett@sun.com

2005-12-06, 3:57 am

> Which is probably the way that the VMS folks implemented these functions.
> There might be some special cases that don't need this much translation.

I doubt that DEC implemented SIND that way. No one who understood
floating-point arithmetic and cared at all about accuracy would do it
that
way.

Bob Corbett

glen herrmannsfeldt

2005-12-06, 3:57 am

Richard Maine wrote:

> <wob96@yahoo.com> wrote:

[color=darkred]
> They aren't part of the standard. You can't generally expect things that
> aren't part of the standard to be implemented everywhere. It isn't just
> a matter of how hard they are. There are an infinite number of functions
> that are easy to do, but aren't part of the standard.

VMS uses a standard calling sequence and mostly standard library for all
languages. It might be that the SIND and COSD required for PL/I and ADA
are available to other languages. They are very convenient in avoiding
the argument reduction inaccuracy that comes from multiplying by an
approximate pi or pi/180.

A google search for SIND COSD ADA reveals an ADA implementation that
multiplies by PI/180 and calls SIN or COS, removing the advantage of
proper argument reduction. Even more interesting are the available
types, Real, Double_Precision, and Real_Star_16, the latter will sound
familiar to some Fortran programmers.

-- glen

David Flower

2005-12-06, 3:57 am

wob96@yahoo.com wrote:
> Hi,
>
> I'm trying to compile a VMS FORTRAN program on Linux, and the g77 says the
> SIND, COSD, etc are not implemented. I thought these functions are just SIN
> or COS accepting degree as argument, but is there something more complicated
> so that g77 would rather not get into it???
>
> Thanks in advance for your comments.
>
> Owen

As others have explained, they are not in the standard.

Personally, I have always felt that the standard should include a
section that states something like:

The following need not be implemented to conform with the standard, but
if implemented, must mean the following...

Good examples would be:
COSD(X)
INTEGER*4 I
Procedure names ending in @ are as specified by Salford

Actually, this is not far from the truth, although examples exist; for
example, the SHARED specified in an OPEN statement is implemented
differently by DVF and Encore

Dave Flower

John Doe

2005-12-06, 7:57 am

John Harper wrote:

>In article <rd6lf.23537$BZ5.5678@newssvr13.news.prodigy.com>,
>Jim <j.n@nospam.com> wrote:
>
>
>
>Don't forget what should have been line 2:
> real,intent(in) :: x
>
>
Not sure if g77 will compile that. Also, a home brew sind function must
be declared external in g77, "sind" is reserved but not implemented.

John Doe

2005-12-06, 7:57 am

robert.corbett@sun.com wrote:

>
>Often OK, but don't expect any relative accuracy for arguments near
>multiples of 180 other than zero.
>
>If accuracy near multiples of 180 counts, first reduce the argument to
>the range -90 to _90. The result still won't be as good as a good
>implementation of SIND, but the error will now be in the low order
>bits instead of the high order bits.
>
>
>

I guess I'm missing the point here. Wouldn't the underlying sin(x)
intrinsic have similar problems for arguments near a multiple of pi ?

John Doe

2005-12-06, 7:05 pm

robert.corbett@sun.com wrote:

>
>Often OK, but don't expect any relative accuracy for arguments near
>multiples of 180 other than zero.
>
>If accuracy near multiples of 180 counts, first reduce the argument to
>the range -90 to _90. The result still won't be as good as a good
>implementation of SIND, but the error will now be in the low order
>bits instead of the high order bits.
>
>

I guess I'm missing the point here. Wouldn't the underlying sin(x)
intrinsic have similar problems for an argument near a multiple of pi ?

glen herrmannsfeldt

2005-12-06, 7:06 pm

John Doe wrote:

> robert.corbett@sun.com wrote:

(snip)

[color=darkred]
> I guess I'm missing the point here. Wouldn't the underlying sin(x)
> intrinsic have similar problems for arguments near a multiple of pi ?

Consider the low order bits of PI*1e16 and 180e16, and the results of
dividing those by PI and 180, respectively.

-- glen

Richard Maine

2005-12-06, 7:06 pm

David Flower <DavJFlower@AOL.COM> wrote:

> Personally, I have always felt that the standard should include a
> section that states something like:
>
> The following need not be implemented to conform with the standard, but
> if implemented, must mean the following...

There are several things things in the standard that are sort of like
that. Not this particular list of things, but there are several features
that the standard says are optional for a compiler to implement; the
standard just provides a standardized "spelling" for those compilers
that do implement them. Several of the intrinsics are in this category -
for example such things as the command-line stuff; those intrinsics do
have to exist, but it is optional to the processor whether they actually
do anything. And the whole of the new C interop stuff is optional.

But I say "sort of like that" because there us one big caveat. I don't
think you can effectively disallow vendors from implementing
extensions,even incompatible ones. If the vendor feels they have enough
reason to, they will do the extension and use whatever weak excuse they
can come up with to call their compiler still conforming. Defining an
optional feature in the standard certainly provides encouragement for
implementations that have the feature to do it that way, but I don't
think you'll find that can be enforced; there are too many ways around
it.

For example, the vendor could just provide a switch to turn off the
feature. Then the vendor would still hjave a pertfectly
standard-conforming compiler with one switch setting... even if it
happened to be a switch setting that was not the default and was seldom
used.

And there are some cases where vendors haven't even bothered to do the
switch. They just wave their arms and claim that the standard allows
them to do extensions, even in cases where I personally disagree. Note
that my personal claim that the compilers in question violate the
standard doesn't have a lot of effect.

One case of this is supporting a 3rd real kind without supporting the
corresponding complex. The standard (as of f90) says that the compiler
must support a complex for each real kind. The vendors in question use
the "excuse" that their support of the 3rd real kind is an extension. I
don't think that excuse holds together in that, if they call the 3rd
real kind an extension, then I think several of the intrinsics give
nonstandard results. For example, a user is supposed to be guaranteed
that selected_real_kind will return either a valid kind value (i.e. one
that can be used for complex) or a negative value; I claim that a
compiler is in violation if selected_real_kind returns a postive value
that can't be used for a complex.

So if you are happy with optional features in the standard providing
encouragement that vendors follow a specific meaning, then that can
work. That's how I think of some of the existing optional features. They
also make it relatively simple for a user to specify in a statement of
requirements ( as in "we require a compiler that implements standard
xxx, including the optional features yyy and zzz"). You don't really
have an enforceable prohibition against incompatible implementations, if
that was your intent. But you do get a stanadrdized specification and
encouragement to follow it.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Ron Shepard

2005-12-06, 7:06 pm

In article <M2hlf.57$XJ5.7@twister.nyroc.rr.com>,
John Doe <jdoe@company.com> wrote:

> I guess I'm missing the point here. Wouldn't the underlying sin(x)
> intrinsic have similar problems for an argument near a multiple of pi ?

Here is the difference. You would expect that SIND(180.) would
return exactly zero for a proper implementation of SIND(), if it
doesn't there is an error of some kind. There is no floating point
number near 3.14 where you would expect SIN(X) to return exactly
zero, and if it does, there is an error of some kind.

$.02 -Ron Shepard

Rich Townsend

2005-12-06, 7:06 pm

Ron Shepard wrote:
> In article <M2hlf.57$XJ5.7@twister.nyroc.rr.com>,
> John Doe <jdoe@company.com> wrote:
>
>
>
>
> Here is the difference. You would expect that SIND(180.) would
> return exactly zero for a proper implementation of SIND(), if it
> doesn't there is an error of some kind. There is no floating point
> number near 3.14 where you would expect SIN(X) to return exactly
> zero, and if it does, there is an error of some kind.
>

I disagree; I would be very happy if SIN(ACOS(-1.)) returns zero. Why would that
be an error?

cheers,

Rich

Gordon Sande

2005-12-06, 7:06 pm

On 2005-12-06 14:42:03 -0400, Rich Townsend <rhdt@barVOIDtol.udel.edu> said:

> Ron Shepard wrote:
>
> I disagree; I would be very happy if SIN(ACOS(-1.)) returns zero. Why
> would that be an error?
>
> cheers,
>
> Rich

Depending on where you start in the mathematics you either

define the derivative of sin ( x ) to be 1 at x = 0 and then
prove the length of the period to be some arcane transcendental
number commonly called "two pi" and the various relationships

or

define the relationships and the period of the character function
to be exactly 1 and then prove that the derivaive at zero is some
arcane transcental number commonly called "two pi".

It turns out the first is (freshman) calculus and the second in abstract
harmonic analysis. The character function is nothing other than
sin ( 2 pi x ) after all the analysis and is often what is wanted.
But many derivations are done with freshman calculus.

You have just given an arguement for the recurrance relations. If there
were a set of mathematic functions defined for period 1 (the character
function of abstract harmonic analysis) then much of this repetitive
discussion might go away.

I spent a couple summers at university doing geophyics where frequency
was measured in cycles. Actually it was period measured in many seconds
as some things happen slowly in that branch of geophysics. I also took
calculus as an undergraduate and learned the joys of radian measure.
Then I took Abstract Harmonic Analysis as a graduate student and learned
that a period of 1 was the way the creator (of the mathematics!) had
intended it.

So I learned that it sometimes takes an advanced viewpoint to make things
as simple as they should be. And radian measure is not what physical
instruements are prone to measure.

James Giles

2005-12-06, 7:06 pm

Rich Townsend wrote:
....
> I disagree; I would be very happy if SIN(ACOS(-1.)) returns zero. Why
> would that be an error?

I wouldn't be very happy with that at all. Suppose I explicitly
input a representable number that's very close to the transcendental
number pi. That number isn't pi, but it's close. The sine of that
number is not zero. In fact, it's further from zero than the smallest
representable floating-point value (by a very large margin). When
I apply SIN to that number I expect an accurate calculation of
the sine of the input value - I do *NOT* want the implementation
to guess that I must really have meant pi! It's perfectly plausible
that I didn't mean pi at all, but some value that was, in a way that's
important to my problem, explicitly different from pi.

Now, since the SIN function have no way of detecting where its
argument came from, any result of a claculation that generates that
same "nearly pi" value must return the same value for SIN as rthe
explicitly input argument did. To do otherwise complicates
numneric stability calculations intolerably. Do you really want
to have to guess about what guesses the implementation made
about your computation? Or would you rather have all operations
be well-defined and operate consistently?

On the other hand, I would expect a proper implementation of
SIND(ACOSD(-1.0)) to compare exactly equal to zero.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Ron Shepard

2005-12-07, 4:01 am

In article <dn4m3r$m8o$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

>
> I disagree; I would be very happy if SIN(ACOS(-1.)) returns zero. Why would
> that
> be an error?

ACOS(-1.) should return the floating point number that is closest to
the value of the mathematical constant PI. That floating point
value is not PI, of course, it has some error. SIN(X) should return
the floating point number that is closest to the corresponding
mathematical value. SIN(X) has a slope of -1 near X=PI, so any
deviations of X away from the exact value of PI should be reflected
in the function value. Also, floating point numbers are more
closely spaced near zero than near PI, so there is no floating point
number near PI that should result in a zero value of SIN(PI).

If you draw a graph of the possible floating point numbers near PI,
the exact SIN(X) of those numbers, and the floating point
approximations of those exact function values, this should be clear.

Of course, if you aren't talking about floating point numbers but
rather symbolic computations, then your statement would be correct.
But if X=ACOS(-1.) is a floating point number, then the most
accurate result for SIN(X) will be nonzero.

$.02 -Ron Shepard

James Van Buskirk

2005-12-07, 4:01 am

"Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message
news:ron-shepard-DCA41F.00445607122005@comcast.dca.giganews.com...

> Of course, if you aren't talking about floating point numbers but
> rather symbolic computations, then your statement would be correct.
> But if X=ACOS(-1.) is a floating point number, then the most
> accurate result for SIN(X) will be nonzero.

What I would have thought. Let's see how this stands up
in practice:

program near_pi
implicit none
real x
real eps
integer k

x = acos(-1.0)
eps = spacing(x)
do k = -5, 5
write(*,'(i2,2(1x,g14.8))') k,x+k*eps,sin(x+k*eps)
end do
end program near_pi

Output with LF95 5.70f:

-5 3.1415915 0.11046701E-05
-4 3.1415918 0.86625153E-06
-3 3.1415920 0.62783295E-06
-2 3.1415923 0.38941437E-06
-1 3.1415925 0.15099580E-06
0 3.1415927 -.87422777E-07
1 3.1415930 -.32584137E-06
2 3.1415932 -.56425995E-06
3 3.1415935 -.80267853E-06
4 3.1415937 -.10410971E-05
5 3.1415939 -.12795157E-05

Output with CVF 6.6C3:

-5 3.1415915 0.11046701E-05
-4 3.1415918 0.86625153E-06
-3 3.1415920 0.62783295E-06
-2 3.1415923 0.38941437E-06
-1 3.1415925 0.15099580E-06
0 3.1415927 -.87422777E-07
1 3.1415930 -.32584137E-06
2 3.1415932 -.56425995E-06
3 3.1415935 -.80267853E-06
4 3.1415937 -.10410971E-05
5 3.1415939 -.12795157E-05

Output with g95 gcc version 4.0.1 (g95!) Sep 1 2005:

-5 3.1415920 0.11046701E-05
-4 3.1415920 0.86625153E-06
-3 3.1415920 0.62783295E-06
-2 3.1415920 0.38941437E-06
-1 3.1415930 0.15099580E-06
0 3.1415930 -.87422777E-07
1 3.1415930 -.32584137E-06
2 3.1415930 -.56425995E-06
3 3.1415930 -.80267853E-06
4 3.1415940 -.10410971E-05
5 3.1415940 -.12795157E-05

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

David Flower

2005-12-07, 4:01 am

Richard Maine wrote:
> David Flower <DavJFlower@AOL.COM> wrote:
>
>
> There are several things things in the standard that are sort of like
> that. Not this particular list of things, but there are several features
> that the standard says are optional for a compiler to implement; the
> standard just provides a standardized "spelling" for those compilers
> that do implement them. Several of the intrinsics are in this category -
> for example such things as the command-line stuff; those intrinsics do
> have to exist, but it is optional to the processor whether they actually
> do anything. And the whole of the new C interop stuff is optional.
>
> But I say "sort of like that" because there us one big caveat. I don't
> think you can effectively disallow vendors from implementing
> extensions,even incompatible ones. If the vendor feels they have enough
> reason to, they will do the extension and use whatever weak excuse they
> can come up with to call their compiler still conforming. Defining an
> optional feature in the standard certainly provides encouragement for
> implementations that have the feature to do it that way, but I don't
> think you'll find that can be enforced; there are too many ways around
> it.
>
> For example, the vendor could just provide a switch to turn off the
> feature. Then the vendor would still hjave a pertfectly
> standard-conforming compiler with one switch setting... even if it
> happened to be a switch setting that was not the default and was seldom
> used.
>
> And there are some cases where vendors haven't even bothered to do the
> switch. They just wave their arms and claim that the standard allows
> them to do extensions, even in cases where I personally disagree. Note
> that my personal claim that the compilers in question violate the
> standard doesn't have a lot of effect.
>
> One case of this is supporting a 3rd real kind without supporting the
> corresponding complex. The standard (as of f90) says that the compiler
> must support a complex for each real kind. The vendors in question use
> the "excuse" that their support of the 3rd real kind is an extension. I
> don't think that excuse holds together in that, if they call the 3rd
> real kind an extension, then I think several of the intrinsics give
> nonstandard results. For example, a user is supposed to be guaranteed
> that selected_real_kind will return either a valid kind value (i.e. one
> that can be used for complex) or a negative value; I claim that a
> compiler is in violation if selected_real_kind returns a postive value
> that can't be used for a complex.
>
> So if you are happy with optional features in the standard providing
> encouragement that vendors follow a specific meaning, then that can
> work. That's how I think of some of the existing optional features. They
> also make it relatively simple for a user to specify in a statement of
> requirements ( as in "we require a compiler that implements standard
> xxx, including the optional features yyy and zzz"). You don't really
> have an enforceable prohibition against incompatible implementations, if
> that was your intent. But you do get a stanadrdized specification and
> encouragement to follow it.
>
> --
> Richard Maine | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle | -- Mark Twain

What I am really saying is that if I take a FORTRAN program that works
using one compiler, and compile it using a second compiler, that I am
happy if:

a) The program runs correctly

OR

b) The compiler or linker generates a fatal error message

BUT

c) The program compiles, but runs incorrectly

is totally unacceptable.

Fortunately, case (c) is rare, but it does exist; for example, the
statement:

INTEGER (KIND=4) IVAR

is treated differently by FTN95

Dave Flower

Rich Townsend

2005-12-07, 7:59 am

James Van Buskirk wrote:
> "Ron Shepard" <ron-shepard@NOSPAM.comcast.net> wrote in message
> news:ron-shepard-DCA41F.00445607122005@comcast.dca.giganews.com...
>
>
>
>
> What I would have thought. Let's see how this stands up
> in practice:
>
> program near_pi
> implicit none
> real x
> real eps
> integer k
>
> x = acos(-1.0)
> eps = spacing(x)
> do k = -5, 5
> write(*,'(i2,2(1x,g14.8))') k,x+k*eps,sin(x+k*eps)
> end do
> end program near_pi
>
> Output with LF95 5.70f:
>
> -5 3.1415915 0.11046701E-05
> -4 3.1415918 0.86625153E-06
> -3 3.1415920 0.62783295E-06
> -2 3.1415923 0.38941437E-06
> -1 3.1415925 0.15099580E-06
> 0 3.1415927 -.87422777E-07
> 1 3.1415930 -.32584137E-06
> 2 3.1415932 -.56425995E-06
> 3 3.1415935 -.80267853E-06
> 4 3.1415937 -.10410971E-05
> 5 3.1415939 -.12795157E-05
>
> Output with CVF 6.6C3:
>
> -5 3.1415915 0.11046701E-05
> -4 3.1415918 0.86625153E-06
> -3 3.1415920 0.62783295E-06
> -2 3.1415923 0.38941437E-06
> -1 3.1415925 0.15099580E-06
> 0 3.1415927 -.87422777E-07
> 1 3.1415930 -.32584137E-06
> 2 3.1415932 -.56425995E-06
> 3 3.1415935 -.80267853E-06
> 4 3.1415937 -.10410971E-05
> 5 3.1415939 -.12795157E-05
>
> Output with g95 gcc version 4.0.1 (g95!) Sep 1 2005:
>
> -5 3.1415920 0.11046701E-05
> -4 3.1415920 0.86625153E-06
> -3 3.1415920 0.62783295E-06
> -2 3.1415920 0.38941437E-06
> -1 3.1415930 0.15099580E-06
> 0 3.1415930 -.87422777E-07
> 1 3.1415930 -.32584137E-06
> 2 3.1415930 -.56425995E-06
> 3 3.1415930 -.80267853E-06
> 4 3.1415940 -.10410971E-05
> 5 3.1415940 -.12795157E-05
>

I stand suitably corrected. Thanks to all who responded.

cheers,

Rich

Richard E Maine

2005-12-07, 7:04 pm

David Flower <DavJFlower@AOL.COM> wrote:

> What I am really saying is that if I take a FORTRAN program that works
> using one compiler, and compile it using a second compiler, that I am
> happy if:
>
> a) The program runs correctly
>
> OR
>
> b) The compiler or linker generates a fatal error message
>
> BUT
>
> c) The program compiles, but runs incorrectly
>
> is totally unacceptable.

While I certainly understand the feeling, and try to work towards that
end, realize that the goal is not perfectly unachievable in practice.
You can take a list of specific features that have proven problematic,
and try to standardize the meaning of those. If the features are ones
with existing incompatible meanings, you will likely find resistance
from both vendors and users that are currently counting on meanings
different from the one you would propose to disallow (regardless of
which one that is). Sometimes such conflict can be resolved, but it
isn't easy. Odds are high that you end up with compiler switches to
support multiple behaviors (though I'll quite agree that having a switch
to get a common meaning beats not having one at all).

But this all does nothing to prevent some new extension from being given
incompatible meanings in different compilers. The only way to prevent
that would be to disallow extensions completely. That is not
realistically going to happen. It is too much at odds with what too many
people want. You can't even globally require that compilers have a
switch to enforce everything in the standard. There are too many things
where enforcement is impractical for various reasons.

There are also ways to write perfectly standard-conforming code that
compiles and gives correct results on some platforms, but wrong results
on others. Numerical instability can (and regularly does) do that. That
isn't readily solved by the Fortran standard. Well, in principle, the
standard could require that compilers all support the same floating
point format. That part has even somewhat seriously been proposed and is
sort-of half in the f2003 standard. You'd also have to pretty much
disallow all optimizations, which isn't likely to fly. What might fly
(and has been proposed) is giving the user the ability to specifically
say that optimizations are disallowed in a particular part of the code.
But this is just a way to allow a sufficiently careful user to get the
same results with different compilers; it doesn't do anything for the
user who just writes code without carefully considering the issues, and
expects it to "just work".

I guess my summary is that the stated goal is one to keep in mind. And
we can try to make progress towards it. But zero defects isn't going to
happen in this regard. There are competing goals, which will require
compromises in practice.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

James Van Buskirk

2005-12-07, 7:04 pm

"David Flower" <DavJFlower@AOL.COM> wrote in message
news:1133944192.967257.327300@o13g2000cwo.googlegroups.com...

> Fortunately, case (c) is rare, but it does exist; for example, the
> statement:

> INTEGER (KIND=4) IVAR

> is treated differently by FTN95

You seem to be holding the snippet up as a rebuke against
FTN95, but as has been repeatedly warned in this forum,
use of hardwired numbers for kind type parameters is a
disaster waiting to happen. Change the example to the
more generally approved:

INTEGER, PARAMETER :: ik8 = SELECTED_INT_KIND(9)
INTEGER (KIND=ik8) IVAR

And then see if you are still experiencing problems
with FTN95.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

John Harper

2005-12-07, 7:04 pm

In article <dn6l3v$a0i$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:[color=darkred]
>James Van Buskirk wrote:
(program and output not repeated here)

With g95 gcc version 4.0.1 (g95!) Sep 1 2005 the values of x+k*eps
written looked less accurate than with the other compilers.
With g95 gcc version 4.0.1 (g95!) Dec 6 2005 the output was the same
as with the other compilers, so it's a good idea to update g95.

--
John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

glen herrmannsfeldt

2005-12-08, 3:58 am

James Giles wrote:
> Rich Townsend wrote:
> ...
>
>
>
> I wouldn't be very happy with that at all. Suppose I explicitly
> input a representable number that's very close to the transcendental
> number pi. That number isn't pi, but it's close. The sine of that
> number is not zero. In fact, it's further from zero than the smallest
> representable floating-point value (by a very large margin). When
> I apply SIN to that number I expect an accurate calculation of
> the sine of the input value - I do *NOT* want the implementation
> to guess that I must really have meant pi! It's perfectly plausible
> that I didn't mean pi at all, but some value that was, in a way that's
> important to my problem, explicitly different from pi.

Some might want a value that is near 3.14 and has a sin() of zero.
Especially those multiplying a value by pi/180 before sending it to sin().

> Now, since the SIN function have no way of detecting where its
> argument came from, any result of a claculation that generates that
> same "nearly pi" value must return the same value for SIN as rthe
> explicitly input argument did. To do otherwise complicates
> numneric stability calculations intolerably. Do you really want
> to have to guess about what guesses the implementation made
> about your computation? Or would you rather have all operations
> be well-defined and operate consistently?

> On the other hand, I would expect a proper implementation of
> SIND(ACOSD(-1.0)) to compare exactly equal to zero.

That would be nice.

-- glen

glen herrmannsfeldt

2005-12-08, 3:58 am

Richard Maine wrote:
(snip)

> One case of this is supporting a 3rd real kind without supporting the
> corresponding complex. The standard (as of f90) says that the compiler
> must support a complex for each real kind. The vendors in question use
> the "excuse" that their support of the 3rd real kind is an extension. I
> don't think that excuse holds together in that, if they call the 3rd
> real kind an extension, then I think several of the intrinsics give
> nonstandard results. For example, a user is supposed to be guaranteed
> that selected_real_kind will return either a valid kind value (i.e. one
> that can be used for complex) or a negative value; I claim that a
> compiler is in violation if selected_real_kind returns a postive value
> that can't be used for a complex.

How about if selected_real_kind never returns that value, but if the
value is supplied directly the appropriate type is available? Then only
non-standard programs would have it available.

-- glen

Richard E Maine

2005-12-08, 7:15 pm

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine wrote:
>
>
> How about if selected_real_kind never returns that value, but if the
> value is supplied directly the appropriate type is available? Then only
> non-standard programs would have it available.

One *COULD* do things that conform to the standard; that would be one.
But that isn't very relevant to my point. I was specifically
illustrating that all compiler vendors that do not feel obligated to
strictly conform to (my interpretation of) the standard. To my knowledge
(and I admit that I haven't kept up - maybe it has been fixed), that's
not the way that all the compilers in question worked.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

kia

2005-12-08, 10:10 pm

> Rich Townsend wrote:
>
> I disagree; I would be very happy if SIN(ACOS(-1.)) returns zero. Why
> would that be an error?

To answer that you'll need to dump your mail-in diploma and start
working toward a real thing... in the meantime, here's your happy
(Kodak) moment (courtesy CVF)

external sin
data x/-1/
print*, sin(acos(x))
end
cvf: 0.0000000E+00

albeit brief, as I let you fill in the details for remastering the sin()
to match its mathematical expectations.

James Giles

2005-12-09, 4:15 am

kia wrote:
>
> To answer that you'll need to dump your mail-in diploma and start
> working toward a real thing... in the meantime, here's your happy
> (Kodak) moment (courtesy CVF)
>
> external sin
> data x/-1/
> print*, sin(acos(x))
> end
> cvf: 0.0000000E+00
>
> albeit brief, as I let you fill in the details for remastering the
> sin() to match its mathematical expectations.

Evidently you have an external function that happens to have
the same name as the SIN intrinsic. No telling what it does.
But one thing is abundantly clear about it: it clearly *doesn't*
compute the trigonometric sine of its argument. In all floating-
point implementations where CVF runs, there's no representable
number in the neighborhood of ACOS(-1.0) whose trigonometric
sine is zero - or even sufficiently close to zero to print as zero.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

kia

2005-12-10, 7:14 pm

James Giles wrote:
>
>
> Evidently you have an external function that happens to have
> the same name as the SIN intrinsic. No telling what it does.
> But one thing is abundantly clear about it: it clearly *doesn't*
> compute the trigonometric sine of its argument. In all floating-
> point implementations where CVF runs, there's no representable
> number in the neighborhood of ACOS(-1.0) whose trigonometric
> sine is zero - or even sufficiently close to zero to print as zero.

Now you need to resolve the number you see in the program output with
your speculative assertions about (pi) neighborhoods... don't know how
CVF does it, but it managed easily with but a little (CVF native) help.

And, hold your thoughts should the lights blink, let the pursuit of
(numeric) happiness keep the noise maker (& evangelists) off the air
for awhile.

Hint:
Poking around standards (& specs) won't get you there,
doing *applied* numerics might.

Rich Townsend

2005-12-10, 7:14 pm

kia wrote:
> James Giles wrote:
>
>
>
> Now you need to resolve the number you see in the program output with
> your speculative assertions about (pi) neighborhoods... don't know how
> CVF does it, but it managed easily with but a little (CVF native) help.
>
> And, hold your thoughts should the lights blink, let the pursuit of
> (numeric) happiness keep the noise maker (& evangelists) off the air
> for awhile.

If I'm the 'noise maker', then don't hold your breath. I don't debate XXXXtards
like yourself; rather, I merely draw attention to their more moronic blunders.

You're my especial favourite, Mr Voh; like the other Gimp that frequents c.l.f,
you can't go one pace without sticking your foot in your gob.

cheers,

Rich

James Giles

2005-12-10, 7:14 pm

kia wrote:
....
> Hint:
> Poking around standards (& specs) won't get you there,
> doing *applied* numerics might.

But this has nothing to do with standards. It's purely a matter
of normal arithmetic. The SIN(x) where x is *not* an integral
multiple of pi is *NOT* zero. That's just a matter of *FACT*.
There are no integral multiples of pi other than zero that can be
represented in floating point. Hence, SIN(x) for x not zero
can't be zero on a machine that uses floating point arithmetic.

Any "applied mathematician" that doesn't know that should not
be hired. And, if anyone's unfortunate enough to have such
a person on staff already, that's a sufficient sign of incompetance
to justify firing him (her). Kia is, as we all know, someone that
thinks plausible wrong answers are better than correct answers.
No one I know would hire such a person. Correctly so.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Gary L. Scott

2005-12-10, 7:14 pm

Rich Townsend wrote:

> kia wrote:
>
>
>
> If I'm the 'noise maker', then don't hold your breath. I don't debate
> XXXXtards

Oh boy, a new term...I can't wait to try it out.

> like yourself; rather, I merely draw attention to their more
> moronic blunders.
>
> You're my especial favourite, Mr Voh; like the other Gimp that frequents
> c.l.f, you can't go one pace without sticking your foot in your gob.
>
> cheers,
>
> Rich

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Richard Maine

2005-12-10, 10:10 pm

James Giles <jamesgiles@worldnet.att.net> wrote:

> someone that
> thinks plausible wrong answers are better than correct answers.
> No one I know would hire such a person. Correctly so.

While I can agree with that sentiment, no one I know would get to the
stage of looking into technical matters in this case. There are more
fundamental people skills, normally associated with kindergarden, that
would consitute a veto. I don't care how competent someone is if he or
she can't communicate civilly.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

glen herrmannsfeldt

2005-12-10, 10:10 pm

James Giles wrote:
(snip)

> But this has nothing to do with standards. It's purely a matter
> of normal arithmetic. The SIN(x) where x is *not* an integral
> multiple of pi is *NOT* zero. That's just a matter of *FACT*.
> There are no integral multiples of pi other than zero that can be
> represented in floating point. Hence, SIN(x) for x not zero
> can't be zero on a machine that uses floating point arithmetic.

> Any "applied mathematician" that doesn't know that should not
> be hired. And, if anyone's unfortunate enough to have such
> a person on staff already, that's a sufficient sign of incompetance
> to justify firing him (her). Kia is, as we all know, someone that
> thinks plausible wrong answers are better than correct answers.
> No one I know would hire such a person. Correctly so.

Applied Mathematics is pretty close to physics. (One place I know
Applied Mathematics is actually computational fluid dynamics.)
Physicists know that floating point values are approximations,
and one value is the closest approximation to pi.

I am pretty sure that for many years in the past it was usual to divide
by pi (or some integer fraction of it) as the first step in argument
reduction. It is only relatively recently that anyone would consider
using hundreds of digits of pi to approximate a number with 16 digits of
significance. It seems unlikely to me that any physicist would do that.

Not that one shouldn't try to get the last bit correct, but there is
overdoing it sometimes.

-- glen

James Giles

2005-12-10, 10:10 pm

glen herrmannsfeldt wrote:
....
> Not that one shouldn't try to get the last bit correct, but there is
> overdoing it sometimes.

But, that's no exciuse for *way* underdoing it. There is no non-
zero floating poit x for which SIN(x) is zero. To ever generate
zero for such a value is rather a large error. It's not a small
error, it's a large one.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Brooks Moses

2005-12-11, 4:10 am

James Giles wrote:
> glen herrmannsfeldt wrote:
>
> But, that's no exciuse for *way* underdoing it. There is no non-
> zero floating poit x for which SIN(x) is zero. To ever generate
> zero for such a value is rather a large error. It's not a small
> error, it's a large one.

It's an error roughly comparable to the error expected in something
like, say, (1.0d0 + 1.0d-40) - 1.0d0 -- or, more to the point, the error
expected in 4.0d0*acos(1) - 3.1415926535897932384626433832795d0. When
one explicitly subtracts one number from a nearly-equal number, one
expects errors that are large compared to the answer.

I think it's an interesting question as to why generating zero is
considered such a gross error when such subtractions are implicit in the
case of argument reduction for trigonometric functions, but are
considered perfectly acceptable in expressions like the one I gave where
the subtractions are explicit.

(I don't mean that it's a rhetorical question, mind; I mean that I'd
honestly be interested in the answer, as I don't see very convincing
arguments on either side of it yet.)

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

James Giles

2005-12-11, 4:10 am

Brooks Moses wrote:
> James Giles wrote:
....
> I think it's an interesting question as to why generating zero is
> considered such a gross error when such subtractions are implicit in
> the case of argument reduction for trigonometric functions, but are
> considered perfectly acceptable in expressions like the one I gave
> where the subtractions are explicit.

But, the argument reductions for the trig functions are not that
bad. Further, the intrinsic is just that: intrinsic. If *you* as
a programmer choose to make larger errors, then that's
your lookout. The implementation should not be permitted
such leeway. By all means, round all return values less than
1.e-8 to zero if *you* choose. there are algorithms were
such results may be more significant.

On the other hand, if you want to have trig functions where
the sine of half a circle evaluates to zero, use degrees (if
you can find implementations of the appropriate functions).
Most of the commonly used divisions of a circle are exactly
representable as degrees. No need to degrade the accuracy
of the trig functions in order to meet naive expectations.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

kia

2005-12-13, 4:13 am

James Giles wrote:
>
> There are no integral multiples of pi other than zero that can be
> represented in floating point. Hence, SIN(x) for x not zero
> can't be zero on a machine that uses floating point arithmetic.

external sin
pi = acos(-1.)
do n=0,4,2
print*, sin(n*pi)
enddo
cvf: 0.0000000E+00
0.0000000E+00
0.0000000E+00

You really should get acquainted with your compiler, and be assured the
"remastered" sin() is far removed from the "hack" you alluded to
elsewhere in the thread; there are no threshold gimmicks, just plain
native CVF ingredients. On that note, we're done - you want ketchup with
that hat?

James Giles

2005-12-13, 4:13 am

kia wrote:
> James Giles wrote:
>
> external sin
> pi = acos(-1.)
> do n=0,4,2
> print*, sin(n*pi)
> enddo
> cvf: 0.0000000E+00
> 0.0000000E+00
> 0.0000000E+00
>
> You really should get acquainted with your compiler, and be assured
> the "remastered" sin() is far removed from the "hack" you alluded to

I think the correct word is "demastered" and yews, it is a hack.
Without the External statement, CVF gives more accurate answers.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Dave Thompson

2005-12-14, 4:00 am

X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 34
Date: Wed, 14 Dec 2005 06:59:43 GMT
NNTP-Posting-Host: 12.76.8.20
X-Complaints-To: abuse@worldnet.att.net
X-Trace: bgtnsc05-news.ops.worldnet.att.net 1134543583 12.76.8.20 (Wed, 14 Dec 2005 06:59:43 GMT)
NNTP-Posting-Date: Wed, 14 Dec 2005 06:59:43 GMT
Organization: AT&T Worldnet
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:140854

On Wed, 7 Dec 2005 07:59:43 -0800, nospam@see.signature (Richard E
Maine) wrote:

> David Flower <DavJFlower@AOL.COM> wrote:

>
> While I certainly understand the feeling, and try to work towards that
> end, realize that the goal is not perfectly unachievable in practice.
> You can take a list of specific features that have proven problematic,
> and try to standardize the meaning of those. If the features are ones
> with existing incompatible meanings, you will likely find resistance
> from both vendors and users that are currently counting on meanings
> different from the one you would propose to disallow (regardless of

<ahem> You ended up with the wrong parity of negations there. </>

> which one that is). Sometimes such conflict can be resolved, but it
> isn't easy. Odds are high that you end up with compiler switches to
> support multiple behaviors (though I'll quite agree that having a switch
> to get a common meaning beats not having one at all).
>
FW(W, COBOL used to have several "modules" in the standard and
multiple "levels" of each (or at least of most). Instead of just
saying "conforms to <x>" as FORTRAN, PL/I, and (later) C and C++ did,
a COBOL system's documentation would say something like "conforms to
<x> at level 2 for the core language, level 1 for Report Writer, level
1 for Debugging" etc. I think this was originally mostly (not
entirely) to allow for implementations on (complete, room-filling)
systems that were about as powerful as today's wristwatches, and I
believe it has actually been dropped recently.
- David.Thompson1 at worldnet.att.net

Richard E Maine

2005-12-14, 9:58 pm

Dave Thompson <david.thompson1@worldnet.att.net> wrote:

> On Wed, 7 Dec 2005 07:59:43 -0800, nospam@see.signature (Richard E
> Maine) wrote:
>
>
> <ahem> You ended up with the wrong parity of negations there. </>

Oops. Yes. Or perhaps I should say that you are not wrong. :-)

I probably was editing "unachievable" to "not perfectly achievable" (in
order to soften the tone), but missed part of the edit.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links