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}
(15) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2
(6) 
3
(1) 
4
(2) 
5
(1) 
6
(3) 
7

8

9

10
(2) 
11
(3) 
12
(18) 
13
(11) 
14
(4) 
15
(25) 
16

17

18

19

20

21

22

23

24
(9) 
25

26
(17) 
27
(19) 
28
(2) 
29
(4) 
30
(2) 
31
(10) 


From: SourceForge.net <noreply@so...>  20060827 20:30:58

Bugs item #1547584, was opened at 20060827 15:23 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&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: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal([a],[a,b]) Initial Comment: is(equal([a],[a,b])) signals an error (from fullmap). That's not right. It should evaluate to false. Barton  >Comment By: Barton Willis (willisbl) Date: 20060827 15:30 Message: Logged In: YES user_id=895922 Another problem with is(equal(...)): assume(equal(a,aa)); is(equal(f(a), f(aa)) > error or unknown depending on prederror (should be true), is(equal(a < b, [a,b]) > error or unknown depending on prederror (should be false) and ....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 20:23:42

Bugs item #1547584, was opened at 20060827 15:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&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: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal([a],[a,b]) Initial Comment: is(equal([a],[a,b])) signals an error (from fullmap). That's not right. It should evaluate to false. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1547584&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 06:45:20

Bugs item #531466, was opened at 20020318 11:09 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531466&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: float needs to be eval. with numer Initial Comment: See below... we'd like to see "float(exp(exp(2)))" evaluated to 1618.177991912654. (C1) float(exp(exp(2))); 2 %E (D1) 2.718281828459045 (C2) float(exp(exp(2))),numer; (D2) 1618.177991912654 (C3)  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:50 Message: Logged In: YES user_id=501686 More of the same: [ 609464 ] 1+%e,numer and %e^%e,numer  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:46 Message: Logged In: YES user_id=501686 See also [ 586688 ] numer and float problem. (more of the same, with different examples).  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:18 Message: Logged In: YES user_id=501686 For the record, same behavior for all examples in Maxima 5.9.3. (%i10) float(exp(exp(2))); (%o10) 2.718281828459045^%e^2 (%i11) float(exp(exp(2))), numer; (%o11) 1618.177991912654 (%i12) float(%pi^%pi); (%o12) 3.141592653589793^%pi (%i13) float(2^%pi); (%o13) 2.0^%pi (%i14) float((%e+%pi)^2); (%o14) 34.33812894536713  Comment By: Stavros Macrakis (macrakis) Date: 20040223 16:51 Message: Logged In: YES user_id=588346 More cases: float(%pi^%pi)=> 3.14^%pi; float(2^%pi) =>2.0^%pi; but float((%e+%pi)^2) => 34.3. The intent is to avoid floating powers of symbolic objects. For example, you don't want float(x^2)=>x^2.0 or float(x^ (1/3)) => x^0.333. But obviously this has been taken too far. If we can get a numerical result for the whole expression, we should (2^%e, %e^2, even %e^%pi). Numer and float just aren't very well thoughtout.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531466&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 06:45:19

Bugs item #609464, was opened at 20020914 21:18 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: 1+%e,numer and %e^%e,numer Initial Comment: %e^%e,numer does not evaluate numerically to 15.15... as it should, it simply returns the simplified expression %e^%e.  Comment By: Robert Dodier (robert_dodier) Date: 20060626 12:17 Message: Logged In: YES user_id=501686 Still present in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20040323 10:48 Message: Logged In: YES user_id=588346 cf. bug 531466 re float(exp(exp(2)))  Comment By: Stavros Macrakis (macrakis) Date: 20020918 21:12 Message: Logged In: YES user_id=588346 1+%e,numer also fails These examples work with bfloat, e.g. 1+%e,bfloat; %e^%e,bfloat;  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609464&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 06:45:18

