Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

[Barton W. <wi...@un...>]

OK, maybe I found the culprit:

(defun bfloat-erf (z)
  ;; Warning!  This has round-off problems when abs(z) is very small.
  (let ((1//2 ($bfloat '((rat simp) 1 2))))
  ;; The argument is real, the result is real too
    ($realpart
      (mul
        (simplify (list '(%signum) z))
        (sub 1
          (mul
            (div 1 (power ($bfloat '$%pi) 1//2))
            (bfloat-gamma-incomplete 1//2 ($bfloat (power z 2)))))))))



And similarly for complex-bfloat-erf .  Changing  1//2 to bfhalf in this code didn't result in any testsuite failures, but I have a few pending changes to the function  absarg.

Also, loading gamma.lisp gives the warning: (SBCL)

 in: DEFUN GAMMA-INCOMPLETE
;     (COND ((COMPLEXP MAXIMA::X) #C(0.0d0 0.0d0)) ((REALP MAXIMA::X) 0.0d0))
; --> IF
; ==>
;   NIL
;
; caught STYLE-WARNING:
;   This is not a NUMBER:
;    NIL
;   See also:
;     The SBCL Manual, Node "Handling of Types"

I think this should be fixed.


________________________________
From: Barton Willis via Maxima-discuss <max...@li...>
Sent: Thursday, December 4, 2025 7:08 AM
To: <max...@li...> <max...@li...>
Subject: [Maxima-discuss] sometimes 1//2 =/= 1/2

Caution: Non-NU Email

The file globals.lisp defines 1//2 as ((rat simp) 1 2).  However, when I run the testsuite, I find that 1//2 is sometimes equal to a  bigfloat 1/2.

Specifically, out of 59,014 calls to the function absarg, 13,691 times 1//2 is a bigfloat half.
I noticed this when I saw that rpart.lisp defines a macro half that returns 1/2.  This macro was introduced eight years ago by Andreas Eder with the following commit message:
backed out the change that necessitated to relax the rel-error bounds
for the erf inverse_erf tests at +/- 2b0 and +/-2b0+/-2b0%i in rtest_gamma.mac.
The problem arises in the function absarg in rpart.lisp. Reintroduced
the half macro again for this use. It should make no difference, but the
code at this point seems to be a bit subtle :-)
Anyway, whith the old half macro instead of the variable 1//2 the test
results are unchanged.

I suspect the subtle problem is that something is converting 1//2 into a bigfloat 1/2  (with various values of fpprec).
There are hundreds of uses of 1//2 in the Maxima code. Changing the value of 1//2 is surely a bug.
Guess:  Fixing this bug will cause at least a handful of testsuite cases to fail.



--Barton