maxima-bugs Mailing List for Maxima -- GPL CAS based on DOE-MACSYMA

**FYI**: For the bit of code I was working with, I worked around this bug by using  `ask-integer` to determine the parity of the integer.   Not ideal, but it works.


---

**[bugs:#4760] crazy question: Is "1" zero or nonzero? from one-arg limit**

**Status:** open
**Group:** None
**Created:** Sat Jun 06, 2026 08:08 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 09:03 PM UTC
**Owner:** nobody


  This should either ask for the parity of `n`, or return something like `(-1)^n * minf`. It should not ask if `1' is zero or nonzero.
 
~~~
(%i1)	declare(n,integer)$

(%i2)	assume(n < 0)$

(%i3)	limit((-1)^n/zerob);
"Is "1" zero or nonzero?"nz;
(%o3)	minf
~~~



---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

- **status**: open --> closed
- **Comment**:

Was still open



---

**[bugs:#4585] Taylor polynomials involving tangent & a quotient**

**Status:** closed
**Group:** None
**Labels:** taylor 
**Created:** Wed Jul 23, 2025 08:18 PM UTC by Barton Willis
**Last Updated:** Fri Dec 19, 2025 06:01 PM UTC
**Owner:** nobody


This is, I think, OK
~~~
(%i34) taylor(tan(x)/(x-a),x,a,2);

(%o34) tan(a)/(x-a)+(tan(a)^2+1)+(tan(a)^3+tan(a))*(x-a)
                   +((3*tan(a)^4+4*tan(a)^2+1)*(x-a)^2)/3
~~~
But this is wrong: it should be more-or-less `%o34` with `%pi + 1` substituted for `a`:
~~~
(%i36) taylor(tan(x)/(x-%pi-1),x,%pi+1,2);
(%o36) 1+(x-%pi-1)^2/3
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

- **status**: open --> closed
- **Comment**:

Fixed by commit [a84283].



---

**[bugs:#4236] Repeated run\_testsuite leads to out of memory error**

**Status:** closed
**Group:** None
**Labels:** run\_testsuite sbcl 
**Created:** Fri Dec 29, 2023 11:34 PM UTC by Robert Dodier
**Last Updated:** Sun Mar 16, 2025 04:15 AM UTC
**Owner:** nobody


Working with Maxima built from commit 3a26747 with SBCL 2.3.7 on Ubuntu 16.04. Running the test suite twice, once with `share_tests = true`, leads to an out of memory error in either `rtest_ctensor` or `rtest_itensor` (seems to vary).
```
(%i1) run_testsuite (); run_testsuite (share_tests = true);
Testsuite run for SBCL 2.3.7:
Running tests in rtest_sqdnst: 13/13 tests passed
Running tests in rtest_extensions: 18/18 tests passed
Running tests in rtest_rules: 210/210 tests passed
[... etc etc ...]
Running tests in rtest_ilt: 31/31 tests passed
Running tests in ulp_tests: 63/63 tests passed


No unexpected errors found out of 13,463 tests.
Evaluation took:
  108.034 seconds of real time
  107.751332 seconds of total run time (102.396675 user, 5.354657 system)
  [ Real times consist of 4.411 seconds GC time, and 103.623 seconds non-GC time. ]
  [ Run times consist of 4.406 seconds GC time, and 103.346 seconds non-GC time. ]
  99.74% CPU
  9,620 forms interpreted
  12,149 lambdas converted
  248,913,931,560 processor cycles
  37,916,342,224 bytes consed
  
(%o0)                                done
(%i1) Testsuite run for SBCL 2.3.7:
Running tests in rtest_sqdnst: 13/13 tests passed
Running tests in rtest_extensions: 18/18 tests passed
Running tests in rtest_rules: 210/210 tests passed
[... etc etc ...]
Running tests in rtest_bernstein: 44/44 tests passed
Running tests in rtest_atensor: 20/20 tests passed
Running tests in rtest_ctensor: Thread local storage exhausted.
fatal error encountered in SBCL pid 15290 tid 15290:
%PRIMITIVE HALT called; the party is over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>    
```
I tried some variations of `run_testsuite` and that combination is what I found that seems to cause the error repeatably. 

I haven't tried to figure out what operation in `rtest_ctensor` or `rtest_itensor` is the immediate cause of the out of memory error. Possibly simplification rules? Just a wild guess.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

- **status**: open --> closed
- **Comment**:

Fixed by commit [a84283].



---

**[bugs:#4517] Maxima crashes on repeated run of rtest\_rules \(SBCL 2.5.2\)**

**Status:** closed
**Group:** None
**Labels:** crash rtest\_rules sbcl 
**Created:** Wed Mar 05, 2025 10:26 AM UTC by David Scherfgen
**Last Updated:** Mon Mar 10, 2025 03:30 PM UTC
**Owner:** nobody


On SBCL 2.5.2 (Windows), Maxima crashes after repeatedly running the `rtest_rules` test.

This also happens with much older snapshots of the Git repository (I tried end of 2023), too, so it's not caused by any recent changes. Maybe it's a bug in SBCL. I don't have much experience with the Lisp debugger, so maybe others can have a look at it.

```
(%i1) run_testsuite(tests=[rtest_rules]);
Testsuite run for SBCL 2.5.2:
Running tests in rtest_rules: Thread local storage exhausted.
fatal error encountered in SBCL pid 47081968:
%PRIMITIVE HALT called; the party is over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
```


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

- **status**: open --> closed
- **Comment**:

Fixed by commit [fe1ee8].



---

**[bugs:#4757] %e^2.0, %emode:false stays %e^2.0**

**Status:** closed
**Group:** None
**Labels:** %emode simplification 
**Created:** Sat Jun 06, 2026 07:14 AM UTC by David Scherfgen
**Last Updated:** Sat Jun 06, 2026 07:14 AM UTC
**Owner:** nobody


According to the manual, `%emode` only controls the simplification of expressions of the type `%e^(%i*%pi*x)`. But when it's set to `false`, it also prevents `%e^2.0` from becoming a float:

~~~
/* OK: */
(%i1) %e^2.0;
(%o1) 7.38905609893065

/* Wrong: */
(%i2) %e^2.0, %emode:false;
(%o2) %e^2.0
~~~

This is caused by `simpexpt` wrapping the code that would do this correctly inside `(when $%emode ...`.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re "the current scheme of converting to factorial form", it does produce some strange results, but it simplifies the code compared to handling **gamma** and **!** separately.

The original sin is of course supporting two distinct functions. But they are not handled symmetrically. For example, there is **minfactorial** but no **mingamma**, so you need to do something like **makegamma(minfactorial(makefact(ex)))**. But **gammalim** doesn't apply to **factorial**. **makegamma** works on **pochhammer**, and **makefactorial** doesn't. But **pochhammer(1,x)** returns **x!** and not **gamma(x+1)**. **stirling** works on **gamma** but not **!**.

Presumably some users prefer one and others prefer the other. (I hope that no real users (as opposed to perverse testers like you and me) write expressions like **x!/gamma(x)**.) This is different from **sin** and **cos**, where they are invariably used together, even though they are related in a similar way.

The "obvious" solution is to use one of them universally as the *internal representation*, and only support the other as an input/output form, perhaps under the control of a switch, e.g., **show_gammafact**. So with **show_gammafact=factorial**, **gamma(x)** would display as **(x-1)!**.

We could  even set that variable when the user enters one or the other, but that might be more and not less confusing for users....

All this to say that it's not a **limit** problem.




---

**[bugs:#4758] limits of the form gamma\(ind\)**

**Status:** open
**Group:** None
**Labels:** limit gamma 
**Created:** Sat Jun 06, 2026 06:55 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 09:34 PM UTC
**Owner:** nobody


Should be `ind`, not `und`:

~~~
(%i1)	limit(gamma(4+sin(x)),x,inf);
(%o1)	und
~~~

Related bug:  should be 0, not `und`
~~~
(%i2)	limit(gamma(4+sin(x))/x,x,inf);
(%o2)	und
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

By defining a  `simplim%function` for the gamma function, it's not too hard to catch some easy cases.  For that scheme to work, you also have to turn off the way the limit code converts all gamma expressions into factorial expressions (that happens in the function `extra-simp`). 

All this could, I suppose be done with the current scheme of converting to factorial form, but I think that the following is inelegant:
~~~
(%i3) limit(gamma(x),x,2/3);
(%o3) (-(1/3))!
~~~
Surely most users would prefer `gamma(2/3)`. To fix up other problems that surface by making such changes requires a fair amount of work. 

Simple demo from a work in progress:
~~~

(%i5) limit(gamma(5+sin(x)),x,inf);
(%o5)                                 ind

(%i6) limit(gamma(5+sin(x))/x,x,inf);
(%o6)                                  0
~~~


---

**[bugs:#4758] limits of the form gamma\(ind\)**

**Status:** open
**Group:** None
**Labels:** limit gamma 
**Created:** Sat Jun 06, 2026 06:55 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 09:13 PM UTC
**Owner:** nobody


Should be `ind`, not `und`:

~~~
(%i1)	limit(gamma(4+sin(x)),x,inf);
(%o1)	und
~~~

Related bug:  should be 0, not `und`
~~~
(%i2)	limit(gamma(4+sin(x))/x,x,inf);
(%o2)	und
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

``limit`` (and in fact Maxima in general) has minimal understanding of intervals and interval arithmetic. For example, ``sign(x^2+sin(x)+2) => pnz``.

It would be great to fix that, but it's not really a "bug", but "known limitation". In the ``gamma`` example, ``und`` is "correct" in the best-effort sense, because it includes the ``zero`` case.


---

**[bugs:#4758] limits of the form gamma\(ind\)**

**Status:** open
**Group:** None
**Labels:** limit gamma 
**Created:** Sat Jun 06, 2026 06:55 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 06:55 PM UTC
**Owner:** nobody


Should be `ind`, not `und`:

~~~
(%i1)	limit(gamma(4+sin(x)),x,inf);
(%o1)	und
~~~

Related bug:  should be 0, not `und`
~~~
(%i2)	limit(gamma(4+sin(x))/x,x,inf);
(%o2)	und
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Agreed this is a bug.

Single-argument ``limit`` isn't supposed to return things like ``(-1)^n*minf``, but to resolve them. In this case, I think the only correct result is ``infinity``, which is what it returns for ``limit((-1)^x/zerob)`` and ``limit((-1)^(-x^2-1)/zerob)`` with no declarations on ``x``.



---

**[bugs:#4760] crazy question: Is "1" zero or nonzero? from one-arg limit**

**Status:** open
**Group:** None
**Created:** Sat Jun 06, 2026 08:08 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 08:08 PM UTC
**Owner:** nobody


  This should either ask for the parity of `n`, or return something like `(-1)^n * minf`. It should not ask if `1' is zero or nonzero.
 
~~~
(%i1)	declare(n,integer)$

(%i2)	assume(n < 0)$

(%i3)	limit((-1)^n/zerob);
"Is "1" zero or nonzero?"nz;
(%o3)	minf
~~~



---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4760] crazy question: Is "1" zero or nonzero? from one-arg limit**

**Status:** open
**Group:** None
**Created:** Sat Jun 06, 2026 08:08 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 08:08 PM UTC
**Owner:** nobody


  This should either ask for the parity of `n`, or return something like `(-1)^n * minf`. It should not ask if `1' is zero or nonzero.
 
~~~
(%i1)	declare(n,integer)$

(%i2)	assume(n < 0)$

(%i3)	limit((-1)^n/zerob);
"Is "1" zero or nonzero?"nz;
(%o3)	minf
~~~



---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4759] limits of gamma toward a negative integer**

**Status:** open
**Group:** None
**Labels:** limit gamma 
**Created:** Sat Jun 06, 2026 07:09 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 07:09 PM UTC
**Owner:** nobody


Wrong--when `n` is a negative integer, this limit is undefined:
~~~
(%i1)	declare(n,integer);
(%o1)	done

(%i2)	limit(gamma(x),x,n);
(%o2)	(n-1)!
~~~
Let's assume `n` is negative:
~~~
(%i3)	assume(n < 0);
(%o3)	[n<0]

(%i4)	limit(gamma(x),x,n,plus);
(%o4)	inf
~~~

No, Maxima needs to ask if `n` is even or odd--consider:
~~~
(%i5)	limit(gamma(x),x,-5,plus);
(%o5)	minf

(%i6)	limit(gamma(x),x,-5, minus);
(%o6)	inf
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4758] limits of the form gamma\(ind\)**

**Status:** open
**Group:** None
**Labels:** limit gamma 
**Created:** Sat Jun 06, 2026 06:55 PM UTC by Barton Willis
**Last Updated:** Sat Jun 06, 2026 06:55 PM UTC
**Owner:** nobody


Should be `ind`, not `und`:

~~~
(%i1)	limit(gamma(4+sin(x)),x,inf);
(%o1)	und
~~~

Related bug:  should be 0, not `und`
~~~
(%i2)	limit(gamma(4+sin(x))/x,x,inf);
(%o2)	und
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4757] %e^2.0, %emode:false stays %e^2.0**

**Status:** open
**Group:** None
**Labels:** %emode simplification 
**Created:** Sat Jun 06, 2026 07:14 AM UTC by David Scherfgen
**Last Updated:** Sat Jun 06, 2026 07:14 AM UTC
**Owner:** nobody


According to the manual, `%emode` only controls the simplification of expressions of the type `%e^(%i*%pi*x)`. But when it's set to `false`, it also prevents `%e^2.0` from becoming a float:

~~~
/* OK: */
(%i1) %e^2.0;
(%o1) 7.38905609893065

/* Wrong: */
(%i2) %e^2.0, %emode:false;
(%o2) %e^2.0
~~~

This is caused by `simpexpt` wrapping the code that would do this correctly inside `(when $%emode ...`.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

- Description has changed:

Diff:

~~~~

--- old
+++ new
@@ -9,7 +9,7 @@
 
 /* Wrong, %e in base with symbolic exponent
    should only be replaced by numerical value
-      when %enumer is true: */
+    when %enumer is true: */
 (%i3) expand(sin(%e^x)), numer;
 (%o3) sin(2.718281828459045^x)
 ~~~

~~~~




---

**[bugs:#4756] expand\(sin\(%e^x\)\), numer incorrectly replaces %e with numerical value**

**Status:** open
**Group:** None
**Labels:** %enumer numer simplification 
**Created:** Sat Jun 06, 2026 06:16 AM UTC by David Scherfgen
**Last Updated:** Sat Jun 06, 2026 06:16 AM UTC
**Owner:** nobody


~~~
/* OK: */
(%i1) %e^x, numer;
(%o1) %e^x

/* Also OK: */
(%i2) sin(%e^x), numer;
(%o2) sin(%e^x)

/* Wrong, %e in base with symbolic exponent
   should only be replaced by numerical value
    when %enumer is true: */
(%i3) expand(sin(%e^x)), numer;
(%o3) sin(2.718281828459045^x)
~~~

This is caused by `simpcheck` setting `%enumer` to `$numer`, which always seemed odd to me.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4756] expand\(sin\(%e^x\)\), numer incorrectly replaces %e with numerical value**

**Status:** open
**Group:** None
**Labels:** %enumer numer simplification 
**Created:** Sat Jun 06, 2026 06:16 AM UTC by David Scherfgen
**Last Updated:** Sat Jun 06, 2026 06:16 AM UTC
**Owner:** nobody


~~~
/* OK: */
(%i1) %e^x, numer;
(%o1) %e^x

/* Also OK: */
(%i2) sin(%e^x), numer;
(%o2) sin(%e^x)

/* Wrong, %e in base with symbolic exponent
   should only be replaced by numerical value
      when %enumer is true: */
(%i3) expand(sin(%e^x)), numer;
(%o3) sin(2.718281828459045^x)
~~~

This is caused by `simpcheck` setting `%enumer` to `$numer`, which always seemed odd to me.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4755] some limits involving definite integrals**

**Status:** open
**Group:** None
**Labels:** limit simplim%function 
**Created:** Thu Jun 04, 2026 02:48 PM UTC by Barton Willis
**Last Updated:** Thu Jun 04, 2026 02:48 PM UTC
**Owner:** nobody


The operator `%integrate` has a `simplim%function`.  This contributes to this bug:

~~~
(%i38) xxx : integrate(1/(x + exp(-x)),x,1,z)/z;
(%o38) ('integrate(1/(x+%e^-x),x,1,z))/z

(%i39) limit(xxx,z,inf);
(%o39) 0
~~~

Defining   `simplim%functions` for sums and products would likely create similar bugs.




---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Should `rectform` behave the same way?


---

**[bugs:#4654] sign of nonscalar inconsistent**

**Status:** open
**Group:** None
**Labels:** sign nonscalar 
**Created:** Wed Dec 24, 2025 07:59 PM UTC by Stavros Macrakis
**Last Updated:** Fri Dec 26, 2025 09:42 PM UTC
**Owner:** nobody


~~~
declare(mm,nonscalar);
sign([1,2,3]) => pnz   << an example of a non-scalar
sign(mm) => pnz
sign([1,2,3]^2) => pnz
sign(mm^2) => pz     <<< ???
sign(mm^^2) => pnz   <<< OK
~~~
or should ``sign(nonscalar)`` give an error exactly like ``sign(%i)``?


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4754] some limits of the form ind/ind**

**Status:** open
**Group:** None
**Labels:** limit indeterminates 
**Created:** Wed Jun 03, 2026 09:42 PM UTC by Barton Willis
**Last Updated:** Wed Jun 03, 2026 09:42 PM UTC
**Owner:** nobody


Maxima gets some limits of the form `ind/ind` correct; for example
~~~
(%i12) limit(sin(x)/(3+sin(x)),x,inf);
(%o12)                                ind
~~~
But Maxima misses other cases:
~~~
(%i13) limit(sin(x)/(3+sin(x)+cos(x)),x,inf);
(%o13)                                und
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

- **status**: open --> closed
- **Comment**:

Fixed by commit	[4c2ce8].



---

**[bugs:#4752] csign doesn't handle subscripted functions like li correctly**

**Status:** closed
**Group:** None
**Labels:** csign sign complex li 
**Created:** Wed Jun 03, 2026 10:29 AM UTC by David Scherfgen
**Last Updated:** Wed Jun 03, 2026 10:29 AM UTC
**Owner:** nobody


OK for normal functions:

~~~
(%i1) declare(f, complex)$

(%i2) csign(f(x));
(%o2) complex
~~~

Wrong for subscripted functions like `li`:

~~~
(%i1) featurep(li, complex);
(%o1) true

(%i2) csign(li[n](x));
(%o2) pnz
~~~

Caused by this code in `sign-any` (compar.lisp) not handling subscripted functions correctly:

~~~
        ((and *complexsign*
              (not (atom x))
              (decl-complexp (caar x)))
         ;; A function f(x), where f is declared to be imaginary or complex.
         (if ($featurep (caar x) '$imaginary)
             (setq sign '$imaginary)
             (setq sign '$complex)))
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4753] some limits of gamma toward minf**

**Status:** open
**Group:** None
**Labels:** limit 
**Created:** Wed Jun 03, 2026 10:32 AM UTC by Barton Willis
**Last Updated:** Wed Jun 03, 2026 10:32 AM UTC
**Owner:** nobody


Wrong:
~~~
(%i9)	xxx : %e^-x*gamma(-x)*(x+1)^(x+1/2)*sin(%pi*x);
(%o9) %e^-x*gamma(-x)*(x+1)^(x+1/2)*sin(%pi*x)

(%i10)	limit(xxx, x,inf);
(%o10) und
~~~

A correct value is
~~~
-%e * sqrt(%pi/2)
~~~

Negative integers are not in the natural domain of `xxx`, but `xxx` does analytically continue to the negative integers.


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

**[bugs:#4752] csign doesn't handle subscripted functions like li correctly**

**Status:** open
**Group:** None
**Labels:** csign sign complex li 
**Created:** Wed Jun 03, 2026 10:29 AM UTC by David Scherfgen
**Last Updated:** Wed Jun 03, 2026 10:29 AM UTC
**Owner:** nobody


OK for normal functions:

~~~
(%i1) declare(f, complex)$

(%i2) csign(f(x));
(%o2) complex
~~~

Wrong for subscripted functions like `li`:

~~~
(%i1) featurep(li, complex);
(%o1) true

(%i2) csign(li[n](x));
(%o2) pnz
~~~

Caused by this code in `sign-any` (compar.lisp) not handling subscripted functions correctly:

~~~
        ((and *complexsign*
              (not (atom x))
              (decl-complexp (caar x)))
         ;; A function f(x), where f is declared to be imaginary or complex.
         (if ($featurep (caar x) '$imaginary)
             (setq sign '$imaginary)
             (setq sign '$complex)))
~~~


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Lots of things should raise errors that don't currently:
~~~
assume(true>false)$ is(true>false) => unknown$
sign(a=b) => pnz
asksign({})
~~~

These are not real numbers in the mathematical sense (members of **R**) -- in fact, they are not numbers at all: ``ind, und, inf, minf, zeroa, zerob``, but they are real in the sense of not having a non-zero imaginary part (as opposed to ``infinity``), which is probably what is needed by most uses.



---

**[bugs:#4749] Declaring a symbol both real and complex or real and imaginary**

**Status:** maybe-fixed
**Group:** None
**Labels:** declare rectform featurep csign 
**Created:** Mon Jun 01, 2026 07:19 AM UTC by David Scherfgen
**Last Updated:** Tue Jun 02, 2026 09:30 AM UTC
**Owner:** nobody


Maxima allows declaring a symbol both `real` and `complex` and even both `real` and `imaginary`. I think that in the second case, it should at least issue a warning, if not an error.

For the first case, where a symbol is declared both `real` and `complex`, Maxima behaves differently across `csign`, `rectform` and `featurep`:

~~~
(%i1) declare(x, real, x, complex);
(%o1) done

(%i2) csign(x);
(%o2) complex

(%i3) rectform(x);
(%o3) x

(%i4) featurep(x, real);
(%o4) true

(%i5) featurep(x, complex);
(%o5) true
~~~

These functions all have a different concept ...


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

I like your pragmatic definition.
We should extend `risplit` so that it can raise errors (controlled by a flag) for expressions that do not describe real or complex numbers, for example `true`, `false`, `und`, `ind`, `inf`, `minf`, lists, equations, inequalities, sets, matrices, ...
Then we can safely rely on `risplit` in `$featurep`.


---

**[bugs:#4749] Declaring a symbol both real and complex or real and imaginary**

**Status:** maybe-fixed
**Group:** None
**Labels:** declare rectform featurep csign 
**Created:** Mon Jun 01, 2026 07:19 AM UTC by David Scherfgen
**Last Updated:** Tue Jun 02, 2026 07:03 AM UTC
**Owner:** nobody


Maxima allows declaring a symbol both `real` and `complex` and even both `real` and `imaginary`. I think that in the second case, it should at least issue a warning, if not an error.

For the first case, where a symbol is declared both `real` and `complex`, Maxima behaves differently across `csign`, `rectform` and `featurep`:

~~~
(%i1) declare(x, real, x, complex);
(%o1) done

(%i2) csign(x);
(%o2) complex

(%i3) rectform(x);
(%o3) x

(%i4) featurep(x, real);
(%o4) true

(%i5) featurep(x, complex);
(%o5) true
~~~

These functions all have a different concept ...


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

- **status**: open --> maybe-fixed
- **Comment**:

I pushed commit [46cd19], which restores some numerical inferences, detects lots of inconsistent type declarations and greatly simplifies `decl-realp`. The issue "real vs. complex" is not resolved yet.



---

**[bugs:#4749] Declaring a symbol both real and complex or real and imaginary**

**Status:** maybe-fixed
**Group:** None
**Labels:** declare rectform featurep csign 
**Created:** Mon Jun 01, 2026 07:19 AM UTC by David Scherfgen
**Last Updated:** Mon Jun 01, 2026 10:40 PM UTC
**Owner:** nobody


Maxima allows declaring a symbol both `real` and `complex` and even both `real` and `imaginary`. I think that in the second case, it should at least issue a warning, if not an error.

For the first case, where a symbol is declared both `real` and `complex`, Maxima behaves differently across `csign`, `rectform` and `featurep`:

~~~
(%i1) declare(x, real, x, complex);
(%o1) done

(%i2) csign(x);
(%o2) complex

(%i3) rectform(x);
(%o3) x

(%i4) featurep(x, real);
(%o4) true

(%i5) featurep(x, complex);
(%o5) true
~~~

These functions all have a different concept ...


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Maxima is not very consistent about all this. For example, we have the ``domain=real/complex`` variable which sounds very powerful, but in fact the only thing it affects is the simplification of ``(a^b)^c`` as far as I can tell.

One pragmatic definition of ``kind(z,complex)`` is that ``imagpart(z)`` returns the nounform ``'imagpart(z)`` and not 0. 

Grepping through the code, it looks as though there are three ways that the declaration is used:  ``kindp, decl-complexp, featurep``. These are used for ``real/complex/imaginary`` in the files ``compar (sign-any), conjugate (manifestly-XXX-p), rpart, simp``.  But I haven't looked at the transitive closure of function calls....



---

**[bugs:#4749] Declaring a symbol both real and complex or real and imaginary**

**Status:** open
**Group:** None
**Labels:** declare rectform featurep csign 
**Created:** Mon Jun 01, 2026 07:19 AM UTC by David Scherfgen
**Last Updated:** Mon Jun 01, 2026 09:19 PM UTC
**Owner:** nobody


Maxima allows declaring a symbol both `real` and `complex` and even both `real` and `imaginary`. I think that in the second case, it should at least issue a warning, if not an error.

For the first case, where a symbol is declared both `real` and `complex`, Maxima behaves differently across `csign`, `rectform` and `featurep`:

~~~
(%i1) declare(x, real, x, complex);
(%o1) done

(%i2) csign(x);
(%o2) complex

(%i3) rectform(x);
(%o3) x

(%i4) featurep(x, real);
(%o4) true

(%i5) featurep(x, complex);
(%o5) true
~~~

These functions all have a different concept ...


---

Sent from sourceforge.net because max...@li... is subscribed to https://sourceforge.net/p/maxima/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/maxima/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.