Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!pur-ee!pur-phy!murphy
From: murphy@pur-phy (William J. Murphy)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Manx 3.6 bug & DBW's ext.c
Keywords: Overflow converting to FFP format!
Message-ID: <2205@pur-phy>
Date: 27 Apr 89 15:14:57 GMT
References: <2185@pur-phy> <829@wucs1.wustl.edu>
Reply-To: murphy@newton.physics.purdue.edu.UUCP (William J. Murphy)
Distribution: na
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 31

In article <829@wucs1.wustl.edu> warren@wucs1.UUCP (Warren Burnett) writes:
>In article <2185@pur-phy> murphy@pur-phy (William J. Murphy) writes:
>
>>#define	    HUGE	    ((float)1.7e+38)
>.......
>>    cv(-HUGE,-HUGE,-HUGE,re->max);
>
>Yes, I got the same error when I tried to compile it.  I believe that changing
>the #define so that HUGE is 1.7e+18 will allow it to compile.  The program
>seems to work correctly with this change, but I haven't tested it extensively.
>
>Does anyone know if this is in fact a problem with the compiler?  There is
>a #define in the include file math.h for something called HUGE_VAL, or 
>something like that;  As I remember,  it is something like 1.79e+308.  

Well, since I started this thread, maybe I can tie it up.  Raz-Berry in an 
earlier posting suggested compiling with the option +fi in Manx which will
then use the IEEE library ma.lib, mal.lib, ma32.lib, or mal32.lib depending
upon the other flags you set when compiling and linking.  I tried Raz's 
suggestion and IT WORKS!!!  

Warren's comment about redefining the value HUGE to 1.7e+18 is not necessary.
That value is correct according to ACCCK* PPHHHT*!@ Microsoft C 5.1 which
lists the limits for the float as 1.7e+38 and 1.7e-38. (MSC5.1 uses the IEEE
spec for numbers. and I couldn't find this figure in Manx's cruddy 
documentation.)  The other number is the value/limit for double precision
IEEE floating point.  

Thanks Raz, Warren and whomever else postedabout this.
Bill Murphy
murphy@newton.physics.purdue.edu