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}
(24) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(29) 
2
(6) 
3

4
(26) 
5
(3) 
6
(10) 
7
(25) 
8
(20) 
9

10
(21) 
11
(10) 
12
(3) 
13
(10) 
14
(7) 
15
(1) 
16
(1) 
17
(1) 
18

19
(15) 
20

21
(1) 
22
(7) 
23
(10) 
24
(10) 
25

26
(1) 
27
(1) 
28
(5) 
29
(26) 
30

31
(30) 





From: SourceForge.net <noreply@so...>  20060701 06:30:50

Bugs item #1515430, was opened at 20060701 00:30 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=1515430&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: 3 Submitted By: Robert Dodier (robert_dodier) Assigned to: Nobody/Anonymous (nobody) Summary: und not propagated through functions Initial Comment: The symbol und, which I guess stands for undefined, isn't propagated through functions, e.g., [sin(und), sqrt(und), log(und), und^2, exp(und)] => [sin(und),sqrt(und),log(und),und^2,%e^und] An example found in the wild: limit(atan(tan(x)^2),x,inf); => atan(und) Not sure what's the right answer for foo(und) in general, but it seems like atan(und) is probably not the best answer in this particular case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1515430&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 06:22:42

Bugs item #660884, was opened at 20030101 17:49 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660884&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: Wont Fix Priority: 2 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: maxprime should be 1 Initial Comment: Maxima 5.5 Windows GCL maxprime (the largest number which may be given to the PRIME(n) command, which returns the nth prime) is set to 489318. Since Prime(n) doesn't work, it should be set to 0 or something.  >Comment By: Robert Dodier (robert_dodier) Date: 20060701 00:22 Message: Logged In: YES user_id=501686 Commented out $prime and $maxprime in src/numth.lisp and committed as r1.8. Keeping an unimplemented function & its associated global variable in the source code serves no useful purpose. Closing this report as "won't fix".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660884&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 06:19:41

Bugs item #661163, was opened at 20030102 09:30 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=661163&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: need special declaration in rat3a/pquotient1/FIX Initial Comment: When running in interpreted (not compiled) GCL, it appears that the special declarations for k and q* in pquotient1 and pquotient2 need to be within the body of the functions, because apparently the special/unspecial declarations surrounding them are dynamic, not lexical. I have no idea if this is a GCL problem or not (I don't know the CL semantics of this case), but adding special declarations right after the arg list appears to fix the problem: (DEFUN PQUOTIENT1 (U V &AUX Q* (k 0)) (declare (fixnum k) (special k q*)) <<<<<<<<<< NEW (sloop do (setq k (f (ptle u) (ptle v))) ..... (DEFUN PQUOTIENT2 (X Y &AUX (I 0)) .... (declare (special k q*)) <<<<<<<<<<< NEW (COND ((NULL Y) X)  >Comment By: Robert Dodier (robert_dodier) Date: 20060701 00:19 Message: Logged In: YES user_id=501686 What triggers this bug? Hard to know if it is fixed without a test case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=661163&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 06:16:47

Bugs item #660948, was opened at 20030101 21:23 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&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  Complex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simplification of exp(%i*...) Initial Comment: There are some weirdnesses and inconsistencies in the simplification of exp(%i*...). First, let's look at the case exp(%i*%pi*q). If q is (m/n) with n in {1,2,3,4,6}, it returns a solution in rationals and radicals, e.g. for q=11/3, we get 1/2SQRT (3)*%I/2. For other n's, it reduces q to the range (1,+1]. If q is a float which is exactly m/n as above, it rationalizes it: exp(%i*%pi*.25) => SQRT(2)*%I/2+SQRT(2)/2 I am not comfortable with this, because a floating point number is supposed to be an approximation, and we're getting an exact result here. It does the same thing for x^1.0 and (x^3)^float(1/3), though not for x^0.5 or x^2.0 or (x^3)^float(5/3). However, it does a weird thing if q is very near m/n: exp(%i*%pi*.166666666) => (%I/2+SQRT(3)/2)*%E^(6.666666663157628E10*%I*% PI) Of course this is accurate, but it seems pointless and bizarre. It is also inconsistent in its handling of purely floating exponents: exp(%i*%pi*.333) => %E^(0.333*%I*%PI) (OK) but exp(%i*%pi*5.333) => %E^(667*%I*%PI/1000) (why rationalized here?) Now let's look at the case exp(%i*q). If q = 1.0 exactly, it acts as though q=1: exp(%i*1.0) => %e^%i. This follows the (in my opinion anomalous) case x^1.0 => x, as above. I don't know why this should be; after all, 2^1.0 => 2.0, not 2. And for other floats, it does no reduction at all to (pi,pi]: exp(%i*ev(%pi,numer)) => %E^(3.141592653589793*%I) exp(%i*ev(%pi*100,numer)) => %E^(314.1592653589793*%I) exp(%i*300.0) => exp(%i*300.0) All this needs to be made consistent and clear. In my opinion, floats should NEVER be coerced to exact numbers, unless the user asks for it (e.g. by converting to Rat form).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660948&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 06:02:12

