You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(23) 
_{Sep}
(108) 
_{Oct}
(68) 
_{Nov}
(66) 
_{Dec}
(47) 
2017 
_{Jan}
(55) 
_{Feb}
(11) 
_{Mar}
(30) 
_{Apr}
(19) 
_{May}
(14) 
_{Jun}
(21) 
_{Jul}
(30) 
_{Aug}
(48) 
_{Sep}
(39) 
_{Oct}
(30) 
_{Nov}
(75) 
_{Dec}
(4) 
S  M  T  W  T  F  S 


1
(1) 
2
(4) 
3
(2) 
4
(1) 
5

6

7
(5) 
8
(9) 
9

10
(2) 
11
(6) 
12
(12) 
13
(5) 
14
(7) 
15
(4) 
16
(4) 
17

18

19
(2) 
20
(7) 
21
(9) 
22
(7) 
23
(6) 
24
(5) 
25
(12) 
26
(12) 
27
(10) 
28
(4) 
29
(4) 
30
(5) 
31




From: SourceForge.net <noreply@so...>  20100308 23:00:01

Bugs item #2789110, was opened at 20090508 18:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2789110&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solve, tan and atan depend on order of variables Initial Comment: solve(tan(x  atan(c1/c2)) = 0, x); returns [x=atan(c1/c2)] corretly, but solve(tan(x  atan(c2/c1)) = 0, x); returns [ ].  Maxima version: 5.18.1 Maxima build date: 14:34 4/18/2009 host type: i686appledarwin8.11.1 lispimplementationtype: CMU Common Lisp lispimplementationversion: 19f (19F)   >Comment By: Dieter Kaiser (crategus) Date: 20100309 00:00 Message: This is an interesting bug which is caused by the comparison with an unsimplified expression. The problem occurs in the routine OFFORMA*F<X>^N+B in solve.lisp. The additional term atan(a/b) or atan(c/b) of this bug report is a constant which should not influence the solvability of the equation. But it does. The first example for atan(a/b) gives the expected answer. The routine OFFORMA*F<X>^N+B returns T. I have put code into the routine to show the values of *HAS*VAR and the result of the call of PDIS: (%i65) solve(tan(x  atan(a/b)) = 0, x); 0: (OFFORMA*F<X>^N+B (#:tan(xatan(a/b))1895 1 1)) OFFORMA*F<X>^N+B : *has*var = (((%TAN) ((MPLUS RATSIMP) $X ((MTIMES RATSIMP) 1 ((%ATAN) ((MTIMES RATSIMP) $A ((MEXPT RATSIMP) $B 1)))))) $X) : pdis.. = ((%TAN) ((MPLUS RATSIMP) $X ((MTIMES RATSIMP) 1 ((%ATAN) ((MTIMES RATSIMP) $A ((MEXPT RATSIMP) $B 1)))))) 0: OFFORMA*F<X>^N+B returned T solve: using arctrig functions to get a solution. Some solutions will be lost. (%o65) [x = atan(a/b)] Now the second example with atan(c/b). For this example the routine OFFORMA*F<X>^N+B returns NIL. The comparison of *HAS*VAR and the return value of PDIS fails. The reason is that *HAS*VAR contains an unsimplified %atan expression with a different order of the arguments. (%i66) solve(tan(x  atan(c/b)) = 0, x); 0: (OFFORMA*F<X>^N+B (#:tan(xatan(c/b))1928 1 1)) OFFORMA*F<X>^N+B : *has*var = (((%TAN) ((MPLUS RATSIMP) $X ((MTIMES RATSIMP) 1 ((%ATAN) ((MTIMES RATSIMP) $C ((MEXPT RATSIMP) $B 1)))))) $X) : pdis.. = ((%TAN) ((MPLUS RATSIMP) $X ((MTIMES RATSIMP) 1 ((%ATAN SIMP) ((MTIMES SIMP) ((MEXPT SIMP RATSIMP) $B 1) $C))))) 0: OFFORMA*F<X>^N+B returned NIL (%o66) [] It is by design of the routines which gives the value of *HAS*VAR (e.g. varsort, newvar, newvar1, fnewvar, ...) that an unsimplified expression with a special order of the arguments is returned. Therefore, it might be the best to improve the test in OFFORMA*F<X>^N+B to be sure not to miss the case of equivalence of two expressions. Dieter Kaiser  Comment By: Harry Litzroth (hlitzroth) Date: 20090513 22:55 Message: I use wxMaxima 0.8.2 with Maxima 5.18.1. The same problem exists with vg1 : tan(x  atan(y/z))= 0; solve(vg1, x); giving the solution tan(atan(y/z)x)=0, and vg2 : tan(x  atan(z/y)) = 0; solve(vg2, x); giving no solution at all.  Comment By: Nobody/Anonymous (nobody) Date: 20090512 07:58 Message: Both give the same result: []  Maxima version: 5.18.1 Maxima build date: 20:57 4/19/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2789110&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 21:06:04