Bugs item #586688, was opened at 20020725 14:17 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=586688&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  Floating point Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: numer and float problem. Initial Comment: Consider this simple transcript with CMUCL with current sources: (C1) exp(1); (D1) %E (C2) ev(%,numer); (D2) %E (C3) float(%); (D3) 2.718281828459045 (C4) exp(2); 2 (D4) %E (C5) ev(%,numer); (D5) 7.389056 (C6) float(d4); (D6) 7.389056 Why is D2 still %E? Shouldn't it be the same as D3? And why does D5 and D6 only have single precision results? They ought to be at least double precision. Clisp has the same problem. GCL doesn't since singlefloat and doublefloat are the same on GCL.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:46 Message: Logged In: YES user_id=501686 See also [ 531466 ] float needs to be eval. with numer (more of the same, with different examples).  Comment By: Robert Dodier (robert_dodier) Date: 20050801 23:44 Message: Logged In: YES user_id=501686 I get similar output, except that now all numerical values are doubles as expected  (%i21) exp(1); (%o21) %e (%i22) ev(%,numer); (%o22) %e (%i23) float(%); (%o23) 2.718281828459045 (%i24) exp(2); (%o24) %e^2 (%i25) ev(%,numer); (%o25) 7.38905609893065 (%i26) float (%o24); (%o26) 7.38905609893065 (%i27) float(exp(4)); (%o27) 54.59815003314424 Compare these to %i22/%o22  (%i28) %e, numer; (%o28) 2.718281828459045 (%i37) :lisp (setq $% '((mexpt) $%e 1)) ((MEXPT) $%E 1) (%i37) %, numer; (%o37) 2.718281828459045 Hmm. Maxima version: 5.9.1.1cvs Maxima build date: 10:5 7/28/2005 host type: i686redhatlinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.33.2 (20040602)  Comment By: Raymond Toy (rtoy) Date: 20041109 08:05 Message: Logged In: YES user_id=28849 float(exp(2)) should return a doublefloat now. float(exp(n)) when n is an integer should be a doublefloat too.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=586688&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #629716, was opened at 20021028 01:37 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629716&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: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: dotexptsimp and x^^2/FIX Initial Comment: In general, dotexptsimp:false inside Expand expands out noncommutative powers to noncommutative products, e.g. dotexptsimp:false; expand((x.y)^^2) => x.y.x.y But not always: dotexptsimp:false expand(x^^2) => x^^2 and dotexptsimp:false expand(x.y^^2) => x.y^^2 This makes it impossible (?) to simplify (x.y)^^2 . y  x.y.x.y^^2 to zero. There is a simple patch for this, which makes expand (x^^3) => x.x.x (if dotexptsimp:false). I wonder if that will cause problems anywhere else? Here's the patch. In simpncexpt, just remove the mnctimesp test in the two tests which read as follows: ((and (or (mplusp factor) (and (not $dotexptsimp) (mnctimesp factor))) ....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629716&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #719968, was opened at 20030411 16:36 Message generated for change (Settings changed) made by robert_dodier 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: Open Resolution: None Priority: 5 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: Robert Dodier (robert_dodier) Date: 20050410 21: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...>  20060827 00:24:13