Bugs item #660876, was opened at 20030101 17:16 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660876&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  Taylor Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor and keepfloat ERR Initial Comment: Maxima 5.5 Windows GCL qq: taylor((x+1.0)^2,x,1,3),keepfloat; => 4.0 + 4.0 (x  1) + 1.0 (x  1) + . . . qq^2 => ... Error: 128.0 is not of type INTEGER. but qq^2,keepfloat => OK  The immediate problem is in CGCD (similarly in PGCDA), which assumes that its arguments are integers if $KeepFloat is false. Though there is an easy patch, namely to remove the "and $KeepFloat" condition, the real problem seems to be that if KeepFloat is false, it should already have rationalized the coefficients, as in the rat case: rr: rat(x+1.0)^2,keepfloat rr^2 => rat replaced 1.0 by ... So if you do do the quick and dirty patch above, you run into a problem later, in *red... Annoyingly, some of these bugs go away if you trace various functions. I have not tracked down the details.  >Comment By: Robert Dodier (robert_dodier) Date: 20060701 00:02 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660876&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 06:00:53

Bugs item #660766, was opened at 20030101 11:57 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660766&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 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(q^a,a,inf) wrong with q=1 Initial Comment: In Maxima 5.5 Windows GCL limit(q^a,a,inf) Is ABS(q)  1 positive, negative, or zero? zero; Is q positive, negative, or zero? pos; => INF (NO) If abs(q)1=0, then abs(q)=1, so q is either 1 or 1. If q is also positive, then q=1, so q^a is everywhere 1, so limit(q^a,a,inf) is also 1. Same thing if q is assumed equal to 1: assume(equal(q,1))$ limit(q^a,a,inf) => INF (NO) Similarly, limit(q^a,a,inf) // abs(q)=1,q<0 => INFINITY (NO) instead of IND, though limit((1)^a,a,inf) => IND (OK).  >Comment By: Robert Dodier (robert_dodier) Date: 20060701 00:00 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=660766&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 05:57:54

Bugs item #659288, was opened at 20021227 23:02 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=659288&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: Closed >Resolution: Works For Me Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: limit(atan(tan(x)^2),x,inf)=>Internal error Initial Comment: limit(atan(tan(x)^2),x,inf); SIGN called on UND.  an error. The correct answer is of course IND  the limit set is [0,%pi/2). Presumably what is happening here is that there is an intermediate calculation of limit(tan(x)^2,x,inf).  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 23:57 Message: Logged In: YES user_id=501686 Present in 5.9.1, but not 5.9.3. In 5.9.3, limit(atan(tan(x)^2),x,inf); => atan(und) which is strange but it is not an error message at least. I'll open a separate report for that. For the other example limit(atan(und)); => und which seems OK.  Comment By: Stavros Macrakis (macrakis) Date: 20040419 16:50 Message: Logged In: YES user_id=588346 limit(atan(und)) also gets Sign called on UND. Of course, onearg limit is not advertised to work with UND, but internally it seems likely that this is what it is doing.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=659288&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 05:52:53