Bugs item #2952900, was opened at 20100216 18:21 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: traxi (traxi) Assigned to: Nobody/Anonymous (nobody) Summary: Solving equations with logarithms Initial Comment: (%i1) solve([log(x)*x=0], [x]); (%o1) [x=1,x=0] Should only be [x=1,x=0]  >Comment By: Dieter Kaiser (crategus) Date: 20100308 22:06 Message: As mentioned in a posting below, the solution x=0 might be considered as a solution too. Setting the resolution to Wont Fix and the status to pending. Dieter Kaiser  Comment By: Nobody/Anonymous (nobody) Date: 20100219 15:23 Message: decreases driven society <a href="http://www.business247.ae">new decline power computer 104</a> [url=http://sarahkassel.com]uncertainty weathering[/url] http://support.microsoft.com  Comment By: traxi (traxi) Date: 20100219 08:32 Message: I'm only interested in real results. Is it possible to configure maxima, ony to get real results in this case?  Comment By: Stavros Macrakis (macrakis) Date: 20100218 23:05 Message: I think you mean "should only be [x=1]". Maxima actually got lucky here, because x=0 is arguably a solution by continuity, since limit(log(x)*x,x,0) = 0 (even for negative x).  Comment By: Barton Willis (willisbl) Date: 20100218 02:07 Message: The alternative solver (to_poly_solve) can not solve this equation either: (%i13) load(to_poly_solver)$ (%i12) %solve([log(x)*x=0], [x]); Division by 0 (%o12) %union() Thanks for this reportI'll try to fix to_poly_solve function.  Comment By: traxi (traxi) Date: 20100217 09:26 Message: Should only be x=1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2952900&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 20:47:27

Bugs item #2139672, was opened at 20081001 07:24 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2139672&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Solve fails for simple equation Initial Comment: Maxima version: 5.16.3 Maxima build date: 14:52 9/22/2008 host type: i686appledarwin8.11.1 lispimplementationtype: SBCL lispimplementationversion: 1.0.20 (%i19) solve([[gox,goy]=[loh1*roh1x,loh1*roh1y]+[loh2*roh2x,loh2*roh2y],[gh2x,gh2y]=lh1h2*[rh1h2x,rh1h2y]+loh2*[roh2x,roh2y]],[loh1,loh2]); (%o19) []  >Comment By: Dieter Kaiser (crategus) Date: 20100308 21:47 Message: As mentioned in a posting from below the syntax is not correct. Therefore, we can not expect to get an answer. I am not sure what the proposed equations are, but this is a result for the first two equations: (%i1) eqn1:gox=loh1*roh1x+loh2*roh2x$ (%i2) eqn2:goy=loh1*roh1y+loh2*roh2y$ (%i3) solve([eqn1,eqn2],[loh1,loh2]); (%o3) [[loh1 = (goy*roh2xgox*roh2y)/(roh1y*roh2xroh1x*roh2y), loh2 = (goy*roh1xgox*roh1y)/(roh1y*roh2xroh1x*roh2y)]] Setting the resolution to invalid and the status to pending. Dieter Kaiser  Comment By: Herminio Gomes (herminio_gomes) Date: 20081212 00:25 Message: Solve fails in many simple equations. Try this solve( (2*%pi*r*R*sqrt(R^2r^2)+2*%pi*r*R^23*%pi*r^3)/(3*sqrt(R^2r^2) ) the solutions in variable "r" is written in terms of "r" . Herminio  Comment By: Barton Willis (willisbl) Date: 20081001 13:53 Message: Maxima doesn't recognize list1 = list2 as being the same as a list of scalar equations. Rewrite your equations in proper format and try again.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2139672&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 17:23:05

