main.func_math fails due to precision error

[Ross M.]

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

[Brian Aker (brianaker)]

Floating point is different for each platform. The test... well it is
likely to not be exact.

On Aug 3, 2009, at 9:31 PM, Ross M. wrote:

> Public bug reported:
>
> 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
>
> ** Affects: drizzle
> Importance: Undecided
> Status: New
>
>
> ** Tags: freebsd
>
> --
> 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: New
>
> 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
> ...

[Stewart Smith (stewart)]

would you be able to attach the disassembly of the test program (just the relevant bits, don't need whole objdump) from each platform?

Also try with -O0 and -fno-builtins (or whatever it is)

[Stewart Smith (stewart)]

I should say... my idea is that since the C standard allows for log() to be evaluated at higher precision, this is what's happening while in the other place, it is getting stored to memory, so it's stored precision. Although not sure why this would be the case on amd64. certainly can be the case on 32bit (387 FPU is 80bits internally while double is 64bits in memory)

[Ross M. (rwmcfa1)]

On Mon, Aug 3, 2009 at 10:18 PM, Stewart Smith<email address hidden> wrote:
> would you be able to attach the disassembly of the test program (just
> the relevant bits, don't need whole objdump) from each platform?
>
> Also try with -O0 and -fno-builtins (or whatever it is)

made slight modifications to my test program so that the log calls
weren't going directly in to printf, compiled with -g -O0 -fno-builtin
results are identical, objdump info follows...

linux:
  double logx = log(x);
  4006b2: f2 0f 10 45 f8 movsd -0x8(%rbp),%xmm0
  4006b7: e8 dc fe ff ff callq 400598 <log@plt>
  4006bc: f2 0f 11 45 f0 movsd %xmm0,-0x10(%rbp)
  double log3 = log(3.0);
  4006c1: f2 0f 10 05 87 01 00 movsd 0x187(%rip),%xmm0
 # 400850 <_IO_stdin_used+0x28>
  4006c8: 00
  4006c9: e8 ca fe ff ff callq 400598 <log@plt>
  4006ce: f2 0f 11 45 e8 movsd %xmm0,-0x18(%rbp)
  double logxlog3 = log(x) / log(3.0);
  4006d3: f2 0f 10 45 f8 movsd -0x8(%rbp),%xmm0
  4006d8: e8 bb fe ff ff callq 400598 <log@plt>
  4006dd: f2 0f 11 45 d8 movsd %xmm0,-0x28(%rbp)
  4006e2: f2 0f 10 05 66 01 00 movsd 0x166(%rip),%xmm0
 # 400850 <_IO_stdin_used+0x28>
  4006e9: 00
  4006ea: e8 a9 fe ff ff callq 400598 <log@plt>
  4006ef: f2 0f 10 4d d8 movsd -0x28(%rbp),%xmm1
  4006f4: f2 0f 5e c8 divsd %xmm0,%xmm1
  4006f8: 66 0f 28 c1 movapd %xmm1,%xmm0
  4006fc: f2 0f 11 45 e0 movsd %xmm0,-0x20(%rbp)

freebsd:
  double logx = log(x);
  4006e6: f2 0f 10 45 e0 movsd 0xffffffffffffffe0(%rbp),%xmm0
  4006eb: e8 84 fe ff ff callq 400574 <_init+0x44>
  4006f0: f2 0f 11 45 e8 movsd %xmm0,0xffffffffffffffe8(%rbp)
  double log3 = log(3.0);
  4006f5: f2 0f 10 05 23 01 00 movsd 291(%rip),%xmm0
# 400820 <_fini+0x88>
  4006fc: 00
  4006fd: e8 72 fe ff ff callq 400574 <_init+0x44>
  400702: f2 0f 11 45 f0 movsd %xmm0,0xfffffffffffffff0(%rbp)
  double logxlog3 = log(x) / log(3.0);
  400707: f2 0f 10 45 e0 movsd 0xffffffffffffffe0(%rbp),%xmm0
  40070c: e8 63 fe ff ff callq 400574 <_init+0x44>
  400711: f2 0f 11 45 d8 movsd %xmm0,0xffffffffffffffd8(%rbp)
  400716: f2 0f 10 05 02 01 00 movsd 258(%rip),%xmm0
# 400820 <_fini+0x88>
  40071d: 00
  40071e: e8 51 fe ff ff callq 400574 <_init+0x44>
  400723: f2 0f 10 4d d8 movsd 0xffffffffffffffd8(%rbp),%xmm1
  400728: f2 0f 5e c8 divsd %xmm0,%xmm1
  40072c: 66 0f 28 c1 movapd %xmm1,%xmm0
  400730: f2 0f 11 45 f8 movsd %xmm0,0xfffffffffffffff8(%rbp)

--
-rm

[Ross M. (rwmcfa1)]

On Mon, Aug 3, 2009 at 10:37 PM, Ross McFarland<email address hidden> wrote:

> made slight modifications to my test program so that the log calls
> weren't going directly in to printf, compiled with -g -O0 -fno-builtin
> results are identical, objdump info follows...

when i say, results are identical i mean linux still has 2 and freebsd
2.000...04...

--
-rm

[Jay Pipes (jaypipes)]

Hi! Can you repeat these results on MySQL 5.1? I'm interested to know if we've inherited this behaviour or have introduced a regression. Thanks!

Jay

[Ross M. (rwmcfa1)]

On Tue, Aug 4, 2009 at 5:15 AM, Jay Pipes<email address hidden> wrote:
> Hi!  Can you repeat these results on MySQL 5.1?  I'm interested to know
> if we've inherited this behaviour or have introduced a regression.
> Thanks!

somewhat surprisingly (to me anyway):

rowlf$ mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.28-rc FreeBSD port: mysql-server-5.1.28_1

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select log(3,9);
+----------+
| log(3,9) |
+----------+
| 2 |
+----------+
1 row in set (0.00 sec)

--
-rm

[Jay Pipes (jaypipes)]

Setting to confirmed. Looks like we have a regression (though for the life of me, I don't know what we might have changed that would have affected this...)

[Ross M. (rwmcfa1)]

On Tue, Aug 4, 2009 at 7:10 AM, Jay Pipes<email address hidden> wrote:
> Setting to confirmed.  Looks like we have a regression (though for the
> life of me, I don't know what we might have changed that would have
> affected this...)

especially when the answer that drizzle is getting matches the one a
simple cpp program gets (on freebsd.)

just dug around and found the log functions log, log2, log10 in both
drizzle and mysql51, there identical so no help there. this is getting
odd...

--
-rm

[Jay Pipes (jaypipes)]

Yes, weird indeed :)

Here's another test to do...

I believe that the Item_typecast classes are to blame. Can you check the output of the following on Drizzle and MySQl 5.1?

CREATE TABLE t1
SELECT log(3,9) as field1;

SHOW CREATE TABLE t1\G

This will tell us if Drizzle is doing the implicit Field class conversion differently than MySQL 5.1.

Thanks much, Ross!

-jay

[Ross M. (rwmcfa1)]

On Tue, Aug 4, 2009 at 9:21 AM, Jay Pipes<email address hidden> wrote:

> Here's another test to do...
>
> I believe that the Item_typecast classes are to blame.  Can you check
> the output of the following on Drizzle and MySQl 5.1?
>
> CREATE TABLE t1
> SELECT log(3,9) as field1;
>
> SHOW CREATE TABLE t1\G
>
> This will tell us if Drizzle is doing the implicit Field class
> conversion differently than MySQL 5.1.

drizzle> create table t1 select log(3,9) as field1;
Query OK, 1 row affected (0.023 sec)
Records: 1 Duplicates: 0 Warnings: 0

drizzle>
drizzle> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `field1` double DEFAULT NULL
) ENGINE=InnoDB
1 row in set (0 sec)

drizzle> select * from t1;
+--------------------+
| field1 |
+--------------------+
| 2.0000000000000004 |
+--------------------+
1 row in set (0 sec)

mysql> create table t1 select log(3,9) as field1;
Query OK, 1 row affected (0.02 sec)
Records: 1 Duplicates: 0 Warnings: 0

mysql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `field1` double DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql>
mysql> select * from t1;
+--------+
| field1 |
+--------+
| 2 |
+--------+
1 row in set (0.00 sec)

--
-rm

[Jay Pipes (jaypipes)]

Hmm, the situation gets weirder :)

