Yigal Weinstein wrote:
> Raymond you wrote,
>
> "If this bug prevents you from using maxima, I suspect you will not be
> satisfied with any program because they all have bugs. Perhaps you
> won't find them, but what if you do?"
>
> I understand this. It is just the more trivial a mistake is the more
> difficult it is to put any faith in a program. This is the idea that
>
The result may seem like a trivial mistake, but it's hard to know
without looking at the code. Perhaps it's caused by a subtle rounding
error? Or some complicated logic in some related routines? Or just
something really stupid. This particular bug goes back to at least
2.35, so it's been there quite a while.
Look through Maxima's bug list. There are lots of things maxima gets
wrong; many of them seem trivial. That they still exist after many
years would probably indicate that they're not so trivial. Perhaps this
sin bug in clisp is like that.
> I mainly asked about the CLISP error to get an idea from programmers how
> usual these errors are. From Sen's and your response I see they are
> quite usual. I am personally trying to find useful applications of CAS
>
I think you inferred too much. Yes, bugs exist. Does this one bug in
clisp cancel out all the other things that clisp gets right?
Perhaps, but perhaps not.
> to what historically has been numerical problems of the 1960s i.e.
> FORTRAN code for solving quantum few body scattering problems using NAG
> and other software. That is trying to replace a little bit of the
> number crunching with some intelligent code. It is just discouraging to
> see something like sin(7.25pi)=0 and realize how far it could be for
> practical use.
>
The easy solution is to use some other Lisp which doesn't have this one
particular bug. The better solution is to help clisp fix it. Then
everyone wins.
Ray