bfloat hangs computer



Edwin Woollett wrote:
> On 3/18/09, Raymond Toy wrote:
> -------------------------------------------------
>
> Robert Dodier wrote:
>> On 3/17/09, Raymond Toy <toy.raymond at gmail.com> wrote:
>>
>>
>>> I can reproduce this problem with current CVS using gcl 2.6.8 on
>>> Solaris.  It's a bit slow on g(8,40), but it gets some kind of
>>> unrecoverable error (fault count too high) with g(9,40) and proceeds to
>>> dump core.
>>>
>>> This doesn't happen with cmucl.  I don't know why gcl would fail in
>>> this
>>> way.
>>>
>>
>> Looks like exp(-1/(1 - xx)) underflows in an ungraceful way ....
>> g(7, 40) yields a term exp(- 9.999999999712443b6) =>
>> 1.51737304873662b-4342945, which (I guess) causes trouble.
>> With Clisp it triggers the error "ASH: too large shift amount 14426900".
>> The error is in FPPLUS. Is that the bigfloat code is trying to
>> normalize terms to a common basis or something? Just a guess.
>>
>>
> Interesting.  My version of clisp (2.47) goes ahead and computes the
> result.  And a different version of gcl (2.6.8 pre, whatever that
> means), works just fine too.
>
> Ray
> -----------------------------------------------------------------
> I have checked that this same bfloat  underflow hang occurs with the
> same code in versions 5.9.3, 5.12.0, 5.13.0, 5.14.0, 5.15.0, 5.16.1,
> as well as
> 5.17.3 (all GCL 2.6.8 except for v. 5.9.3 which uses GCL 2.6.7).
>
> I suppose a workaround is to define my own exponential function with
> graceful
> underflow behavior, but isn't this something which should be part of
> the bfloat
> code??
>
AFAIK, bfloats essentially never overflow or underflow because the
exponent range is only limited by the size of a bignum (and memory).  I
don't know what graceful underflow would mean in this case.

I will try to take a look at it on the one machine where gcl hangs for
me.  No promises though.  Could be a bug in gcl not handling large
shifts.  Even though clisp complains (as reported by Robert) about a too
large shift, I doubt maxima is trying to do a left shift of 14426900
bits.  It's probably a right shift.

Ray