Change in +prog=eqc behavior from 4.5.0 to 4.6.1

[Orion Poplawski]

With 4.5.0:

proj +proj=eqc +lon_0=0 +a=5.3049894774131808e-315

does not complain.

With 4.6.1:

proj +proj=eqc +lon_0=0 +a=5.3049894774131808e-315
Rel. 4.6.1, 21 August 2008
<proj>:
projection initialization failure
cause: no system list, errno: 34

program abnormally terminated


Is this expected?  If so, what needs to be done to get it to work in 4.6.1?

Thanks for any help.

--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  [hidden email]
Boulder, CO 80301              http://www.cora.nwra.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Gerald I. Evenden]

On Thursday 16 July 2009 12:30:36 pm Orion Poplawski wrote:

> With 4.5.0:
>
> proj +proj=eqc +lon_0=0 +a=5.3049894774131808e-315
>
> does not complain.
>
> With 4.6.1:
>
> proj +proj=eqc +lon_0=0 +a=5.3049894774131808e-315
> Rel. 4.6.1, 21 August 2008
> <proj>:
> projection initialization failure
> cause: no system list, errno: 34
>
> program abnormally terminated
>
>
> Is this expected?  If so, what needs to be done to get it to work in 4.6.1?
>
> Thanks for any help.

I do not get the point with the absurd value of +a=?

Does the program fail with a more sane specification of +a?

gie@charon:~$ lproj +proj=eqc +lon_0=0 +a=5.3049894774131808e-315
1 1
0.00    0.00
20 20
0.00    0.00
gie@charon:~$ lproj +proj=eqc +lon_0=0 +a=1000
10 10
174.53  174.53
gie@charon:~$

In my case, lproj just returns junk zeroes for a junk major axis.  Dunno why,
don't care.

--
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Orion Poplawski]

On 07/16/2009 11:25 AM, Gerald I. Evenden wrote:
>
> I do not get the point with the absurd value of +a=?

Me neither, it's from a test suite for Perl-PDL so it's probably testing
extremes.

> Does the program fail with a more sane specification of +a?
>

Yes.  So, more of a number parsing issue?

--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  [hidden email]
Boulder, CO 80301              http://www.cora.nwra.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Orion Poplawski]

On 07/16/2009 11:34 AM, Orion Poplawski wrote:
> Yes.  So, more of a number parsing issue?
>

Turns out that somewhere between glibc 2.9 and 2.10.1, atof/strtod for
"5.3049894774131808e-315" starting setting errno to ERANGE.  Having
errno set causes pj_init to abort.  I believe this is a bug in glibc
(file here: http://sourceware.org/bugzilla/show_bug.cgi?id=10404).

--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  [hidden email]
Boulder, CO 80301              http://www.cora.nwra.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Orion Poplawski]

On 07/16/2009 02:29 PM, Orion Poplawski wrote:
> Turns out that somewhere between glibc 2.9 and 2.10.1, atof/strtod for
> "5.3049894774131808e-315" starting setting errno to ERANGE.  Having
> errno set causes pj_init to abort.  I believe this is a bug in glibc
> (file here: http://sourceware.org/bugzilla/show_bug.cgi?id=10404).

Well, apparently the glibc maintainer doesn't agree with me (big
surprise), so it seems that proj should be made so that it can handle
errno getting set to ERANGE.  I'm not sure what the best way would be.
I'd be tempted for now just to set errno to 0 after calling atof, but
that is not very good form.

--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: [phone]
3380 Mitchell Lane                  [hidden email]
Boulder, CO 80301              http://www.cora.nwra.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Glynn Clements]

Orion Poplawski wrote:

> On 07/16/2009 02:29 PM, Orion Poplawski wrote:
> > Turns out that somewhere between glibc 2.9 and 2.10.1, atof/strtod for
> > "5.3049894774131808e-315" starting setting errno to ERANGE.  Having
> > errno set causes pj_init to abort.  I believe this is a bug in glibc
> > (file here: http://sourceware.org/bugzilla/show_bug.cgi?id=10404).
>
> Well, apparently the glibc maintainer doesn't agree with me (big
> surprise),

C99 and POSIX permit atof() to set errno to ERANGE on underflow. C99
permits strtod() to set errno to ERANGE on underflow, while POSIX
requires it.

--
Glynn Clements <[hidden email]>
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Aaron Friesen]

> -----Original Message-----
> On 07/16/2009 02:29 PM, Orion Poplawski wrote:
> > Turns out that somewhere between glibc 2.9 and 2.10.1, atof/strtod
> for
> > "5.3049894774131808e-315" starting setting errno to ERANGE.  Having
> > errno set causes pj_init to abort.  I believe this is a bug in glibc
> > (file here: http://sourceware.org/bugzilla/show_bug.cgi?id=10404).
>
> Well, apparently the glibc maintainer doesn't agree with me (big
> surprise), so it seems that proj should be made so that it can handle
> errno getting set to ERANGE.  I'm not sure what the best way would be.
> I'd be tempted for now just to set errno to 0 after calling atof, but
> that is not very good form.

If I'm reading the IEEE spec correctly, the smallest normalized double
precision floating point value that can be stored has a hex pattern of
0x0020000000000000 (the right-most exponent bit set, all other bits
zero), which is approximately 4.4501477170144028e-308.  With denormalized
values, it is possible to represent smaller numbers, but the conversion
routines (atof/strtod) cannot (or at least should not) produce
denormalized values.

I would agree with the glibc maintainer, that ERANGE is a proper
response when attempting to convert "5.3049894774131808e-315".

By the way, the Visual Studio debugger shows 5.304989477413e-315 for the
denormalized value with hex pattern 0x0000000040000000.

Aaron
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj