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

_{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...>  20060710 05:04:56

Bugs item #836773, was opened at 20031105 13:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&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: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ntrig is broken Initial Comment: (C4) load("ntrig.mac"); (D4) ?C\:\/maxima\/Maxima\/share\/maxima\/5\.9\.0 \/share\/trigonometry\/ntrig\.mac (C5) sin(6*%pi/5); (D5) (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) (C6) float(%); (D6) 0.58778525229247 (C7) sin(float(6*%pi/5)); (D7) 0.58778525229247 Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:04 Message: Logged In: YES user_id=501686 Assign category = share libraries.  Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:03 Message: Logged In: YES user_id=501686 Bug shown in original report is fixed by r1.2 share/trigonometry/ntrig.mac, which was made to fix bug report # 1082010 (sign error). Patches proposed here were never applied so far as I can tell. Bug not observed in 5.9.3cvs. Closing this report as fixed.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031116 11:21 Message: Logged In: YES user_id=581700 What about combining the two approaches like this. define_variable (usin_list, block([e1 : (sqrt(5)1)/4, e2 : (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)), e3 : (sqrt(5)+1)/4, e4 : sqrt(sqrt(5)+5)/(2*sqrt(2))], [e1, e2, e3, e4, 1, e4, e3, e2, e1, 0]), any)$ usin(n):= /* MODE_DECLARE treats INTEGER like FIXNUM... */ (mode_declare(n,number), /* Note that this works because MOD is supposed to return an integer in [9, 10] here. Sadly, GCL misbehaves (see bug #706562). Normally, this doesn't matter, however: If the argument of SIN is an integer multiple of %pi/2 the usual simplification routines take care of it, so at this point N won't be a multiple of 5. */ if (n : mod(n, 20)) > 0 then usin_list[n] else usin_list[10+n])$ ucos(n):= usin(5n)$  Comment By: Barton Willis (willisbl) Date: 20031115 12:47 Message: Logged In: YES user_id=895922 I wrote testing code for ntrig; both proposed fixes pass all the tests. Barton  Comment By: Stavros Macrakis (macrakis) Date: 20031110 15:07 Message: Logged In: YES user_id=588346 Please test the following replacement for ntrig. /* Some of these simplifications give results with radicals in the denominator. These could be presimplified here, but ratsimp(...),algebraic:true will also take care of it. */ eval_when([translate,batch,demo,load,loadfile], matchdeclare(n,integerp))$ tellsimpafter(sin(n*%pi/10),usin(n))$ tellsimpafter(cos(n*%pi/10),ucos(n))$ tellsimpafter(tan(n*%pi/10),usin(n)/ucos(n))$ tellsimpafter(cot(n*%pi/10),ucos(n)/usin(n))$ tellsimpafter(sec(n*%pi/10),1/ucos(n))$ tellsimpafter(csc(n*%pi/10),1/usin(n))$ usin_list: makelist( [ 0, (sqrt(5)1)/4, sqrt(2)*(sqrt(5)1)*sqrt(sqrt(5)+5)/8, (sqrt(5)+1)/4, sqrt(sqrt(5)+5)/(2*sqrt(2)), 1] [i], i,[1,2,3,4,5,6,5,4,3,2,1,2,3,4,5,6,5,4,3,2] ) /* In the pre11/2003 version, usin_list[3] was (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)). But the new version is better simplified, and simplifies just as well. */ $ usin(n):= (declare(n,integer), n : remainder(n,20), if n<0 then n:n+20, /* Workaround for bug in remainder */ (if n <= 10 then usin_list[n+1] /* 1origin indexing */ else usin_list[n+1]) )$ ucos(n):=usin(n+5)$  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031107 10:51 Message: Logged In: YES user_id=581700 Perhaps simply rewrite USIN(N):= BLOCK([YUK:mod(N,20)], signum(YUK)*(YUK:abs(mod(YUK,10)), IF YUK=1 THEN (SQRT(5)1)/4 ELSE IF YUK=2 THEN (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) ELSE IF YUK=3 THEN (SQRT(5)+1)/4 ELSE IF YUK=4 THEN SQRT(SQRT(5)+5)/(2*SQRT(2))))$ UCOS(N):= USIN(5N)$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 05:04:33

Bugs item #1082010, was opened at 20041209 04: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=1082010&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: FrancoB (franco68tn) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in NTRIG.MAC(?) Initial Comment: Wrong values of trigonometric functions. I suppose that there is a bug in "/share/maxima/5.9.1/share/trigonometry/ntrig.mac". Some values of trigonometric functions are wrong after ntrig.mac has been loaded. Try this: kill(all)$ postfix("°")$ x°:=x*%pi/180$ for i: 0 thru 20 do print("sin(",i*18,"°)","=",float(sin (i*18°)))$ for i: 0 thru 20 do print("cos(",i*18,"°)","=",float(cos (i*18°)))$ for i: 0 thru 20 do if not(i = 5 or i = 15) then print("tan (",i*18,"°)","=",float(tan(i*18°))) else print("tan (",i*18,"°) = NOT DEFINED")$ You will see that the output is okay. Now load ntrig.mac and then reexecute the same instructions: load(ntrig)$ for i: 0 thru 20 do print("sin(",i*18,"°)","=",float(sin (i*18°)))$ for i: 0 thru 20 do print("cos(",i*18,"°)","=",float(cos (i*18°)))$ for i: 0 thru 20 do if not(i = 5 or i = 15) then print("tan (",i*18,"°)","=",float(tan(i*18°))) else print("tan (",i*18,"°) = NOT DEFINED")$ and you will see a lot of results (sixteen!) with wrong sign! oooooooooooooooooooo Furthermore, these two commands produce different outputs: <1> kill(all)$ load(ntrig)$ sin(6*%pi/5),numer; yields the correct result (0.58778525229247325), <2> kill(all)$ load(ntrig)$ sin(6*%pi/5); %,numer; yields the wrong result (0.58778525229247325). Best regards, Franco Buratti (Italy) bufranz@...  Maxima version: 5.9.1 Maxima build date: 7:34 9/24/2004 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL 2.6.5   >Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:04 Message: Logged In: YES user_id=501686 Assign resolution = fixed.  Comment By: Viktor Toth (vttoth) Date: 20041210 06:11 Message: Logged In: YES user_id=1023504 The reported bug is not present in the current version of cvs. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1082010&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 05:03:41

Bugs item #836773, was opened at 20031105 13:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&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 (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: ntrig is broken Initial Comment: (C4) load("ntrig.mac"); (D4) ?C\:\/maxima\/Maxima\/share\/maxima\/5\.9\.0 \/share\/trigonometry\/ntrig\.mac (C5) sin(6*%pi/5); (D5) (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) (C6) float(%); (D6) 0.58778525229247 (C7) sin(float(6*%pi/5)); (D7) 0.58778525229247 Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 23:03 Message: Logged In: YES user_id=501686 Bug shown in original report is fixed by r1.2 share/trigonometry/ntrig.mac, which was made to fix bug report # 1082010 (sign error). Patches proposed here were never applied so far as I can tell. Bug not observed in 5.9.3cvs. Closing this report as fixed.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031116 11:21 Message: Logged In: YES user_id=581700 What about combining the two approaches like this. define_variable (usin_list, block([e1 : (sqrt(5)1)/4, e2 : (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)), e3 : (sqrt(5)+1)/4, e4 : sqrt(sqrt(5)+5)/(2*sqrt(2))], [e1, e2, e3, e4, 1, e4, e3, e2, e1, 0]), any)$ usin(n):= /* MODE_DECLARE treats INTEGER like FIXNUM... */ (mode_declare(n,number), /* Note that this works because MOD is supposed to return an integer in [9, 10] here. Sadly, GCL misbehaves (see bug #706562). Normally, this doesn't matter, however: If the argument of SIN is an integer multiple of %pi/2 the usual simplification routines take care of it, so at this point N won't be a multiple of 5. */ if (n : mod(n, 20)) > 0 then usin_list[n] else usin_list[10+n])$ ucos(n):= usin(5n)$  Comment By: Barton Willis (willisbl) Date: 20031115 12:47 Message: Logged In: YES user_id=895922 I wrote testing code for ntrig; both proposed fixes pass all the tests. Barton  Comment By: Stavros Macrakis (macrakis) Date: 20031110 15:07 Message: Logged In: YES user_id=588346 Please test the following replacement for ntrig. /* Some of these simplifications give results with radicals in the denominator. These could be presimplified here, but ratsimp(...),algebraic:true will also take care of it. */ eval_when([translate,batch,demo,load,loadfile], matchdeclare(n,integerp))$ tellsimpafter(sin(n*%pi/10),usin(n))$ tellsimpafter(cos(n*%pi/10),ucos(n))$ tellsimpafter(tan(n*%pi/10),usin(n)/ucos(n))$ tellsimpafter(cot(n*%pi/10),ucos(n)/usin(n))$ tellsimpafter(sec(n*%pi/10),1/ucos(n))$ tellsimpafter(csc(n*%pi/10),1/usin(n))$ usin_list: makelist( [ 0, (sqrt(5)1)/4, sqrt(2)*(sqrt(5)1)*sqrt(sqrt(5)+5)/8, (sqrt(5)+1)/4, sqrt(sqrt(5)+5)/(2*sqrt(2)), 1] [i], i,[1,2,3,4,5,6,5,4,3,2,1,2,3,4,5,6,5,4,3,2] ) /* In the pre11/2003 version, usin_list[3] was (sqrt(5)1)*sqrt(sqrt(5)+5)/(4*sqrt(2)). But the new version is better simplified, and simplifies just as well. */ $ usin(n):= (declare(n,integer), n : remainder(n,20), if n<0 then n:n+20, /* Workaround for bug in remainder */ (if n <= 10 then usin_list[n+1] /* 1origin indexing */ else usin_list[n+1]) )$ ucos(n):=usin(n+5)$  Comment By: Wolfgang Jenkner (wjenkner) Date: 20031107 10:51 Message: Logged In: YES user_id=581700 Perhaps simply rewrite USIN(N):= BLOCK([YUK:mod(N,20)], signum(YUK)*(YUK:abs(mod(YUK,10)), IF YUK=1 THEN (SQRT(5)1)/4 ELSE IF YUK=2 THEN (SQRT(5)1)*SQRT(SQRT(5)+5)/(4*SQRT(2)) ELSE IF YUK=3 THEN (SQRT(5)+1)/4 ELSE IF YUK=4 THEN SQRT(SQRT(5)+5)/(2*SQRT(2))))$ UCOS(N):= USIN(5N)$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=836773&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 04:55:43

Bugs item #834813, was opened at 20031102 18:22 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: a < b or 1 < 2 wrong Initial Comment: Assume nothing is known about a and b. prederror:true just making sure it is set to the default for the test avoid ev in case ev complicates matters a<b or 1<2 => error ! is(a<b or 1<2) => error ! if (a<b or 1<2) then 5 => error ! prederror:false a<b or 1<2 => unknown ! is(a<b or 1<2) => true (OK) if a<b or 1<2 then 5 => 5 (OK) I believe that (a<b or 1<2) should be returning true in all these cases. Maxima 5.9.0 gcl 2.5.0 Windows 2000  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 22:55 Message: Logged In: YES user_id=501686 Code for unevaluated conditionals (share/contrib/boolsimp/) handles a < or 1 < 2 (also xxx or true, example given below) as expected when prederror = false (which is boolsimp's default mode). Same problems are observed when boolsimp = true, because I wrote boolsimp to have the same behavior as current code when prederror = true. I'd rather just be rid of prederror altogether and have the code always yield what is now yielded when prederror = false.  Comment By: Stavros Macrakis (macrakis) Date: 20031102 18:25 Message: Logged In: YES user_id=588346 Same problem for xxx or true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834813&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 04:48:20

Bugs item #834417, was opened at 20031101 23:09 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834417&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: Luc Maisonobe (maisonobe) Assigned to: Nobody/Anonymous (nobody) Summary: wrong TeX output for indexed variables with exponent Initial Comment: This simple session shows the error: (C1) tex(expand((1+alpha[1])^2)); $$\alpha^2\left(1\right)+2\,\alpha_{1}+1$$ (D1) FALSE Instead of \alpha^2\left(1\right), I would have expected \alpha_{1}^2  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 22:48 Message: Logged In: YES user_id=501686 Example in original report is OK. Here is the 5.9.3 output: (%i1) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ Example shown in comment below still the same: (%i3) tex(f[5](x)^9); $$f_{5}(x)^9$$ I guess that's not quite right, but it seems like a pretty minor bug so I've reduced the priority.  Comment By: Barton Willis (willisbl) Date: 20031115 13:03 Message: Logged In: YES user_id=895922 The file texmexpt.lisp has a possible fix for this bug. (C1) load("l:/texmexpt.lisp")$ (C2) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ (D2) FALSE Here is another problem: Powers of subscripted functions don't TeX with the exponent immediately following the function (C3) f[5](x)^9; (D3) f[5](x)^9 (C4) tex(%); $$f_{5}(x)^9$$ Barton  Comment By: Barton Willis (willisbl) Date: 20031115 13:02 Message: Logged In: YES user_id=895922 The file texmexpt.lisp has a possible fix for this bug. (C1) load("l:/texmexpt.lisp")$ (C2) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ (D2) FALSE Here is another problem: Powers of subscripted functions don't TeX with the exponent immediately following the function (C3) f[5](x)^9; (D3) f[5](x)^9 (C4) tex(%); $$f_{5}(x)^9$$ Barton  Comment By: Barton Willis (willisbl) Date: 20031115 13:01 Message: Logged In: YES user_id=895922 The file texmexpt.lisp has a possible fix for this bug. (C1) load("l:/texmexpt.lisp")$ (C2) tex(expand((1+alpha[1])^2)); $$\alpha_{1}^2+2\,\alpha_{1}+1$$ (D2) FALSE Here is another problem: Powers of subscripted functions don't TeX with the exponent immediately following the function (C3) f[5](x)^9; (D3) f[5](x)^9 (C4) tex(%); $$f_{5}(x)^9$$ Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=834417&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:59:31

Bugs item #817557, was opened at 20031003 21:54 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817557&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: To be reviewed Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve/numer spurious polarform Initial Comment: solve(x^21,x),numer => [x=%E^(3.14*%i), x=%E^(6.28*%i)] same for solve(x^21.0,x),numer; Why???? Mysteriously, solve(x^2.01.0,x),numer => [x=1.0]  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:59 Message: Logged In: YES user_id=501686 5.9.3cvs / sbcl, clisp, gcl (all Linux) yield solve(x^21,x),numer; => [x = 1.2246063538223773E16 (%i  8165889364191922), x =  2.4492127076447545E16 (%i  4082944682095961)] so the reported spurious polarform seems to have gone away. Mark this report for verification on Windows  if not observed there we can close this report.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=817557&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:53:13

Bugs item #816808, was opened at 20031002 14:58 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=816808&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(in)part of rat  internal errs Initial Comment: substpart(x,2/3,2) => $x not of type integer It turns out that mformat doesn't change ((rat) 2 3) to ((mquotient) 2 3) as I'd have expected. substinpart does not give an error, but it does give an invalid result: substinpart(x,2/3,2) => ((rat simp) 2 $x) so if you try to manipulate it further, you *then* get an error. substinpart also neglects to simplify rats when the substitution is numeric: substinpart(4,2/3,2) => 2/4 (!!) Maxima 5.9,0 gcl 2.5.0 mingw32 W2k Athlon  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:53 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=816808&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:49:07

Bugs item #815836, was opened at 20031001 07: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=815836&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: Jaime E. Villate (villate) Assigned to: Nobody/Anonymous (nobody) >Summary: "step" fails for negative values Initial Comment: Using Maxima 5.9.0 (GCL, Debian package 5.9.011), I have tried out a simple "for" loop from 3 to 3, and then the same loop in reverse order from 3 to 3. The second one fails: (C10) x1: 3$ (C11) x2: 3$ (C12) p: 5$ (C13) for x:x1 step (x2x1)/p thru x2 do display(x); x =  3 9 x =   5 3 x =   5 3 x =  5 9 x =  5 x = 3 (D13) DONE (C14) x1: 3$ (C15) x2: 3$ (C16) for x:x1 step (x2x1)/p thru x2 do display(x); (D16) DONE In this second case I had to use a '' that was not necessary in the first case: (C17) for x:x1 step ''(x2x1)/p thru x2 do display(x); x = 3 9 x =  5 3 x =  5 3 x =   5 9 x =   5 x =  3  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:49 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20031002 01:03 Message: Logged In: YES user_id=588346 Yes, the current code for DO foolishly assumes that the step's sign can be determined from the syntactic form of the unevaluated step expression, but it also (peculiarly) re evaluates the step each time around the loop. It also uses the most generic way of comparing things (is), but I suppose that ensures that it will correctly handle fixnums, floats, bfloats, rats, and possible etc.'s. So we have such lovely nonsense as: q:1$ for i : 1 thru 5 step q do print(xxx) ... does nothing because "q" is syntactically positive for i step i thru 10 do print(i) ... prints 1 2 4 8 ... note reevaluation of i each time through for i:1 thru 20 step i*2i do print(i); ... note trick for multiplicative counting for i:1 thru 8 step i*2i do print(i); ... even alternating sign... but why does it end with 16? => 1 ,  2 , 4 ,  8 , 16 assume(u>0,v>0); for i:u step v thru u+10*v do print(i); ... amazing, eh? The solution is to evaluate step exactly once.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=815836&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:45:32

Bugs item #814957, was opened at 20030930 02: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=814957&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: Xmaxima >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: No internet => No xMaxima Initial Comment: The windows compiled version of xMaxima refuses to work if a connection to internet is not available and working. A message saying "Error starting Maxima: Could not open a socket" is issued. After that the window xMaxima keeps mute, no prompt, no echo, nothing... If we have no Internet connection how can we keep working with Maxima through the xMaxima interface?  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:45 Message: Logged In: YES user_id=501686 I wonder just how much network stuff needs to be active in order to enable the Maxima <> Xmaxima connection. It seems like just having the network stuff running with the loopback address (127.0.0.1) should be enough. Should be possible to test by shutting down any other interfaces and then trying to launch Xmaxima.  Comment By: Peter Ulrich Kruppa (pukruppa) Date: 20031111 08:26 Message: Logged In: YES user_id=778327 Some of my students have reported this problem to me, too, although everything on my laptop (WinXP Home Edition) works fine  even without internet connection. The only significant difference to their machines, I can think of, is that I once activated XP's compatibility mode for older programs (sorry, I don't know the exact words since I am running XP in german  do search for "compatibility" in the help menu and reinstall maxima with it). Just one possibility. Regards, Uli.  Comment By: Stavros Macrakis (macrakis) Date: 20030930 12:25 Message: Logged In: YES user_id=588346 An active Internet connection is not required by xMaxima. However, you must have sockets installed, working, and enabled, because Maxima uses them for interprocess communication. Firewall software may be closing off sockets, for example.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=814957&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:42:22

Bugs item #812968, was opened at 20030926 03: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=812968&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: Joel Ray Holveck (piquan) Assigned to: Nobody/Anonymous (nobody) Summary: is(equal(...)) says unknown, ratsimp says 0 Initial Comment: The way I understood EQUAL, it seems that it's supposed to answer true if ratsimp returns true. But in the following equation, it is clear that this is not happening. Sorry about the mess; this was the simplest reproduction scenario I could find. (C112) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2)), (x1)/(2*x*sqrt(2)))); (D112) UNKNOWN (C113) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2)), (x)/(2*x*sqrt(2))1/(2*x*sqrt(2)))); (D113) TRUE (C114) ratsimp(x/(2*x*sqrt(2))  1/(2*x*sqrt(2))  (x1)/(2*x*sqrt(2))); (D114) 0 (C115) facts(); (D115) [NOT EQUAL(x, 0)] I did consider that the problem may be related to the fact that ratsimp simplifies the two sides of the equation differently, so I tried putting them on the same side. In the following, the left side of the equal ratsimp's to 0 (as seen in D114), and yet equal doesn't assert that it's equal to 0. (C130) is(equal(x/(2*x*sqrt(2))  1/(2*x*sqrt(2))  (x1)/(2*x*sqrt(2)), 0)); (D130) UNKNOWN I may be missing something obvious here I'm just learning Maxima but this seems off to me.  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:42 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Robert Dodier (robert_dodier) Date: 20060326 17:44 Message: Logged In: YES user_id=501686 Looking at src/compar.lisp, it appears that the compare and sign functions don't call ratsimp, maybe they should. Hard to tell what's going on in compar.lisp.  Comment By: Stavros Macrakis (macrakis) Date: 20030927 11:58 Message: Logged In: YES user_id=588346 You are absolutely right: this is a bug. Worse, is(equal(1/sqrt(2),sqrt(2)/2)) and even is(equal(1/sqrt (2)sqrt(2)/2,0)) return False! As you say, it should be using ratsimp(1/sqrt(2)sqrt(2)/2)  which does correctly return 0. It is also a known problem (bug?) that 1/sqrt(2) and sqrt(2)/2 do not simplify to the same thing, but as you say, even when you put them on the same side, it doesn't work.... 5.9.0 gcl 2.5.0 W2k  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=812968&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:38:58

Bugs item #808676, was opened at 20030918 10:13 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=808676&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: bfloat(1+10^30) rounds wrong with fpprec:20 Initial Comment: fpprec:20$ bfloat(1+10^30)  1; > 3.388...B21 The correct answer is 0.0b0, because bfloat(1+10^30) should round to exactly 1.0b0.  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:38 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Raymond Toy (rtoy) Date: 20041123 11:27 Message: Logged In: YES user_id=28849 I think the problem is because it converts the ratio (10^30+1)/10^30 to a bigfloat and doesn't quite round correctly. It's off by one bit. Adding 1b0+1b30 does round correctly and return 1b0 exactly.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=808676&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:29:09

Bugs item #801231, was opened at 20030905 10:59 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=801231&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  Assume Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: MAX(a+b,c) is NOT equal to MAX(c,a+b) Initial Comment: (C1) assume(a+b>c)$ (C2) MAX(a+b,c); MAX(c,a+b); (D2) b + a (C3) (D3) MAX(c, b + a) #why it is not simplified ? (C4) is(MAX(a+b,c)=MAX(c,a+b)); (D4) FALSE #why FALSE if must be TRUE ? P.S. Appreciate if you exclude javascripts from the site. Alexander VIDYBIDA vidybida@...  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:29 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Barton Willis (willisb) Date: 20030905 11:46 Message: Logged In: YES user_id=570592 Most likely, this bug is related to the bug (C1) assume(a+b > c); (D1) [ C + b + a > 0] (C2) sign(a+bc); (D2) POS (C3) sign(c(a+b)); (D3) PNZ The result of PNZ (positive, negative, or zero) isn't wrong; however, Maxima should be able to determine that c  (a + b) < 0. That is (d3) should be NEG instead of PNZ. Barton  Comment By: Nobody/Anonymous (nobody) Date: 20030905 11:08 Message: Logged In: NO Comment by A lexander VIDYBIDA vidybida@... Maxima version: 5.9.0 Maxima build date: 19:1 8/5/2003 host type: i586pclinuxgnu lispimplementationtype: CLISP lispimplementationversion: 2.27 (released 20010717) (built 3223390905) (memory 3269088151)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=801231&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:27:06

Bugs item #798571, was opened at 20030901 08:10 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=798571&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: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) >Summary: sign(sqrt(2)/2  1/sqrt(2)) => zero, pos, neg, or pnz Initial Comment: Depending on the values of fpprec and signbfloat, sign(sqrt(2)/2  1/sqrt(2)) evaluates to zero, pos, neg, or pnz. (C1) display2d : false; (D1) FALSE (C2) a : sqrt(2)/2  1/sqrt(2); (D2) SQRT(2)/21/SQRT(2) (C3) for k : 20 thru 25 do (fpprec : k, print(k,sign(a))); 20 ZERO 21 POS 22 ZERO 23 POS 24 ZERO 25 NEG (D3) DONE (C4) sign(a), signbfloat : true; (D4) NEG (C5) sign(a), signbfloat : false; (D5) PNZ Here is another example  this time sign(p) should evaluate to pos. (C7) p : exp(x)  sum(x^k/k!,k,0,15)$ (C8) p : subst(1/10000001,x,p)$ (C9) sign(p),signbfloat : true; (D9) ZERO (C10) sign(p),signbfloat : false; (D10) PNZ (C11) for k : 20 thru 25 do (fpprec : k, print(k,sign (p))); 20 POS 21 NEG 22 NEG 23 ZERO 24 POS 25 ZERO (D11) DONE (C12) Additionally, signbfloat isn't documented (C17) describe("signbfloat"); (D17) FALSE Barton  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:27 Message: Logged In: YES user_id=501686 The p : exp(x)  sum(x^k/k!,k,0,15)$ etc stuff is still present in 5.9.3cvs. Now sqrt(2)/2  1/sqrt(2) simplifies to 0, so that one has gone away. Incrementing the priority since sign problems are pervasive and important.  Comment By: Stavros Macrakis (macrakis) Date: 20031019 23:57 Message: Logged In: YES user_id=588346 About the specific case of sqrt(2)/2  1/sqrt(2), cf. bug 721575  they should really simplify to a standard form and cancel. The general problem of using approximate arithmetic to check sign/is remains.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=798571&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:15:55

Bugs item #797401, was opened at 20030829 10:43 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=797401&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: infix should return string, not internal op Initial Comment: infix("X") returns the atom $X (which prints as "X"). The problem with that is that after X is defined as infix, that atom is useless and in fact can't be input into Maxima; "X" means the *string* X, not the *operator* X. Maxima goes to great lengths to make sure that operators can be referred to by their string name. For example, part(1 x 2,0) returns the string &X ("X") even though internally it is $X. Infix("X") should thus be returning the *string* &X ("X").  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:15 Message: Logged In: YES user_id=501686 In 5.9.3cvs, infix("X") => "X" (i.e. Lisp atom &x). Also comment by Ray says it is fixed. Closing this report as fixed.  Comment By: Raymond Toy (rtoy) Date: 20050412 10:49 Message: Logged In: YES user_id=28849 Fixed. Also see bug 1173788.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=797401&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:12:41

Bugs item #792862, was opened at 20030821 18: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=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 Group: None Status: Open Resolution: None Priority: 5 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: Robert Dodier (robert_dodier) Date: 20060709 21:12 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030829 10: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...>  20060710 03:10:21

Bugs item #792114, was opened at 20030820 13: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=792114&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: Robert Dodier (robert_dodier) >Summary: "/" should be the quotient operator /FIX Initial Comment: The name of the quotient operator is currently "//" rather than "/". There is no good reason for this. Currently: part(a/b,0) => "//" (internally &//) "//"(a,b) => a/b Strangely, it also works to say: "/"(a,b) => a/b apply("//",[a,b]) => a/b but apply("/",[a,b]) gives /(a,b), which has nothing to do with division. This is inconsistent, confusing, and unnecessary. I suspect it is accidental, because in some Lisps you needed to write // instead of / (/ was an escape character). Fix: in comm.lisp, change (MNCTIMES &.) (RAT &//) (MQUOTIENT &//) (MNCEXPT &^^) to (MNCTIMES &.) (RAT &/) (MQUOTIENT &/) (MNCEXPT &^^) I suppose you could go through the whole source and change // to /, but since all the other uses are internal, it doesn't matter.  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:10 Message: Logged In: YES user_id=501686 Closely related to bug report # 712462. After applying the patch given here, verify whether the problems reported in are resolved.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=792114&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:10:07

Bugs item #712462, was opened at 20030330 21: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=712462&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: Robert Dodier (robert_dodier) Summary: Operator "/" treated inconsistently Initial Comment: "/"(a,b) correctly gives a/b However, in most other contexts, Maxima expects "//": part(a/b,0) => // WHY? subst("/",f,f(a,b)) => /(a,b) NO! substpart("/",f(a,b),0) => /(a,b) NO! apply("/",[a,b]) => /(a,b) NO! This is presumably a relic of the Maclisp quoting convention that used slash to quote the next character (similar to backslash in Common Lisp). Presumably in the Maclisp version, it cancelled out and the user saw "/", not "//". This needs to be fixed for Common Lisp. Maxima 5.9.0 GCL 2.5.0 Windows 2000  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:10 Message: Logged In: YES user_id=501686 Closely related to bug report # 792114. Maybe applying fix given in that report will fix the problems shown here.  Comment By: Robert Dodier (robert_dodier) Date: 20050410 21:51 Message: Logged In: YES user_id=501686 This seems to be a problem with differing internal and external representations for the same operator. I don't think the / vs // has much to do with it, although it would be nice if one or the other were used consistently. An input a/b is parsed as ((MQUOTIENT) $A $B)  as far as I can tell, it is not simplified to that from ((&/) $A $B), instead it seems the simplifier never sees the operator (&/) and so it doesn't have any rules for simplifying that into (MQUOTIENT). It seems the fundamental problem would be resolved by moving the substitution / > MQUOTIENT out of the parser and into the simplifier; if there are other such replacements, maybe they should be moved too. tellsimpafter seems happy enough to clean up for us: (%i9) apply("/", [a,b]); (%o9) /(a, b) /* OOPS */ [... snip ...] (%i11) matchdeclare ([a,b],true); (%o11) done (%i12) tellsimpafter (''%o9, a/b); (%o12) [/RULE1, false] [... snip ...] (%i19) apply ("/", [a+b, cd]); b + a (%o19)  /* OK */ c  d (%i20) subst ("/", f, f(x,y)); x (%o20)  /* OK */ y (%i21) substpart ("/", f(x,y), 0); x (%o21)  /* OK */ y  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=712462&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 03:05:52

Bugs item #932132, was opened at 20040408 19:25 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932132&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: rhs/lhs don't check for equationlike things Initial Comment: rhs/lhs are documented to give the rhs and lhs of an equation. They consider every expr that is not of the form a=b to be the equation expr=0. I don't think that's a reasonable convention. It's asking for trouble to make rhs(a>b) => a>b. Same thing for dispfun(f) rhs(%) These should either give the 2nd argument, or an error.  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 21:05 Message: Logged In: YES user_id=501686 lhs and rhs were extended to handle equationlike expressions (e.g. greater than, less than, function defn, some others) circa 2006/01 (first appeared in 5.9.3 release). Closing this report as fixed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=932132&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 02:58:05

Bugs item #791607, was opened at 20030819 17:46 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=791607&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: Xmaxima Group: Fix for 5.9.0 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: "Could not open a socket" error Initial Comment: I installed Maxima 5.9 a couple of days ago, and it worked fine, until I installed Borland Turbo C++ 4.5, and now every time Maxima starts, I get a "Could not open a socket" error. I can't do any operation inside the program, because of that. I have already unistalled and reinstalled the program several times, and nothing has changed. Can I do anything to avoid that error?  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 20:58 Message: Logged In: YES user_id=501686 Closing this report as "won't fix" because fixing it requires additional information which is impossible to obtain at this late date. Sounds vaguely like the Windows firewall problem which has been reported > 1 time, although of course I can't be sure.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=791607&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 02:55:34

Bugs item #791234, was opened at 20030819 08:20 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=791234&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((x^(1/3)+1)^3) fails Initial Comment: factor((x^(1/3)+1)^3) fails, though factor((x^(1/3)+1) ^2) works. The problem is presumably that in the ^2 case, the powers of x are explicitly of the form n/3, whereas in the ^3 case, (x^(1/3))^3 => x, where the (1/3) is not explicit. Similarly for (x^(1/4)+1)^2. Shouldn't factor normalize the exponents (like radcan)?  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 20:55 Message: Logged In: YES user_id=501686 Seems to work the same way in 5.9.3cvs (although I don't fully understand what the problem is).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=791234&group_id=4933 
From: SourceForge.net <noreply@so...>  20060710 02:53:08

Bugs item #789059, was opened at 20030814 21:55 Message generated for change (Settings changed) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789059&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lisp Core  Simplification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: simpexpt problem: sign called on imag arg Initial Comment: The expression ((1)^(1/6))^(1/2) gives the error SIGN called on an imaginary argument This looks a lot like bug report 711885, except that in this case the expression causing the problem was generated directly from valid user input, not by another routine (in that case rootscontract) which created an incorrectly simplified internal result.  >Comment By: Robert Dodier (robert_dodier) Date: 20060709 20:52 Message: Logged In: YES user_id=501686 Still present in 5.9.3cvs.  Comment By: Stavros Macrakis (macrakis) Date: 20030814 21:59 Message: Logged In: YES user_id=588346 Maxima 5.9.0 gcl 2.5.0 mingw32 Windows 2000 Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=789059&group_id=4933 