Bugs item #2965460, was opened at 20100308 15:43 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2965460&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: log(e) simplify bug Initial Comment: Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Integration/Differentiation often causes a function wich contains the expression "log(e)" which cannot be simplified by maxima itself  >Comment By: Dieter Kaiser (crategus) Date: 20100308 18:23 Message: This might be a bug, if Maxima returns log(e) and not log(%e) which of course simplifies immediately. Perhaps you have introduced the symbol e and not %e with you input. This example uses the correct symbol %e for the base of the natural logarithm: (%i6) diff(%e^x,x); (%o6) %e^x In this example log(e) does not simplify, because e represents a general variable and not the base of the natural logarithm: (%i7) diff(e^x,x); (%o7) e^x*log(e) Please can you give an example. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2965460&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 15:12:56

Bugs item #1106912, was opened at 20050121 14:07 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1106912&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(x/sin(x)^2,x,inf) Initial Comment: limit(x/sin(x)^2,x,inf) => UND actually = inf  >Comment By: Dan Gildea (dgildea) Date: 20100308 10:12 Message: The change in limit.lisp rev 1.93 introduces the following problems: (%i5) limit(x/(sin(x)),x,inf); (%o5) inf (%i10) limit(x/(2+sin(x)),x,inf); (%o10) inf reopening report.  Comment By: Dieter Kaiser (crategus) Date: 20100210 14:37 Message: Fixed in in limit.lisp revision 1.93. Closing this bug report as fixed. Dieter Kaiser  Comment By: https://www.google.com/accounts () Date: 20100207 09:11 Message: After 5 years it still doesn't work. Another similar limit non properly evaluated: limit(x/(a+sin(x)),x,inf) (a is a number greater or equal to 1) that returns "und" instead of "inf"  Comment By: Raymond Toy (rtoy) Date: 20061108 20:35 Message: Logged In: YES user_id=28849 Fix summary. Problem still exists in current CVS.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1106912&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 14:43:09

Bugs item #2965460, was opened at 20100308 14:43 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2965460&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: log(e) simplify bug Initial Comment: Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Integration/Differentiation often causes a function wich contains the expression "log(e)" which cannot be simplified by maxima itself  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2965460&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 14:32:14

