Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

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

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

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



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

9
(3) 
10
(4) 
11
(4) 
12
(6) 
13
(3) 
14
(1) 
15
(4) 
16

17

18

19
(6) 
20
(5) 
21

22
(2) 
23
(1) 
24
(4) 
25

26

27
(1) 
28

29
(2) 
30
(1) 



From: SourceForge.net <noreply@so...>  20100615 00:53:50

Bugs item #3015864, was opened at 20100614 06:29 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3015864&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ler kru (lerkru) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima can't evaluate limit Initial Comment: limit((tan(sin(x))sin(tan(x)))/(atan(asin(x))asin(atan(x))),x,0,plus); Result must be 1, but maxima can't evaluate this.  >Comment By: Barton Willis (willisbl) Date: 20100614 19:53 Message: Workaround: (%i35) tlimit((tan(sin(x))sin(tan(x)))/(atan(asin(x))asin(atan(x))),x,0,plus); Evaluation took 0.0200 seconds (0.0200 elapsed) (%o35) 1  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3015864&group_id=4933 
From: SourceForge.net <noreply@so...>  20100614 11:29:14

Bugs item #3015864, was opened at 20100614 15:29 Message generated for change (Tracker Item Submitted) made by lerkru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3015864&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ler kru (lerkru) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima can't evaluate limit Initial Comment: limit((tan(sin(x))sin(tan(x)))/(atan(asin(x))asin(atan(x))),x,0,plus); Result must be 1, but maxima can't evaluate this.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3015864&group_id=4933 
From: SourceForge.net <noreply@so...>  20100613 19:26:01

