There are better libraries than mine for 128-bit, which is quad precision, that use 12-bit exponents; my package always uses 16-bit exponents. Quad precision packages use the hardware 80-bit floating point in most CPU cores these days and would be smaller and faster than my package. My package is useful for precisions higher than 128 bits. I typically use it for 256 bits and higher.
James K Beard -----Original Message----- From: Kai Tietz [mailto:[email protected]] Sent: Sunday, April 10, 2011 2:48 AM To: [email protected]; [email protected] Cc: James K Beard; JonY Subject: Re: [Mingw-w64-public] mingw-w64 Decimal Floating Point math 2011/4/10 James K Beard <[email protected]>: > JonY - well, mine is in Fortran 95 structured format, with layers of classes > and derived data types. An experienced programmer could port it to C++ > fairly quickly, giving you a a C++ class with overloaded arithmetic and > casting/data conversion operations. But I'm not a C++ programmer and don't > want to become one; I'm not in software or computer science and have other > plans for my time than gaining expertise in C++. But I would be happy to > support other people to do the conversion to C++. Well, C++ is a good language, but nevertheless for a C runtime-library something not really usable. At least not for gcc, where we end then in egg/chicken situation, as initial bootstrap provides C compiler, but C++ isn't present completely. So if we include a dfp library into runtime, it needs to be written in C language. But well, to transscript C++ to C isn't a hard thing. So as startup version a C++ variant might be good enought here. > The Numerical Recopies core utilities are extended-precision fixed-point > arithmetic without extensions (I do the extensions myself), an algorithm to > compute pi to arbitrary precision, and an algorithm to do multiplication > using an FFT to convolve polynomials of integers that are the extended > precision mantissas broken up into bytes. The multiplication and division > algorithms are non-trivial and the computer science in them is very much key > to acceptable speeds in multiplication. If you guys are at all serious > about this I will approach the NR people about how to proceed. My tentative > thinking has been to put out what I have under the GPL, MIT, BSD or whatever > license and note the NR modules needed to complete the package and leave it > at that. For something to become a package in another language, I need a > release into the MIT or BSD license. That's not at all very different from > what they offer in the books and CD, so I think that it might be > forthcoming, particularly if a plug for NR is included, but at this late > date even that might not be required. > > My package has an initialization routine that sets up all the transcendental > functions in arbitrary precision - log, exp, sine, cosine, tangent, arc > sine, arc cosine, arc tangent - one and two argument - and a couple of > others like the log gamma function. All of that is mine and free for me to > release in any license. > > James K Beard Well, the interesting part here would be to support 128-bit binary floats, which need to be emulated by software for x86/x64 anyway. By this the support of dfp 128 should be then much easier. So I wondering, if it wouldn't be in general a better solution to provide first 128-bit binary float, and then use it for dfp 128. For dfp 64 and 32 bit, the 80-bit precission we support already, is for sure precise enough. Only thing is the rounding after complex calculations. Regards, Kai ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
