gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: GCL bugs (decode-float, rationalize, expt)


From: Camm Maguire
Subject: [Gcl-devel] Re: GCL bugs (decode-float, rationalize, expt)
Date: 03 Jan 2003 17:35:02 -0500

Greetings!

"Stavros Macrakis" <address@hidden> writes:

> Camm--
> 
> I am a little confused by the GCL setup at gnu.org.  Most bugs appear to
> be entered as "tasks", but I am not authorized to add tasks.  User

Yes, unfortunately there seems to be no way on savannah to enable
general task editing by non-developers.  Unless I can't see it for
some reason.  Would be happy to be enlightened here.  For now,
non-developer requests go to 'support'.

> problems seem to go under "support requests", so I've added a bug report
> for decode-float, integer-decode-float, rationalize, and expt as Support
> Request #101688.

Here is the reposted original report:
=============================================================================
In GCL 2.5.0 (mingw):
  (rationalize 1.0e-300) => Illegal Instruction (CRASH)

In GCL 2.3.6 (mingw):
  (float (rationalize 1.0e-320)) =>
     1.1125369292541007E-308
       (note that this is off by 12 orders of
        magnitude; obviously it is misinterpreting
        denormalized numbers)

In both:

  (expt 10.0 -310) => 0.0 on both 2.3.6 and 2.5.0
     1.0e-310 is a perfectly good number....

  (expt 10 -300) => Illegal Instruction (CRASH)

  (decode-float 1.0e-300) => 0.72, -1022, 1.0

  (decode-float 1.0e-320) => 0.50, -1022, 1.0

Apparently it gets confused by denormalized numbers.

Integer-decode-float has similar problems in 2.3.6, 
but in 2.5.0 it just straightforwardly crashes, even 
on the simplest case...

  (integer-decode-float 1.0) =>
     Illegal Instruction (CRASH)
=============================================================================

Thank you for this.  I've posted the results under the latest CVS binary
on GNU/Linux below.  In general, most of the misbehavior you are
seeing is mingw specific.  There may be a floating point number
precision problem in the printing code, it seems.  I would be most
appreciative if you could detail what results you would expect to the
commands below that differ from the present behavior.

Mike, can you confirm/comment on the mingw crashes?

Take care,
=============================================================================
intech19:/fix/t2/camm/b/gcl$ gcl
GCL (GNU Common Lisp)  Version(2.5.0) Thu Dec  5 08:07:35 EST 2002
Licensed under GNU Library General Public License
Contains Enhancements by W. Schelter

>(rationalize 1.0e-300)

6032057205060441/6032057205060440848842124543157735677050252251748505781796615064961622344493727293370973578138265743708225425014400837164813540499979063179105919597766951022193355091707896034850684039059079180396788349106095584290087446076413771468940477241550670753145517602931224392424029547429993824129889235158145614364972941312

>(float (rationalize 1.0e-320))

0.0

>(expt 10.0 -310)

0.0

>(expt 10 -300)

1/1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

>(decode-float 1.0e-300)

0.66969287949141709
-996
1.0

>(decode-float 1.0e-320)

0.50000000000022471
-1022
1.0

>(integer-decode-float 1.0)

4503599627370496
-52
1

>(by)
=============================================================================

> 
>        -s
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]