Yes, this is an infinite recursion. It would be nice if infinite recursions didn't core-dump. f():=f(); f() gives an error (no tail-recursion handling), but it doesn't core-dump. Why does scanmap? As for Dodier's proposed new-scanmap, isn't that equivalent to bottomup? Presumably the top-down version is useful if the function rewrites its argument before the recursion. I haven't come up with a simple, non-contrived example of that yet....
Yes, sign should ideally raise an error when the argument is never real. But it should return a result when the result is real somewhere. For example, sign(sqrt(sin(x)-1)) => zero (correct), even though it is only real and zero when x is a multiple of %pi. Now consider sign(%i*x). Maxima gives an error because it is syntactically complex. But it is zero when x=0, so going by the previous example, it too should return zero. That said, Maxima cannot tell in general whether an expression is everywhere...
tl;dr We don't need to special-case this; an error is fine. Neither fpprec nor the inherent precision of the bfloat (?caddar(...)) is relevant to this calculation. After all, Maxima is perfectly happy to calculate floor(float(3^100)) even though there are no significant fraction digits. This is following the "exact number" philosophy of floating point, that is, float(3^100) represents 3176259199493869*2^107 and not an interval like 2^107*(3176259199493869+[-1/2+2^-20,1/2]), which covers something...
tl;dr We don't need to special-case this; an error is fine. Neither fpprec nor the inherent precision of the bfloat (?caddar(...)) is relevant to this calculation. After all, Maxima is perfectly happy to calculate floor(float(3^100)) even though there are no significant fraction digits. This is following the "exact number" philosophy of floating point, that is, float(3^100) represents 3176259199493869*2^107 and not an interval like 2^107*(3176259199493869+[-1/2+2^-20,1/2]), which covers something...
Yes, returning the bfloat was exactly my proposal. Do we believe that returning an object of type integer is expected and required?aube worth discussing on the mailing list.
We define binomial as a function over the reals, e.g., binomial(2.3,1.2) => 2.327, binomial(-2.3,-1.2) => 0.0535, so there is no need to restrict to non-negative integers. And if I'm not mistaken, the two forms have exactly the same behavior everywhere, even at the (removable) singularities. Or am I missing something?
To be clear, I mean that as a specification. To implement, we can use integer-decode-float and ash to align the binary representations, like this (thank you, Claude): (defun float=bigfloat (f bf) "Return T if CL double-float F and Maxima bigfloat BF are exactly equal. Uses INTEGER-DECODE-FLOAT and ASH to compare as integers without any floating-point arithmetic." (multiple-value-bind (f-sig f-exp f-sign) (integer-decode-float f) (let* ((signed-sig (* f-sign f-sig)) (bf-mantissa (cadr bf)) (bf-exp...
is(equal(x,y)) is not symmetric for mixed float/bfloat