Activity for Andrii Sokolov
-
Andrii Sokolov created merge request #37 on Code
Fix the < and > Texinfo 7.0.3 problem in a simpler way + small improvements
-
Robert, thanks for an update! I don't know why only GCL and ECL run into an error, but anyway it appears the error has gone away There was a discussion with Richard concerning this bug, and it might be that GCL (as well as its derivative ECL) is not able to properly handle long variable names that include capital letters https://sourceforge.net/p/maxima/mailman/message/37768131/. The reasoning behind that is that this bug can be fixed by changing W1 to wu1 etc (see https://sourceforge.net/p/maxima/mailman/message/37768148/...
-
Robert, thanks for an update! I don't know why only GCL and ECL run into an error, but anyway it appears the error has gone away There was a discussion with Richard concerning this bug, and it might be that GCL (as well as its derivative ECL) is not able to properly handle long variable names that include capital letters https://sourceforge.net/p/maxima/mailman/message/37768131/. The reasoning behind that is that this bug can be fixed by changing W1 to wu1 etc (see https://sourceforge.net/p/maxima/mailman/message/37768148/...
-
Thanks for your fix! Your solution is rather elegant, but I should say it's not ideal, at least to my taste. declare(a, complex)$ tex(conjugate(a^2)) gives $$\left(a^{\ast}\right)^2$$, while I would prefer $$a^{\ast2}$$. The latter is what my re-definition of "^" achieves.
-
Thanks for a comment! A "workaround" I needed to do to run my old code that uses a similar call of facsum was to (finally) waste some time and compile Maxima with SBCL. I should say that Maxima compiles quite fast and the configuration process is straightforward; I would like to thank everyone responsible for that.
-
facsum + operator(".") + dotdistrib:true + GCL = FAIL
-
Sorry, the workaround in the original bug report does not take into account the case when there is some expression in the power of conjugate(...). A workaround that works for that case is: texput("^", lambda([e], block( [base : first(e), pow : second(e)], if atom(base) then sconcat(tex1(base), "^{", tex1(pow), "}") else if op(base) # conjugate then sconcat("\\left(", tex1(base), "\\right)^", "{", tex1(pow), "}") else if atom(pow) or member(op(pow), ["*",".","/","^"]) then sconcat(tex1(first(base)),...
-
Double superscript in tex(conjugate(z))^2
-
Bad string representation of integers in the first argument of `save`
-
Actually, the original bug now does not reproduce for me (5.46.0 with GCL x86_64-redhat-linux-gnu)...
-
Could it be that in this very case it is enough that function arguments not only "treated in exactly same way as the variables in a block" (from ? Function) -- that is, their value is removed and restored, but also any properties of the argument are removed and restored (just like the local does)? Maybe doing this also cures the following? (%i1) callfun(fun) := fun()$ (%i2) foo() := print("Hey")$ (%i3) callfun(foo)$ Hey (%i4) fun() := print("Bye")$ (%i5) callfun(foo)$ /* One expects to hear "Hey"...
-
Could it be that in this very case it is enough that function arguments not only "treated in exactly same way as the variables in a block" (from ? Function) -- that is, their value is removed and restored, but also any properties of the argument are removed and restored (just like the local does)? Maybe doing this also cures the following? ~~~ (%i1) callfun(fun) := fun()$ (%i2) foo() := print("Hey")$ (%i3) callfun(foo)$ Hey (%i4) fun() := print("Bye")$ (%i5) callfun(foo)$ / One expects to hear "Hey"...
-
The bug is also present in the CoCalc service that uses SAGE that uses Maxima built with ECL . You can check and play with it in my publicly available notebook https://cocalc.com/share/public_paths/c265d82c5e5cc92322649dea20fdfa1a0b2ef4fe
-
/* comment */ :lisp does not work
-
(1) I did not built Maxima myself. I think I installed Maxima from maxima-exec-gcl-5.46.0-1.x86_64.rpm and maxima-5.46.0-1.x86_64.rpm from https://sourceforge.net/projects/maxima/files/Maxima-Linux/5.46.0-Linux/ (2) Personally I have not tested in with Clozure CL, but it was mentioned in the mailing list that it works with orderless (see the Barton Willis mail in the thread https://sourceforge.net/p/maxima/mailman/maxima-discuss/thread/CAAsY_sToe27Uz_7TcFfT%2BbJhAPANDOC%3DxD2dwLf%3DE_0sEDADPw%40mail.gmail.com/#msg37766880)...
-
I have found that ratsimp(eq) fails with a similar (albeit the "case 2b") error.
-
I also tried to_poly_solve and it gives the same error: (%o5) to_poly_solve(eq, B10); (%i5) %solve(eq,B10) PQUOTIENT: Quotient by a polynomial of higher degree (case 1)
-
Error in [lin]solve with orderless called before
-
Declaring l1 or l2 constant makes facsum defunct
-
Maxima's trace handles rules incorrectly
1