OK, so it seems like Drizzle's handling of DOUBLE is different than MySQL 5.1. I'll check out our implementation of Field_double::store() and see if the handling of the korr.h macros is different.

Thanks, Ross!

[Ross M. (rwmcfa1)]

On Tue, Aug 4, 2009 at 9:21 AM, Jay Pipes<email address hidden> wrote:
> Yes, weird indeed :)

a bit more digging had lead me away from the log function/path.

stepping through both mysql5.1 and drizzle i've found that in
Item::send case (MYSQL|DRIZZLE)_TYPE_DOUBLE the line

  double nr= val_real();

ends up with the exact same value. the next applicable line is:

 result= protocol->store(nr, decimals, buffer);

the value in buffer in mysql51 is:

$2 = {Ptr = 0x7fffffbbb1b0 "2", str_length = 1, Alloced_length = 766,
  alloced = false, str_charset = 0x9bd940}

the value in buffer on drizzle is:

$2 = {Ptr = 0x7ffffebe4c80 "2.", '0' <repeats 15 times>, "4", str_length = 18,
  Alloced_length = 1021, alloced = false, str_charset = 0x9fd9c0}

so something down inside of protocol->store is different between the
two. i'll be off of here for a couple hours, but once i'm back i'm
going to start walking down in that code and see where i get, but i
assume there are likely large differences in the protocol between the
two (if protocol ends up meaning what i currently guess that it does.)

