[Haskell-cafe] attoparsec double precision, quickCheck and aeson

[Thomas Schilling]

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 <bos at serpentine.com> wrote:
>   On Wed, Jun 6, 2012 at 6:20 AM, Doug McIlroy <doug at cs.dartmouth.edu>
> 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-problems-you-didnt-even-know-you-had/
>
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Push the envelope. Watch it bend.