Bugs item #658850, was opened at 20021226 17:47 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=658850&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  Taylor Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: Taylor "invalid call to varexpand" Initial Comment: Maxima 5.5 on Windows GCL C15) taylor(exp(x)/x,x,0,5); Invalid call to varexpand  an error. This is an internal error. Though this expression does not have a Taylor/Laurent expansion, it should still give a useroriented error, not an internal error.  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 23:52 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030602 14:00 Message: Logged In: YES user_id=588346 expr: (nn^(nn+1)(nn2)^nn*nn+2*(nn2)^nn)*p/(2*nn^nn*ppy) taylor(expr,nn,inf,0) gives Invalid call to varexpand but taylor(expand(expr),nn,inf,0) returns a result which looks correct.  Comment By: Martin Rubey (kratt5) Date: 20030123 03:39 Message: Logged In: YES user_id=651552 It should read taylor(exp(1/x)/x,x,0,5); Invalid call to varexpand  an error. Quitting. To debug this try DEBUGMODE(TRUE);  Comment By: Stavros Macrakis (macrakis) Date: 20030122 06:48 Message: Logged In: YES user_id=588346 Sorry, I must have miscopied the error case (or perhaps some flags were set?), and I can't reconstruct it. The example I gave does work in 5.5, and does have a Laurent expansion. I am deleting this bug report and marking it as "invalid".  Comment By: Martin Rubey (kratt5) Date: 20030122 06:39 Message: Logged In: YES user_id=651552 I do not quite understand. On my (slightly patched) maxima I get:  Maxima version: 5.9.0rc3 Maxima build date: 21:0 11/26/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  The above information is also available from the Maxima function build_info(). (D1) (C2) taylor(exp(x)/x,x,0,5); 2 3 4 5 1 x x x x x (D2)/T/   1 +    +    +  + . . . x 2 6 24 120 720 (C3) which seems to be correct... Martin  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=658850&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 05:01:31

Bugs item #652470, was opened at 20021211 20:44 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=652470&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: Pickapart error (due to MEMSIMILAR) Initial Comment: The Pickapart of a rather messy formula (irrelevant here) gives: Error: ((RAT SIMP) 1 9) is not of type NUMBER. The problem is in the MEMSIMILAR routine: (DEFUN MEMSIMILAR (ITEM1 ITEM2 ITEM2EV) (COND ((EQUAL ITEM2EV 0) NIL) ((ALIKE1 ITEM1 ITEM2EV) ITEM2) (T (LET ((ERRORSW T) R) (SETQ R (CATCH 'ERRORSW (DIV ITEM2EV ITEM1))) (AND (not (zerop1 r)) ;(MNUMP R) (NOT (ZEROP R)) ;;; ^^^ NO! MNump includes rats and bigfloats (DIV ITEM2 R))))))  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 23:01 Message: Logged In: YES user_id=501686 Bug is presumably still present in 5.9.3cvs because MEMSIMILAR in src/outmis.lisp still calls MNUMP. Not clear how to patch MEMSIMILAR, not clear how to test if patch works.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=652470&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 04:56:04

Bugs item #651585, was opened at 20021210 12:24 Message generated for change (Comment added) 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 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...>  20060701 04:50:30

Bugs item #649669, was opened at 20021206 11:55 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649669&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: is(equal([x],[rat(x)])) => error Initial Comment: is(equal([x],[rat(x)])) => FATAL ERROR Macsyma 5.5  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 22:50 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs. gcl => "Caught fatal error [memory may be damaged]" sbcl & clisp => "1 is not a list" Probably ratdisrep or something like that needs to be called. See also bug report # 643254 "orderlessp([rat(x)], [rat(x)])".  Comment By: Robert Dodier (robert_dodier) Date: 20031209 19:19 Message: Logged In: YES user_id=501686 I tried this again with a build from cvs dated 20031128, and I don't get a fatal error, I get: Maxima encountered a Lisp error: CAR: 1 is not a LIST Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil. and then it's back to the user input prompt. I'm running Maxima on clisp 2.31. I don't know what the right behavior is, but it's encouraging that I didn't get a fatal error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=649669&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 04:42:31