Bugs item #635338, was opened at 20021107 22:17 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635338&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: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ratsimp bug Initial Comment: In Maxima 5.5/Windows/gcl expr: 4*(SQRT(5)1)/(SQRT(5)*(102*SQRT(5))* ((4*x+SQRT(5)+1)^2/(102*SQRT(5))+1)) 4*(SQRT(5)+1)/(SQRT(5)*(2*SQRT(5)+10)* ((4*xSQRT(5)+1)^2/(2*SQRT(5)+10)+1)) (SQRT(5)+3)*(4*x+SQRT(5)+1)/ ((10*SQRT(5)+10)*(2*x^2+(SQRT(5)+1)*x+2)) +(SQRT(5)3)*(4*xSQRT(5)+1)/ ((1010*SQRT(5))*(2*x^2+(1SQRT(5))*x+2)) +1/(5*(x1)) expr,x=1.1,numer => 1.638... exprsimp: ratsimp(expr) exprsimp,x=1.1,numer => 0.384...n (!!!) Other simplifications do not run into this problem, e.g. ratsimp(factor(expr)), ratsimp(rat(expr)), which nicely yield 1/(x^51).  Comment By: Robert Dodier (robert_dodier) Date: 20060630 21:24 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs / sbcl 0.9.9.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635338&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #619927, was opened at 20021007 15:05 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=619927&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: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: (1.0b0)^(1/3) vs (1.0d0)^(1/3) Initial Comment: With domain : real, (1.0b0)^(1.3) evaluates to its principal value while (1.0d0)^(1/3) evaluates using the realbranch rule. (C24) domain : real; (D24) REAL (C25) (1.0b0)^(1/3); (D25) 8.660254037844387B1 %I + 5.0B1 (C26) (1.0d0)^(1/3); (D26)  1.0 (C27) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=619927&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #751934, was opened at 20030610 08:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=751934&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: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent simplification of 1.0*x etc. Initial Comment: Maxima is sloppy about simplifications involving floating point numbers. Notation: ==> means simplifies to (OK) means I think this is correct (No!) means I think this is incorrect 1.0*x ==> x (No!) Prefer: 1.0*x though 2.0*x ==> 2.0*x (OK) 0.0*x ==> 0.0 (OK) 2.0*x2.0*x ==> 0 (No!) Prefer: 0.0 though 2.02.0 ==> 0.0 (OK) (2.02.0)*x ==> 0.0 (OK) x^1.0 ==> x (No!) Prefer: x^1.0 though x^2.0 ==> x^2.0 (OK) x^1.0 ==> x^1.0 (OK) (normally displays as 1/ (x^1.0)) x+0.0 ==> x (???) I am not sure whether this is correct. All the above cases also happen with mixed float/fixed and with bfloats.  Whenever the result depends on the floatingpoint precision, the float must be maintained.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=751934&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:24:13

Bugs item #721575, was opened at 20030414 21:45 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=721575&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: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: 2/sqrt(2) doesn\'t simplify Initial Comment: 2/sqrt(2) doesn't simplify. Similarly for 2/2^(2/3). On the other hand, x/sqrt(x) => sqrt(x). And of course sqrt(2) simplifies to itself  it doesn't become 2/sqrt(2)!! I believe the original examples should simplify to sqrt(2) and 2^(1/3). Note that 2^(4/3) => 2*2^(1/3) (the current behavior) is probably CORRECT, in order to make things like 10^(10/3) intelligible. Or is there something I'm missing? Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  Comment By: Stavros Macrakis (macrakis) Date: 20031008 21:21 Message: Logged In: YES user_id=588346 More examples. Righthand side is after ratsimp/algebraic. I believe the general simplifier should be giving those forms. 1/(2*2^(2/3)) 2^(1/3)/4 1/2^(2/3) 2^(1/3)/2 1/(2*SQRT(2)) SQRT(2)/4 1/SQRT(2) SQRT(2)/2 1/(2*2^(1/3)) 2^(2/3)/4 1/2^(1/3) 2^(2/3)/2 Things get worse with nonnumeric contents. In the following, each group of expressions denotes the same thing, but none simplifies to the others. I have put *** next to those forms which are the results of ratsimp/algebraic. Note that in several cases, there is more than one equivalent ratsimp'ed form.... 1/(a*b)^(5/2) 1/(a^2*b^2*SQRT(a*b)) *** SQRT(a*b)/(a^3*b^3) *** 1/(a*b)^(3/2) 1/(a*b*SQRT(a*b)) *** SQRT(a*b)/(a^2*b^2) *** 1/(a*b)^(7/6) 1/(a^(2/3)*b^(2/3)*SQRT(a*b)) *** SQRT(a*b)/(a^(5/3)*b^(5/3)) *** (a*b)^(5/6)/(a^2*b^2) *** 1/(a*b)^(5/6) *** 1/(a^(1/3)*b^(1/3)*SQRT(a*b)) *** (a*b)^(1/6)/(a*b) *** SQRT(a*b)/(a^(4/3)*b^(4/3)) *** 1/SQRT(a*b) *** SQRT(a*b)/(a*b) *** a^(1/3)*b^(1/3)/SQRT(a*b) *** 1/(a*b)^(1/6) *** SQRT(a*b)/(a^(2/3)*b^(2/3)) *** (a*b)^(5/6)/(a*b) *** Now it is true that these expressions are in fact not all equivalent as to principal value, but I will leave that exercise for later. Many of them are, and they are not being canonicalized.  Comment By: Stavros Macrakis (macrakis) Date: 20030417 12:53 Message: Logged In: YES user_id=588346 Yes, of course there are ways within Maxima to perform this simplification. But it should be the default in the general simplifer. The logic already appears to be in the general simplifier, but there is a bug in this particular case. If the general simplifier's philosophy were to leave such things untouched, why does it simplify x/sqrt(x) and the like?  Comment By: Barton Willis (willisb) Date: 20030417 12:44 Message: Logged In: YES user_id=570592 Try ratsimp with algebraic : true (C1) z : 2/sqrt(2); (D1) 2/SQRT(2) (C2) ratsimp(z); (D2) 2/SQRT(2) (C3) ratsimp(z),algebraic; (D3) SQRT(2) (C4) z : 2/2^(2/3); (D4) 2/2^(2/3) (C5) ratsimp(z); (D5) 2/2^(2/3) (C6) ratsimp(z),algebraic; (D6) 2^(1/3) (C7)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=721575&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:22:06

