cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/06/07/15:50:26

From: rohde AT prairienet DOT org (Scott Rohde)
Subject: Linking in the math library produces peculiar results.
Newsgroups: comp.os.msdos.djgpp
Organization: Prairienet
Lines: 82
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
Message-ID: <_3K63.2422$xg.109@firefly>
Date: Mon, 07 Jun 1999 06:58:02 GMT
NNTP-Posting-Host: 192.17.3.4
X-Complaints-To: newsmgr AT prairienet DOT org
X-Trace: firefly 928738682 192.17.3.4 (Mon, 07 Jun 1999 01:58:02 CDT)
NNTP-Posting-Date: Mon, 07 Jun 1999 01:58:02 CDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

The following test program, which uses the sine function, works as
expected when compiled without the -lm option (I assume that means it
is using a definition for sin(double) in libc.a).  But with -lm, I get
very peculiar results: for the integral (but not int!) values of x
between x = 29.0 and x = 75.0, the value returned by the sine function
for one of the four angles having x for a reference angle is off in
all but eleven cases.  As far as I can tell, the other three of the
values always correspond (and seem to be correct, though I haven't
gone through and checked each one against a trig table), but the
errant value is usually not even in the ballpark.  For example, if the
results of my test program are to be believed,

	|sin(30)| = |sin(150)| = |sin(330)| = 0.5

but

	|sin(210)| = 0.362922


I get similar results from tan and cos (with appropriate changes of
signs).  I tried compiling with the -D_USE_LIBM_MATH_H, but that
doesn't seem to work either.  Also, I tried using the graphics library
to plot several cycles of the sine function--the spurious results seem
to be confined to the interval (-2pi, +2pi).

BTW, I am using a 486sx cpu--i.e., no math co-processor.  Whether or
not I link in floating point emulation with the -lemu switch makes no
difference in the program results.  But as I said before, the results
seem fine when I compile without the -lm switch, so I wouldn't think
this would be a hardware or floating-point emulation problem.  Any
clues as to what is going on here?

Here's the program I used:

#include <math.h>
#include <iostream.h>
#include <iomanip.h>
#include <float.h>

_LIB_VERSION_TYPE _LIB_VERSION = _POSIX_; // included as an after-thought
// per documentation instructions--didn't help

int bigdiff(double a, double b)
{
  double diff = a - b;
  return (diff > 0.01 || diff < -0.01);
}



double toRadians(double angle)
{
  return angle * M_PI / 180.0;
}


int main()
{
  // included as an after-thought per documentation
  // instructions ust in case it might help--it didn't:
  _clear87 ();
  _fpreset ();


  cout << "starting program" << endl;
  for (double x = 0.0; x <= 90.01; x += 1.0)
  {
    if (
	bigdiff(sin(toRadians(x)), sin(toRadians(180 - x))) ||
	bigdiff(sin(toRadians(x)), -sin(toRadians(180 + x))) ||
	bigdiff(sin(toRadians(x)), -sin(toRadians(360 - x)))
	)
    {
      cout << setw(3) << x << setw(15) << sin(toRadians(x))
	   << setw(15) << sin(toRadians(180 - x))
	   << setw(15) << sin(toRadians(180 + x))
	   << setw(15) << sin(toRadians(360 - x)) << endl;
    }
  }
  cout << "ending program" << endl;
}

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019