Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!pur-ee!ea.ecn.purdue.edu!housel
From: housel@en.ecn.purdue.edu (Peter S. Housel)
Newsgroups: comp.os.minix
Subject: Re: FP libraries
Message-ID: <13579@ea.ecn.purdue.edu>
Date: 21 Jul 89 13:50:33 GMT
References: <13470@ea.ecn.purdue.edu> <19965@louie.udel.EDU> <062089A1778@syntel.UUCP>
Sender: housel@ea.ecn.purdue.edu
Reply-To: housel@en.ecn.purdue.edu (Peter S. Housel)
Organization: Purdue University Engineering Computer Network
Lines: 27
In-reply-to: dal@syntel.UUCP (Dale Schumacher)

In article <062089A1778@syntel.UUCP>, dal@syntel (Dale Schumacher) writes:
>In article <13470@ea.ecn.purdue.edu>, housel@en.ecn.purdue.edu (Peter S. Housel) writes:
>> 	Wait another week or two... I have a floating point kit for
>> Minix-PC that is mostly done and ready to post.
>> 
>> 	The elementary functions library is currently very sparse, but
>> the basis for something bigger is there.
>Has anyone looked into making use of the publically released LIBM from
>4.2 BSD?  With the basic FP support in place, it would seem to be a
>very good source for code to complete the package.

	See my recent lament in comp.lang.c. Basically it is truly
wonderful numerically, but very tricky to understand or port,
especially if you're not a numerical analyst. Anyone who wants to try
porting it is encouraged to, but I'd rather write my own (at the
expense of some loss of accuracy). I'm reusing all of the
redistributable BSD code that will work, but libm isn't in that set (yet).

>PS.  Peter, where do you find the time to do all this code!

	No social life! (Even for an engineering student :-)


>\\   /  Dale Schumacher                         399 Beacon Ave.


-Peter S. Housel-	housel@ecn.purdue.edu		...!pur-ee!housel