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}
(12) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




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

6

7
(1) 
8
(2) 
9

10

11

12

13
(1) 
14

15

16

17
(1) 
18
(1) 
19
(3) 
20

21
(1) 
22

23
(3) 
24

25
(2) 
26
(2) 
27
(2) 
28

29

30
(3) 
31
(5) 

From: SourceForge.net <noreply@so...>  20070808 12:59:52

Bugs item #696804, was opened at 20030303 14:52 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=696804&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  Polynomials Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor FAILS on polynomial !!! Initial Comment: Factor fails to factor a polynomial in two variables. p: (23*x^10*y^5 + 82*x^9*y^4 + 80*x^8*y^4  28*x^7*y^3  47*x^6*y^3  74*x^5*y^2 + 28*x^4*y^2  74*x^3*y + 25*x^2*y + 21*x  41) * (78*x^10*y^5 + 49*x^9*y^4 + 48*x^8*y^4 + 49*x^7*y^3 + 65*x^6*y^3  8*x^5*y^2 + 82*x^4*y^2  7*x^3*y  15*x^2*y  6*x + 30) factor(expand(p)) => irreducible If this is some intentional limitation, it should give some sort of warning. But I don't see why it should be. This was a polynomial generated randomly using: product(sum((random(200)100) * x^i * y^entier(i/2), i,0,10), j,1,2) Sometimes these polynomials factor correctly, but mostly they come back as irreducible. I tried setting Berlefact:false to see if that would make a difference, but that causes an internal error (POWERSET requires less than two arguments). I also tried using rat instead of expand to make sure it wasn't a multiplication problem rather than a factoring problem. Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  >Comment By: Dan Gildea (dgildea) Date: 20070808 08:59 Message: Logged In: YES user_id=1797506 Originator: NO fixed in cvs. incrlimk was not setting integer modulus big enough  removed buggy logtwo and logn routines.  Comment By: Robert Dodier (robert_dodier) Date: 20060909 10:14 Message: Logged In: YES user_id=501686 All three examples behave the same in Maxima 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030917 19:19 Message: Logged In: YES user_id=588346 Here is the smallest (degree and maximum product coefficient) case I've been able to find: (35*x*y^2+19*x^2+25) * (35*x*y^2+25*x^2+19) Found by a combination of randomized and systematic searching. The larger the coefficients, the denser the failure cases. Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  Comment By: Stavros Macrakis (macrakis) Date: 20030916 09:28 Message: Logged In: YES user_id=588346 Another factor failure: (34*y^3+987*x*y23*x^31)*(234*x^23*y^45 978*x^43*y^10+1) Setting berlefact:false gives error: POWERSET [or a callee] requires less than two arguments.  Comment By: Barton Willis (willisb) Date: 20030304 16:16 Message: Logged In: YES user_id=570592 Macsyma 2.2 also fails to factor p after it has been expanded. Setting berlefact : false didn't make any difference. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=696804&group_id=4933 
From: SourceForge.net <noreply@so...>  20070807 18:51:40

Bugs item #1769598, was opened at 20070807 13:51 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=1769598&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: 7 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: (negative float)^rational Initial Comment: negative float to a rational power is broken: (%i7) (4.207913)^(2/3); (%o7) (0.25*26695^(2/3))/793^(2/3) (%i8) (4.2079137)^(2/3); (%o8) (1.0*5849^(2/3))/1390^(2/3) (%i9) (4.207)^(2/3); (%o9) 0.01*4207^(2/3) When 'float' is true, it's worse: (%i16) (4.2079137)^(2/3); (%o16) (4.2079137)^0.66666666666667 (%i17) rectform(%); (%o17) 2.25722671285884*%i1.303210450291064 Since the exponent gets converted to a float, the real branch rule isn't an option. After that, rectform does the right thing.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1769598&group_id=4933 
From: SourceForge.net <noreply@so...>  20070804 17:47:46

