On Wed, Nov 9, 2011 at 6:37 AM, Richard Fateman
<fateman at eecs.berkeley.edu>wrote:
> On 11/8/2011 10:41 PM, Raymond Toy wrote:
>
>> On 11/8/11 1:42 PM, Richard Fateman wrote:
>>
>>> On 11/8/2011 12:55 PM, Edwin Woollett wrote:
>>>
>>>> Is it possible to return an error in bessel.lisp
>>>> when, for example, the numerical value of
>>>> a bessel function is so large that the code/system
>>>> can't cope, and the answer returned for a calculation
>>>> is completely wrong?
>>>>
>>>> The "right" solution is to roll over to another computer program that
>>> uses bigfloats and an appropriate algorithm for the argument values,
>>> and gives the right answer. (This is one of the things that
>>> Mathematica claims to do.)
>>>
>>> On the other hand, I think there's an expectation that floats are
>> reasonably fast. If they automatically overflowed to bfloats, then
>> suddenly everything gets slower.
>>
> It would be noticeably slower when they DID overflow to bfloats, but
> should be just as fast for double-floats.
I think it depends on the code. But in this particular case, I agree. But
if the bessel_i function is buried deep in some other Lisp code, then it
could be potentially slower because the caller now has to deal with whether
bessel_i returns a float or a bigfloat. May not be significant, but that's
hard to tell without a test case.
>
> That would go against my expectations.
>>
>> But if we signaled an error, as Ted suggests, then the user could catch
>> it and do something about it, including conversion to bfloats.
>>
> Not so easy to do, unless the error message was something like ...
> argument wxyz too big for bessel_j(pqr,wxyz), but if you really want to
> know, its bigfloat value is ab........b1234. I think that
In this case, zbesj is returning an error code of 2, which means overflow.
We could easily signal float overflow error which the user could catch and
just redo the bessel_i computation in bfloats. Which we would have to do
anyway. The user could continue the rest of the computation in bigfloats
fairly easily.
> your suggestion -- which is, I think, that the user re-do the whole
> problem in bigfloats -- seems unnecessarily painful, and also requires
> something that Maxima does not have, which is a complete coverage of all
> floating point library routines in bigfloat arithmetic. As you know, we
> can't just run the FORTRAN 2 Lisp stuff in bfloat -- most algorithms/
> constants are not adequate for anything of higher precision than machine
> double-floats.
>
The lack of bigfloat routines for all of the special functions is a
different problem. I know that Barton's hypergeometric code could be used
to evaluate them, but it seems unnecessarily slow to use hypergeometrics to
evaluate these common special functions. It would, however, be a
reasonable workaround for this lack of coverage.
>
> While I recognize that people might hope for fast computing, they are,
> after all, using a computer algebra system and might be willing to wait for
> an answer that is "correct" if possible.
>
> But my proposal is more long terml thinking than a proposal to "fix this
> bug".
>
Agreed.
Ray