Bugs item #2960403, was opened at 20100227 22:57 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: spurious floats in asksign Initial Comment: (%i3) integrate(1/(x^2 + x + b)^2,x); Is b0.25 positive or negative?pos; (%o3) (4*atan((2*x+1)/sqrt(4*b1)))/(4*b1)^(3/2)+(2*x+1)/((4*b1)*x^2+(4*b1)*x+4*b^2b) (%i4) build_info(); Maxima version: 5.20.1 Maxima build date: 21:25 12/14/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 (%o4)  >Comment By: Dieter Kaiser (crategus) Date: 20100308 15:32 Message: A further oberservation: The bug is visible when we put in addition a fact into the assume database: (%i2) assume(notequal(4*b1,0)); (%o2) [notequal(b,1/4)] (%i3) asksign(4*b1); Is b0.25 positive or negative? This is done by the integration routine too. This indicates that we have a problem with the assume database alone. As reported the bug is not present in Maxima 5.18. I have located the problem in the following revision: Revision 1.18  (view) (download) (annotate)  [select for diffs] Fri Apr 3 17:27:07 2009 UTC (11 months ago) by are_muc Branch: MAIN Changes since 1.17: +243 208 lines Diff to previous 1.17 If I go back to revision 1.17 of db.lisp the bug vanishes, but it is present with revision 1.18. Unfortunately, the change seems to be very subtle and about 240 lines have changed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100301 22:27 Message: Some observations: (1) The bug has been introduced between Maxima 5.18 and Maxima 5.19. Maxima 5.18.1 http://maxima.sourceforge.net Using Lisp CLISP 2.44.1 (20080223) 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) integrate(1/(x^2 + x + b)^2,x); Is 4 b  1 positive or negative? Maxima 5.19.2 http://maxima.sourceforge.net Using Lisp CLISP 2.44.1 (20080223) 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) integrate(1/(x^2 + x + b)^2,x); Is b  0.25 positive or negative? (2) The bug is not reproducible with asksign alone. We can trace $asksign to see the involved expression: (%i1) :lisp (trace $asksign) ($ASKSIGN) (%i1) integrate(1/(x^2 + x + b)^2,x); 0: ($ASKSIGN ((MPLUS SIMP) 1 ((MTIMES SIMP RATSIMP) 4 $B))) Is b  0.25 positive or negative? That is the expression which is passed to $asksign and it works as expected: (%i3) asksign(ratsimp(4*b+1)); 0: ($ASKSIGN ((MPLUS SIMP) 1 ((MTIMES SIMP RATSIMP) 4 $B))) Is 4 b  1 positive, negative, or zero? Perhaps we have a global switch or flag which is set by the integration routines and changes the behaviour of $asksign. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2960403&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 02:20:22

Bugs item #719968, was opened at 20030411 22:36 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: No SIMP function Initial Comment: The info file documents a function SIMP, which "causes exp to be simplified regardless of the setting of the switch SIMP which inhibits simplification if FALSE". But there is no such function defined. It is also not clear if this is supposed to force resimplification of the whole expression, or only the part without SIMP flags.  >Comment By: SourceForge Robot (sfrobot) Date: 20100308 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100221 14:26 Message: A comment about the possibility to resimplify an expression with the command expand(expr,0,0) has been added to Simplifications.texi revision 1.25. The possibility to resimplify with the command ev(expr,noeval) is already documented. In addition and if it is desired we might support a user function resimplify which does expand(expr,0,0) in a more user friendly way. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100217 18:53 Message: Again an example to show the possibilities we have: We set the variable y and x. (%i1) y:sin(x); x:1; (%o1) sin(x) (%o2) 1 We change the environment: (%i3) exponentialize:true; (%o3) true These are three possibilities to resimplify sin(x) without evaluation (the value of x is not inserted): (%i4) expand(y,0,0); (%o4) %i*(%e^(%i*x)%e^(%i*x))/2 (%i5) ev(y,noeval); (%o5) %i*(%e^(%i*x)%e^(%i*x))/2 (%i6) ?resimplify(y); (%o6) %i*(%e^(%i*x)%e^(%i*x))/2 These three possibilities behave differently when we have a CRE expression. (%i13) exponentialize:false$ (%i12) r:rat(2*sin(x)); (%o12)/R/ 2 sin(x) (%i13) exponentialize:true$ The function expand does a specrepcheck. The result is no longer a CRE expression: (%i14) expand(r,0,0); (%o14) %i*(%e^(%i*x)%e^(%i*x)) The function ev simplifies and returns a CRE expression: (%i15) ev(r,noeval); (%o15)/R/ (%i*(%e^(%i*x))^2%i)/%e^(%i*x) The Lisp function resimplify does nothing for a CRE expression: (%i16) ?resimplify(r); (%o16)/R/ 2 sin(x) The possibility to resimplify with ev(expr,noeval) is part of the documentation of the function ev. I would like to suggest to add a comment to the function expand that expand(expr,0,0) allows the resimplification of an expression and to close this bug report. Dieter Kaiser  Comment By: Stavros Macrakis (macrakis) Date: 20060829 14:58 Message: Logged In: YES user_id=588346 expand(...,0,0) calls ?resimplify. The difference is that expand does a specrepcheck. Since almost no simplification flags apply to specreps, it is probably appropriate to do the specrepcheck. You could argue that if the input is in CRE form, you should just rerat it to get the effect of changed keepfloat, ratfac, etc. flags, but I think that's too complicated; and you can always call rat to rerat. ex:log(a*b) => log(a b) rex:rat(ex)$ logexpand:all$ ex => log(a b) rex => /R/ log(a b) expand(ex) => log(b) + log(a) ?resimplify(ex) => log(b) + log(a) expand(rex) => log(b) + log(a) ?resimplify(rex) => /R/ log(a b)  Comment By: Robert Dodier (robert_dodier) Date: 20060829 14:34 Message: Logged In: YES user_id=501686 There exists a Lisp function RESIMPLIFY  How does expand(foo, 0, 0) differ from ?resimplify(foo) ?  Comment By: Stavros Macrakis (macrakis) Date: 20060828 14:48 Message: Logged In: YES user_id=588346 Robert, you suggest that we expose Simplifya. But Simplifya is called automatically by meval every time you evaluate anything. You might think it was useful when simp=false. But when simp=false, it has no effect. I think what you want is a "resimplify" function, which would resimplify all subparts of an expression with current settings. As I've mentioned in email before, this already exists, though admittedly in a very obscure form: expand(...,0,0). It would be reasonable to have a userfriendly name for it, e.g. resimplify.  Comment By: Robert Dodier (robert_dodier) Date: 20050411 03:23 Message: Logged In: YES user_id=501686 The description of the simp function went away some months ago (late 2004, I think). So the documentation of a nonexistent function is no longer a problem. It makes me wonder, though, if we to expose SIMPLIFYA somehow or something like that. If the answer is "no", let's close this bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=719968&group_id=4933 
From: SourceForge.net <noreply@so...>  20100308 02:20:21

