[GRASS5] r.flow: strange compile error M_PI

Thu Jun 23 01:46:19 EDT 2005

> > > > > after an update of the Linux OS, I am no longer able to
> > > > > compile r.flow:
..
> > > > > aspect.c: In function `aspect_fly':
> > > > > aspect.c:50: error: `M_PI' undeclared (first use in this function)
> > > > > aspect.c:50: error: (Each undeclared identifier is reported only once
> > > > > aspect.c:50: error: for each function it appears in.)
> > > > > make: *** [OBJ.i686-pc-linux-gnu/aspect.o] Error 1
> > > > > 
> > > > > thuille:r.flow[282.26] cat /etc/issue
> > > > > Red Hat Enterprise Linux WS release 4 (Nahant Update 1)
> > > > > Kernel \r on an \m
> > > > > 
> > > > > It should be in math.h, right?
> > > > > How to debug such things?
> > > > 
> > > > Yes, it should be in <math.h>, but it's not defined on all systems. I
> > > > don't understand it being missing from your system, either.
> > > 
> > > Sorry, forgot to post that. Yes, it is defined:
> > > 
> > > grep M_PI /usr/include/math.h
> > > # define M_PI           3.14159265358979323846  /* pi */
> > > # define M_PI_2         1.57079632679489661923  /* pi/2 */
> > > # define M_PI_4         0.78539816339744830962  /* pi/4 */
> > > # define M_PIl          3.1415926535897932384626433832795029L  /* pi */
> > > # define M_PI_2l        1.5707963267948966192313216916397514L  /* pi/2 */
> > > # define M_PI_4l        0.7853981633974483096156608458198757L  /* pi/4 */
> > >  
> > > > Generally, I add the following to the source that uses it:
> > > > 
> > > > #ifndef M_PI
> > > > #define M_PI 3.14...
> > > > #endif
> > 
> > I believe I have found the culprit.  M_PI is not defined when specifying
> > the -ansi compiler option.
> 
> Ah! Thanks, Brad. You suggested ifndef statement is now in the
> code (with copy-paste of pi from /usr/include/math.h).
> 
> The problem seems to be solved.

we currently define PI in 31 places:

Note we sometimes use the wrong value (...3116) !

display/d.vect.chart/bar.c:#define PI  3.14159265358979323846
display/d.vect.chart/pie.c:#define PI  3.14159265358979323846
imagery/i.gensigset/subcluster.c:#define PI 3.141592654
imagery/i.smap/bouman/model.c:#define PI 3.141592654
imagery/i.zc/findzc.c:#define PI      3.141592654
lib/cdhc/dagstndn.c:#define PI 3.141592654
lib/gis/pi.h:#define PI 3.14159265358979323846
lib/ogsf/trans.c:#define NPI  3.14159265358979323846
lib/symbol/stroke.c:#define PI 3.14159265
lib/vector/Vlib/buffer.c:#define PI 3.141592653589793116
lib/vector/rtree/gammavol.c:#   define M_PI 3.1415926535
lib/vector/rtree/sphvol.c:#     define M_PI 3.1415926535
misc/m.cogo/main.c:  #define M_PI   3.14159265358979323846
ps/ps.map/vector.h:#define PI 3.14159265
raster/r.le/r.le.patch/patch.h:#define  PI    3.14159
raster/r.los/radians.h:#define          PI              3.141592654
raster/r.out.pov/main.c:#define M_PI        3.14159265358979323846
raster/r.random.cells/ransurf.h:#define PI                      3.141592653589793116
raster/r.random.surface/ransurf.h:#define PI                    3.141592653589793116
raster/r.surf.idw/pi.h:#define PI       3.14159265358979323846
raster/r.transect/parse_line.c:#define PI       3.14159265358979323846
raster/wildfire/r.spread/main.c:/*float PI = 3.14159; */
raster/wildfire/r.spread/select_linksB.c:#define PI 3.1415926535897932
raster/wildfire/r.spread/spot.c:#define PI 3.1415926535897932
raster/wildfire/r.spread/spread.c:#define PI 3.1415926535897932
vector/v.buffer/main.c:#define PI 3.141592653589793116
vector/v.in.dwg/entity.c:#define LOCPI 3.14159265358979323846
vector/v.label/main.c:#define PI    3.1415926535897932384626433832795029L
vector/v.label/.#main.c.1.6:#define PI    3.1415926535897932384626433832795029L
vector/v.label/.#main.c.1.7:#define PI    3.1415926535897932384626433832795029L
vector/v.transform/trans_digit.c:#define PI  3.141592653589793116

There was talk of this on another maling list I follow a month or so back, 
some postings from the experts over there follow. (sorry for the long 
post, but it is interesting reading if you are into this sort of thing.)

A question: do we want to be strict ANSI ISO C90 compliant or strict 
POSIX compliant? Is there any reason to be stricter than POSIX? 
i.e. gcc -ansi is good at keeping us honest, but does it go too far?

The precision of PI is actually quite important, e.g. for calculations on
decimal degrees a little error translates to something quite real on the 
ground.

