Activity for Maxima -- GPL CAS based on DOE-MACSYMA
-
Stavros Macrakis posted a comment on ticket #4623
That would be a nice quick patch, but it would be really nice to find the root cause and fix that.
-
David Scherfgen posted a comment on ticket #4623
An easy fix would be to replicate what you did, before returning the answer, and including a correction factor if necessary.
-
gcfactor should factor gaussian rationals
-
gcfactor requires explicit gaussian integer
-
gcfactor(4), expand(%%) => -4
-
Robert Dodier modified ticket #4622
Windows display issue
-
Thank you for your interest in Maxima, and thank you for the bug report. I have closed this ticket as "won't fix" since the problem is not in Maxima itself. Please feel free to raise any new issues on the bug tracker or mailing list (https://sourceforge.net/projects/maxima/lists/maxima-discuss).
-
vsxbamboo posted a comment on ticket #4587
I guess it's because it cannot determine the limit of n(x) that it also cannot determine the limit of n(x)/d(x).
-
ourfalli posted a comment on ticket #4622
Thank you, bug reported on GitHub.
-
Barton Willis posted a comment on ticket #4622
To report a bug to the wxMaxima developers, try https://github.com/wxMaxima-developers/wxmaxima/issues
-
I apologise for the confusion. I will report this in the adequate project. Thank you.
-
Jaime E. Villate posted a comment on ticket #4622
This is not a Maxima bug report but a Wxmaxima bug report. We here cannot fix Wxmaxima bugs (a separate project).
-
Windows display issue
-
Hmm, I'm sorry to hear defsystem isn't working for ECL + Windows. Defsystem is an older system for building Lisp programs and indeed it hasn't been updated in decades to the best of my knowledge. I guess my advice is to try to solve the problems in ASDF, although I know that's easier said than done. I have a Windows system I can try it on, I will try to remember to try building with ECL in the near future.
-
Correctly returns minf on Maxima 5.41.0 ECL 16.1.3 (MaximaOnAndroid)
-
limit(inf*minf);
-
Update ChangeLog for fix to bug #4614
-
atan2 reflection rule
-
Fixed by Commit [eb00d1] master. Closing this ticket.
-
Fix #4614: correct atan2 reflection rule
-
incorrect integration
-
Closing this ticket as fixed. Git bisect shows it was fixed by commit 4d8e30 which was intended to fix #4257, nice to see this one got fixed too. I added the original problem as a test case in commit 50a7d7c.
-
Robert Dodier committed [50a7d7] on Code
Add a test case for SF #3795: "incorrect integration"
-
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.
-
Dominik, thanks for the additional example. I've copied it to a separate ticket: https://sourceforge.net/p/maxima/bugs/4620/
-
trigreduce incorrect result with domain = complex
-
limit( (sin(x)+1)/sin(x), x, inf); -> 1 and not und
-
Yes, the examples here should definitely be included as test cases. I've marked this ticket with the milestone has_test_cases. I know that's little-used, but anyway maybe it will help us keep track of this.
-
Robert Dodier committed [66001d] on Code
In 2-d display for derivatives, correct depth of denominator in Leibniz notation.
-
Robert Dodier committed [9b17dd] on Code
Commit new script test_matrix_display.mac to test display flags for matrix and box.
-
Robert Dodier committed [9eb0dc] on Code
New flag display_determinant_bars; when true, display determinant of a literal matrix with a bar on either side,
-
Robert Dodier committed [e8eaab] on Code
New flag display_matrix_brackets; when true, display matrices with a bracket on either side,
-
Robert Dodier committed [7bea89] on Code
New flag display_box_double_lines; when true, display box expressions with double-line characters, otherwise single-line.
-
Appears that this bug was fixed somewhere between Maxima 5.47 and 5.48. I will try to pin down the specific commit.
-
Well, the result %o4 seems OK -- it is not incorrect, right? It's just that limit and/or integrate was not able to figure out the integral. For the record, I see that integrate can't figure out the integral (i.e., returns a noun expression) for both integrate((1-1/t)^t*%e^(%e*t), t, %e, x) and integrate((1-1/t)^t*%e^(%e*t), t, %e, inf).
-
Further, I found that the calculation of the following expression also seems to be problematic: (%i4) n(x) := integrate((1-1/t)^t*%e^(%e*t), t, %e, x); limit(n(x), x, inf); (%o3) n(x):=integrate((1-1/t)^t*%e^(%e*t),t,%e,x) (%o4) integrate((1-1/t)^t*%e^(%e*t),t,%e,inf)
-
The top-level function for the one argument limit is simpinf, not infsimp. I'm still puzzling over what kinds of expressions infsimp is supposed to handle. I notice that the limit code sends one argument limits through both-side. That's unnecessary, I think. There are cases where infsimp recieves an mplus expression, but here it does not. It's possible that there are calls to infsimp that should be simpinf. These names are easy for me to confuse. Possibly only simpinf should call infsimp. (%i5) limit(a+b+inf);...
-
Further, I found that the calculation of the following expression also seems to be problematic: (%i4) n(x) := integrate((1-1/t)^t%e^(%et), t, %e, x); limit(n(x), x, inf); (%o3) n(x):=integrate((1-1/t)^t%e^(%et),t,%e,x) (%o4) integrate((1-1/t)^t%e^(%et),t,%e,inf)
-
Not entirely sure what's going on, but anyway I see (%i26) n(x)/d(x); x ⌠ - %e x ⎮ %e t 1 t (%o26) %e ⎮ %e (1 - ─) dt ⎮ t ⌡ %e and limit appears to be looking at each of the terms; it gets 0 for the limit of the first term (correctly), and for the second it gets inf ⌠ ⎮ %e t 1 t (%o27) ⎮ %e (1 - ─) dt ⎮ t ⌡ %e I speculate the limit is thinking that it can just multiply the two limits together, and then it gets 0. limit might be only looking to see if the result of the second is not a limit noun expression,...
-
I'll continue doing experiments. For my next revision, I'll definitely eliminate the (or (not (free ..))) with a call to amongl. So far, my experimental fixes also fixes #4603. I'd like to eliminate expand(e,1,1), but it's baked into simpinf1 and simpinf2, but I'll see what I can do. Instead of simpfin2, I think there should be functions for mplusp, mtimesp and mexptp expressions. I've collected all the approximately 59,000 calls to simpinf to study them. Thanks.
-
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?
-
OK by me to make the changes suggested. I don't work on the limit code too much but the proposed changes make sense to me.
-
Maybe not a fix, but the bug vanishes by inserting a trap for when x and e are syntactically equal at the top of infsimp2. The argument names to infsimp2 are misleading, I think. The first argument to infsimp2 is expand(e,1,1); it is not a limit variable as the name x suggests. When x and e are syntactically equal, the call (setq x ($limit x)) in infsimp2 causes an infinite loop. A revised function: (defun infsimp2 (x e) (cond ((alike1 x e) e) (t (setq x ($limit x)) (if (isinop x '%limit) e x))))...
-
askinteger extremely weak
-
residue should check if taylor series is a power series
-
Maxima-5.48.1 Breaks Draw3d With Surface_Hide=True
-
Thanks for the bug report. I am marking it as "won't fix", since it appears that the problem is in Gnuplot. If some further information is found which suggests the problem is in Maxima after all, no problem, we can just reopen this ticket.
-
Control stack regression with abs_integrate / 5.48.0
-
Looks like this is triggered by a bug in limit. See bug report #4619.
-
limit(inf = inf) causes stack overflow
-
Control stack regression with abs_integrate / 5.48.0
-
floor fails with factored argument
-
ceiling also stumbles on this example, returning an incorrect result. (%i1) ceiling(factor(1013*1019*1021*1031*1033*1039*1049*1051*1061)/3); (%o1) 454732756132228744033075200 while the correct result, I think, is (%i2) ceiling((1013*1019*1021*1031*1033*1039*1049*1051*1061)/3); (%o2) 454732756132228747506337474 Tracing PRETTY-GOOD-FLOOR-OR-CEILING shows that it's called when factor is present, not otherwise. Increasing fpprec to 100 (I didn't try anything else) enables ceiling to return a noun expression...
-
Robert Dodier committed [6d68ba] on Code
Commit new script test_matrix_display.mac to test display flags for matrix and box.
-
li[2] evaluated near one is slow
-
taylorinfo ignores asymp
-
Thjs bug was recently fixed and the test /*4602 taylorinfo ignores asymp */ taylorinfo(taylor(exp(1/x),[x,0,3,'asymp])); [[x, 0, 3, asymp]]$ put into rtest_taylor. Closing this ticket.
-
%i * 3^%i/2^%i; does not consistently simplify
-
Commit [99a826] appended these tests to rtest_great. These bugs were fixed by Commit [227d11]. Closing this ticket
-
Append tests from \#3183 %i * 3^%i/2^%i; does not consistently simplify
-
great not transitive (so simplifya not idempotent)
-
more 'great' bugs
-
Fixed by Commit [227d11]
-
Fixed by Commit [227d11]. Closing this ticket.
-
Updates the list of fixed bugs.
-
Robert Dodier committed [3259c8] on Code
New flag display_determinant_bars; when true, display determinant of a literal matrix with a bar on either side,
-
Robert Dodier committed [ce80ff] on Code
New flag display_matrix_brackets; when true, display matrices with a bracket on either side,
-
Robert Dodier committed [a70604] on Code
New flag display_box_double_lines; when true, display box expressions with dobuble-line characters, otherwise single-line.
-
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...
-
indefinite integral result contains unneeded constant of integration
-
Moving this ticket to the feature requests tracker. The new feature would be detecting a constant of integration which can be omitted from the result.
-
Ticket moved from /p/maxima/bugs/4610/
-
different result in an integral
-
Andres, thanks for taking the time to make a report. I'm marking this ticket as "not a bug", since it appears that the result is correct; it differs from the expected result by just a constant. I agree the presence of the extra constant is suboptimal. I think it's reasonable to think about ways to detect constant terms that could be omitted. That would be a new feature for the indefinite integration code. As such I will move this ticket to the feature requests tracker.
-
Update ChangeLog
-
carg range is not in (-%pi, %pi]
-
Quoting atan2 inhibits simplification
-
This was fixed some time ago. Regression test added to rtest_atan2. Closing ticket.
-
integrate(atan2(sin(x), cos(x)), x, 0, 9*%pi);
-
Fixed by Commit [d00e00] . Regression test added to rtest_atan2. Closing ticket.
-
atan2(inf,inf) -> 0
-
Fixed by Commit [d00e00] . Regression tests added to rtest_atan2. Closing ticket.
-
Fixed by Commit [d00e00] . Regression tests added to rtest_atan2. Closing ticket.
-
Also, the source code comment for 2pistrip says that it ``Attempts to reduce to interval (-pi,pi]." It often fails in this effort: (%i8) ?2pistrip(42); (%o8) 42 (%i13) ?2pistrip(42+ 3*%pi); (%o13) %pi+42 The source code comment doesn't say what the function is supposed to do when it cannot reduce to the interval (-pi,pi].
-
Fixes for \#4615, \#4609, and \#4613
-
carg reflection rule
-
carg reflection rule
-
Raymond Toy committed [5f931d] on Code
Merge branch 'rtoy-rework-highlightjs-vars'
-
Run update_examples on one example for integrate_use_rootsof
-
Remove commented out AC_SUBST(HLJS_CSS_SELECTOR)
-
Gunter Königsmann committed [cdb028] on Code
wrstcse: Documented the new functionalities.
-
wrstcse: wc_inputvalueranges now has an optional parameter that accepts a bool
-
wrstcse: Added wc_tolassumptions, which tells maxima which range tol[n] will be in
-
wrstcse: wc_ewc_simplify no more uses diff() and limit()
-
some unsimplified antiderivatives
-
wrstcse: Temporary definitions for wc_ewc_simplify()
-
I think that the correct value is %pi/4.
-
Add some comments about the variables
-
Rework highlightjs to make it easier read/modify
-
Run update_examples on one example for integrate_use_rootsof
1 >