Bugs item #1650226, was opened at 20070201 18:47 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1650226&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  Polynomials Group: None >Status: Pending >Resolution: Fixed Priority: 6 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: Bind stack overflow for factor 7th degree Initial Comment: (%i1) 156*x^7+4808*x^6182041*x^51266489*x^4+43104271*x^3 +29839285*x^22542327662*x+7826952672$ (%i2) factor(%); Maxima encountered a Lisp error: Error in MACSYMATOPLEVEL [or a callee]: Bind stack overflow. The factors are all linear: (%i3) berlefact : false; (%o3) false (%i4) factor(%i1); (%o4) (x16)*(x+14)*(x+49)*(2*x11)*(2*x+21)*(3*x49)*(13*x63)  >Comment By: Dan Gildea (dgildea) Date: 20070804 13:47 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in cvs. I think nalgfac should only be called if there is a minimum polynomial, so choozp should only return 'splitcase if there is a minimum polynomial.  Comment By: Carl Witty (cwitty) Date: 20070630 16:47 Message: Logged In: YES user_id=14517 Originator: NO Here's another example of (presumably) the same problem: (%i1) factor(351039744*u^47  4146785280*u^46 + 21010752000*u^45  51641487360*u^44 + 22909388544*u^43 + 226995397632*u^42  609312557056*u^41 + 241407713280*u^40 + 1862346686208*u^39  4143913640960*u^38 + 1996259731968*u^37 + 5683411390464*u^36  10233183569664*u^35 + 3570312475776*u^34 + 5427479744256*u^33  14632753159296*u^32 + 35014067381760*u^31 + 919601276544*u^30  120004234261760*u^29 + 89792759938176*u^28 + 146430616799232*u^27  174447418437376*u^26  83088089063424*u^25 + 152708862935040*u^24 + 39789942893600*u^23  68867281548288*u^22  84869607997440*u^21 + 59149909463040*u^20 + 167176883404800*u^19  202290559266816*u^18 + 26574158757888*u^17 + 66648721563648*u^16  38084983750656*u^15 + 6347497291776*u^14); Maxima encountered a Lisp error: ... (I'm pretty sure it doesn't matter, but just in case: Debian x86 32bit, maxima package version 5.12.01; Maxima version: 5.12.0 Maxima build date: 8:49 5/4/2007 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 )  Comment By: Barton Willis (willisbl) Date: 20070206 07:46 Message: Logged In: YES user_id=895922 Originator: YES I think the bug happens when choozp (called from fact5) returns 'splitcase. When this happens, eventually fact5 calls nalgfac. Either nalgfac is called with the wrong arguments (see comment in nalgfa.lisp), or nalgfac (or friends) is broken. Also, I see that nalgfa has several undocumented user level functions. That makes me wonder if nalgfac was never fully tested. It's possible to make choozp less likely to return spiltcase. To do change the test (in choozp) (> algcont 6) to something like (> algcont 100). I'm guessing that changing this test is harmless (the test suite is OK with it). And the change eliminates this particular bug. But changing (> algcont 6) > (> algcont 100) *doesn't* fix the bug. So I'm not going the change the source.  Comment By: Vadim V. Zhytnikov (vvzhy) Date: 20070203 08:22 Message: Logged In: YES user_id=366498 Originator: NO Another manifestation of the same bug is factor(taylor(sin(x),x,%pi/4,20); Notice also that error message "Bind stack overflow" is (a) GCL specific and (b) misleading. Other lisps (clisp, sbcl, cmucl) complain that "NIL is not of numeric type".  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1650226&group_id=4933 
From: SourceForge.net <noreply@so...>  20070804 17:43:48

Bugs item #635338, was opened at 20021108 00:17 Message generated for change (Comment added) made by dgildea 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: Pending >Resolution: Works For Me Priority: 5 Private: No 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: Dan Gildea (dgildea) Date: 20070804 13:43 Message: Logged In: YES user_id=1797506 Originator: NO Seems OK in 5.12.0.  Comment By: Robert Dodier (robert_dodier) Date: 20060630 23: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...>  20070804 17:39:22

Bugs item #1042244, was opened at 20041007 09:47 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1042244&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  Polynomials Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gfactor(a^4+b^4) fatal error Initial Comment: The command : factorsum(a**4+b**4) works, while the command gfactorsum(a**4+b**4) does not work. I use the version 5.5 of maxima  >Comment By: Dan Gildea (dgildea) Date: 20070804 13:39 Message: Logged In: YES user_id=1797506 Originator: NO Fixed by 681191.  Comment By: Robert Dodier (robert_dodier) Date: 20060730 23:44 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20041007 21:16 Message: Logged In: YES user_id=588346 Error is in gfactor(a^4+b^4)  result should be (b^2%I*a^2)*(b^2+%I*a^2)  Comment By: Stavros Macrakis (macrakis) Date: 20041007 21:11 Message: Logged In: YES user_id=588346 Specifically: gfactorsum(a^4+b^4) gives a fatal error in PSHIFT  tested in 5.9.0/GCL2.5.0/Mingw32/W2k  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1042244&group_id=4933 
From: SourceForge.net <noreply@so...>  20070804 17:36:40

Bugs item #681191, was opened at 20030205 15:17 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=681191&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  Polynomials Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gfactor(x^4y^4); crashes Initial Comment: well, this describes everything: (C39) factor(x^4y^4); (D39)  (y  x) (y + x) (y^2 + x^2 ) (C40) gfactor(x^2+y^2); (D40) (y  %I x) (y + %I x) but: (C41) gfactor(x^4y^4); Error: Caught fatal error [memory may be damaged] Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at FACTOR. Type :H for Help. MAXIMA>> i'm using: maxima 5.9.0.rc4 under win2k  >Comment By: Dan Gildea (dgildea) Date: 20070804 13:36 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in cvs. (%i3) gfactor(x^4+y^4); (%o3) (y^2%i*x^2)*(y^2+%i*x^2)  Comment By: Robert Dodier (robert_dodier) Date: 20060704 01:25 Message: Logged In: YES user_id=501686 Still present 5.9.3 / sbcl / linux.  Comment By: Stavros Macrakis (macrakis) Date: 20030220 15:29 Message: Logged In: YES user_id=588346 Peculiarly, factor(x^4y^4,q^2+1) works just fine.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=681191&group_id=4933 
From: SourceForge.net <noreply@so...>  20070804 17:34:29

