>>>>> "James" == James Amundson <amundson@fnal.gov> writes:
James> Previously, I could do this:
James> (C1) %j[1](sqrt(x));
James> (D1) %J (SQRT(x))
James> 1
James> Now, I get this:
James> (C1) %j[1](sqrt(x));
James> Is x positive, negative, or zero?
James> This bug has to be fixed. I see you updated to tests to work around the
James> bug. Please roll back those changes. I haven't found the source of the
James> bug yet, but the above information should be a good lead.
Yes. I'll fix this asap.
But perhaps my choice of using adding simplifiers to %j was wrong.
Maybe I should have left them for bessel_j, as Macsyma seems to call
it? I didn't do that because I didn't want to duplicate whatever was
done for %j and friends.
>> For rtest14.mac, test 3 has the wrong value for bessel(2,3), which is
>> purely real, not complex.
James> Right. The only reason I hadn't updated that number is that I wanted to
James> get verify the number through a third party. It is obvious that some of
James> the tests in the special function section are checking against values
James> that are incorrect past single-precision. I would love to have a
James> volunteer audit all the special function numerical tests. Comparison
James> with a third party is really necessary.
FWIW, matlab says
0.12894324947440
whereas we say
0.1289432494744021
If you really want an answer, I'll probably have to hit the library to
find some more accurate tables.
>> Don't know about test 16. I suspect this
>> might be caused by my change to make %j[1/2](x) expand to elementary
>> functions.
James> Is it related to the bug I described above?
I modified the bessel routines not to expand these unless besselexpand
is true. Test 16 passes now.
Ray