Our use of floats are minimal (vs double), but we'd have to watch our 
printf()s, G_warning()s, etc if we start promoting calculations to long
doubles via M_PIl and then try to output the result.

-> include in grass6/include/gmath.h   gis.h??

#ifdef M_PIl
#define PI M_PIl
#else
#define PI M_PI
#endif

#ifndef M_PI
#define PI 3.14...
#endif

#define RAD2DEG (180.0/PI)

or some better munge of that order and then edit the above 31 flavours 
to use it consistently.

so without further ado, some cross-list eaves dropping for ya.
(with apologies & thanks to Gary, Eric, and Rob)

Hamish

===============================
From: "Gary E. Miller" <gem at rellim.com>
Subject: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 10:08:11 -0700 (PDT)
To: "Eric S. Raymond at BerliOS" <esr at sheep.berlios.de>
cc: gpsd-dev at lists.berlios.de
Sender: gpsd-dev-admin at berlios.de

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Eric!

Not a good move.

Taking the trailing L off cuts the precision by more than half.  This will
bring the acuracy of the math below the accuracy of the best GPS
measuserments.

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Wed, 18 May 2005, Eric S. Raymond at BerliOS wrote:

> Date: Wed, 18 May 2005 04:59:16 +0200
> From: Eric S. Raymond at BerliOS <esr at sheep.berlios.de>
> To: gpsd-commit-watch at lists.berlios.de
> Subject: [Gpsd-commit-watch] r2463 - trunk
>
> Author: esr
> Date: 2005-05-18 04:59:10 +0200 (Wed, 18 May 2005)
> New Revision: 2463
>
> Modified:
>    trunk/sirfmon.c
> Log:
> Wrong type on constants does wacky things.
>
>
> Modified: trunk/sirfmon.c
> ===================================================================
> --- trunk/sirfmon.c	2005-05-18 00:21:09 UTC (rev 2462)
> +++ trunk/sirfmon.c	2005-05-18 02:59:10 UTC (rev 2463)
> @@ -44,8 +44,8 @@
>
>  #define MAXCHANNELS	12
>
> -#define PI 3.1415926535897932384626433832795029L
> -#define RAD2DEG  57.2957795130823208767981548141051703L
> +#define PI 3.1415926535897932384626433832795029
> +#define RAD2DEG  57.2957795130823208767981548141051703
>
>  /* how many characters to look at when trying to find baud rate lock */
>  #define SNIFF_RETRIES	1200
>
> _______________________________________________
> Gpsd-commit-watch mailing list
> Gpsd-commit-watch at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/gpsd-commit-watch
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFCi3Z+8KZibdeR3qURAjVsAKDvu/DSWXcv3Z9+30NsIr1Z4W6U2gCgsdhM
Ct3/N1sGavc3s3YHuL12MvE=
=TbiH
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev

From: "Rob Janssen" <gpsd at xs4all.nl>
Subject: Re: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 19:20:02 +0200 (CEST)
To: gpsd-dev at lists.berlios.de
Sender: gpsd-dev-admin at berlios.de

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yo Eric!
>
> Not a good move.
>
> Taking the trailing L off cuts the precision by more than half.  This will
> bring the acuracy of the math below the accuracy of the best GPS
> measuserments.

Really?  I think all calculations are done in double, not long double,
arithmetic.

BTW, such constants can be found in math.h, which is already included.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev

From: "Gary E. Miller" <gem at rellim.com>
Subject: Re: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 11:53:23 -0700 (PDT)
To: Rob Janssen <gpsd at xs4all.nl>
cc: gpsd-dev at lists.berlios.de
Sender: gpsd-dev-admin at berlios.de

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Rob!

On Wed, 18 May 2005, Rob Janssen wrote:

> > Taking the trailing L off cuts the precision by more than half.  This will
> > bring the acuracy of the math below the accuracy of the best GPS
> > measuserments.

I just ran some simple checks on gcc 3.3.4 and gcc 4.0.0 on x86.  I
can find no problem with losing the trailing L in my sample code tests.

gcc merges these three constants into one if they are only used in
double precision calculations:

#define PI_1 3.141592653589793
#define PI_2 3.1415926535897932384626433832795029
#define PI_3 3.1415926535897932384626433832795029L

They all store in to this one 80 bit constant:

.LC0:
        .long   1413754136
        .long   1074340347

So there is good reason to be sure that constants are 80 bits long when
using double math.

However these two are not the same, there is a loss of precision, if
they are used in long double calculations:

#define PI_2 3.1415926535897932384626433832795029
#define PI_3 3.1415926535897932384626433832795029L

> Really?  I think all calculations are done in double, not long double,
> arithmetic.

I grepped and everything important appears to be double, with no float
or long double in the lat/lon path.  So double is a fair start for
constants.  It looks like you are right and the L is overkill.

While looking at the assembly output of the double math I see that both
gcc 3.3.4 and gcc 4.0.0 are really performing 80 bit math with doubles
and not merely 64 bit math.  The gcc doubles are a bit more than doubles!
So there is a benefit to makeing sure constants are 80bit.

> BTW, such constants can be found in math.h, which is already included.