best,
--
-rm

[Ross M. (rwmcfa1)]

On Tue, Aug 4, 2009 at 7:50 PM, Ross McFarland<email address hidden> wrote:

> so something down inside of protocol->store is different between the
> two. i'll be off of here for a couple hours, but once i'm back i'm
> going to start walking down in that code and see where i get, but i
> assume there are likely large differences in the protocol between the
> two (if protocol ends up meaning what i currently guess that it does.)

problem is in drizzle mystrings/dtoa.cc, dtoa

only reference to dtoa in mysql51:

strings/decimal.c:

int double2decimal(double from, decimal_t *to)
{
  /* TODO: fix it, when we'll have dtoa */
...

walking through that func (it's huge and hairy) to try to determine
what's going on.

--
-rm

[Ross M. (rwmcfa1)]

On Tue, Aug 4, 2009 at 9:26 PM, Ross McFarland<email address hidden> wrote:
> On Tue, Aug 4, 2009 at 7:50 PM, Ross McFarland<email address hidden> wrote:

> problem is in drizzle mystrings/dtoa.cc, dtoa

found it:

 res= dtoa(x, 4, type == MY_GCVT_ARG_DOUBLE ?
            min(width, DBL_DIG) : width,
            &decpt, &sign, &end);

should be:

 res= dtoa(x, 4, type == MY_GCVT_ARG_DOUBLE ?
            min(width, DBL_DIG) : min(width, FLT_DIG),
            &decpt, &sign, &end);

it was passing in width (the size of the buffer, 341) for ndigits
which is supposed to be the (max) number of digits to include in the
string (buffer should be this size or larger.) when 341 is passed it
tries to convert to a string that is higher precision than the double
it's copying from can reliably be used for (> DBL_DIG digits) and thus
gets noise. this just happens to work on linux since it gives out the
double value of exactly 2 in the first place.

good news is that fixes the log(3, 9) func_math test. bad news is that
others are now failing. looking at the failures i'm not 100% sure yet,
but i think the expected values may be wrong. digging yet more...

--
-rm

[Ross M. (rwmcfa1)]

On Tue, Aug 4, 2009 at 10:15 PM, Ross McFarland<email address hidden> wrote:

> found it:

fixes and related test result corrections pushed to associated branch.
verified that it didn't break linux.

these fixes, along with 408690, complete FreeBSD porting -- make check passes!

--
-rm

[Jay Pipes (jaypipes)]

Ross, you rock!

I'll mark this assigned to you and fix committed. I'll merge your branch into my captain branch shortly.

Thanks much!

-jay

[Ross M. (rwmcfa1)]

On Wed, Aug 5, 2009 at 10:09 AM, Jay Pipes<email address hidden> wrote:

> I'll mark this assigned to you and fix committed.  I'll merge your
> branch into my captain branch shortly.

sweet! that leaves https://bugs.launchpad.net/drizzle/+bug/408690 as
the only remaining bug in the way of clean build and test on FreeBSD.

--
-rm

[Ross M. (rwmcfa1)]

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

[Monty Taylor (mordred)]

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),l...

[Ross M. (rwmcfa1)]

On Thu, Oct 1, 2009 at 8:37 PM, Monty Taylor <email address hidden> wrote:
> 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?

libgmp looks interesting, but i'm not sure that drizzle needs what it
offers (seems to be mostly targeted at arbitrary precision stuff) and
would worry that performance would suffer, but maybe not. it does look
like gnulib would offer the necessary math functions. i'll take a look
at it this weekend and see what it looks like on freebsd. if it works
correctly there i'll try to create a branch with that worked in and
the tests reverted. (busy weekend tho, so not sure i'll make it around
to it that soon.)

--
-rm

[Ross M. (rwmcfa1)]

On Thu, Oct 1, 2009 at 8:37 PM, Monty Taylor <email address hidden> wrote:
> 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?

after a bit a digging it appears that gnulib-tool doesn't provide an
alternate implementation of log (perhaps it should since freebsd at
least has precision problems.) i'm looking at alternatives. i'm
downloading gnulib-tool to check what code is in it though there's
little chance of it compiling on freebsd. i will probably suggest that
gnulib-tool provide an alternate log, but have no clue if that's
feasible.

--
-rm