Bugs item #792862, was opened at 20030821 20:17 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792862&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  Polynomials Group: None >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor(r^23*r+3,a^3+1) fatal error Initial Comment: factor(r^23*r+3,a^3+1) Error: Caught fatal error [memory may be damaged] Error signalled by PFACTORALG1. (should be irreducible) This happens regardless of the setting of GCD. Note that various closeby cases work just fine: ..., a^2+3 (factors) ..., a^2+2 (irreducible) ..., a^2+1 (irreducible) ..., a^3+3 (irreducible) ..., a^4+1 (irreducible) ..., a^4+3 (factors) ..., a^6+3 (factors) Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  >Comment By: Dan Gildea (dgildea) Date: 20070804 13:34 Message: Logged In: YES user_id=1797506 Originator: NO Fixed in cvs: no error message now, but factors main expr if possible.  Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:12 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030829 12:39 Message: Logged In: YES user_id=588346 Simpler case: factor(q^2+1,a^21); In general, this seems to happen when the second argument isn't irreducible over the integers (which it is supposed to be). This should not cause a fatal error, but an error message.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792862&group_id=4933 
From: SourceForge.net <noreply@so...>  20070803 23:06:39

Bugs item #635357, was opened at 20021108 01:57 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635357&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  Polynomials Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: factor infinite loop Initial Comment: expr: (%i*a1)/(a^2+1)^2 factor(expr) runs forever but factor((%i*a1)/(a^2+1)) works fine, as does gfactor(expr)  >Comment By: Dan Gildea (dgildea) Date: 20070803 19:06 Message: Logged In: YES user_id=1797506 Originator: NO Seems ok in 5.12.0.  Comment By: Andrej Vodopivec (andrejv) Date: 20060215 20:26 Message: Logged In: YES user_id=1179910 This is a bug in the simplifier: ratsimp(expr), ratfac=true; goes to infinite loop. The infinite loop is in function lgcd1 in lesfac.lisp: aloop (cond ((setq t1 (testdivide ai c)) (setq ai t1 d1 (f1+ d1)) (go aloop))) ai=a*%i1 and c=%i. Since division by %i is multiplication by %i, maxima keeps dividing ai with c. It is not clear if maxima should never get to this loop or if testdivide should not perform the division by %i. Andrej  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=635357&group_id=4933 
From: SourceForge.net <noreply@so...>  20070803 02:20:17

Bugs item #1751951, was opened at 20070711 07:51 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1751951&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: Closed Resolution: Fixed Priority: 4 Private: No Submitted By: Miguel Aguado (maguado) Assigned to: Barton Willis (willisbl) Summary: diag_matrix() with block matrices gets offdiag boxes wrong Initial Comment: Hello, I couldn't find this bug among the reports, sorry if I didn't search hard enough. The problem is related to "linearalgebra," concretely to function diag_matrix, which is said in the documentation to create appropriate offdiagonal zero blocks when its arguments are matrices. This is not so, as in the following example: (%i2) b1 : matrix( [ 1 ] ); (%o2) [ 1 ] (%i3) b2 : matrix( [ 0, 1 ], [ 7, 9 ] ); [ 0 1 ] (%o3) [ ] [ 7 9 ] (%i4) dma : diag_matrix( b1, b2 ); [ 0 1 ] (%o4) diag_matrix([ 1 ], [ ]) [ 7 9 ] (%i5) load("linearalgebra"); (%o5) /usr/share/maxima/5.10.0/share/linearalgebra/linearalgebra.mac (%i6) dma : diag_matrix( b1, b2 ); [ [ 1 ] [ 0 ] ] [ ] (%o6) [ [ 0 0 ] [ 0 1 ] ] [ [ ] [ ] ] [ [ 0 0 ] [ 7 9 ] ] Obviously, mat_unblocker fails to handle this output. Thanks in advance, Miguel  \; Maxima version: 5.10.0 Maxima build date: 14:57 10/18/2006 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7 \;   >Comment By: SourceForge Robot (sfrobot) Date: 20070802 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Barton Willis (willisbl) Date: 20070719 09:29 Message: Logged In: YES user_id=895922 Originator: NO Fixed by linearalgebra.mac CVS revison 1.6. (%i12) b1 : matrix( [ 1 ] ); (%o12) matrix([1]) (%i13) b2 : matrix( [ 0, 1 ], [ 7, 9 ] ); (%o13) matrix([0,1],[7,9]) (%i14) dma : diag_matrix( b1, b2 ); (%o14) matrix([matrix([1]),matrix([0,0])],[matrix([0],[0]),matrix([0,1],[7,9])]) (%i15) mat_unblocker(%); (%o15) matrix([1,0,0],[0,0,1],[0,7,9])  Comment By: Barton Willis (willisbl) Date: 20070714 12:58 Message: Logged In: YES user_id=895922 Originator: NO Oh, I think that you are suggesting that size of the zero matrices in the offdiagonal entries be adjusted so that mat_unblocker will work. OK. I'll try to do that. Thanks for the bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1751951&group_id=4933 
From: SourceForge.net <noreply@so...>  20070803 00:59:14

