We can perhaps include log in what we're using from gnulib... I'll check it out in a bit. I've also looked in the past at using libgmp to replace math stuff... perhaps we should revisit that?

"Ross M." <email address hidden> wrote:

>After a lot more digging (after discussion on the mysql dtoa bug) it
>appears that this patch is incorrect.
>
>http://bugs.mysql.com/bug.php?id=46577
>
>i wrote a couple test programs looking at the bits on freebsd and the
>there is a precision problems with log on freebsd :(
>
>the dtoa stuff is a mess, apparently the float path has know problems
>one of which lead me to think the patch was the correct fix. this
>change and it's associated test changes should be backed out. i'm not
>sure what the real solution to this problem is. perhaps including a
>version of log to use when the system log has such problems. that
>sounds like a mess/horrible thing though.
>
>i assume mysql 6 (with the dtoa stuff) may have a similar problem with
>log, but it may take other paths that avoid the trouble...
>
>anyway, if desired/necessary i can create a branch that reverts
>things, but i'm not sure that's the best route.
>
>--
>-rm
>
>-- 
>main.func_math fails due to precision error
>https://bugs.launchpad.net/bugs/408694
>You received this bug notification because you are a member of Drizzle-
>developers, which is subscribed to Drizzle.
>
>Status in A Lightweight SQL Database for Cloud and Web: Fix Released
>
>Bug description:
>differences in precision are causing func_math test to fail. log(3,9) is
>expecting exactly 2, but on freebsd gets 2.0000000000000004440892.
>
>a simple program doing log(9) / log(3) produces the following on linux, and 
>freebsd:
>
>animal$ uname -a
>Linux animal 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux
>animal$ ./log 
>2.1972245773362195642164 / 1.0986122886681097821082 = 2.0000000000000000000000
>
>rowlf$ uname -a
>FreeBSD rowlf.local 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan  1 08:58:24 UTC 2009     <email address hidden>:/usr/obj/usr/src/sys/GENERIC  amd64
>rowlf$ ./log 
>2.1972245773362195642164 / 1.0986122886681095600636 = 2.0000000000000004440892
>
>log(9) is identical on both systems, but log(3) differs after 15 or 16 digits
>and the division of log(9) / log(3) effectively doubles that error. 
>
>i'm at a loss as to how to address this one. it seems like the freebsd log call
>can return data less accurately than linux, but i'm not sure it's safe to assume
>that you have a full double's worth of precision in those sorts of calculations.
>don't think there'll be a patch i can attach to this one without some
>discussion...
>
>- test failure -----------------------------------------------------------------
>
>main.func_math                 [ fail ]
>
>--- ../tests/r/func_math.result	2009-08-04 07:07:52.669905696 +0300
>+++ ../tests/r/func_math.reject	2009-08-04 07:15:33.773824490 +0300
>@@ -44,7 +44,7 @@
> Note	1003	select abs(-(10)) AS `abs(-10)`,sign(-(5)) AS `sign(-5)`,sign(5) AS `sign(5)`,sign(0) AS `sign(0)`
> select log(exp(10)),exp(log(sqrt(10))*2),log(-1),log(NULL),log(1,1),log(3,9),log(-1,2),log(NULL,2);
> log(exp(10))	exp(log(sqrt(10))*2)	log(-1)	log(NULL)	log(1,1)	log(3,9)	log(-1,2)	log(NULL,2)
>-10	10.000000000000002	NULL	NULL	NULL	2	NULL	NULL
>+10	10.000000000000002	NULL	NULL	NULL	2.0000000000000004	NULL	NULL
> Warnings:
> Error	1365	Division by 0
> Error	1365	Division by 0
>

Sent from my Android phone with K-9. Please excuse my brevity.