Ok i might have been quick to judge, because i don't really trust
floating point arithmetic.
btw. exp2f works correct on i386.
On 06/02/14 10:17, Mark Kettenis wrote:
Date: Mon, 02 Jun 2014 09:34:20 +0200
From: Benjamin Baier <program...@netzbasis.de>
You might want to read up on floating point arithmetic. (rounding and
representation)
Well, the difference between 4.994404 and 5.0 is a bit large to blame
rounding and binary representation. And other OpenBSD platforms
(amd64, sparc64, powerpc) return the expected result. So I'd say that
there is a bug in the i386-specific implementation of exp2(3).
On 06/02/14 05:13, Daniel Dickman wrote:
I hit this problem while working with the numpy 1.8.1 regress suite
which has some tests that are currently failing.
Here is a reduced test case of the logaddexp2 python function which
ends up calling exp2. Is this a bug in the openbsd exp2
implementation?
---8<---
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
int main(void) {
double x;
double y;
// x = log2(5)
x = 2.32192809489;
// y = 2**(log2(5))
y = exp2(x);
printf("expected: 5.0\n");
printf("actual: %f\n", y);
---8<---
on a linux/x86_64 machine:
# gcc -lm test.c && ./a.out
expected: 5.0
actual: 5.000000
on an openbsd/i386 machine:
# gcc -lm test.c && ./a.out
expected: 5.0
actual: 4.994404
