Stavros Macrakis wrote:
> Finally, you might wonder why find_root(myg(y),y,1,3) didn't cause an error
> in quad_qags in the original case where you called myg('y). It turns out
> that quad_qags is sloppily written, and treats non-numerical endpoints as
> zero rather than throwing an error:
>
> quad_qags(x,x,a,b) => [0,0,21,0] /* !!! should give an error */
>
This looks like an oversight in the quad_argument_check function. It
needs to make sure the limits are (or can be coerced) to a number.
> It also doesn't throw errors in the standard Maxima way, but returns an
> error code as the 4th element of the list, which makes it easy to ignore
> (your code, for example, doesn't check it). So even if it *had* checked the
> non-numerical endpoint case, your code wouldn't have noticed.
>
> I consider this a bug in quad_qags, or at least poor practice.
Yes, wasn't sure if users wanted an error message or wanted to check the
return code. To be useful the errors need to be unique for each
possible error code. I think each quad_* function has some different
error codes that only apply to that function.
I will be happy to implement these if someone can give some guidance.
Ray