On armv7hl architecture, number->string converts scientific notation to decimal notation

[michel-slm]

This happens on Fedora build servers for both the stable Fedora 23 release and the development tree that will become Fedora 24. The other unit tests pass, and the failing test succeeds on x86_64 and i686.

"unit-tests/03-number/number2string.scm"@16.1: FAILED (check-equal? (number->string .0009765625) "9.765625e-4") GOT ".0009765625"
FAILED 1 UNIT TESTS OUT OF 61 (1.6%)

see complete log for build options and compilation logs
gambit-4.8.4-armv7hl-build.txt

[michel-slm]

Note: the test case source file actually specifies 9.765625e-4 but the output is misleading because, in this case, number->string itself returns the wrong result.

[feeley]

This is not easy to debug without access to the platform. What is your setup? Are you using an emulator? Could you try evaluating:

(##flonum->inexact-exponential-format .0009765625)

[gambiteer]

On 02/22/2016 03:08 PM, Marc Feeley wrote:

This is not easy to debug without access to the platform. What is your
setup? Are you using an emulator? Could you try evaluating:

|(##flonum->inexact-exponential-format .0009765625)|

—
Reply to this email directly or view it on GitHub
https://github.com/feeley/gambit/issues/181#issuecomment-187363408.

I'll do this tonight when I get home on my Raspberry Pi. The bug shows
up there, configured with

./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4
-mfloat-abi=hard' '--enable-single-host' '--enable-shared'
'--enable-multiple-versions' '--disable-gnu-gcc-no-strict-aliasing’

You should get a Raspberry Pi 2 Model B, Marc, it's about $60 loaded
(power supply, WIFI, micro-disk, etc.) and it's fun.

Brad

[gambiteer]

On Feb 22, 2016, at 3:08 PM, Marc Feeley notifications@github.com wrote:

This is not easy to debug without access to the platform. What is your setup? Are you using an emulator? Could you try evaluating:

(##flonum->inexact-exponential-format .0009765625)

I find

(##flonum->inexact-exponential-format 9.765625e-4)
#(1. -10 1)
(##flonum->inexact-exponential-format .0009765625)
#(1. -10 1)

The line in the test file is

(check-equal? (number->string 9.765625e-4) "9.765625e-4")

Brad

[feeley]

How about (##flonum->exact-exponential-format .0009765625) ?

[gambiteer]

Didn't I just report that one too?

On Feb 22, 2016, at 8:57 PM, Marc Feeley notifications@github.com wrote:

How about (##flonum->exact-exponential-format .0009765625) ?

—
Reply to this email directly or view it on GitHub.

[feeley]

You gave two calls to ##flonum->inexact-exponential-format with the same value. I want to see the result of ##flonum->exact-exponential-format. It should be:

> (##flonum->exact-exponential-format .0009765625)  
#(4503599627370496 -62 1)

[michel-slm]

will check when I get home (in 9 hours or so); I have access to some Fedora test servers (beefy ARM machines with 4GB RAM) but my SSH key is on my home machines.

[gambiteer]

(##flonum->exact-exponential-format .0009765625)
#(4503599627370496 -62 1)

On Feb 22, 2016, at 10:32 PM, Marc Feeley notifications@github.com wrote:

(##flonum->exact-exponential-format .0009765625)

[feeley]

Could you trace the execution of

(##flonum-printout .0009765625 "")

? By "trace" I mean add pps at appropriate places in its logic.

[michel-slm]

So far I'm getting identical results on ARM and on x86_64:

ARM:

Gambit v4.8.4

> (##flonum->inexact-exponential-format .0009765625)
#(1. -10 1)
> (##flonum->inexact-exponential-format 9.765625e-4) 
#(1. -10 1)
> (##flonum->exact-exponential-format .0009765625)
#(4503599627370496 -62 1)
> 

x86_64:

Gambit v4.8.4

> (##flonum->inexact-exponential-format .0009765625)
#(1. -10 1)
> (##flonum->inexact-exponential-format 9.765625e-4) 
#(1. -10 1)
> (##flonum->exact-exponential-format .0009765625)
#(4503599627370496 

Is there a patch I can try to do the tracing? I'm afraid I'm not that familiar with Gambit internals yet.

[feeley]

In ##flonum-printout just after

  (let* ((x (flonum->exponent-and-digits v))
         (e (##car x))
         (d (##cdr x))            ;; d = digits
         (n (##string-length d))) ;; n = number of digits

add

(pp (list e: e d: d n: n))

[michel-slm]

added that to lib/_num.scm, make clean and make, and I don't really see any debugging information printed. hmm, weird.

[feeley]

The information should be printed when you call (number->string .0009765625). Is that what you tried?

[gambiteer]

Whoa. It's seems to be in ##flonum->fixnum.

I had to get around some problems that I couldn't print out
floating-point numbers in all the (pp ...) statements. The difference is in

(pp (list scale: r: r
s: s
m+: m+
m-: m-
round?: round?
base-10-log-v: (inexact->exact (base-10-log v))
epsilon: (inexact->exact (epsilon))
inexact-est: (inexact->exact (##flceiling (##fl- (base-10-log v)
(epsilon))))
est: est))

in scale. If I replace

 (let ((est
        (##flonum->fixnum
         (##flceiling (##fl- (base-10-log v) (epsilon))))))

with

 (let ((est
        (##inexact->exact
         (##flceiling (##fl- (base-10-log v) (epsilon))))))

The problem goes away.

Brad

On X86-64:

(number->string (expt 2. -10))
(flonum->exponent-and-digits: f: 4503599627370496 e: -62)
(scale: r: 18014398509481984 s: 18446744073709551616 m+: 2 m-: 1 round?:
#t base-10-log-v: -3389296440749119/1125899906842624 epsilon:
7737125245533627/77371252455336267181195264 inexact-est: -3 est: -3)
(fixup: r: 18014398509481984000 s: 18446744073709551616 m+: 2000 m-:
1000 k: -3 round?: #t)
(generate: r: 14123288431433875456 s: 18446744073709551616 m+: 20000 m-:
10000 round?: #t n: 0)
(generate: r: 12105675798371893248 s: 18446744073709551616 m+: 200000
m-: 100000 round?: #t n: 1)
(generate: r: 10376293541461622784 s: 18446744073709551616 m+: 2000000
m-: 1000000 round?: #t n: 2)
(generate: r: 11529215046068469760 s: 18446744073709551616 m+: 20000000
m-: 10000000 round?: #t n: 3)
(generate: r: 4611686018427387904 s: 18446744073709551616 m+: 200000000
m-: 100000000 round?: #t n: 4)
(generate: r: 9223372036854775808 s: 18446744073709551616 m+: 2000000000
m-: 1000000000 round?: #t n: 5)
(generate: r: 0 s: 18446744073709551616 m+: 20000000000 m-: 10000000000
round?: #t n: 6)
(##flonum-printout: e: -3 d: "9765625" n: 7)
"9.765625e-4"

on Arm:

(number->string (expt 2. -10))
(flonum->exponent-and-digits: f: 4503599627370496 e: -62)
(scale: r: 18014398509481984 s: 18446744073709551616 m+: 2 m-: 1 round?:
#t base-10-log-v: -3389296440749119/1125899906842624 epsilon:
7737125245533627/77371252455336267181195264 inexact-est: -3 est: 0)
(fixup: r: 18014398509481984 s: 18446744073709551616 m+: 2 m-: 1 k: 0
round?: #t)
(generate: r: 180143985094819840 s: 18446744073709551616 m+: 20 m-: 10
round?: #t n: 0)
(generate: r: 1801439850948198400 s: 18446744073709551616 m+: 200 m-:
100 round?: #t n: 1)
(generate: r: 18014398509481984000 s: 18446744073709551616 m+: 2000 m-:
1000 round?: #t n: 2)
(generate: r: 14123288431433875456 s: 18446744073709551616 m+: 20000 m-:
10000 round?: #t n: 3)
(generate: r: 12105675798371893248 s: 18446744073709551616 m+: 200000
m-: 100000 round?: #t n: 4)
(generate: r: 10376293541461622784 s: 18446744073709551616 m+: 2000000
m-: 1000000 round?: #t n: 5)
(generate: r: 11529215046068469760 s: 18446744073709551616 m+: 20000000
m-: 10000000 round?: #t n: 6)
(generate: r: 4611686018427387904 s: 18446744073709551616 m+: 200000000
m-: 100000000 round?: #t n: 7)
(generate: r: 9223372036854775808 s: 18446744073709551616 m+: 2000000000
m-: 1000000000 round?: #t n: 8)
(generate: r: 0 s: 18446744073709551616 m+: 20000000000 m-: 10000000000
round?: #t n: 9)
(##flonum-printout: e: 0 d: "0009765625" n: 10)
".0009765625"

[gambiteer]

On 02/23/2016 09:47 PM, Bradley Lucier wrote:

Whoa. It's seems to be in ##flonum->fixnum.

Here is what that ##flonum->fixnum expands to:

___r1=(((int)(((unsigned int)(___F64V3))<<2)));

I think you want to have instead

___r1=(((int)(((unsigned int)((int)(___F64V3)))<<2)));

[feeley]

Nice catch Brad! I've just learned something today... for reference see: http://stackoverflow.com/questions/10541200/is-the-behaviour-of-casting-a-negative-double-to-unsigned-int-defined-in-the-c-s

So I changed the definition of ___F64TOFIX to

#define ___F64TOFIX(x)___FIX(___CAST(___WORD,x))

Please confirm that it fixes the issue on ARM.