Bugs item #643259, was opened at 20021124 15:33 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643259&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: Duplicate Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) >Summary: orderlessp([rat(x)], [rat(x)]) (duplicate of # 643254) Initial Comment: The orderlessp function often halts with a (nondescriptive) error message if one or more of its arguments are lists or matrices containing CRE expressions. The Maxima documentation for orderlessp doesn't mention this limitation. If you need to order expressions that might involve lists or matrices containing CRE expressions, apply totaldisrep to each argument of the ordering predicate. Here's an example Maxima 5.5 Tue Dec 5 16:55:33 2000 (with enhancements by W. Schelter). Licensed under the GNU Public License (see file COPYING) (C4) xorderlessp(x,y) := orderlessp(totaldisrep(x), totaldisrep(y)); (D4) xorderlessp(x, y) := ORDERLESSP(TOTALDISREP(x), TOTALDISREP(y)) /* xorderlessp works okay on lists with CRE elements */ (C5) xorderlessp([rat(x)],[rat(x)]); (D5) FALSE (C6) orderlessp([rat(x)], [rat(x)]); Error: 1 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. MAXIMA>> Either the documentation should warn the user not to use orderlessp or ordergreatp on lists or matrices that contain CRE elements, or these functions should apply totaldisrep to each argument. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 22:42 Message: Logged In: YES user_id=501686 Duplicate of # 643254.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643259&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 04:40:20

Bugs item #643254, was opened at 20021124 15:11 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643254&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 (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp([rat(x)], [rat(x)]) Initial Comment: The orderlessp function often halts with a (nondescriptive) error message if one or more of its arguments are lists or matrices containing CRE expressions. The Maxima documentation for orderlessp doesn't mention this limitation. If you need to order expressions that might involve lists or matrices containing CRE expressions, apply totaldisrep to each argument of the ordering predicate. Here's an example Maxima 5.5 Tue Dec 5 16:55:33 2000 (with enhancements by W. Schelter). Licensed under the GNU Public License (see file COPYING) (C4) xorderlessp(x,y) := orderlessp(totaldisrep(x), totaldisrep(y)); (D4) xorderlessp(x, y) := ORDERLESSP(TOTALDISREP(x), TOTALDISREP(y)) /* xorderlessp works okay on lists with CRE elements */ (C5) xorderlessp([rat(x)],[rat(x)]); (D5) FALSE (C6) orderlessp([rat(x)], [rat(x)]); Error: 1 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. MAXIMA>> Either the documentation should warn the user not to use orderlessp or ordergreatp on lists or matrices that contain CRE elements, or these functions should apply totaldisrep to each argument. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 22:40 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs. Right thing to do here is to have GREAT apply totaldisrep. Even better would be to give CRE's a representation which doesn't require special cases scattered through the entire codebase.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=643254&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 04:23:07

Bugs item #640332, was opened at 20021118 14:35 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=640332&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Need to specdisrep more systematically Initial Comment: There are lots of places where the Poisson representation isn't handled properly, and a few where Rat isn't handled properly. I'm not sure if anyone cares about Poisson representation, to tell the truth, but it would be nice if specrepcheck were used more consistently.... Of course, it would be even better if representationspecific routines were called, but we can start with specrepcheck. For example: diff(rat(x),rat(x)) => 1 OK but diff(x,rat(x)) => 0 BAD diff(intopois(U),U) => fatal error taylor(intopois(sin(U),U,0,3) => fatal error ratsimp(intopois(sin(U))) => internal error  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=640332&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 04:21:14

Bugs item #639880, was opened at 20021117 21:03 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=639880&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: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ode2 internal error for invalid input Initial Comment: ode2('diff(y,x,3)=0,y,x) => $STATUS is invalid as a function I realize that ode2 is only supposed to handle 1st and 2nd order, but it should fail more gracefully. Same error for similarly for ode2('diff(y,x)^2=1,y,x); (Maxima 5.5)  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 22:21 Message: Logged In: YES user_id=501686 Appears to have been fixed by r1.2 src/ode2.lisp. At present the above examples provoke "Not a proper differential equation" which I guess is OK although perhaps not maximally informative. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=639880&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 04:09:56

