
Bryan, do you remember what the issue is with C++ in this case? I
thought, adding a wrapper with extern "C" definitions should do the
trick for simpler libraries (as this one seems to be). Is the
interaction with the memory allocator the issue? Linker flags?
On 11 June 2012 06:38, Bryan O'Sullivan
On Wed, Jun 6, 2012 at 6:20 AM, Doug McIlroy
wrote: Last I looked (admittedly quite a while ago), the state of the art was strtod in http://www.netlib.org/fp/dtoa.c. (Alas, dtoa.c achieves calculational perfection via a murmuration of #ifdefs.)
That was indeed the state of the art for about three decades, until Florian Loitsch showed up in 2010 with an algorithm that is usually far faster: http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-proble...
Unfortunately, although I've written Haskell bindings to his library, said library is written in C++, and our FFI support for C++ libraries is negligible and buggy. As a result, that code is disabled by default.
It's disheartening to hear that important Haskell code has needlessly fallen from perfection--perhaps even deliberately.
Indeed (and yes, it's deliberate). If I had the time to spare, I'd attempt to fix the situation by porting Loitsch's algorithm to Haskell or C, but either one would be a lot of work - the library is 5,600 lines of tricky code.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Push the envelope. Watch it bend.