Bugs item #1764114, was opened at 20070730 19: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=1764114&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: signum misses simp rule Initial Comment: (%i1) tellsimpafter(signum(x),zzz); (%o1) [signumrule1,simpsignum] (%i2) signum(x); Wrong! (%o2) should be zzz (%o2) signum(x) (%i3) ev(%); (%o3) zzz The fix is easy.  >Comment By: Robert Dodier (robert_dodier) Date: 20070802 18:59 Message: Logged In: YES user_id=501686 Originator: NO Barton, I see what you mean, makes sense to me. I think you should go ahead and try the proposed fix. Let us know how it turns out.  Comment By: Barton Willis (willisbl) Date: 20070801 05:54 Message: Logged In: YES user_id=895922 Originator: YES Here is a proposed fix (untested) (defmfun simpsignum (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((mnump y) (setq y (num1 y)) (cond ((plusp y) 1) ((minusp y) 1) (t 0))) ((eq (setq z (csign y)) t) (eqtest (list '(%signum) y) x)) ((eq z '$pos) 1) ((eq z '$neg) 1) ((eq z '$zero) 0) ((mminusp y) (neg (take '(%signum) (neg y)))) (t (eqtest (list '(%signum) y) x)))) I fixed a similar bug in simpabs. The problem is that (mul2 1 (list '(%signum simp) (neg y))) doesn't send the signum expression through simplifya. In this code, if (mminpus y) and (mminusp (neg y)) are both true, the code will infinitely loop. Here is another (untested) fix. As a bonus, it does signum(signum(x)) > signum(x). It uses the applyreflectionrule scheme instead of mminusp. I don't see the point of the (mnump y) check in the original code (speed maybe)  csign should take care of this. I also cut the eqtest stuff. Maybe that's not goodI don't know. (setf (get '%signum 'reflectionrule) #'oddfunctionreflect) (defun simpsignum (x yy z) (declare (ignore yy)) (oneargcheck x) (setq x (simpcheck (cadr x) z)) (let ((sgn (csign x))) (cond ((eq sgn '$pos) 1) ((eq sgn '$neg) 1) ((eq sgn '$zero) 0) ((opequalp x '%signum) x) ((applyreflectionsimp '%signum x t)) (t `((%signum simp) ,x)))))  Comment By: Robert Dodier (robert_dodier) Date: 20070731 21:54 Message: Logged In: YES user_id=501686 Originator: NO Looks like what happens is that signumrule1 gives up after simpsignum returns 1 * signum(x), because the operator in that result is not %SIGNUM: #<FUNCTION LAMBDA (X ANS A3) (SETQ X (SIMPSIGNUM X ANS A3)) (COND (*AFTERFLAG X) (T (PROG (TRGENSYM~0 *AFTERFLAG RULEHIT) (DECLARE (SPECIAL TRGENSYM~0 *AFTERFLAG)) (SETQ *AFTERFLAG T) (COND ((OR (ATOM X) (NOT (EQ (CAAR X) '%SIGNUM))) (RETURN X))) (SETQ TRGENSYM~0 (CDR X)) (MULTIPLEVALUESETQ (ANS RULEHIT) (CATCH 'MATCH (PROG (TRGENSYM~1) (DECLARE (SPECIAL TRGENSYM~1)) (SETQ TRGENSYM~1 (KAR TRGENSYM~0)) (COND ((NOT (ALIKE1 TRGENSYM~1 (MEVAL '$X))) (MATCHERR))) (COND ((NTHKDR TRGENSYM~0 1) (MATCHERR))) (RETURN (VALUES (MEVAL '$ZZZ) T))))) (RETURN (IF RULEHIT ANS (EQTEST X X))))))> I'm not sure what to do here. I guess if whichever simplification functions are carried out return an expression with a different operator, then maybe start over? I guess the problem to watch out for is endless looping. The *AFTERFLAG special variable is meant to prevent that; it might also prevent starting over from having any effect.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764114&group_id=4933 
From: SourceForge.net <noreply@so...>  20070802 02:20:10

Bugs item #716508, was opened at 20030406 19:50 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=716508&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  Polynomials Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: GCD/subres problem using Partfrac Initial Comment: expr: 1/ ( (x+(SQRT(3)1)^(1/3)) *(x+(SQRT(3)1)^(4/3)) *(x(SQRT(3)+1)^(1/3)) *(x(SQRT(3)1)^(1/3)*(SQRT(3)+1)) *(x+(SQRT(3)+1)^(4/3))) partfrac(expr,x) takes forever (infinite loop?). However, with nondefault GCD's, it works fine: partfrac(expr,x),gcd:ez // spmod // algebraic  >Comment By: SourceForge Robot (sfrobot) Date: 20070801 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Dan Gildea (dgildea) Date: 20070718 03:43 Message: Logged In: YES user_id=1797506 Originator: NO seems to work in 5.12.0 and current cvs.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=716508&group_id=4933 
From: SourceForge.net <noreply@so...>  20070802 01:35:46

Bugs item #1765721, was opened at 20070801 16:51 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1765721&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Is it a bug??? Initial Comment: I am new and i dont know if it is a bug. (%i1) y:5; (%o1) 1 (%i2) 3+x^y=235; (%o2) x + 3 = 235 (%i3) solve(%); (%o3) [x = 232] (%i4) y:1; (%o4) 5 (%i5) solve(%); Got a null variable list, continuing  `solve' (%o5) [] (%i6) y:1; (%o6) 1 (%i7) solve(%); Got a null variable list, continuing  `solve' (%o7) [] (%i8) bug_report(); Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20070801 21:35 Message: Logged In: YES user_id=28849 Originator: NO More information needed. Do you mean that %o3 says x + 3 = 235 instead of x^5+3 = 235? Or you get the message after %i5 and %i7? %i5 and %i7 are expected. Not sure what happened in %o3, but I suspect what you show isn't what you actually typed. Set to pending.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1765721&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 21:25:47