Bugs item #635627, was opened at 20021108 11:35 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: subst([...] is orderdependent Initial Comment: I would have expected subst([a=...,b=...],...) to substitute a and b simultaneously (like Lisp Sublis), but it does not, and it simplifies along the way. Here are some cases where it matters. The most obvious case is subst([b=c,a=b],b) => c This means that subst cannot be used to permute variables, e.g. subst([x=y,y=x],...) That is not good.  But there are other cases:  subst([a=0,b=0],atan2(a,b)) Depending on the answers to a>0 etc., this can return 0 or %pi, whereas subst([b=0,a=0],...) can return pi/2 or  pi/2. I believe that it should give the error: atan2(0.0) has been generated.  subst(["="="+","["="*"],[x=1,x=2]); gives (x+1) * (x+2) as expected, but subst(["["="*","="="+"],[x=1,x=2]); gives x^2+2 ((It would have been nice if minus were nary, so that I could use "="=""...))  These two cases can be worked around by turning simp off temporarily, e.g. subst(["["="*","="="+"],[x=1,x=2]), simp:false; but the workaround for the first case is much clumsier: subst([x=x0,y=x,x0=y],...)  Comment By: Stavros Macrakis (macrakis) Date: 20030712 14:23 Message: Logged In: YES user_id=588346 Another case where simultaneous substitution is necessary... subst([a=[1,2],b=[3,4]],a+b) => [[4,5],[5,6]] instead of the expected [4,6] because [1,2]+b => [1+b,2+b], then 1+[3,4] => = [4,5] etc. I am arguing that simultaneous substitution is the only reasonable default behavior.  Comment By: Stavros Macrakis (macrakis) Date: 20021119 12:48 Message: Logged In: YES user_id=588346 Sublis is broken for operators, e.g. sublis(["+"="*"],x+y) And the online documentation (describe) of subst does not mention the parallel substitution issue. I do not think we need both subst([...]) and sublis([...]...). My guess is that sublis was defined before subst was extended to cover the multiple substitution case.  Comment By: Nobody/Anonymous (nobody) Date: 20021116 09:43 Message: Logged In: NO The info tells you to use SUBLIS if you want to do substitution in parallel.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635627&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 03:52:38

Bugs item #635616, was opened at 20021108 11:17 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635616&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  Integration Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: defint infloop with algebraic:false Initial Comment: expr: 1/(2*x^2sqrt(5)1) integrate(expr,x,0,inf) => takes forever (infloop?) but if you set algebraic:true (the default value is false), it returns 0 quickly. Is the user supposed to know that algebraic must be set to true in cases like this? It seems a lot to ask, especially since I doubt it's documented anywhere....  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 21:52 Message: Logged In: YES user_id=501686 Evaluation of integrate(expr,x,0,inf) with algebraic=false is slow (ranging from 15 s for gcl to 45 s for clisp, on my 450 MHz desktop box), but well short of infinite. Evaluation is much faster when algebraic=true (ranging from 3 to 15 s). It is not reasonable to expect the user to know how to set the algebraic flag for this case but that is a separate topic. Closing this report as "works for me".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635616&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 03:24:45

Bugs item #635338, was opened at 20021107 22:17 Message generated for change (Comment added) 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 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...>  20060701 03:17:07

Bugs item #635045, was opened at 20021107 09:31 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635045&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: Fixed Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: derivatives of acsc, ... Initial Comment: Maxima's formulae for the derivatives of acsc, asec, acsch, and asech are incorrect in the left half plane. To illustrate, we should have asin(1/x)  acsc(x) = 0 for all x # 0; however, (C2) ratsimp(diff(asin(1/x)  acsc(x),x)); (D2) SQRT(x^21)*(ABS(x)x)/(x^4x^2) This only vanishes for x > 0. I've attached a diff file for comm.lisp that fixes these problems. And I attached an rtest file that tests the derivatives of the inverse trig functions. Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 21:17 Message: Logged In: YES user_id=501686 Problem shown here is OK now (5.9.3cvs): ratsimp(diff(asin(1/x)  acsc(x),x)); => 0 Patch was applied to src/comm.lisp and committed as r1.12. Test cases found their way into the cvs as tests/rtest_diff_invtrig.mac and 5.9.3cvs passes all tests. Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635045&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 03:05:24