Bugs item #2036462, was opened at 20080803 08:34 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2036462&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Solving equations Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: thbesson (thbesson) Assigned to: Nobody/Anonymous (nobody) Summary: Very long calculation time, normal ? Initial Comment: wxMaxima 0.7.5 http://wxmaxima.sourceforge.net Maxima 5.15.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) kill(all); (%o0) done (%i1) declare(a,constant); (%o1) done (%i2) declare(b,constant); (%o2) done (%i3) declare(c,constant); (%o3) done (%i4) solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c); running since 12 hours on a dualcore  >Comment By: Dieter Kaiser (crategus) Date: 20100613 21:26 Message: When we declare the symbols a, b, and c as a constant for the reported example, the algorithm of solvequartic in psolve.lisp hangs. In the routine solvequartic the routine simpnrt in called directly to calculate the square root of an expression. But simpnrt never returns. If we cut out the direct call of simpnrt and replace the code with calls to the main simplifier we no longer get the error: (%i1) declare([a,b,c],constant); (%o1) done (%i2) solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c); (%o2) [x = sqrt(48*b/(a*sqrt((a*(32*sqrt( 32*a*c^3+96*%pi*a*b*c^2 ((96*%pi^2+216)*a*b^224*a^3)*c +81*b^4 (32*%pi^3216*%pi)*a*b^3 180*a^2*b^224*%pi*a^3*b8*a^4) /a^2 .... and lot of more terms. This is the piece of code in solvequartic. The calls to simpnrt have been replaced with calls to the function power: lb1 ; (setq d (simpnrt (simplify (list '(mplus) tr1 tr2)) 2)) (setq d (power (add tr1 tr2) '((rat simp) 1 2))) ; (setq e ; (simpnrt (simplify (list '(mplus) ; (list '(mtimes) 1 tr2))) ; 2)) (setq e (power (add tr1 (mul 1 tr2)) '((rat simp) 1 2))) We have no problems with the testsuite. In the share_testsuite we have only one example which gives the same solutions, but in a different order: ********************** Problem 116 *************** Input: nicedummies(%solve(cos(x)2*cos(2*x)+cos(3*x) = 1/2,x,simpfuncs = ['expand])) Result: %union([x = 2*%pi*%z0atan(sqrt(sqrt(13)/2+1/2)/(1/2sqrt(13)/2))%pi], [x = 2*%pi*%z1+atan(sqrt(sqrt(13)/2+1/2)/(1/2sqrt(13)/2))+%pi], [x = 2*%pi*%z2%i*log(sqrt(13)/4sqrt(sqrt(13)/21/2)/2+1/4)], [x = 2*%pi*%z3%i*log(sqrt(13)/4+sqrt(sqrt(13)/21/2)/2+1/4)], [x = 2*%pi*%z4%pi/3],[x = 2*%pi*%z5+%pi/3]) This differed from the expected result: %union([x = 2*%pi*%z0%i*log(1/4sqrt(sqrt(13)1)/2^(3/2)+sqrt(13)/4)], [x = 2*%pi*%z1%i*log(1/4+sqrt(sqrt(13)1)/2^(3/2)+sqrt(13)/4)], [x = 2*%pi*%z2%pi/3],[x = %pi/3+2*%pi*%z3], [x = %piatan(sqrt(1+sqrt(13))/(1/sqrt(2)sqrt(13)/sqrt(2))) +2*%pi*%z4], [x = %pi+atan(sqrt(1+sqrt(13))/(1/sqrt(2)sqrt(13)/sqrt(2))) +2*%pi*%z5]) I think there is no reason to call simpnrt directly and we should replace these calls. Dieter Kaiser  Comment By: Jason Nevins (jnevins32) Date: 20080901 22:52 Message: Logged In: YES user_id=2201177 Originator: NO Hi, thanks, workaround helped. Also, I have realized that I had support compiled for multiple Common Lisp interpreters. Will try to reduce this to only one and see if it makes a difference.  Comment By: Jason Nevins (jnevins32) Date: 20080901 22:32 Message: Logged In: YES user_id=2201177 Originator: NO Hi I'm Having exact same problem (see: 2087495). Also when doing exactly the above the problem is reproduced. Maxima 5.16.2 http://maxima.sourceforge.net Using Lisp CLISP 2.43 (20071118) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) declare(a,constant); (%o1) done (%i2) declare(b,constant); (%o2) done (%i3) declare(c,constant); (%o3) done (%i4) solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c); <<<<<<<<<<<<<<<<<<<< HANGS HERE. Regards Jason Nevins  Comment By: Robert Dodier (robert_dodier) Date: 20080803 20:24 Message: Logged In: YES user_id=501686 Originator: NO Assign category.  Comment By: Robert Dodier (robert_dodier) Date: 20080803 18:58 Message: Logged In: YES user_id=501686 Originator: NO Well, this is a bug. Here is a workaround: omit the declare(..., constant) and tell solve to solve for x specifically. solve(a*x^4/4!+a*x^2/2!+b*x%pi*b+a+c, x); => (quickly returns a long expression) I can't tell what is the problem here; simpler examples seem to get solved right away. I've moved this to the bug tracker in hope of eventually resolving it.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2036462&group_id=4933 
From: SourceForge.net <noreply@so...>  20100613 09:54:08

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Comment added) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Derek O'Connor (derekroconnor) Date: 20100613 10:54 Message: The bug is not really in gcl but in ming32. R 2.11.0 under ming32 gives the wrong answer while R 2.11.0 under ming64 gives the right answer. Is it possible to get a version of Maxima (or gcl) that uses ming64?  Comment By: Raymond Toy (rtoy) Date: 20100613 03:00 Message: As I mentioned, I consider this a bug in gcl, not maxima. Although I could fix it, I'm not inclined to do so. It would be a lot of work to do and to support just for gcl when ccl, I think, produces the correct result. (It does on Mac OS X.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 23:56 Message: I am NOT concerned about bfloat(sin(10^22)) or sin(bfloat(10^22)). I am concerned that sin(10^22) gives the wrong answer on my system, and presumably, on many similar systems.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 10:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 23:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 19:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100613 02:00:06

Bugs item #3014845, was opened at 20100611 10:10 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Raymond Toy (rtoy) Date: 20100612 22:00 Message: As I mentioned, I consider this a bug in gcl, not maxima. Although I could fix it, I'm not inclined to do so. It would be a lot of work to do and to support just for gcl when ccl, I think, produces the correct result. (It does on Mac OS X.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 18:56 Message: I am NOT concerned about bfloat(sin(10^22)) or sin(bfloat(10^22)). I am concerned that sin(10^22) gives the wrong answer on my system, and presumably, on many similar systems.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 05:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 18:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 14:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 22:56:08

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Comment added) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Derek O'Connor (derekroconnor) Date: 20100612 23:56 Message: I am NOT concerned about bfloat(sin(10^22)) or sin(bfloat(10^22)). I am concerned that sin(10^22) gives the wrong answer on my system, and presumably, on many similar systems.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 10:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 23:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 19:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 09:50:49