Bugs item #742909, was opened at 20030524 16:27 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742909&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  Trigonometry Group: None Status: Open Resolution: None Priority: 4 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigrat(sin(x/2)) makes a mess Initial Comment: trigrat(sin(x/2)) => (%I*(SIN(x/2)*SIN(x)+COS(x/2)*COS(x)COS(x/2)) COS(x/2)*SIN(x)+SIN(x/2)*COS(x)SIN(x/2))/(2*SIN(x/2) ^2+2*COS(x/2)^2) Although this is correct, I doubt that this is what trigrat is supposed to do. After all, it has not eliminated sin (x/2); the result contains sin(x/2), but also contains sin^2+cos^2, so it doesn't seem "more linear" in any sense. Also, it is not a canonical form: trigrat(ev(sin (x/2),halfangles)) gives something else (even messier). Note also that sin(2*x) does not expand in trigrat.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=742909&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:20:22

Bugs item #651585, was opened at 20021210 12:24 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=651585&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: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: solve cannot handle sets of nonlinear e Initial Comment: intech19:/fix/f/debian/mm/maxima/59/maxima$ ./maximalocal GCL (GNU Common Lisp) Version(2.5.0) Thu Dec 5 08:07:35 EST 2002 Licensed under GNU Library General Public License Contains Enhancements by W. Schelter Maxima 5.9.0rc3 http://maxima.sourceforge.net Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (C1) y:[ (x2x1)^2+(y2y1)^2=36^2, (x3x1)^2+(y3y1)^2=25^2, (x3x2)^2+(y3y2)^2 =17^2]; 2 2 2 2 (D1) [(Y2  Y1) + (x2  x1) = 1296, (Y3  Y1) + (x3  x1) = 625, 2 2 (Y3  Y2) + (x3  x2) = 289] (C2) solve(y, [x1, y1, x2, y2, x3, y3]); Error: 0 is not of type LIST. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. ======================================================================= intech19:/fix/f/debian/mm/maxima/59/maxima$ ./maximalocal i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `+' / 8 8 8 ooooo 8oooo `____' 8 8 8 8 8  8 o 8 8 o 8 8 + ooooo 8oooooo ooo8ooo ooooo 8 Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 19941997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 19992001 Maxima 5.9.0rc3 http://maxima.sourceforge.net Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (C1) y:[ (x2x1)^2+(y2y1)^2=36^2, (x3x1)^2+(y3y1)^2=25^2, (x3x2)^2+(y3y2)^2 =17^2]; 2 2 2 2 (D1) [(Y2  Y1) + (x2  x1) = 1296, (Y3  Y1) + (x3  x1) = 625, 2 2 (Y3  Y2) + (x3  x2) = 289] (C2) solve(y, [x1, y1, x2, y2, x3, y3]); ***  CDR: 0 is not a list The following restarts are available: R1 = Macsyma toplevel 1. Break [1]>  Comment By: Robert Dodier (robert_dodier) Date: 20060630 22:56 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs. 2nd example needs to have c replaced by C to trigger error: algsys ([a*b*C(a1)*(a+1)*d,b*(a*db*C+1), C*(a*db*C+1),ad*(a*db*C)], [a,b,C,d]); => error  Comment By: Stavros Macrakis (macrakis) Date: 20030131 15:20 Message: Logged In: YES user_id=588346 Another example (checked in 5.9.0rc4): algsys([a*b*C(a1)*(a+1)*d,b*(a*db*C+1),C*(a*db*C+1),ad* (a*db*C)],[a,b,c,d]) => Error: 0 is not of type LIST.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=651585&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:20:21

