I cannot reproduce this using the current maxima git version with cmucl, gcl, or ccl.
I'm guessing this is caused by the version of gcl used with 5.31.2 on windows. I don't have access to that.
Consider the number, 884279719003555/562949953421312, which is slightly less than %pi/2 and is exactly representable in double precision floating point.
Maxima evaluates float(cos(884279719003555/562949953421312)) as 6.1230317691118863e-17, but the correct value is 6.123233995736766e-17, which can be confirmed by evaluating float(bfloat(cos(884279719003555/562949953421312))).
It appears that Maxima gives incorrect values for cosine when the input is close to a zero of cosine. If you consider the input, x = floor(%pi*2^(p-1))/2^p, which is essentially a truncation of %pi/2, noticeable error in cos(x) starts to show up at around p = 22.
I am using Maxima 5.31.2 on a Windows machine.
I cannot reproduce this using the current maxima git version with cmucl, gcl, or ccl.
I'm guessing this is caused by the version of gcl used with 5.31.2 on windows. I don't have access to that.
On Linux (Ubuntu), I get float(cos(884279719003555/562949953421312)) => 6.123031769111886E-17 for GCL, SBCL, and Clozure CL, and 6.122503540205582E-17 for Clisp.
Maxima punts to the underlying Lisp implementation for various elementary functions including cos. GCL, SBCL, and CCL presumably punt to libm.so and indeed a C program outputs 6.123031769111886e-17. If I'm not mistaken, Clisp has its own software implementation of floats, and presumably its own cos, therefore the different result.
I wonder whether we should consider this a bug. I guess it's arguable that Maxima should yield the same value for all Lisp implementations -- if so maybe Maxima should bundle a portable math library such as GSL and call that instead. But if the user wants exactly portable results, he can use bigfloats. Also, even if it's a bug, it seems not very significant, practically speaking.
I'm tempted to close this report as "won't fix". Perhaps OP would like to make an argument in favor of leaving it open?
I was just surprised that I was only getting four significant digits of accuracy. My only argument is that I imagine most people expect (rightly or wrongly) for nearly all displayed digits of elementary function floating point output to be correct. And, since float(sin(x)) always provides me with accurate results (as far as I can tell), why should I expect that float(cos(x)) would be any less accurate?
In any case, I'm certainly not complaining, and I greatly appreciate Maxima and all those who have poured time and effort into developing and maintaining it. As you mentioned, I always make sure now to use bigfloats for anything where accuracy is critical.
I think "wont fix" is good. We might want to file a bug with clisp, though.
I've marked this item "wont-fix" as discussed. I think it's an interesting and useful topic, but it is a very large project -- surely we would want to have accurate, portable results for all functions, not just cos. If someone can identify a library that we could bundle (GSL is just a guess, doubtless there are others) to achieve accurate, portable results, I think it makes sense to open a feature request and/or mailing list discussion for it.