Bugs item #1765597, was opened at 20070801 11:12 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1765597&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: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Miguel Aguado (maguado) Assigned to: Nobody/Anonymous (nobody) Summary: Consecutive, commaseparated loops executed in wrong order? Initial Comment: Hi, Thank you for the quick solution of my previous bug. What I am reporting now seems a bug to me, otherwise it is a very strange feature, in my humble opinion. I write two consecutive loops (not nested), say, for i : 0 thru 4 do display( i ), for j : 0 thru 4 do display( j ); and Maxima executes the second loop first. This is counterintuitive to me. If it is intended, I would beg for a rationale. Thank you in advance, and keep up the good work, Miguel  Maxima version: 5.10.0 Maxima build date: 14:57 10/18/2006 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7   >Comment By: Robert Dodier (robert_dodier) Date: 20070801 15:25 Message: Logged In: YES user_id=501686 Originator: NO Miguel, the input (%i1) foo, bar; is equivalent to ev(foo, bar), that is, to evaluate foo with flags and values specified by bar. I;m pretty sure you did not intend that. Probably you want (%i1) (foo, bar); or (%i1) block (foo, bar); either of which evaluates the items within parentheses one by one. (The plain parentheses (...) is like block(...) except that (...) cannot have a list of local variables.) Hope this helps. Closing this report as rejected since it's not a bug.  Robert Dodier  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1765597&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 20:51:47

Bugs item #1765721, was opened at 20070801 13:51 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=1765721&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 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Is it a bug??? Initial Comment: I am new and i dont know if it is a bug. (%i1) y:5; (%o1) 1 (%i2) 3+x^y=235; (%o2) x + 3 = 235 (%i3) solve(%); (%o3) [x = 232] (%i4) y:1; (%o4) 5 (%i5) solve(%); Got a null variable list, continuing  `solve' (%o5) [] (%i6) y:1; (%o6) 1 (%i7) solve(%); Got a null variable list, continuing  `solve' (%o7) [] (%i8) bug_report(); Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 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=1765721&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 17:12:35

Bugs item #1765597, was opened at 20070801 19:12 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=1765597&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: Miguel Aguado (maguado) Assigned to: Nobody/Anonymous (nobody) Summary: Consecutive, commaseparated loops executed in wrong order? Initial Comment: Hi, Thank you for the quick solution of my previous bug. What I am reporting now seems a bug to me, otherwise it is a very strange feature, in my humble opinion. I write two consecutive loops (not nested), say, for i : 0 thru 4 do display( i ), for j : 0 thru 4 do display( j ); and Maxima executes the second loop first. This is counterintuitive to me. If it is intended, I would beg for a rationale. Thank you in advance, and keep up the good work, Miguel  Maxima version: 5.10.0 Maxima build date: 14:57 10/18/2006 host type: i686pclinuxgnu lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.7   You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1765597&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 11:54:38

Bugs item #1764114, was opened at 20070730 20:49 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764114&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: signum misses simp rule Initial Comment: (%i1) tellsimpafter(signum(x),zzz); (%o1) [signumrule1,simpsignum] (%i2) signum(x); Wrong! (%o2) should be zzz (%o2) signum(x) (%i3) ev(%); (%o3) zzz The fix is easy.  >Comment By: Barton Willis (willisbl) Date: 20070801 06:54 Message: Logged In: YES user_id=895922 Originator: YES Here is a proposed fix (untested) (defmfun simpsignum (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((mnump y) (setq y (num1 y)) (cond ((plusp y) 1) ((minusp y) 1) (t 0))) ((eq (setq z (csign y)) t) (eqtest (list '(%signum) y) x)) ((eq z '$pos) 1) ((eq z '$neg) 1) ((eq z '$zero) 0) ((mminusp y) (neg (take '(%signum) (neg y)))) (t (eqtest (list '(%signum) y) x)))) I fixed a similar bug in simpabs. The problem is that (mul2 1 (list '(%signum simp) (neg y))) doesn't send the signum expression through simplifya. In this code, if (mminpus y) and (mminusp (neg y)) are both true, the code will infinitely loop. Here is another (untested) fix. As a bonus, it does signum(signum(x)) > signum(x). It uses the applyreflectionrule scheme instead of mminusp. I don't see the point of the (mnump y) check in the original code (speed maybe)  csign should take care of this. I also cut the eqtest stuff. Maybe that's not goodI don't know. (setf (get '%signum 'reflectionrule) #'oddfunctionreflect) (defun simpsignum (x yy z) (declare (ignore yy)) (oneargcheck x) (setq x (simpcheck (cadr x) z)) (let ((sgn (csign x))) (cond ((eq sgn '$pos) 1) ((eq sgn '$neg) 1) ((eq sgn '$zero) 0) ((opequalp x '%signum) x) ((applyreflectionsimp '%signum x t)) (t `((%signum simp) ,x)))))  Comment By: Robert Dodier (robert_dodier) Date: 20070731 22:54 Message: Logged In: YES user_id=501686 Originator: NO Looks like what happens is that signumrule1 gives up after simpsignum returns 1 * signum(x), because the operator in that result is not %SIGNUM: #<FUNCTION LAMBDA (X ANS A3) (SETQ X (SIMPSIGNUM X ANS A3)) (COND (*AFTERFLAG X) (T (PROG (TRGENSYM~0 *AFTERFLAG RULEHIT) (DECLARE (SPECIAL TRGENSYM~0 *AFTERFLAG)) (SETQ *AFTERFLAG T) (COND ((OR (ATOM X) (NOT (EQ (CAAR X) '%SIGNUM))) (RETURN X))) (SETQ TRGENSYM~0 (CDR X)) (MULTIPLEVALUESETQ (ANS RULEHIT) (CATCH 'MATCH (PROG (TRGENSYM~1) (DECLARE (SPECIAL TRGENSYM~1)) (SETQ TRGENSYM~1 (KAR TRGENSYM~0)) (COND ((NOT (ALIKE1 TRGENSYM~1 (MEVAL '$X))) (MATCHERR))) (COND ((NTHKDR TRGENSYM~0 1) (MATCHERR))) (RETURN (VALUES (MEVAL '$ZZZ) T))))) (RETURN (IF RULEHIT ANS (EQTEST X X))))))> I'm not sure what to do here. I guess if whichever simplification functions are carried out return an expression with a different operator, then maybe start over? I guess the problem to watch out for is endless looping. The *AFTERFLAG special variable is meant to prevent that; it might also prevent starting over from having any effect.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764114&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 07:40:38