Yes, PI is too common to be redefined.  It is also defined, differently,
in sirfmon.c and gps.h.  Maybe an oddball port of gpsd lacks PI in math.h

RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	gem at rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFCi48m8KZibdeR3qURAmckAKDr70iNazL2fAcsxavz1ZjiwaRcTgCfWfP7
6fllH7piNIViH6gj7wL5lq4=
=pJ/h
-----END PGP SIGNATURE-----

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev

From: "Eric S. Raymond" <esr at thyrsus.com>
Subject: Re: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 15:25:42 -0400
To: "Gary E. Miller" <gem at rellim.com>
Cc: Rob Janssen <gpsd at xs4all.nl>, gpsd-dev at lists.berlios.de
Reply-To: esr at thyrsus.com
Sender: gpsd-dev-admin at berlios.de
Organization: Eric Conspiracy Secret Labs

Gary E. Miller <gem at rellim.com>:
> I grepped and everything important appears to be double, with no float
> or long double in the lat/lon path.  So double is a fair start for
> constants.  It looks like you are right and the L is overkill.

I knew the calculation path was only at double precision, so I thought
this would be the case.  Thanks for confirming it.

> > BTW, such constants can be found in math.h, which is already included.
> 
> Yes, PI is too common to be redefined.  It is also defined, differently,
> in sirfmon.c and gps.h.  Maybe an oddball port of gpsd lacks PI in math.h

I don't actually know whether it's portable to get PI from math.h.  
But one of the objectives of sirfmon.c is *not* to include gps.h.  
sirfmon is intended to be an independent sanity check on SiRF decoding,
so it deliberately doesn't use much of the library.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev

From: "Eric S. Raymond" <esr at thyrsus.com>
Subject: Re: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 14:52:17 -0400
To: "Gary E. Miller" <gem at rellim.com>
Cc: "Eric S. Raymond at BerliOS" <esr at sheep.berlios.de>,   gpsd-dev at lists.berlios.de
Reply-To: esr at thyrsus.com
Sender: gpsd-dev-admin at berlios.de
Organization: Eric Conspiracy Secret Labs

Gary E. Miller <gem at rellim.com>:
> Taking the trailing L off cuts the precision by more than half.  This will
> bring the acuracy of the math below the accuracy of the best GPS
> measuserments.

I had to do it.  The long constant was causing some kind of weird
overflow in the sirfmon printfs.  Try it and see.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev

From: "Rob Janssen" <gpsd at xs4all.nl>
Subject: Re: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 21:31:54 +0200 (CEST)
To: gpsd-dev at lists.berlios.de
Sender: gpsd-dev-admin at berlios.de

> Gary E. Miller <gem at rellim.com>:
>> Taking the trailing L off cuts the precision by more than half.  This
>> will
>> bring the acuracy of the math below the accuracy of the best GPS
>> measuserments.
>
> I had to do it.  The long constant was causing some kind of weird
> overflow in the sirfmon printfs.  Try it and see.

Only the RAD2DEG of course.  The reason is that expressions are passed to
printf, and the result from the expressions does not match the format.

A change of %f to %Lf for arguments of form RAD2DEG*var will also fix it.

I think it is better to use something like:

#ifdef M_PIl
#define PI M_PIl
#else
#define PI M_PI
#endif

#define RAD2DEG (180.0/PI)

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev

From: "Eric S. Raymond" <esr at thyrsus.com>
Subject: Re: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 16:08:51 -0400
To: Rob Janssen <gpsd at xs4all.nl>
Cc: gpsd-dev at lists.berlios.de
Reply-To: esr at thyrsus.com
Sender: gpsd-dev-admin at berlios.de
Organization: Eric Conspiracy Secret Labs

Rob Janssen <gpsd at xs4all.nl>:
> I think it is better to use something like:
> 
> #ifdef M_PIl
> #define PI M_PIl
> #else
> #define PI M_PI
> #endif
> 
> #define RAD2DEG (180.0/PI)

Fair enough.  At least that will blow up nice and loud at compile time
if the local math.h doesn't carry either constant.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev

From: "Rob Janssen" <gpsd at xs4all.nl>
Subject: Re: [Gpsd-dev] Re: [Gpsd-commit-watch] r2463 - trunk
Date: Wed, 18 May 2005 22:18:51 +0200 (CEST)
To: gpsd-dev at lists.berlios.de
Sender: gpsd-dev-admin at berlios.de

> Rob Janssen <gpsd at xs4all.nl>:
>> I think it is better to use something like:
>>
>> #ifdef M_PIl
>> #define PI M_PIl
>> #else
>> #define PI M_PI
>> #endif
>>
>> #define RAD2DEG (180.0/PI)
>
> Fair enough.  At least that will blow up nice and loud at compile time
> if the local math.h doesn't carry either constant.

POSIX requires the M_PI.  I think C99 does as well.

FWIW, I have examined some math.h files belonging to different compilers.
A Borland C from 1987 already includes M_PI.  Aztec C from 1984 doesn't.
It is also not mentioned in my K&R The C Programming Language, 2nd edition.

M_PIl of course is a GNU extension.

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/gpsd-dev