Bugs item #633367, was opened at 20021104 10:07 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=633367&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: Share Libraries Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Reimar Finken (reimar) Assigned to: Nobody/Anonymous (nobody) Summary: assoc_leg_cos bug Initial Comment: assoc_leg_cos (which is called only by spherical_harmonic()) gives an error when the x parameter is a number and not a symbol: (C2) spherical_harmonic(1,0,0,0); 0 0 has been generated #0: assoc_leg_cos(n=1,m=0,x=0)(specfun.mac line 591) #1: spherical_harmonic(n=1,m=0,theta=0,phi=0)(specfun.mac line 607)  an error. Quitting. To debug this try DEBUGMODE(TRUE);) (C3) assoc_leg_cos(1,0,0); 0 0 has been generated #0: assoc_leg_cos(n=1,m=0,x=0)(specfun.mac line 591)  an error. Quitting. To debug this try DEBUGMODE(TRUE);) The error occurs before the ultraspherical() function is called on line 591 in specfun.mac, but after the c value has correctly been evaluated in the if branch before.  >Comment By: Robert Dodier (robert_dodier) Date: 20060630 21:05 Message: Logged In: YES user_id=501686 specfun package is superseded by orthopoly (which is in 5.9.3 and maybe 5.9.2, can't remember at the moment). Now the above example is OK: load (orthopoly); spherical_harmonic (1,0,0,0); => sqrt(3)/(2*sqrt(%pi)) Closing this report as fixed.  Comment By: Reimar Finken (reimar) Date: 20021104 11:33 Message: Logged In: YES user_id=641546 The expression sin (x)^m, which evaluated to 0^0, was causing the problems. Splitting this line into the two different if branches (taking care of the m=0 case) solved the problem. Patch attached.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=633367&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 02:58:24

Bugs item #631216, was opened at 20021030 12:54 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=631216&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: horner([...],x)/FIX Initial Comment: Horner of a list/matrix/equation returns the argument. Looking at the code shows that it is intended to map across these aggregates (or bags as they're called). The problem is that it is putting the argument in rational form *before* checking whether it is a bag. There are two possible ways to fix it. First is to modify Horner. (defmfun $horner (expr &rest vars) (if (mbagp expr) (cons (car expr) (mapcar #'(lambda (u) (apply '$horner u vars)) (cdr expr))) (let* (($ratfac nil) (varlist (cdr $ratvars)) (genvar nil) (x (apply '$rat (taychk2rat expr) vars))) (mapc #'(lambda (y z) (putprop y z 'disrep)) (cadddr (car x)) (caddar x)) (div* (hornrep (cadr x)) (hornrep (cddr x)))))) The cleaner way is to modify taychk2rat to use $rat instead of ratf. In that case, ratnumer and ratdenom also need to be modified to explicity check mbagp. The only other use of taychk2rat is in partfrac, and this change doesn't bother it. The only risk to doing this is if there is user code that depends on (e.g) ratnumer([x/y]) returning [x/y] rather than [x], which seems highly unlikely. (DEFMFUN $RATNUMER (X) (IF (MBAGP X) (CONS (CAR X) (MAPCAR '$RATNUMER (CDR X))) (SETQ X (TAYCHK2RAT X)) (CONS (CAR X) (CONS (CADR X) 1)))) (DEFMFUN $RATDENOM (X) (IF (MBAGP X) (CONS (CAR X) (MAPCAR '$RATDENOM (CDR X))) (SETQ X (TAYCHK2RAT X)) (CONS (CAR X) (CONS (CDDR X) 1)))) (DEFUN TAYCHK2RAT (X) (COND ((AND ($RATP X) (MEMQ 'TRUNC (CDAR X))) ($TAYTORAT X)) (T ($RAT X))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=631216&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 02:56:46

Bugs item #629714, was opened at 20021028 01: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=629714&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: x^^1 . x . y . x . y Initial Comment: x^^1 . x . y . x . y simplifies to x^^1 . (x . y)^^2 instead of y . x . y But the following work correctly: x^^1 . x . y . x . y . y => y . x . y^^2 (x^^1 . x . y) . x . y => y . x . y y . x . y . x . x^^1  A consequence of the above (this was the original problem I ran into): x^^1 . (x . y)^^2 expand(%) returns it unchanged. OK expand(%), dotexptsimp:false returns x^^1 . x . y . x . y and now expand(%) gives x^^1 . (x . y)^^2 instead of y . x . y Hmm. So how do I simplify this to y.x.y?  Compare this to x^^1 . (x . y)^^2 . y^^1 and (x . y . x^^1)^^2 and y . (x . y)^^1 and (x . y)^^1 . x for all of which the sequence expand/dotexptsimp:false then expand performs the expected cancellation.  The problem is that simpnct simplifies from right to left, so that by the time it sees x^^1 . x . y...., that has already become x^^1 . (x . y)^^2, which it doesn't currently simplify. The quick fix is to specialcase this in simpnct, but it's a bit messy....  Comment By: Stavros Macrakis (macrakis) Date: 20030804 09:26 Message: Logged In: YES user_id=588346 For commutative terms, there is a simple canonical form in Maxima. But there is no canonical form for noncommutative terms. I wonder if by default the simplifer should canonicalize them. Currently, for example, (a.b.a^^1)^^2 and a.b^^2 .a^^1 (which are equivalent): both currently simplify to themselves. But if we canonicalize to the second one (following the rule that all possible cancellations have been carried out), we lose the structure shown in the first case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=629714&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 02:55:38