Bugs item #1764284, was opened at 20070731 12:13 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764284&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: Problem not in Maxima Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Andrej Vodopivec (andrejv) Summary: WxMaxima typesetting (xml display) Initial Comment: I think the output must be in the form f²(x) (not f(x)²). Example: (%i1) sin(x)^2; 2 (%o1) sin(x) would be (%i1) sin(x)^2; 2 (%o1) sin (x) this case is concerning another function like cos(x), log(x), etc...  >Comment By: Andrej Vodopivec (andrejv) Date: 20070801 09:40 Message: Logged In: YES user_id=1179910 Originator: NO Moved to wxmaxima project: http://sourceforge.net/tracker/index.php?func=detail&aid=1765127&group_id=126731&atid=707631 Andrej  Comment By: Robert Dodier (robert_dodier) Date: 20070801 05:09 Message: Logged In: YES user_id=501686 Originator: NO Andrej, since this is a WxMaxima item, can you please copy it to the WxMaxima tracker and close it here. Thanks.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764284&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 07:36:29

Bugs item #1764292, was opened at 20070731 12:28 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764292&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: Problem not in Maxima Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Andrej Vodopivec (andrejv) Summary: wxMaxima typesetting (xml display) Initial Comment: I think the output must be in the form fª(x) (not f(x)ª). Example 1: (%i1) sin(x)^2; (%o1) sin(x)² would be (%i1) sin(x)^2; (%o1) sin²(x) Example 2: (%i1) cos(x)^3; (%o1) cos(x)³ would be (%i1) cos(x)^3; (%o1) cos³(x) this case is concerning another function and for all exponent.  >Comment By: Andrej Vodopivec (andrejv) Date: 20070801 09:36 Message: Logged In: YES user_id=1179910 Originator: NO This is a duplicate of bug 1764284, so I'm closing it. Andrej  Comment By: Robert Dodier (robert_dodier) Date: 20070801 05:08 Message: Logged In: YES user_id=501686 Originator: NO Andrej, since this is a WxMaxima item, can you please copy it to the WxMaxima tracker and close it here. Thanks.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764292&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 03:54:34

Bugs item #1764114, was opened at 20070730 19: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=1764114&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Barton Willis (willisbl) Summary: signum misses simp rule Initial Comment: (%i1) tellsimpafter(signum(x),zzz); (%o1) [signumrule1,simpsignum] (%i2) signum(x); Wrong! (%o2) should be zzz (%o2) signum(x) (%i3) ev(%); (%o3) zzz The fix is easy.  >Comment By: Robert Dodier (robert_dodier) Date: 20070731 21:54 Message: Logged In: YES user_id=501686 Originator: NO Looks like what happens is that signumrule1 gives up after simpsignum returns 1 * signum(x), because the operator in that result is not %SIGNUM: #<FUNCTION LAMBDA (X ANS A3) (SETQ X (SIMPSIGNUM X ANS A3)) (COND (*AFTERFLAG X) (T (PROG (TRGENSYM~0 *AFTERFLAG RULEHIT) (DECLARE (SPECIAL TRGENSYM~0 *AFTERFLAG)) (SETQ *AFTERFLAG T) (COND ((OR (ATOM X) (NOT (EQ (CAAR X) '%SIGNUM))) (RETURN X))) (SETQ TRGENSYM~0 (CDR X)) (MULTIPLEVALUESETQ (ANS RULEHIT) (CATCH 'MATCH (PROG (TRGENSYM~1) (DECLARE (SPECIAL TRGENSYM~1)) (SETQ TRGENSYM~1 (KAR TRGENSYM~0)) (COND ((NOT (ALIKE1 TRGENSYM~1 (MEVAL '$X))) (MATCHERR))) (COND ((NTHKDR TRGENSYM~0 1) (MATCHERR))) (RETURN (VALUES (MEVAL '$ZZZ) T))))) (RETURN (IF RULEHIT ANS (EQTEST X X))))))> I'm not sure what to do here. I guess if whichever simplification functions are carried out return an expression with a different operator, then maybe start over? I guess the problem to watch out for is endless looping. The *AFTERFLAG special variable is meant to prevent that; it might also prevent starting over from having any effect.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1764114&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 03:40:27

