Activity for Stavros Macrakis
-
Stavros Macrakis posted a comment on ticket #198
Today, we have sort(list) and sort(list,predicate fun). What if we allow sort(list,key) where key can be a number or a list of numbers which specify the keys? Fully compatible, although it does violate the principle that static analysis should tell you the meaning. For example, sort(...,f) could mean sort by a function or sort by a key specification, depending on the value of f. We could compatibly also add sort(list,predicate fun,keyfun), maybe using false to specify the default predicate.
-
sign("foo") => Lisp error
-
sign("foo") => Lisp error
-
sign of nonscalar inconsistent
-
floor/ceiling/round of large bfloats gives errors
-
floor/ceiling/round of large bfloats gives errors
-
Range reduction for periodic trig functions
-
complexify fails on rats
-
Interrupt ctrl G does not work and cannot do anything but ctrl-alt-del and lose all
-
This has to do with your local environment. In MacOS, I can interrupt a Maxima started in a Terminal window with one Control-C. Under Emacs, I can interrupt it with two Control-Cs.
-
I can't seem to reproduce that error in Maxima 5.48.1 SBCL 2.5.7. map('nfloat, [1,1.0,1.0b0,2/3,x,1.0*x,1.0b0*x,2/3*x, x/y,2*x/y,2/3*x/y,1.0*x/y,1.0b0*x/y, %i*x,%i*1.0*x,%i*1.0b0*x,%i*2/3*x, %i*x/y,%i*2*x/y,%i*2/3*x/y,%i*1.0*x/y,%i*1.0b0*x/y, 1+%i*x,1+%i*1.0*x,1+%i*1.0b0*x,1+%i*2/3*x,1+%i*x/y, 1+%i*2*x/y,1+%i*2/3*x/y,1+%i*1.0*x/y,1+%i*1.0b0*x/y]) => no errors Maybe a bug has been introduced into nfloat recently? Of course, it's hard to know what's a bug and what isn't because nfloat isn't docume...
-
bfloat((x+1)/x includes unnecessary 1.0b0 factor
-
I tried using SBCL native complexes (following Barton's idea) and I don't get overflow, but the answer is off by a hundred ULPs, which is the sort of thing to expect with "naive" complex float division. (defun $cldiv (a b) (let* ((recta (risplit a)) (ac (complex (car recta) (cdr recta))) ; will err out if not numeric (rectb (risplit b)) (bc (complex (car rectb) (cdr rectb))) (q (/ ac bc))) (add (realpart q) (mul '$%i (imagpart q))))) bfdiv(a,b):=block([fpprec:32],float(rectform(bfloat(a)/bfloat(b))));...
-
I do not know why t[2] doesn't return a matrix. Maxima defines a matrix as being composed of rows, each of which is a vector/list. t[2] is the second row, and is a list, not a matrix. If you want the second row as a matrix, you can use row(M,2), which gives a nx1 matrix, not a list. col(M,2) gives an 1xn matrix. But, beware! You can modify the parent matrix via the rows, but not via the columns. I'd like to say that this is all beautifully designed, but frankly it was probably just an expedient way...
-
You don't seem to be paying attention to what Raymond and I are telling you. The list [0.1] is not the same as the number 0.1. Maxima does allow arithmetic on lists, so that 0.1*[2] yields [0.2]. But that is not equal to 0.2.
-
rectform/polarform complex division overflow
-
bfloat((x+1)/x includes unnecessary 1.0b0 factor
-
A matrix is a value like any other value. For example: ~~~ normmat(M):= block([r,c,d], r: length(M), c: length(M[1]), d: determinant(M), if d=0 then error("normmat needs det(M) to be nonzero"), M/abs(d)^(1/r) )$ ee: matrix([1,2],[3,4]); normmat(ee) => matrix([sqrt(2),2^(3/2)],[3*sqrt(2),2^(5/2)]) determinant(%) => -1 ~~~
-
Perhaps you should look at the value of flatten(t)[2]: t:matrix([1],[2])$ flatten(t)[2] => [2] In some systems (e.g. R), a singleton value is the same as a vector of length 1. That is not true in Maxima or most other systems, as you can verify: is([2]=2) => false "Of coourse it should work like it is supposed to without either any of these extra things." Comments like this are inappropriate in a bug report, for multiple reasons: * It is obnoxiously phrased. "Of course" is presumptuous. * It presumes...
-
I don't understand what you mean by "make a function of a matrix". A Maxima variable can be assigned or bound to a matrix just like anything else. Of course (fmat(matc):=disp(]matc]),fmat(matb)) has mismatched parentheses and gives a sensible (not bogus) error message. Surely you meant (fmat(matc):=disp([matc]),fmat(matb)), but I'm not sure why you wrote that rather than say (fmat(matc):=disp(matc),fmat(matb)). By the way, writing multiple commands on one line like that is a bit less clear than writing...
-
I don't understand what you mean by "make a function of a matrix". A Maxima variable can be assigned or bound to a matrix just like anything else. Of course (fmat(matc):=disp(]matc]),fmat(matb)) has mismatched parentheses. Surely you meant (fmat(matc):=disp([matc]),fmat(matb)), but I'm not sure why you wrote that rather than say (fmat(matc):=disp(matc),fmat(matb)). By the way, writing multiple commands on one line like that is a bit less clear than writing it on multiple lines as e.g.: fmat(matc):=disp(matc)$...
-
Negative zero not normalized, but 0.0 == -0.0 (not a problem!)
-
See https://sourceforge.net/p/maxima/bugs/4642/ for the csign problem.
-
sign(1.0e-310*%i) gives error because 1e-310*x/1e-310 fails
-
In addition to the 0.0/-0.0 case that you mention (hypotenouse-binary64 1e-170 0.0) => 0.0 -- should be 1e-170 it isn't right for denormalized numbers: (hypotenouse-binary64 1e-323 1e-323) => 3.1467296279827185e-308 (* 1e-323 (sqrt 2.0)) => 1.4821969375237396e-323 PS By the way, although I appreciate the spelling hypotenouse as being more faithful to the Greek (ὑποτείνουσα), that's not the usual English spelling.
-
On Mon, Dec 1, 2025 at 11:03 AM Raymond Toy via Maxima-bugs maxima-bugs@lists.sourceforge.net wrote: Here's one way for doing cabs(x+%iy), where x is a number. Divide by the arg by sqrt(x) to get cabs(sqrt(x)+%iy/sqrt(x)) = sqrt(y^2/x+x). The final answer will be sqrt(x)*sqrt(y^2/x+x). Something similiar if y is a number. I don't know how to do this if both x and y are more complicated expressions composed of numbers + variables. Can you give some examples? Are you thinking of, say, cabs((x+1e200)+%i)?...
-
We should be able to do this right. The classic algorithms for complex numbers are well documented (and pretty simple). For more complicated things like say Z: 1e140x + %i1e+170, cabs(Z), it's not much more complicated. It goes something like this: risplit(Z) => [1e140x, %i1e+170]; map('numericcoeff,%%) => [1e140, 1e170]... and then Something like cabs(multthru(1e-155Z))1e155 does the trick. On Mon, Dec 1, 2025 at 11:03 AM Raymond Toy via Maxima-bugs maxima-bugs@lists.sourceforge.net wrote: Here's...
-
I was concerned by bigfloat:to, not bigfloat:signum because I assumed that it converted all numbers to bigfloats, and consing up and normalizing a bigfloat is not free. But that isn't what it does. Very confusing name! Is it naive of me to think that something named bigfloat:to converts its argument to a bigfloat? I see that the bigfloat class also supports complex number objects, which is great ... although I'm not sure how you use that from Maxima (maybe a future extension to translate?). For existing...
-
Really? That seems like a sledgehammer for a tiny nut. Classical numerical techniques are simple and effective. Just because machines are 1000x faster now doesn't mean we should make our code 10x slower when there is a food alternative. On Sat, Nov 29, 2025, 17:40 Barton Willis via Maxima-bugs maxima-bugs@lists.sourceforge.net wrote: The current signum(2.3) => 1.0 behavior comes from a call to the bigfloat code: (maxima::to (bigfloat::signum (bigfloat::to x))))) I'm not the right person to alter...
-
cabs/carg/polarform overflow and underflow
-
I agree with Ray. I don't see what we gain by having signum(2.3)=>1.0. (I may have argued the opposite in the past...?)
-
This code has serious problems. First of all, it overflows and underflows: signum(1e-170) => division by zero signum(1e-170 + %i*1e-170) => ERROR signum(1e170 + %i*1e+170) => ERROR signum(1e170 ) => ERROR Secondly, it is using the messy and expensive algebraic operation for the simple real numeric case, where that case is already handled efficiently below (should check that im#0). Third, the type of the result is inconsistent: signum(1.0) => 1.0 signum(abs(x)+1.0) => 1 signum(exp(x)*2.0) => 1 (although...
-
Not sure when this code got in here: ($expand (div x (ftake 'mexpt (add (mul re re) (mul im im)) 1//2)) 1 0)) but that seems like a silly way to handle the real case (and makes the rest of the code unnecessary for real numerical inputs). Presumably this should not be used when im=0.
-
expand not idempotent (simplus)
-
Thanks for the quick reply! I see that contrib/altsimp has very different code for simplus than src/simp does. Has it been promoted to the default simplus now? Or are there known problems with it? Or are we afraid that there are unknown problems with it?
-
expand not idempotent (orderlessp?)
-
expand not idempotent (orderlessp?)
-
%solve(abs(sin(x))=1,x) misses solutions
-
%solve(abs(sin(x))=1,x) misses solutions
-
box(inf) causes infinite recursion in limit and integrate
-
box(inf) causes infinite recursion in limit and integrate
-
On Wed, Oct 29, 2025 at 4:07 PM David Scherfgen tomasriker@users.sourceforge.net wrote: I'm not a friend of the idea that the simplifier should introduce inf or minf. Agreed. 1) The simplifier doesn't know anything about these symbols, not even that minf = -inf. It turns inf + inf into 2*inf and inf - inf into 0. Arguably, this could be changed, but I bet there's lots of code that operates on assumptions that would no longer be true then. I plan to fix this sometime in 2026, but I don't know when...
-
Maxima's default floating-point system is machine floating point (typically 64-bit IEEE 754, ~16 decimal digits of precision, limited to ~2^1024), and uses conventional one-pass bottom-up expression evaluation, so float(cos(2^10000)) is in effect t1 <- 2^10000 (a very large integer); t2 <- float(t1); t3 <- sin(t2). The overflow happens with float(t1), and the cos function never even "sees" the argument. Maxima also provides an arbitrary fixed-precision floating point type called bfloat or bigfloat....
-
Maxima's default floating-point system is machine floating point (typically 64-bit IEEE 754, ~16 decimal digits of precision, limited to ~2^1024), and uses conventional one-pass bottom-up expression evaluation, so float(cos(2^10000)) is in effect t1 <- 2^10000 (a very large integer); t2 <- float(t1); t3 <- sin(t2). The overflow happens with float(t1), and the cos function never even "sees" the argument. Maxima also provides an arbitrary fixed-precision floating point type called bfloat or bigfloat....
-
That would be a nice quick patch, but it would be really nice to find the root cause and fix that.
-
gcfactor should factor gaussian rationals
-
gcfactor requires explicit gaussian integer
-
gcfactor(4), expand(%%) => -4
-
Correctly returns minf on Maxima 5.41.0 ECL 16.1.3 (MaximaOnAndroid)
-
Another workaround is map('trigreduce,cos(1/2*acos(q))^2*sin(1/2*acos(q))^2) => (1-q)*(1+q)/4 but of course that doesn't fix the bug.
-
Couldn't we replace (or (not (free...))) with a call to amongl and avoid traversing e 5 times? Does anyone understand the expand(e,1,1) clause? Why expand the expresson before testing for the presence of non-finite objects?
-
2pistrip as written (in 197x) was intended to be strictly syntactic, and to operate with minimal consing, and certainly without calling $floor, which in general uses bfloats via pretty-good-floor-or-ceiling. Time and space were precious. So this isn't a bug (operates as designed), but probably a misfeature. That said, the trig simplifiers don't handle many cases of %pi reduction either: sin(%pi*67/5) => unchanged (could be -sin(2/5*%pi)) sin(10) => unchanged sin(10+%pi/5) => unchanged The first case...
-
Agreed that inf-inf => 0 is a much more common case. Perhaps have some sort of structured comment in the code when we notice cases like this. e.g. ;;; BAD atan2(inf,inf)
-
floor fails with factored argument
-
askinteger is extremely weak. With declare(ii,integer)$ , it doesn't know that all of the following are always integer-valued: (-1)^ii ii*(ii+1)/2 sin(ii*%pi/2) and that the following are never integer-valued: ii+1/2 %pi*ii sin(ii) log(ii) %e^ii All of these seem much more likely to arise "in the wild" and be useful to users than the %i*%pi case. I have generalized https://sourceforge.net/p/maxima/bugs/4605/ to include them. -s On Wed, Sep 3, 2025 at 1:26 PM David Scherfgen via Maxima-bugs maxima-bugs@lists.sourceforge.net...
-
askinteger extremely weak
-
We need to write a FAQ about floating point. Of course it is the same in every other system, but Maxima also has bigfloats and rationals, which are helpful for discussing floats. For example: rationalize -- converts a floating point number to the exact rational number it is equal to -- the denominator is always a power of 2 rationalize(10.0/3.0) - 1/3 => 1/6755399441055744 ... float(%) => 1.4802973661668753e-16 rat -- finds the "nicest" rational within ratepsilon (default 2.0e-15) of a float 10.0/3.0...
-
Sounds good.
-
Hmm. The current behavior gives the user more control -- they can choose to push the factor into as many levels of some as they want. If it were recursive, how could the user push it in just one level?
-
I upgraded to 5.48.1 (using brew) and the result is identical.
-
I'll update to 5.48.1 and see if that fixes it. Maxima 5.48.0 https://maxima.sourceforge.io using Lisp SBCL 2.5.7 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) ( display2d:false, leftjust:true, linel:70 )$ (%i2) xxx: x^3+3*%i*x^2+3*x^2+6*%i*x+2*%i-2$ (%i3) solve(xxx,x); expt: undefined: 0^0 -- an error. To debug this try: debugmode(true); (%i4) algebraic:true; (%o4) true...
-
xxx : (x^2 + 1+%i)^3$ solve(expand(xxx),x) For all values of gcd, solve(expand(xxx),x) gives an error with algebraic:false and the correct answer with algebraic:true. The answer is ridiculously large and ''not'' correctly simplified (i.e. expand(...,0,0) changes it). But expand and rectform reduce it to the simple answer. algebraic:true$ solve(expand(xxx),x)[1] => - 1 sqrt(3) %i x = (─── - ──────────) 2 2 3 6 (3 %i + 3) %i - 3 (2 %i - 2) - 1 (3 %i + 3) 1/3 (────────────────────────────── + ───────────────)...
-
xxx : (x^2 + 1+%i)^3$ solve(expand(xxx),x) For all values of gcd, solve(expand(xxx),x) gives an error with algebraic:false and the correct answer with algebraic:true. Although the answer is simplified (i.e. expand(...,0,0) leaves it unchanged), it is ridiculously large. But expand and rectform reduce it to the simple answer. algebraic:true$ solve(expand(xxx),x)[1] => - 1 sqrt(3) %i x = (─── - ──────────) 2 2 3 6 (3 %i + 3) %i - 3 (2 %i - 2) - 1 (3 %i + 3) 1/3 (────────────────────────────── + ───────────────)...
-
same error for xxx:(x+%i+1)^3
-
Ah! The documentation is actually at a different place (not devine): /share/contrib/guess/guess.info That clarifies that "product" here means not multiplication, but an indexed product(...). Which also explains how it handles 2^n = product(2,i,1,n) and n! = product(i,i,1,n).
-
The doc is also bizarre because on the one hand, a product of rational functions is itself a rational function, and on the other hand, it handles cases which aren't listed there, like geometric series: guess([1,1/2,1/4,1/8]) => [2^(1-i0),2^(1-i0)] ~~~~ Each item in the return list is supposed to be a different expression, but here they're all the same. ~~~~ guess(makelist(2^i,i,0,10)) => [2^(i0-1),2^(i0-1),2^(i0-1),2^(i0-1),2^(i0-1),2^(i0-1),2^(i0-1),2^(i0-1),2^(i0-1)]
-
guess fails on trivial cases
-
I think the OP did in fact include multiplication signs. But sourceforge interpreted them as formatting. Compare this (in text mode): ab^35 with this (in code mode): a*b^3*5 The text I entered is the same in both cases, but in the first, the asterisk is interpreted as "start italics". As far as I can tell, there isn't any way to see the OP's raw input, but you can look at the italic transitions and reconstruct their input as n(x) := integrate((1-1/t)^t*%e^(%e*t), t, %e, x); which is what you suggested....
-
ERROR! The markdown supplied could not be parsed correctly. Did you forget to surround a code snippet with "~~~~"?Your traces include *zeroa* as well as *zerob*, so it's strange that *zeroa *doesn't show up in the code. And when is *zero* used? A quick glance at the code suggests that it's only used as a result from *sign* and is some sort of leftover in *hayat.* On Mon, Jun 30, 2025 at 8:39 AM Barton Willis via Maxima-bugs < maxima-bugs@lists.sourceforge.net> wrote: > *Oberservations:* > > 1. Surely...
-
By the way, the declaration declare(vv,real) means that vv as a symbolic variable is real. The declaration is not meaningful if you are going to assign a value to vv: declare(rr,real)$ imagpart(rr) => 0 rr: 1+%i$ imagpart(rr) => 1 << the value 1+%i is looked at; the declaration is irrelevant Also, the last line of your script is vacuous: subst(-1,%i*%i,%) is identical to subst(-1,-1,%) since %i*%i is simplified before subst uses it.
-
realpart gives an imaginary result
-
There seems to be a typo in your fifth input line. You have rl:r+x%i; (with a variable named x%i) which I will guess is intended to be rl:r+x*%i; By the way, I think the example would be easier to work with if you assigned names to the intermediate values rather than using %th(...).
-
Sure, linearray = 1000 seems OK. I pretty often use matrices just as a display mechanism.
-
taylor internal error in limit
-
I was misled by the startup banner, which reads Maxima on Android 3.2.1 September 7, 2018 Maxima 5.41.0 http://maxima.sourceforge.net I guess September 7, 2018 is the build date of MaximaOnAndroid. Which brings up back to the original question: does anyone know how to build MoA from Maxima source?
-
Agreed that 5.41 is carbon dated (from 2018!), but it's the latest version of Maxima On Android as far as I can tell. Does anyone know how to build Maxima on Android with a more recent version?
-
trigsimp misses a simplification
-
I disagree that we should call $string on its arguments. At most, accept either a string or a symbol. Behavior like this helps no one (and should be fixed in load, too): load(a*b); Maxima encountered a Lisp error: In function STRING, the value of the first argument is ((MTIMES SIMP (0 "stdin" SRC)) $A $B) which is not of the expected type STRING Tested in Maxima on Android 3.2.1 September 7, 2018 Maxima 5.41.0 http://maxima.sourceforge.net using Lisp ECL 16.1.3
-
gnuplot gives obscure Lisp error when gnuplot_command is not a string
-
The error you're getting is not about the variable gnuplot, but about the value of gnuplot_command. Neither Maxima nor Lisp supports the notion of a variable type. The bug here is that Maxima is giving an obscure internal Lisp error, rather than a meaningful Maxima error. Since it is a Lisp error, it doesn't look at stringdisp when displaying the value. A reasonable Maxima error message would be something like: "gnuplot_command is 'gnuplot', which is not a valid pathname string" or something.
-
guess_exact_value failure on trivial case
-
Sorry, I had apparently changed fpprec and forgotten that it affects guess_exact_value.
-
Polynomials are a special case. For any function continuous at x, f(x) = limit(f(q),q,x) with no need for expansion or detailed analysis. Consider, for example, limit( (gamma(x)-tan(x)+1/x)^50000 + 2*x, x, 23). We know that tan, gamma, and1/x are continuous at 2/3 and q^50000 is continuous everywhere that q is -- and the result (gamma(2/3)-tan(2/3)+3/2)^50000 + 4/3 is much shorter and easier to understand than the expanded form.
-
guess_exact_value failure on trivial case
-
Can't control matrix 2d print formatting
-
?? ratvars returns the same text three times
-
?? ratvars returns the same text three times
-
is("string">0) causes lisp error
-
I disagree. This should cause a Maxima error, since comparing a number and a string is undefined.b
-
trigrat often makes expressions unnecessarily complicated
-
trigrat often makes expressions unnecessarily complicated
-
scanmap(rectform,f(1)) stack overflow
-
scanmap(rectform,f(1)) stack overflow
-
factor inconsistent for function arguments
-
factor inconsistent for function arguments
-
factor inconsistent for function arguments
-
factor inconsistent when applied to sets
-
factor inconsistent when applied to sets
-
Here's a slightly simpler version of the bug: limit( log((sin(x)+cos(x))/(%i*sin(x)+cos(x)+2)) , x, t) Some more cases, substituting other simplifying functions (exp, gamma, log): limit ( log((log(x)+exp(x))/(%i*exp(x)+log(x)+2)), x, t) limit( log((%i*(%e^x-2))/(%i*log(x)+%e^x+2)), x, t) These run a while and then exhaust heap. Maxima 5.47.0 SBCL 2.4.9
-
ratdisrep([taylor(k,k,inf,1)]) is unsimplified
1 >