Bugs item #834813, was opened at 20031103 01:22 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: a < b or 1 < 2 wrong Initial Comment: Assume nothing is known about a and b. prederror:true just making sure it is set to the default for the test avoid ev in case ev complicates matters a<b or 1<2 => error ! is(a<b or 1<2) => error ! if (a<b or 1<2) then 5 => error ! prederror:false a<b or 1<2 => unknown ! is(a<b or 1<2) => true (OK) if a<b or 1<2 then 5 => 5 (OK) I believe that (a<b or 1<2) should be returning true in all these cases. Maxima 5.9.0 gcl 2.5.0 Windows 2000  >Comment By: SourceForge Robot (sfrobot) Date: 20100308 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100221 12:25 Message: With prederror:false (the default value) the examples of this bug report work as expected: (%i1) prederror; (%o1) false (%i2) a<b or 1<2; (%o2) true (%i3) is(a<b or 1<2); (%o3) true (%i4) if (a<b or 1<2) then 5; (%o4) 5 When we set prederror to true we get the following: (%i11) prederror:true; (%o11) true (%i12) a<b or 1<2; Unable to evaluate predicate a < b  an error. To debug this try: debugmode(true); (%i13) is(a<b or 1<2); Unable to evaluate predicate a < b  an error. To debug this try: debugmode(true); (%i14) if (a<b or 1<2) then 5; Unable to evaluate predicate a < b  an error. To debug this try: debugmode(true); I think this is the expected and documented behaviour of the option variable prederror. It might be arguable that an error should be given only if the whole predicate can not be evaluated to be true or false. But the error message is clear. At this point we might close this bug report, because the default behaviour works as expected and the case prederror:false is documented. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060710 04:55 Message: Logged In: YES user_id=501686 Code for unevaluated conditionals (share/contrib/boolsimp/) handles a < or 1 < 2 (also xxx or true, example given below) as expected when prederror = false (which is boolsimp's default mode). Same problems are observed when boolsimp = true, because I wrote boolsimp to have the same behavior as current code when prederror = true. I'd rather just be rid of prederror altogether and have the code always yield what is now yielded when prederror = false.  Comment By: Stavros Macrakis (macrakis) Date: 20031103 01:25 Message: Logged In: YES user_id=588346 Same problem for xxx or true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&group_id=4933 