Bugs item #1763261, was opened at 20070729 15: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=1763261&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 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: unexpected sign called on ... Initial Comment: I should look for a simple example... (%o74) (sqrt(sqrt(15)+sqrt(2)*sqrt(5sqrt(5))+sqrt(3)+8)/32+sqrt(sqrt(15)+sqrt(2)*sqrt(5sqrt(5))+sqrt(3)8)/32)^(1/3)+1/(4*(sqrt(sqrt(15)+sqrt(2)*sqrt(5sqrt(5))+sqrt(3)+8)/32+sqrt(sqrt(15)+sqrt(2)*sqrt(5sqrt(5))+sqrt(3)8)/32)^(1/3)) (%i75) ratsimp(sqrt(1%^2)); `sign' called on an imaginary argument: sqrt(sqrt(15)+sqrt(2)*sqrt(5sqrt(5))+sqrt(3)8)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1763261&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 03:39:47

Bugs item #1758469, was opened at 20070722 09:08 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1758469&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: 4 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: genmatrix and improper array call Initial Comment: genmatrix has a weird evaluation scheme; for example (%i1) (g : h, h : lambda([a,b],a+b)); (%o1) lambda([a,b],a+b) (%i2) genmatrix(g,1,1); Improper array call The "improper array call" message is nonsense.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1758469&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 03:38:36

Bugs item #1754781, was opened at 20070716 07:29 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754781&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 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot doesn't work with special characters in Username Initial Comment: (%i2) f(x):=x; (%o2) f(x):=x (%i3) wxplot2d([%o2], [x,5,5]) $Maxima encountered a Lisp error: Error in APPLY [or a callee]: Cannot create the file C:/Dokumente und Einstellungen/blubb/maxout.gnuplot.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil.(%i4) The Username is not correct. It must be b^l^u^b^b. It seems that special characters are ignored.  Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   >Comment By: Robert Dodier (robert_dodier) Date: 20070731 21:38 Message: Logged In: YES user_id=501686 Originator: NO It may be too late, but anyway, a workaround is to assign maxima_tempdir to some acceptable folder, say maxima_tempdir : "c:\temp". Then the plotting functions will put the Gnuplot output file there.  Comment By: Robert Dodier (robert_dodier) Date: 20070731 21:36 Message: Logged In: YES user_id=501686 Originator: NO What are the special characters in question, I wonder? I'm pretty sure GCL does not know how to handle Unicode characters, although I would expect ISOLatinwhatever would be OK ... Someone who has a foreignlanguage windows installation would be able to tell for sure.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754781&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 03:37:00

Bugs item #1754781, was opened at 20070716 07:29 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754781&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 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot doesn't work with special characters in Username Initial Comment: (%i2) f(x):=x; (%o2) f(x):=x (%i3) wxplot2d([%o2], [x,5,5]) $Maxima encountered a Lisp error: Error in APPLY [or a callee]: Cannot create the file C:/Dokumente und Einstellungen/blubb/maxout.gnuplot.Automatically continuing.To reenable the Lisp debugger set *debuggerhook* to nil.(%i4) The Username is not correct. It must be b^l^u^b^b. It seems that special characters are ignored.  Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8   >Comment By: Robert Dodier (robert_dodier) Date: 20070731 21:36 Message: Logged In: YES user_id=501686 Originator: NO What are the special characters in question, I wonder? I'm pretty sure GCL does not know how to handle Unicode characters, although I would expect ISOLatinwhatever would be OK ... Someone who has a foreignlanguage windows installation would be able to tell for sure.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1754781&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 03:24:17