Bugs item #609466, was opened at 20020914 21:26 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609466&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal error in solve/algsys Initial Comment: solve( [ a^2+b^2+c^21, c*f+b*d+a*b, c*g+b*f+a*c, c*f+b*d+a*b, b^2+d^2+f^21, f*g+d*f+b*c, c*g+b*f+a*c, f*g+d*f+b*c, g^2+f^2+c^21], [a,b,c,d,f,g]) gives "Caught fatal error".  Comment By: Robert Dodier (robert_dodier) Date: 20060626 12:19 Message: Logged In: YES user_id=501686 Observed in 5.9.3.  Comment By: Stavros Macrakis (macrakis) Date: 20020917 22:09 Message: Logged In: YES user_id=588346 A simpler fatal error. solve([a+b+c=0,a^2+b^2+c^2=1],[a,b,c])  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=609466&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:20:21

Bugs item #611129, was opened at 20020918 08:52 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611129&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Egregious bug in Solve/Algsys Initial Comment: In a very simple case, Solve/Algsys (a) reports many incorrect solutions and (b) misses all the parameterized solutions.  Define equations eqs: [a+b+c=0, a*b*c=1]  These seem pretty simple, don't they?  Solve 2 equations for 3 unknowns (normal algsys) sols: solve(eqs,[a,b,c])  Gives 12 solutions  Substitute back the solutions subst: map(lambda([sol],subst(sol,eqs)),sols)  Big mess  Now evaluate them numerically to eyeball them rectform(subst),numer  Surprise! Only 6 of the 12 are right. And it is completely missing the parametric solution(s)!!! For example, a= 2 / ( sqrt( Q^44*Q )  Q^2 ) b= ( sqrt( Q^44*Q )  Q^2 ) / (2*Q) c= Q  Comment By: Robert Dodier (robert_dodier) Date: 20060626 12:22 Message: Logged In: YES user_id=501686 Observed in 5.9.3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611129&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:20:21

Bugs item #607079, was opened at 20020909 19:21 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=607079&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve with repeated variable Initial Comment: solve([x=1],[x,x]) returns [[x=1%R12,x=%R12]] which is obviously bogus. It should either complain about the repeated solution variable or  better  return [[x=1]] or [[x=1,x=1]]  Comment By: Robert Dodier (robert_dodier) Date: 20060626 12:15 Message: Logged In: YES user_id=501686 Maxima 5.9.1 & 5.9.3: solve([x = 1], [x, x]) => bogus solution. But algsys([x = 1], [x, x]) => [[x = 1]]. Cut algsys out of summary line accordingly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=607079&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:18:55