Bugs item #626791, was opened at 20021022 03:30 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626791&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: scanmap factor problem Initial Comment: expr: %I*LOG( ( x^4/((x^21)^2+2*x^2) 4*x^2/((x^21)^2+2*x^2) +1/((x^21)^2+2*x^2) )^2 + ( 2*SQRT(2)*x^3/((x^21)^2+2*x^2) 2*SQRT(2)*x/((x^21)^2+2*x^2) )^2 ); scexpr: scanmap(factor,expr) => %I*LOG((x^8+2*x^4+1)/(x^4+1)^2) This looks OK, except that the inside rational expression is not factored (it is actually equal to 1). So let's try scanmap/factoring it again: scanmap(factor, scexpr) => No change! On the other hand, if we enter the expression from scratch: entered: %I*LOG((x^8+2*x^4+1)/(x^4+1)^2) we find that it does factor nicely scanmap(factor,entered) => 0 The reason is that the internal form of scexpr is marked Factored and Irreducible: ((MTIMES SIMP) $%I ((%LOG SIMP) ((MTIMES SIMP FACTORED) ((MEXPT SIMP) ((MPLUS SIMP IRREDUCIBLE) 1 ((MEXPT SIMP RATSIMP) $x 4)) 2) ((MPLUS SIMP IRREDUCIBLE) 1 ((MTIMES SIMP) 2 ((MEXPT SIMP RATSIMP) $x 4)) ((MEXPT SIMP RATSIMP) $x 8))))) I see two issue here. First of all, I'd have expected the scanmap/factor to go directly to the fully factored form, namely 0. Secondly, if it doesn't, it should at least not mismark the result as factored/irreducible. The incomplete factoring is arguably part of the semantics of Scanmap, inherent in topdown scanning, . And indeed Scanmap/bottomup does get the simplest form (after patching subst0 as reported in the previous bug note). On the other hand, I don't see any excuse for mismarking. If something isn't factored or irreducible, it shouldn't be marked as factored or irreducible. Note that Factor actually has a special case for Scanmap (the scanmapp flag). I suspect that this is to force incomplete factoring, and that mismarking comes as an undesired sideeffect.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626791&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 02:54:59

Bugs item #626721, was opened at 20021022 01:15 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626721&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: logarc of atan2 wrong Initial Comment: res : logarc(atan2(y,x))$ rectform(res),y=1,x=1; => %pi/4 BUT atan2(1,1) => 3*%pi/4 The fix is to change the formula in $logarc and in simpatan2. Currently, logarc(atan2(y,x)) => logarc(atan (y/x)), which gives incorrect results as above. This formula should be replaced by %i*log((y+%i*x)/sqrt(x^2+y^2))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=626721&group_id=4933 
From: SourceForge.net <noreply@so...>  20060701 02:49:43

Bugs item #625226, was opened at 20021018 07:50 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625226&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: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Factor errors: finite modulus, 3 vrbls Initial Comment: poly: (x+y+z)*(w+y+z)*(w+x+z); factor(rat(poly)),modulus:2; => Not enough choices for substitution.  an error. factor(rat(poly)),modulus:3 => irreducible (WRONG) factor(rat(poly)),modulus:5 => OK factor(rat(poly)),modulus:1031 => OK factor(rat(poly)),modulus:1048583 => OK (but slow) poly1: (y+x)*(z+x)*(z+x+w)*(z+y)*(z+y+w)*(z+y+x) factor(rat(poly1)),modulus: xxx => Not enough choices for substitution.  an error. for modulus= 2,3,5,7,11,1031,1048583  Comment By: Stavros Macrakis (macrakis) Date: 20021018 10:39 Message: Logged In: YES user_id=588346 factor(rat(x^5+y^5)),modulus:2 also thinks it's irreducible, but in fact it is = (y+x)*(y^4+x*y^3+x^2*y^2+x^3*y+x^4).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625226&group_id=4933 