Bugs item #1732298, was opened at 20070606 12: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=1732298&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: Installation >Group: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ted Woollett (woollett) Assigned to: Vadim V. Zhytnikov (vvzhy) Summary: postscript eps file error Initial Comment: use of standard eps file generation, as in: (%i2) plot2d( sin(x),[x,%pi, %pi] ,[gnuplot_term,ps], [gnuplot_out_file,"c:/work2/test2.eps" ] ) $ Output file "c:/work2/test2.eps". results in the generation of test2.eps which is 2kb and contains no plot instructions. The end of the file has an apparent error message(? I am no expert in postscript language ): ... /hpt hpt_ def /vpt vpt_ def Level1 {} { /SDict 10 dict def systemdict /pdfmark known not { userdict /pdfmark systemdict /cleartomark get put } if SDict begin [ /Title (c:/work2/test2.eps) /Subject (gnuplot plot) /Creator (gnuplot 4.2 patchlevel 0) /Author (Edwin Woollett) % /Producer (gnuplot) % /Keywords () /CreationDate (Wed Jun 06 10:38:32 2007) /DOCINFO pdfmark end } ifelse When viewed with gsview32, there in no plot. Direct use of wguplot32 software results in a file of size about 14 kb. This error observed with both v 5.11.xx and 5.12: My build info: Maxima version: 5.12.0 Maxima build date: 19:33 5/3/2007 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8 Edwin (Ted) Woollett  >Comment By: Robert Dodier (robert_dodier) Date: 20070731 21:24 Message: Logged In: YES user_id=501686 Originator: NO Marking this item for review.  Comment By: Vadim V. Zhytnikov (vvzhy) Date: 20070708 00:22 Message: Logged In: YES user_id=366498 Originator: NO Fixed in Maxima CVS. Please wait for the forthcoming 5.13 rc1 to test/  Comment By: Ted Woollett (woollett) Date: 20070705 16:56 Message: Logged In: YES user_id=1806103 Originator: YES Back from vacation! I have used the file prologue.ps, placing it in the directory structure suggested, on my computer a rather long path name: c:\Program Files\Maxima5.12.0\bin\share\PostScript\prologue.ps Maxima now correctly creates the eps file. Thanks. Ted Woollett  Comment By: Robert Dodier (robert_dodier) Date: 20070621 09:13 Message: Logged In: YES user_id=501686 Originator: NO >From what I can tell, the Maxima 5.12.0 Windows installation is missing a file that Gnuplot wants, namely prologue.ps. I've taken the liberty of attaching the prologue.ps from Gnuplot 4.2 to this report. That file should be copied to ...\Maxima5.12.0\bin\share\PostScript\prologue.ps in the Maxima installation. Please give that a try and let us know how it turns out. File Added: prologue.ps  Comment By: Ted Woollett (woollett) Date: 20070607 11:36 Message: Logged In: YES user_id=1806103 Originator: YES I observed this eps file bug on my Win XP box and using Maxima 5.11.99 and 5.12.0 A milder version appears in ver 5.9.3 in which Maxima complained but produced a viewable plot as viewed with gsview32. The 5.9.3 complaint looks like: Maxima 5.9.3 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) (%i1) plot2d( sin(x),[x,%pi, %pi] ,[gnuplot_term,ps], [gnuplot_out_file,"c:/work2/test6.eps" ] ) $ 'ghostview' is not recognized as an internal or external command, operable program or batch file. Output file "c:/work2/test6.eps". (%i2)  Comment By: Robert Dodier (robert_dodier) Date: 20070606 19:02 Message: Logged In: YES user_id=501686 Originator: NO Same error observed on my Win XP box + Maxima 5.12.0. However it works as expected with Maxima 5.11.0 on same Win XP box, and with Maxima 5.12.0 on Linux.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1732298&group_id=4933 
From: SourceForge.net <noreply@so...>  20070801 03:16:54

Bugs item #1721661, was opened at 20070518 23:19 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1721661&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: To be reviewed Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Robert Dodier (robert_dodier) Summary: lsquares (newton) does not work Initial Comment: The following example from the Maxima 5.12 manual does not work (compiled on Linux with GCL 2.6.7): load("lsquares"); lsquares(matrix([1.1,7.1],[2.1,13.1],[3.1,25.1],[4.1,49.1]), [x,y], y=a*b^x+c, [a,b,c], [5,5,5]); The output is: Improper argument to ev: Solutions i #0: lsquares(arglist=[matrix([1.1,7.1],[2.1,13.1],[3.1,25.1],[4.1,49.1]),[x,y],y = c+a*b^x,[a,b,c],[5,5,5]])(lsquares.mac line 147)  an error. To debug this try debugmode(true); loading mnewton before lsquares seems to change this behavior  although it still does not work.  >Comment By: Robert Dodier (robert_dodier) Date: 20070731 21:16 Message: Logged In: YES user_id=501686 Originator: NO lsquares has been replaced by a different implementation. Retest this example with Maxima 5.13.0 or a release candidate, and if it succeeds we can close this report.  Comment By: Nobody/Anonymous (nobody) Date: 20070520 10:52 Message: Logged In: NO I thought I added the following comment but it disappeared somehow: If you change keepfloat:true to keepfloat:flase in the following, I no longer get errors. It is slow, however, since it carries out fractions at full accuracy. mnewton(FuncList, VarList, GuessList):= block([nfunc, Solutions, Increments, solved:false, h, DF, i, j, k, keepfloat:true, ratprint:false],  Comment By: Nobody/Anonymous (nobody) Date: 20070519 15:30 Message: Logged In: NO It looks like the manual is missing the fact that mnewton should be loadded (loading it is also commented out in lsquares.mac). However, still the three parameter fit bombs as I say above. The exact output is: quotient is not exact #0: mnewton(funclist=[2*b^4.1*c+2*b^3.1*c+2*b^2.1*c+2*b^1.1*c+2*a*b^8.199999999999999+2*a*b^6.2+2*a*b^4.298.2*b^4.150.2...,varlist=[a,b,c],guesslist=[5,5,5])(mnewton.mac line 89) #1: lsquares(arglist=[matrix([1.1,7.1],[2.1,13.1],[3.1,25.1],[4.1,49.1]),[x,y],y = c+a*b^x,[a,b,c],[5,5,5]])(lsquares.mac line 136)  an error. To debug this try debugmode(true);  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1721661&group_id=4933 