Bugs item #3014545, was opened at 20100610 23:52 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014545&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: submatrix does not work as expected Initial Comment: submatrix(10,20,zeromatrix(20,20)); does not delete any rows. It returns zeromatrix(20,20) also submatrix(3,5,F,3,5); matrix([1,1,1],[1,1,1],[1,1,1]) and submatrix(2,5,F,2,5); do the exact same thing. I'm running Maxima 5.21.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (a.k.a. GCL)  Comment By: Aleksas Domarkas (alex108) Date: 20100612 12:50 Message: Works for me correct (%i1) submatrix(10,20,zeromatrix(20,20))$ (%i2) matrix_size(%); (%o2) [18,20] (%i3) submatrix(zeromatrix(20,20),10,11,20)$ (%i4) matrix_size(%); (%o4) [20,17] (%i5) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014545&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 09:30:06

Bugs item #3014845, was opened at 20100611 17:10 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  Comment By: Aleksas Domarkas (alex108) Date: 20100612 12:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100612 01:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 21:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 02:20:12

Bugs item #2973860, was opened at 20100320 17:57 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2973860&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Oliver Kullmann (xgateruq9) Assigned to: Nobody/Anonymous (nobody) Summary: string in term causes error in evaluation Initial Comment: declare(f, posfun); is(f("x") > 0); Maxima encountered a Lisp error: "x" is not of type LIST.  >Comment By: SourceForge Robot (sfrobot) Date: 20100612 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100528 18:00 Message: I think this problem is no longer present. With the current CVS version I get: (%i1) is(f("x")>0); (%o1) unknown (%i2) declare(f,posfun); (%o2) done (%i3) is(f("x")>0); (%o3) true This is my build info: Maxima version: 5.20post Maxima build date: 17:38 5/28/2010 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.29.11.debian Setting the status to pending and the resolution to "works for me". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2973860&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 02:20:11

Bugs item #2998546, was opened at 20100508 13:27 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998546&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: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Crash on startup with Windows XP and 7 Initial Comment: On all of my Systems (2x Windows 7 Home Premium x64 and 1x Windows XP Home SP3) when starting xmaxima or wxmaxima it says that "maxima.exe" crashed with this information: Problemsignatur: Problemereignisname: BEX Anwendungsname: maxima.exe Anwendungsversion: 0.0.0.0 Anwendungszeitstempel: 48008dee Fehlermodulname: StackHash_96fa Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: 00000000 Ausnahmeoffset: 10d7573c Ausnahmecode: c0000005 Ausnahmedaten: 00000008 Betriebsystemversion: 6.1.7600.2.0.0.768.3 GebietsschemaID: 1031 Zusatzinformation 1: 96fa Zusatzinformation 2: 96fa395741d68f9a26119358963d26da Zusatzinformation 3: 369d Zusatzinformation 4: 369d051849f5f0abf3480665efbcb70c Please fix it. I need maxima so often.  >Comment By: SourceForge Robot (sfrobot) Date: 20100612 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Viktor Toth (vttoth) Date: 20100528 19:03 Message: BEX is caused by a data execution prevention exception. Make sure you add maxima.exe to the list of DEP exceptions. (On Windows 7, in the Start menu rightclick Computer, click Properties, click Advanced system settings, click the Settings button under Performance, click the Data Execution Prevention tab, and then click Add and locate maxima.exe.  Comment By: Dieter Kaiser (crategus) Date: 20100528 18:35 Message: I do not have any problems with Maxima (all versions and CVS) and Windows XP and I think we have a lot of installations on Windows 7 too. At first, it might be useful to get some more information. What is the source of your Maxima version? What version of Maxima you are using? Is it possible to start Maxima in a terminal? Setting the status to pending to get more information. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2998546&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 02:20:09

Bugs item #3008330, was opened at 20100528 04:01 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3008330&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Integration Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to integrate floor( x ) Initial Comment: The following: integrate( floor( x ) , x ); does not produce a solution in Maxima. Clearly solutions exist. For instance, integrate( floor( x ) , x , 1.3 , 1.7 ); should return the value 0.2  >Comment By: SourceForge Robot (sfrobot) Date: 20100612 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Barton Willis (willisbl) Date: 20100601 01:19 Message: I added an integral property to both floor and ceiling. The next Maxima version will be able to integrate floor without loading abs_integrate.  Comment By: Dieter Kaiser (crategus) Date: 20100528 15:50 Message: Because Maxima is able to solve this integral when loading the package abs_integrate, I think we have no bug. I suggest to close this bug report as "works for me". Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20100528 11:00 Message: (%i2) load(abs_integrate)$ (%i3) integrate(floor(x),x); (%o3) (floor(x)*(floor(x)2*x+1))/2 (%i4) integrate(floor(x),x,13/10,17/10); (%o4) 2/5  Comment By: Aleksas Domarkas (alex108) Date: 20100528 06:31 Message: integrate( floor( x ) , x ); should return x*floor(x) (%i1) ratprint:false$ (%i2) S:integrate(floor(x),x,1.3,1.7); (%o2) integrate(floor(x),x,1.3,1.7) (%i3) changevar(S, y=x1, y, x); (%o3) integrate(floor(y)+1,y,0.3,0.7) (%i4) sol:ev(%, nouns); (%o4) 0.4  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3008330&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 22:40:55