Bugs item #580721, was opened at 20020712 12:38 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: trigexpand bug Initial Comment: Consider this: (C1) display2d:false; (D1) FALSE (C2) tan(%pi/2+x); (D2) COT(x) (C3) tan(%pi/2+%pi*x); (D3) TAN(%PI*x+%PI/2) (C4) %,trigexpand; Division by 0  an error. Quitting. To debug this try DEBUGMODE(TRUE);) d3 should have been expanded into cot(%pi*x) instead of getting a division by zero error.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:40 Message: Logged In: YES user_id=501686 For the record, same problem observed in maxima 5.9.3.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=580721&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:18:55

Bugs item #505443, was opened at 20020118 09:53 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=505443&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Yapp (starseeker) Assigned to: Nobody/Anonymous (nobody) Summary: Halfangle limitation Initial Comment: Setting HALFANGLES gives sin(x/2) => sqrt(1cos(x))/2. Of course, this is wrong if x is negative. Need to make it smarter.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 16:13 Message: Logged In: YES user_id=501686 For the record, (halfangles : true, sin (x/2)); => sqrt(1cos(x))/sqrt(2)$ i.e., same behavior as when this report was first made. Recently (Maxima 5.9.3) floor and ceiling have been implemented as simplifying functions, and the simplifications for entier mentioned below are all implemented. (1)^(2*floor(x)) => 1 floor(floor(x)) => floor(x) floor(x + 5) => floor(x) + 5 Perhaps this means it is now reasonable to change the halfangle simplification to (1)^floor(x/(2*%pi)) * <whatever>.  Comment By: Stavros Macrakis (macrakis) Date: 20021003 10:49 Message: Logged In: YES user_id=588346 The proposed correction, sign(x)*sqrt(1cos(x)) / sqrt(2) only extends the validity of the formula from [0,2pi] to [ 2pi,2pi]. It continues to be incorrect whenever fix(x/(2*pi)) is odd. I suppose you could use (1)^entier(x/(2*pi)) * sqrt(1cos(x))/sqrt(2) but I'm not sure that is terribly useful, especially since Maxima knows nothing about Entier except how to evaluate it for constants. For example, (1)^(2*Entier(...)) should simplify to 1, but doesn't. Entier(Entier(x)) should simplify to Entier (x). Entier(x+5) should simplify to Entier(x)+5. Etc.  Comment By: Raymond Toy (rtoy) Date: 20020627 11:42 Message: Logged In: YES user_id=28849 What are you expecting? I think it would be fairly easy for maxima to say sign(x)*sqrt(1cos(x))/2 (assuming I got that right.) See halfangleaux in logarc.lisp.  Comment By: Cliff Yapp (starseeker) Date: 20020626 15:19 Message: Logged In: YES user_id=11463 Unfortunately, I wasn't the original person to speak on this one  I just submitted it from the list, and I can't remember who it was. If you think the current behavior is OK then it probably isn't worth fussing with too much. CY  Comment By: Raymond Toy (rtoy) Date: 20020626 15:06 Message: Logged In: YES user_id=28849 What are you expecting? I think it would be fairly easy for maxima to say sign(x)*sqrt(1cos(x))/2 (assuming I got that right.) See halfangleaux in logarc.lisp.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=505443&group_id=4933 
From: SourceForge.net <noreply@so...>  20060827 00:18:55

Bugs item #708917, was opened at 20030324 10:34 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=708917&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  Trigonometry Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: trigreduce(sin(x)^2/cos(x)^2) Initial Comment: trigreduce(sin(x)^2/cos(x)^2) => tan(x)^2 Shouldn't it return (1cos(2*x))/(1+cos(2*x))? For that matter, it would be nice if trigreduce(tan(x)^2) also did this, but the documentation of trigreduce explicitly says that it handles only sin's and cos's (unlike trigexpand, which handles trigs in general). On the other hand, Trigrat already does this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=708917&group_id=4933 