The actual test value is 24985672148.49706999957561492919921875 (exact)
The gnumeric file contains 24985672148.49707 which rounds correctly to the
exact value above when read into a "double".  We seem to have a GUI issue
that makes you see "....4971", but that is unrelated to the sine problem.

WolframAlpha gives the value -0.55266506738426566413304255... for the sine.

So you really should be getting a negative value.  (And since the test values
were not created by or for Gnumeric,


The question is why.

* Where did you get your Gnumeric from?
* If you compiled yourself, please attach config.log
* What is the precise version?


Same questions for lingoffice.


what output do you get from running this in a shell?

perl -e 'printf "%g\n", sin(24985672148.49706999957561492919921875);'

(Perl will also use the libc sin function, but it may be compiled differently,
so there are a few too many unknowns.)

Also, what is the output from

cat /proc/cpuinfo

?

Morten meant liboffice in comment #1 (not lingoffice)

Created attachment 271793 [details]
config.log, as requested

Hi-

   I compiled it myself (1.12.12). config.log is attached. I don't have
   the config.log for goffice around anymore, but it's 0.10.12. Perl
   gets it wrong (positive answer), same as gnumeric. GNU bc, however,
   gets it right (negative answer). And the output from
   "cat /proc/cpuinfo" is:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 6
model name	: AMD Sempron(tm) 145 Processor
stepping	: 3
microcode	: 0x10000c8
cpu MHz		: 2800.430
cache size	: 1024 KB
fdiv_bug	: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc pni
monitor cx16 popcnt lahf_lm svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv
svm_lock nrip_save bogomips	: 5600.86 clflush size	: 64
cache_alignment	: 64 address sizes	: 48 bits physical, 48
bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate

(but, as you can see from the config.log, the arch is i686-pc-linux-gnu
- --- so 32-bit mode).

             -Andrew Warshall

Please compile and run the test program below with

    gcc -Wall -O2 -march=amdfam10 sss.c -lm
    ./a.out 24985672148.49707

For reference, I see:

x = 24985672148.4970703125 aka 0x1.7450c6751fdp+34
sin (x) = -0.552665

I expect from the above that you will see the same x, but a positive sine.
If that indeed does happen, then please compile to assembler:

    gcc -v -S -Wall -O2 -march=amdfam10 sss.c -lm

and attach the resulting sss.s file here together with the output from
the compile command.  I expect that sss.s will have a call to "sin" in
there:

# grep sin sss.s
	.string	"sin (x) = %g\n"
	call	sin

This is looking like a glibc and/or cpu(!) problem.



#include <stdio.h>
#include <math.h>
#include <stdlib.h>

int
main (int argc, char **argv)
{
  double x = atof (argv[1]);
  printf ("x = %.30g aka %a\n", x, x);
  printf ("sin (x) = %g\n", sin (x));
  return 0;
}

Created attachment 271819 [details]
compilation log for sss.c

It came out positive, as you had expected. The assembly-language output should follow shortly.

Created attachment 271820 [details]
sss in assembler

Please file this for glibc over at

    https://sourceware.org/bugzilla/enter_bug.cgi

and drop a link to the resulting bug here.

This may be related to https://sourceware.org/bugzilla/show_bug.cgi?id=16625

Hi-

   glibc appears to be on this. Linking against their patched libm solves the problem. Thanks.

               -Andrew Warshall

Please file anyway, so we can be sure.  That also is likely to get this
case added to the test suite in the future.

Note: the glibc bug I pointed at suggests that this might be a compiler
bugs.  That could cause weirdness it lots of places.  Does your system
have an alternate compiler to try with?

That's what I did. glibc merged my report with a pre-existing one, for which there was a patch. The patch then worked when I applied it.

It wasn't the bug you pointed at, but a different one; my glibc didn't suffer from the bug you pointed at.

Sorry for the confusion.

          -Andrew Warshall

Great.  For reference, this is the bug

    https://sourceware.org/bugzilla/show_bug.cgi?id=16708

which links to

    https://sourceware.org/bugzilla/show_bug.cgi?id=16623

I have added a test for this problem to goffice.  It will print a warning
on startup.

--> NOTGNOME.

Why would this depend on the locale?

aguelzow@kirkman ~ $ LC_ALL=de_DE.utf8 jhbuild run gnumeric

** (gnumeric:22639): WARNING **: Running with buggy math library, see https://bugzilla.gnome.org/show_bug.cgi?id=726250
aguelzow@kirkman ~ $ jhbuild run gnumeric
aguelzow@kirkman ~ $ 

I appear to get the warning when I run with LC_ALL=de_DE.utf8 but not when I use the default:
aguelzow@kirkman ~ $ locale
LANG=en_CA.UTF-8
LANGUAGE=
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=

I have fixed the test to -- hopefully -- be locale independent.

no warnings in either locale now