Bugs item #3014845, was opened at 20100611 10:10 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Raymond Toy (rtoy) Date: 20100611 18:40 Message: Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer. Maxima with cmucl produces 0.8522008497671888, as you expect. I consider this a bug in gcl, not maxima. Marking as pending/wontfix.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 14:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 18:38:47

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Comment added) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Derek O'Connor (derekroconnor) Date: 20100611 19:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 14:10:53

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Tracker Item Submitted) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: sin(1e22); (%o1) 0.41214336710708 The correct answer is 8.522008497671888 Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is 10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22 This incorrect result suggests that the rangereduction step, where the argument x is reduced to lie in a small interval around 0, such as [pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect. This value 10^22 was carefully chosen by Ng to uncover faulty range reduction: http://www.derekroconnor.net/Software/NgArgReduction.pdf Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it. I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using? Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 02:20:11

Bugs item #873301, was opened at 20040108 20:39 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873301&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Gradef doesn't understand diff (workaround) Initial Comment: Suppose that f(x)=exp(g(x)). Then f'(x)=f(x)*g'(x). So how do we define this using gradef? Let's try the obvious solution: gradef( f(x), f(x) * diff(g(x),x) ) Now diff(f(x^2),x) => f(x1)*'DIFF(g(x1),x1,1) Oops! That isn't right! It is substituting x1 for x in the *second* argument of diff as well as the first! So we have to work around this doing something like gradef( f(x), f(x) * g1(x) ) gradef( g(x), g1(x) )  >Comment By: SourceForge Robot (sfrobot) Date: 20100611 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100527 20:55 Message: As explained in the last posting I would like to suggest to close this bug report as "works for me". Setting the status to pending. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20100511 20:34 Message: First, again the example of this bug report: (%i6) gradef(f(x), f(x)*diff(g(x),x)); We get a wrong result with the above definition: (%i7) diff(f(2*sin(x)),x); (%o7) 2*cos(x)*f(2*sin(x))*'diff(g(2*sin(x)),2*sin(x),1) But Maxima can do it correctly. We have to define the problem the following way: (%i8) gradef(f(x), f(x)*at(diff(g(u),u),u=x))$ (%i9) diff(f(2*sin(x)),x); (%o9) 2*('at('diff(g(u),u,1),u = 2*sin(x)))*cos(x)*f(2*sin(x)) The example of the bug report now gives a correct result too: (%i10) diff(f(x^2),x); (%o10) 2*('at('diff(g(u),u,1),u = x^2))*x*f(x^2) >From this we might conclude, that we have not a bug, but we have to formulate the problem more precisely. By the way: The derivatives of the nine inverse Jacobi functions wrt the parameter m are defined as a noun form. Furthermore, the derivatives of the Bessel Y and K functions wrt the order have a noun form of a derivative on the property list. All this derivatives do not work too, but have the same error as reported in this bug report, e.g. (%i11) diff(inverse_jacobi_ns(x,2*m),m); (%o11) 2*'diff(inverse_jacobi_ns(x,2*m),2*m,1) The error for the inverse Jacobi functions is easy to correct. We simply put NIL for the derivative wrt the parameter m on the property list. We had some time ago an extension to sdiff to return a noun form for this case. With this change we get a correct noun form: (%i13) diff(inverse_jacobi_ns(x,2*m),m); (%o13) 'diff(inverse_jacobi_ns(x,2*m),m,1) This is an example of a wrong derivative of a Bessel K function: (%i15) diff(bessel_k(sin(n),x),n); (%o15) cos(n)*(%pi*csc(%pi*sin(n)) *('diff(bessel_i(sin(n),x),sin(n),1) 'diff(bessel_i(sin(n),x),sin(n),1)) /2 %pi*bessel_k(sin(n),x)*cot(%pi*sin(n))) To get this derivative in general correct we can put an expression with AT on the property list. Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060722 15:48 Message: Logged In: YES user_id=501686 In 5.9.3cvs, I'm seeing a different wrong answer. gradef( f(x), f(x) * diff(g(x),x) ); diff(f(x^2),x) ; => 2*x*f(x^2)*'?%diff(g(x^2),x^2,1) Should be 2*x*f(x^2)*at('?%diff(g(u),u,1),[u=x^2]) or something like that (i.e., distinguish point of evaluation x^2 from variable of differentiation). <rant> Maxima adopts numerous mathematical conventions, mostly successfully, but this customary sloppiness with differentials is something I wish we could clean up. </rant> Not sure how the proposed workaround is supposed to work. It turns out g1(x) = bessel_i(1,x)*%e^x  surprise!  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=873301&group_id=4933 
From: SourceForge.net <noreply@so...>  20100610 20:52:40

Bugs item #3014545, was opened at 20100610 20:52 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014545&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: submatrix does not work as expected Initial Comment: submatrix(10,20,zeromatrix(20,20)); does not delete any rows. It returns zeromatrix(20,20) also submatrix(3,5,F,3,5); matrix([1,1,1],[1,1,1],[1,1,1]) and submatrix(2,5,F,2,5); do the exact same thing. I'm running Maxima 5.21.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (a.k.a. GCL)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014545&group_id=4933 
From: SourceForge.net <noreply@so...>  20100610 05:22:34

Bugs item #3013945, was opened at 20100609 22:15 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013945&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: Wont Fix Priority: 5 Private: No Submitted By: Al Schapira (aschapira) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima (Wxmaxima) prints { for  in %o output Initial Comment: Maxima (Wxmaxima) prints left brace '{' for minus '' in %o output, although on screen the '' are okay. E.g. (ab) yields (%o1) (a{b) Maxima version: 5.20.1 Maxima build date: 18:51 5/10/2010 Host type: i386redhatlinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.382.fc12  >Comment By: Andrej Vodopivec (andrejv) Date: 20100610 07:22 Message: This is probably a configuration problem on your system. Read similar reports at the wxMaxima project: http://sourceforge.net/tracker/index.php?func=detail&aid=2980951&group_id=126731&atid=707628 http://sourceforge.net/projects/wxmaxima/forums/forum/435775/topic/3728309 I'm closing this bugreport as Wont Fix. If you can't find the solution in the posts above, open a bugreport at the wxMaxima project.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013945&group_id=4933 
From: SourceForge.net <noreply@so...>  20100610 05:21:43

Bugs item #3013943, was opened at 20100609 22:10 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013943&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: Wont Fix Priority: 5 Private: No Submitted By: Al Schapira (aschapira) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima (Wxmaxima) prints only first page Initial Comment: Maxima version: 5.20.1 Maxima build date: 18:51 5/10/2010 Host type: i386redhatlinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.382.fc12 I get only the first page printed.  >Comment By: Andrej Vodopivec (andrejv) Date: 20100610 07:21 Message: This is probably a configuration problem on your system. Read similar reports at the wxMaxima project: http://sourceforge.net/tracker/index.php?func=detail&aid=2980951&group_id=126731&atid=707628 http://sourceforge.net/projects/wxmaxima/forums/forum/435775/topic/3728309 I'm closing this bugreport as Wont Fix. If you can't find the solution in the posts above, open a bugreport at the wxMaxima project.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013943&group_id=4933 
From: SourceForge.net <noreply@so...>  20100610 02:20:09

Bugs item #1078046, was opened at 20041203 00:46 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1078046&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Closed Resolution: Wont Fix Priority: 4 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Alias atoms displayed after unorder() Initial Comment: I wonder whether the following behavior of Maxima is a bug. (%i1) display2d:false$ (%i2) ordergreat(a,b,c)$ (%i3) p:a*x^3+b*x^2+c*x+d=0; (%o3) x^3*a+x^2*b+x*c+d = 0; (%i4) unorder()$ (%i5) p; (%o5) x^3*?_103a+x^2*?_102b+x*?_101c+d = 0 Notice the strange output at %o5. Why does this happen? 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: SourceForge Robot (sfrobot) Date: 20100610 02:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).  Comment By: Dieter Kaiser (crategus) Date: 20100526 23:55 Message: The documentation of unorder has been extended to document the reported behavior of this bug report. I suggest to close this bug report as "wont fix". Setting the status to pending and the resolution to "wont fix". Dieter Kaiser  Comment By: Robert Dodier (robert_dodier) Date: 20060802 04:49 Message: Logged In: YES user_id=501686 unorder() removes the REVERSEALIAS property for the constructed atoms _103a, _102b, etc. Therefore the display code shows _103a, etc instead of a. The display can be changed back to a, b, etc by :lisp (putprop '_103a 'a 'reversealias) and that's great, but it doesn't address the problem that _103a is treated as distinct from a in computations. E.g. you can easily get stuff like "a  a" showing up. That could be addressed by scanning all expressions not yet garbage collected and substitute a for _103a. I don't know how hard that is. Just a thought.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1078046&group_id=4933 
From: SourceForge.net <noreply@so...>  20100609 21:41:35

Bugs item #3013990, was opened at 20100610 01:41 Message generated for change (Tracker Item Submitted) made by beshenov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013990&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Beshenov (beshenov) Assigned to: Nobody/Anonymous (nobody) Summary: reduce functions in nset.texi Initial Comment: Although lreduce, rreduce, tree_reduce, and xreduce come from the set package, they operate on lists. Isn't it better to move the corresponding documentation from nset.texi to Lists.texi?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013990&group_id=4933 
From: SourceForge.net <noreply@so...>  20100609 20:15:06

Bugs item #3013945, was opened at 20100609 16:15 Message generated for change (Tracker Item Submitted) made by aschapira You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013945&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: Al Schapira (aschapira) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima (Wxmaxima) prints { for  in %o output Initial Comment: Maxima (Wxmaxima) prints left brace '{' for minus '' in %o output, although on screen the '' are okay. E.g. (ab) yields (%o1) (a{b) Maxima version: 5.20.1 Maxima build date: 18:51 5/10/2010 Host type: i386redhatlinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.382.fc12  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013945&group_id=4933 
From: SourceForge.net <noreply@so...>  20100609 20:10:35

Bugs item #3013943, was opened at 20100609 16:10 Message generated for change (Tracker Item Submitted) made by aschapira You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013943&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: Al Schapira (aschapira) Assigned to: Nobody/Anonymous (nobody) Summary: Maxima (Wxmaxima) prints only first page Initial Comment: Maxima version: 5.20.1 Maxima build date: 18:51 5/10/2010 Host type: i386redhatlinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.382.fc12 I get only the first page printed.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3013943&group_id=4933 
From: SourceForge.net <noreply@so...>  20100607 19:42:41

Bugs item #3012778, was opened at 20100607 14:42 Message generated for change (Tracker Item Submitted) made by amoralesm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3012778&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: alejandro morales (amoralesm) Assigned to: Nobody/Anonymous (nobody) Summary: Lisp stack overflow with dpart. Initial Comment: (%i1) dpart(cos(a+b),1); ***  Lisp stack overflow. RESET [../src/eval.d:527] reset() found no driver frame (sp=0x99a465a00x99a400e0) Exiting on signal 6 Process maxima aborted  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3012778&group_id=4933 
From: SourceForge.net <noreply@so...>  20100607 08:29:34

Bugs item #3012427, was opened at 20100607 10:29 Message generated for change (Tracker Item Submitted) made by mrstamper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3012427&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: Open Resolution: None Priority: 5 Private: No Submitted By: Samgar Reichert (mrstamper) Assigned to: Nobody/Anonymous (nobody) Summary: tex2ooo.lisp invalid output Initial Comment: load(tex2ooo); A:matrix( [1,2], [3,4]); tex(A); outputs: left( matrix {1 # 2 ## 3 # 4 ## } right) This code is invalid. It must be: left( matrix {1 # 2 ## 3 # 4 } right)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3012427&group_id=4933 
From: SourceForge.net <noreply@so...>  20100606 11:05:55

Bugs item #2988544, was opened at 20100416 15:37 Message generated for change (Settings changed) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2988544&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 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: abs_integrate bug Initial Comment: load(abs_integrate)$ integrate(signum(abs(x)),x,2,2); yields a noun form, while the integrals from 2>0 and 0>2 are computed.  >Comment By: Barton Willis (willisbl) Date: 20100606 06:05 Message: Fixed by abs_integrate CVS revision 1.28; appended regression tests  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2988544&group_id=4933 