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}
(83) 
S  M  T  W  T  F  S 



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

6

7
(13) 
8
(6) 
9
(2) 
10
(8) 
11
(4) 
12

13
(15) 
14
(19) 
15
(3) 
16
(4) 
17
(2) 
18
(1) 
19
(1) 
20

21
(4) 
22
(7) 
23
(3) 
24

25
(2) 
26
(1) 
27
(1) 
28
(4) 
29
(7) 
30
(3) 
31
(1) 


From: SourceForge.net <noreply@so...>  20091214 17:30:42

Bugs item #2914296, was opened at 20091214 17:30 Message generated for change (Tracker Item Submitted) made by villate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914296&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: Jaime E. Villate (villate) Assigned to: Nobody/Anonymous (nobody) Summary: Limit gets Maxima stuck Initial Comment: The following limit makes Maxima 5.20 enter an endless loop: limit( (log(1+x^2)2+2*cos(x))/((sin(x))^2+2*sqrt(1x^2)2),x,0); In version 5.19.0 the loop ended with a wrong result "minf". The correct result is 5/7.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914296&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 15:00:23

Bugs item #2913967, was opened at 20091214 05:39 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913967&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: Tests Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: windows, 5.20.0, rtestum 151 and 154 fail Initial Comment: Windows 7, running tests gives 2 failures, same error when running that test alone Running tests in rtestsum: ********************** Problem 151 *************** Input: product(%pi  3, i, minf, inf) Result: 1 + inf + inf (%pi  3) This differed from the expected result: 0 ********************** Problem 154 *************** Input: product( %pi, i, minf, inf) Result: 1 + inf + inf 2 inf + 1 %pi ( 1) This differed from the expected result: infinity  Error summary: Errors found in D:/Cristian/Maxima5.20.0/share/maxima/5.20.0/tests/rtestsum.mac, problems: (151 154) real time : 325.470 secs rungbc time : 306.780 secs child run time : 0.000 secs gbc time : 18.690 secs (%i1) Maxima version: 5.20.0 Maxima build date: 22:10 12/8/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Kind regards, Cristian.  >Comment By: Dieter Kaiser (crategus) Date: 20091214 16:00 Message: This problem has been fixed in revision 1.86 of limit.lisp. Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913967&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 14:57:05

Bugs item #2913614, was opened at 20091213 11:40 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: LAPACK: dgesvd is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  >Comment By: Andrej Vodopivec (andrejv) Date: 20091214 15:57 Message: The best I could come up with is attached. (%i3) dgesvd(A); debugger invoked on a SIMPLEERROR: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Type HELP for debugger help, or (SBEXT:QUIT) to exit from SBCL. restarts (invokable by number or by possiblyabbreviated name): 0: [MACSYMAQUIT] Maxima toplevel 1: [CONTINUE ] Ignore and continue with next eval option. 2: [ABORT ] Skip rest of eval options. 3: Skip to toplevel READ/EVAL/PRINT loop. 4: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ((FLET #:LAMBDA139) #<TYPEERROR {132837C1}>) 0] backtrace 20 0: ((FLET #:LAMBDA139) #<TYPEERROR {132837C1}>) 1: ((FLET #:LAMBDA139) #<TYPEERROR {132837C1}>)[:EXTERNAL] 2: (SIGNAL #<TYPEERROR {132837C1}>)[:EXTERNAL] 3: (ERROR TYPEERROR)[:EXTERNAL] 4: (SBKERNEL::OBJECTNOTTYPEERRORHANDLER #<unavailable argument> #.(SBSYS:INTSAP #X011FF7D8) #<SBALIENINTERNALS:ALIENVALUE :SAP #X0006A000 :TYPE (* (SBALIEN:STRUCT SBVM::OSCONTEXTTSTRUCT))> (142 14)) 5: (SBKERNEL::OBJECTNOTTYPEERRORHANDLER #<unavailable argument> #.(SBSYS:INTSAP #X011FF7D8) #<SBALIENINTERNALS:ALIENVALUE :SAP #X0006A000 :TYPE (* (SBALIEN:STRUCT SBVM::OSCONTEXTTSTRUCT))> (142 14))[:EXTERNAL] 6: (SBKERNEL:INTERNALERROR #.(SBSYS:INTSAP #X0006A000) #<unavailable argument>) 7: ("foreign function: call_into_lisp") 8: ("foreign function: funcall2") 9: ("foreign function: interrupt_internal_error") 10: ("foreign function: signal_emulation_wrapper") 11: ("foreign function: os_get_runtime_executable_path") 12: ("foreign function: os_get_runtime_executable_path") 13: (LAPACK::DLASCL "G" 0 0 2.926974774165864d0 9.989595361011175d145 7 1 #(2.926974774165864d0 2.757202750978322d0 1.8889138843296875d0 0.5641183706403035d0 1.1901286134034068d0 0.2776359985260924d0 0.24215003810892827d0 0.0d0 4.0d0 0.3701265560273339d0 0.35596118043153524d0 0.0d0 ...) 7 #<unavailable argument>) 14: (LAPACK::DLASQ1 4 #(2.926974774165864d0 1.8889138843296875d0 1.1901286134034068d0 0.24215003810892827d0) #(2.757202750978322d0 0.5641183706403035d0 0.2776359985260924d0 0.0d0 2.926974774165864d0 2.757202750978322d0 1.8889138843296875d0 0.5641183706403035d0 1.1901286134034068d0 0.2776359985260924d0 0.24215003810892827d0 0.0d0 ...) #(2.926974774165864d0 2.757202750978322d0 1.8889138843296875d0 0.5641183706403035d0 1.1901286134034068d0 0.2776359985260924d0 0.24215003810892827d0 0.0d0 4.0d0 0.3701265560273339d0 0.35596118043153524d0 0.0d0 ...) #<unavailable argument>) 15: (LAPACK::DBDSQR "U" 4 0 0 0 #(2.926974774165864d0 1.8889138843296875d0 1.1901286134034068d0 0.24215003810892827d0) #(2.757202750978322d0 0.5641183706403035d0 0.2776359985260924d0 0.0d0 2.926974774165864d0 2.757202750978322d0 1.8889138843296875d0 0.5641183706403035d0 1.1901286134034068d0 0.2776359985260924d0 0.24215003810892827d0 0.0d0 ...) #(0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 ...) 4 #(0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 ...) 4 #(0.0d0) 1 #(2.926974774165864d0 2.757202750978322d0 1.8889138843296875d0 0.5641183706403035d0 1.1901286134034068d0 0.2776359985260924d0 0.24215003810892827d0 0.0d0 4.0d0 0.3701265560273339d0 0.35596118043153524d0 0.0d0 ...) #<unavailable argument>) 16: (LAPACK:DGESVD "No columns of U" "No columns of V^T" 4 4 #(2.926974774165864d0 0.10610322483770288d0 0.21267407794367488d0 0.41800896708772406d0 2.757202750978322d0 1.8889138843296875d0 0.14591288303296437d0 0.0033539118023266363d0 0.46269703294122566d0 0.5641183706403035d0 1.1901286134034068d0 0.16003447244391097d0 ...) 4 #(2.926974774165864d0 1.8889138843296875d0 1.1901286134034068d0 0.24215003810892827d0) #(0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 ...) 4 #(0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 0.0d0 ...) 4 #(2.757202750978322d0 0.5641183706403035d0 0.2776359985260924d0 0.0d0 2.926974774165864d0 2.757202750978322d0 1.8889138843296875d0 0.5641183706403035d0 1.1901286134034068d0 0.2776359985260924d0 0.24215003810892827d0 0.0d0 ...) 268 #<unavailable argument>) 17: ($DGESVD (($MATRIX SIMP) ((MLIST SIMP) 1.8276191992257917d0 0.39036923559557746d0 0.9647810497032392d0 0.7108801143185723d0) ((MLIST SIMP) 0.5044777533707618d0 0.8311254454429657d0 1.2251477785076492d0 1.6836253106718426d0) ((MLIST SIMP) 1.0111788892876237d0 1.356923990037029d0 0.07278663179984379d0 1.2505950366836145d0) ((MLIST SIMP) 1.9874629157389636d0 0.08317849230889962d0 1.2652507787332024d0 1.186304363033953d0)) NIL NIL) 18: (MEVAL1 #<unavailable argument>) 19: (MEVAL (($DGESVD) $a))  Comment By: Raymond Toy (rtoy) Date: 20091214 14:57 Message: I cannot reproduce this either with cmucl on mac os x. Running this with maxima g and looking at the Lisp error will help a lot in figuring this problem out. The boolean results are documented; it means the left and right singular vectors were not requested. Perhaps that should be changed, but that's a different issue.  Comment By: Dieter Kaiser (crategus) Date: 20091213 18:39 Message: On my system I get: (%i2) build_info(); Maxima version: 5.20post Maxima build date: 17:36 12/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3469710995) (%o2) (%i3) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i4) dgesvd(A); (%o4) [[3.755933922081446, 1.830035687063915, .7142611635301948, 0.127875116930834], false, false] I do not get a Lisp error. But the result contains boolean values. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 14:39:50

Bugs item #2910001, was opened at 20091207 08:16 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Clarphimous (clarphimous) Assigned to: Nobody/Anonymous (nobody) Summary: optimization of bfloat input Initial Comment: When using the input method that goes like 2.53b10, it tends to get very slow with large exponents. This applies for large negative exponents as well. I believe the reason is that it is converting all the digits up to the decimal point into binary, where it really only needs to convert them up to the number of bits of precision. For example: 1b1000000; takes quite a while to perform. Not far above this, Maxima crashes on my system (another bug I was originally investigating, which applies to rational numbers as well). On the other hand, if we do a calculation like x:1b1000; x^40000000; you can get a result in less than a second, although it does have some rounding errors at the end.  >Comment By: Raymond Toy (rtoy) Date: 20091214 09:39 Message: Some fixes have been checked in. The fast algorithm is used if the exponent exceeds 100000, but that is userchangeable. Further tests indicate that the fast algorithm matches the exact algorithm most of the time (.2% difference) if the number of digits is less than fpprec. If the number of digits exceeds fpprec, the fast method differs about 5% of the time. Perhaps this is good enough, since it's easy to change the bfloat precision. Closing report.  Comment By: Raymond Toy (rtoy) Date: 20091210 19:30 Message: Extra digits are already used, based on the size of the exponent. (Hmm. Should include the exponent and the number in case someone does 12345<many digits>90.123<many more>90 b <bigexp>) And with your example 1.12233445566...b0, maxima computes 11223344556677889900112233/10^25, exactly, and then rounds that (once) to a bfloat with 10 digits. The fast method always rounds at least 3 times, perhaps many more when computing 10b0^n. All of the differences occur with negative exponents. Don't know why that is.  Comment By: Clarphimous (clarphimous) Date: 20091210 17:12 Message: Alrighty. I think what would prevent roundoff errors is if you give it a few extra bits of precision while doing the calculations. In other words, guard digits/bits. If the input is shorter than the number of digits of precision, add some extra zeroes. The calculators I've used usually have 3 guard digits (although they were using binary coded decimal). For example: fpprec: 10; x:1.1223344556677889900112233b0 For this, cut it off 3 digits after the 10th digit. That would be 1.122334455668, with rounding. Then, convert that to binary with some extra bits of precision. Finally, round that answer off to the number of bits you usually have. Another example: a:1.23456789b0; For this I would assume that the actual input is 1.234567890000. Then convert that to binary, and cut off the excess bits when you're done. It might take some experimentation to figure out how how many extra digits and bits you need, but I'm pretty sure this will work. Here is a quick experiment I did where I manually rounded the numbers: fpprec: 10; x:1.1223344556677889900112233b0; x1.122334455b0; y:1.1223344557b0; y1.122334455b0; z:1.12233445567b0; z1.122334455b0; http://www.disillusionary.com/files/exp.png  Comment By: Raymond Toy (rtoy) Date: 20091210 12:40 Message: I've done some work on this, and bfloat input for large inputs is now much faster. 2.53b10 is converted by computing bfloat(253)*10b0^(102). Except the exponent is much larger. Small exponents use the current algorithm. The new algorithm has roundoff issues and about 5% of the time differs from the old algorithm. Perhaps this is acceptable for large exponents.  Comment By: Clarphimous (clarphimous) Date: 20091208 02:22 Message: Okay, I don't know exactly how you'd implement it, as I'm not very knowledgeable about base conversion algorithms (although I do know a little). However, I can tell you that the Sage CAS performs the exact same conversion without taking nearly as long for really large numbers. (On the other hand, the default Sage interface seems to only accept floatingpoint numbers up to around 323,000,000 digits before marking them as "infinity.") First, a 1000 digit bfloat in Maxima: set_display('ascii)$ fpprec:35; x:3.4000000000000000000000000000000001b1000; fpprec:1001; (x+1)1; result: http://www.disillusionary.com/files/maxima_big_a.png Next, the same calculation in Sage. x = 3.4000000000000000000000000000000001e1000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_a.png Apparently with this calculation the same number of bits of precision are used. For the next one, though, I had to pad Sage's input with an extra zero to get the same result. In Maxima: fpprec:35; x:3.4000000000000000000000000000000001b5000000; fpprec:1001; x+1b4999000; result: http://www.disillusionary.com/files/maxima_big_b.png And now for Sage x = 3.40000000000000000000000000000000010e5000000 x parent(x) y = ZZ(x) parent(y) y result: http://www.disillusionary.com/files/sage_big_b.png Here is where the results in speed and memory usage come into play. Sage doesn't take any longer than it usually does to store the value of x. So... the point is that there is a way, but I do not know how to do it, myself. I was thinking maybe you could use the same process you use to output the decimal value of the bfloat each time it's displayed... but I don't know if it works both ways.  Comment By: Raymond Toy (rtoy) Date: 20091207 14:48 Message: The algorithm for reading bfloats converts the bfloat to an exact rational. Thus 2.53b10 is 253/100*10^10. This is then converted to a bfloat. So 1b1000000 is converted to the exact rational 10^1000000 and converted to a bfloat. This should incur exactly one rounding operation. I think doing it in any other way will incur additional roundoff errors, and we would very much like that the internal representation be as close as possible to the input number. This is also complicated by the fact that bfloats are internally represented using base 2 exponents, not base 10. Marking as pending/wontfix.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2910001&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 14:22:33

Bugs item #2914176, was opened at 20091214 08:54 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914176&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: Conversion of rational to bfloat is inaccurate Initial Comment: The conversion of rationals to bfloats can be inaccurate. In the current code, $bfloat converts a rational to a bfloat by converting the numerator and denominator of a rational to bfloats, and then does a bfloat division. This can entail 3 rounding operations. Here is an example showing the inaccuracy: (%i151) fpprec:5; (%o151) 5 (%i152) (220+1)/(2201); (%o152) 1048577/1048575 (%i153) bfloat(%); (%o153) 1.0b0 (%i154) :lisp $%o153 ((BIGFLOAT SIMP 19) 262144 1) That is, maxima thinks the answer is exactly 1. But (%i154) %o1521; (%o154) 2/1048575 (%i157) is(%o154>= 1/262144/2); (%o157) true That is, the difference between %o152 and 1 is greater than 1/2 unit, so maxima should have rounded the number up to (bigfloat 19) 262145 1).  >Comment By: Raymond Toy (rtoy) Date: 20091214 09:22 Message: Fixed in CVS, float.lisp rev 1.59  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914176&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 13:58:08

Bugs item #2913614, was opened at 20091213 05:40 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: LAPACK: dgesvd is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  >Comment By: Raymond Toy (rtoy) Date: 20091214 08:57 Message: I cannot reproduce this either with cmucl on mac os x. Running this with maxima g and looking at the Lisp error will help a lot in figuring this problem out. The boolean results are documented; it means the left and right singular vectors were not requested. Perhaps that should be changed, but that's a different issue.  Comment By: Dieter Kaiser (crategus) Date: 20091213 12:39 Message: On my system I get: (%i2) build_info(); Maxima version: 5.20post Maxima build date: 17:36 12/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3469710995) (%o2) (%i3) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i4) dgesvd(A); (%o4) [[3.755933922081446, 1.830035687063915, .7142611635301948, 0.127875116930834], false, false] I do not get a Lisp error. But the result contains boolean values. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 13:55:55

Bugs item #2914176, was opened at 20091214 08:54 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914176&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: Conversion of rational to bfloat is inaccurate Initial Comment: The conversion of rationals to bfloats can be inaccurate. In the current code, $bfloat converts a rational to a bfloat by converting the numerator and denominator of a rational to bfloats, and then does a bfloat division. This can entail 3 rounding operations. Here is an example showing the inaccuracy: (%i151) fpprec:5; (%o151) 5 (%i152) (220+1)/(2201); (%o152) 1048577/1048575 (%i153) bfloat(%); (%o153) 1.0b0 (%i154) :lisp $%o153 ((BIGFLOAT SIMP 19) 262144 1) That is, maxima thinks the answer is exactly 1. But (%i154) %o1521; (%o154) 2/1048575 (%i157) is(%o154>= 1/262144/2); (%o157) true That is, the difference between %o152 and 1 is greater than 1/2 unit, so maxima should have rounded the number up to (bigfloat 19) 262145 1).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2914176&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 04:57:13

Bugs item #2909980, was opened at 20091207 07:26 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2909980&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Clarphimous (clarphimous) Assigned to: Nobody/Anonymous (nobody) Summary: optimization for log of bfloats Initial Comment: bfloats can store very large and very small numbers, and I found out that the log() function takes a long time for very large and very small bfloats. I do not know their binary representations, but it may be possible to decrease the time needed by logarithmic simplification. I have found that in general, when fpprec is 3/2 or greater than the absolute value of the exponent (in decimal), it is faster to use this simplification. That's a broad estimation, though. With negative exponents, the ratio is slightly higher. Also, it may turn out completely different when coded. I did not have the same improved results with regular floats, so this simplification may already be implemented with them. First, an extreme example: fpprec:50; fun1():=log(3b1000000); fun2():=1000000*log(10b0)+log(3b0); fun3():=log(3b1000000); fun4():=1000000*log(10b0)+log(3b0); timer(fun1,fun2,fun3,fun4); fun1(); fun2(); fun3(); fun4(); timer_info(fun1,fun2,fun3,fun4); http://www.disillusionary.com/files/log1.png Next, a more reasonable example: fpprec:150; fun5():=for i:0 step 1 thru 1000 do x:log(7b100); fun6():=for i:0 step 1 thru 1000 do y:100*log(10b0)+log(7b0); timer(fun5,fun6); fun5(); x; fun6(); y; timer_info(fun5,fun6); http://www.disillusionary.com/files/log2.png  >Comment By: Raymond Toy (rtoy) Date: 20091213 23:57 Message: Fixed in float.lisp, rev 1.58. Two tests fail because the results are not as accurate as expected. Closing bug.  Comment By: Raymond Toy (rtoy) Date: 20091207 21:45 Message: I have implemented this change. Some examples, using cmucl on a mac mini: x:2b1000000; y:2b1000000; fpprec:50; (%i4) log(x); Evaluation took 21.6700 seconds (23.2400 elapsed) using 2360.417 MB. (%o4) 2.3025857861412262439632949548375584044564573860171b6 (%i6) log(y); Evaluation took 27.3200 seconds (33.3400 elapsed) using 3021.686 MB. (%o6)  2.3025843998468651240726820374522427494245334131286b6 With the new code: (%i7) log(x); Evaluation took 0.0100 seconds (0.0000 elapsed) using 137.609 KB. (%o7) 2.3025857861412262439632949548375584044564573860171b6 (%i8) log(y); Evaluation took 0.0000 seconds (0.0000 elapsed) using 34.883 KB. (%o8)  2.3025843998468651240726820374522427494245334131287b6 I will check in this change soon.  Comment By: Raymond Toy (rtoy) Date: 20091207 14:34 Message: You are correct. Maxima represents bfloats as, essentially, frac * 2^exp, where 1/2 < frac <= 1. The log routine does not take advantage of this fact. Instead, the algorithm removes powers of e until the result is small and computes the log of that. Instead we should just compute log(f) and use a cached value of log(2). I'll try to fix this. Using this fact should also help quite a bit in accuracy too.  Comment By: Clarphimous (clarphimous) Date: 20091207 07:39 Message: correction: "when the absolute value of the exponent (in decimal) is greater than 2/3rds of fpprec"  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2909980&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 04:39:10

Bugs item #2913967, was opened at 20091214 04:39 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913967&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: Tests Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: windows, 5.20.0, rtestum 151 and 154 fail Initial Comment: Windows 7, running tests gives 2 failures, same error when running that test alone Running tests in rtestsum: ********************** Problem 151 *************** Input: product(%pi  3, i, minf, inf) Result: 1 + inf + inf (%pi  3) This differed from the expected result: 0 ********************** Problem 154 *************** Input: product( %pi, i, minf, inf) Result: 1 + inf + inf 2 inf + 1 %pi ( 1) This differed from the expected result: infinity  Error summary: Errors found in D:/Cristian/Maxima5.20.0/share/maxima/5.20.0/tests/rtestsum.mac, problems: (151 154) real time : 325.470 secs rungbc time : 306.780 secs child run time : 0.000 secs gbc time : 18.690 secs (%i1) Maxima version: 5.20.0 Maxima build date: 22:10 12/8/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Kind regards, Cristian.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913967&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 02:20:20

Bugs item #2299224, was opened at 20081116 15:47 Message generated for change (Comment added) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2299224&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: Includes proposed fix >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: unsimplified result from rectform Initial Comment: (%i1) logarc : true; (%o1) true (%i2) rectform(log(x + %i * y)); (%o2) log(y^2+x^2)/2+%i*atan2(y,x) (%i3) expand(%,0,0); (%o3) log(y^2+x^2)/2+(log((%i*y)/x+1)log(1(%i*y)/x))/2 Also (%o3) is wrong for x = 0 and in the left half plane.  >Comment By: SourceForge Robot (sfrobot) Date: 20091214 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: 20091130 00:05 Message: As discussed on the mailing list, rectform sets the option variable logarc to NIL to preserve the standard form x+%i*y for its result. With Maxima 5.19post we get: (%i4) rectform(log(x+%i*y)); (%o4) log(y^2+x^2)/2+%i*atan2(y,x) logarc gives the following result, which no longer has the standard form of rectform: (%i5) logarc(%); (%o5) log((%i*y+x)/sqrt(y^2+x^2))+log(y^2+x^2)/2 I think we can close this bug report. The first issue has gone. The result of rectform is correct. The second issue is the expected behavior. rectform returns a standard form, which might simplify further, when the user sets the option variable logarc to TRUE. Setting the status to pending and the resolution to "works for me". Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20090508 20:45 Message: The expression does not simplify as expected because the global flag $logarc is set to nil in the routine risplit. It is possible to remove this from the routine risplit. Then we would get: (%i11) rectform(log(x+%i*y)),logarc; (%o11) log((%i*y+x)/sqrt(y^2+x^2))+log(y^2+x^2)/2 Because of revision 1.25 the result of the simplification is now correct. I have checked this with the testsuite and the share_testsuite. There are no examples which depend on the setting of $logargs in the routine risplit. Should we change the routine risplit and remove the setting of the flag $logarg? Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2299224&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 00:59:06

Bugs item #2875784, was opened at 20091009 11:38 Message generated for change (Comment added) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2875784&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: Fixed Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: fourier integral incorrect Initial Comment: The following is incorrect: (%i2) I : 'integrate(%e^(%i*x)*sin(x)/x,x,minf,inf); (%o2) 'integrate(%e^(%i*x)*sin(x)/x,x,minf,inf) (%i3) J : changevar(I,y+x,y,x); (%o3) 'integrate(%e^(%i*y)*sin(y)/y,y,minf,inf) (%i4) ev(I,nouns); (%o4) %pi (%i5) ev(J,nouns); (%o5) 0  >Comment By: Dan Gildea (dgildea) Date: 20091213 19:59 Message: Fixed in defint.lisp rev 1.68. (%i15) integrate(%e^(%i*x)*sin(x)/x,x,minf,inf); Principal Value (%o15) %pi/2 (%i16) integrate(%e^(%i*x)*sin(x)/x,x,minf,inf); Principal Value (%o16) %pi/2 (%i17) integrate(cos(x)*sin(x)/x,x,minf,inf); (%o17) %pi/2  Comment By: Dan Gildea (dgildea) Date: 20091207 08:48 Message: The problem seems to be in mtosc, which corresponds to page 77 of Paul Wang's thesis: http://publications.csail.mit.edu/lcs/pubs/pdf/MITLCSTR092.pdf This routine handles integrals of the form exp(%i*m*x)*r(x) where r(x) is rational. The thesis indicates that r(x) should have no real poles. Most integrands with real poles are caught by polesininterval before being dispatched to mtosc. However, polesininterval does not consider sin(x)/x to have any poles. I think mtosc is finding the wrong answer because 1/x does have a pole at zero. I tried adding a test for this case to mtosc: ((and (or (setq plf (polfactors n)) t) + (eq (realroots d var) '$no) ; fail if rational part has poles Now we get noun forms for the following integrals: (%i2) integrate(%e^(%i*x)*sin(x)/x,x,minf,inf); (%o2) 'integrate(%e^(%i*x)*sin(x)/x,x,minf,inf) (%i3) integrate(%e^(%i*x)*sin(x)/x,x,minf,inf); (%o3) 'integrate(%e^(%i*x)*sin(x)/x,x,minf,inf) %pi/2 would be better, but at least these aren't wrong. However, now we get the wrong answer for: (%i4) integrate(cos(x)*sin(x)/x,x,minf,inf); (%o4) 0 Where previously mtosc gave the correct answer, now mtosc gives up, and intsubs seems to give a wrong answer because it misses discontinuities in gamma_incomplete.  Comment By: Leo Butler (l_butler) Date: 20091009 12:13 Message: I should add that there are two problems above: first, I and J should be equal; second, the correct answer should be (%i19) integrate(cos(x)*sin(x)/x,x,minf,inf); (%o19) %pi/2  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2875784&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 00:44:23

Bugs item #893633, was opened at 20040209 20:38 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893633&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: depends(a,[b,b,b]) Initial Comment: depends(a,[b,b,b]); diff(a,b) => 3 * (da/db) NO! The correct result is (da/db). The original depends should either have given an error, or been synonymous with depends(a,b,a,b,a,b) which is synonymous with ( depends(a,b), depends(a,b), depends (a,b) ). Originally reported by Dan Stanger on Maxima list (02/09/2004 07:02 AM)  >Comment By: Dieter Kaiser (crategus) Date: 20091214 01:44 Message: The implementation of the function i$dependencies has been reworked:  Check that all arguments are symbols  Do not add duplicates to the list of dependencies  Overwrite existing dependencies with new dependencies We get: (%i1) depends(a,[b,b,b]); (%o1) [a(b)] (%i2) diff(a,b); (%o2) 'diff(a,b,1) (%i3) depends(f,x*y); depends: argument must be a symbol; found x*y  an error. To debug this try: debugmode(true); Closing this bug report as fixed. Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20040212 18:54 Message: Logged In: YES user_id=895922 Depends should check for some other things too: (C1) depends(f,x*y); (D1) [f(x y)] (C2) depends(f,x); (D2) [f(x)] (C3) diff(f,x); Error: Frame stack overflow. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by OR. Broken at DEPENDS. Type :H for Help. MAXIMA>> I think the second argument to depends should be required to be a symbol. For anything more complex than a symbol, I'd suggest a user try pdiff. The same holds for gradef: (C4) gradef(f, x < y, g); (D4) f (C5) diff(f,x); (D5) g*'DIFF(x < y,x,1) Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893633&group_id=4933 
From: SourceForge.net <noreply@so...>  20091214 00:29:08

Bugs item #776441, was opened at 20030723 14:25 Message generated for change (Settings changed) made by dgildea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core Group: None >Status: Pending >Resolution: Fixed Priority: 7 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: orderlessp not transitive Initial Comment: l: [z+x*(x+2)+v+1,z+x^2+x+v+1,z+(x+1)^2+v]; orderlessp(l[1],l[2]) => True orderlessp(l[2],l[3]) => True orderlessp(l[1],l[3]) => False !!! More concise example: q: x^2; r: (x+1)^2; s: x*(x+2); orderlessp(q,r) => true orderlessp(r,s) => true orderlessp(s,q) => true That is, s<q<r<s. The problem is somewhere in the internal great function, which by the way does some strange things, in particular: why does ordlist have an explicit check for mplus: (RETURN (COND ((= L2 0) (EQ CX 'MPLUS)) (Thanks to Barton for his contributions to tracking this down.) Maxima 5.9.0 GCL 2.5.0  >Comment By: Dan Gildea (dgildea) Date: 20091213 19:29 Message: I think these issues are resolved in simp.lisp rev 1.93.  Comment By: Robert Dodier (robert_dodier) Date: 20060708 13:13 Message: Logged In: YES user_id=501686 Increasing the priority on this one  potential for subtle breakage in various contexts.  Comment By: Wolfgang Jenkner (wjenkner) Date: 20030808 19:50 Message: Logged In: YES user_id=581700 This one doesn't even involve MEXPT (I found it while checking one of the cases needed for proving that ORDLIST implements a consistent way of extending a given total order on a set of simplified expressions to their simplified sums and products. So it doesn't...) (C1) orderlessp(t/2,t); (D1) TRUE (C2) orderlessp(t,t+1/4); (D2) TRUE (C3) orderlessp(t/2,t+1/4); (D3) FALSE The point is that t/2 is ((MTIMES SIMP) ((RAT SIMP) 1 2) $t) and, lexicographically, we have (t, 1/2) < (t, 1), (t, 0) < (t, 1/4) and (t, 1/2, *) > (t, 1/4, +). So t corresponds to (t, 1) in the first comparison and to (t, 0) in the second comparison. Trouble. Floats instead of rational numbers give the same results, by the way. This one is more like Stavros's examples. (C1) orderlessp((x+1)^2,x^21); (D1) TRUE (C2) orderlessp(x^21,x^2); (D2) TRUE (C3) orderlessp((x+1)^2,x^2); (D3) FALSE Maybe powers whose exponents are positive integers should be treated like products. Actually, ORDMEXPT does this already but it isn't always called by ORDFN, for whatever reason. Anyway, here is the patch I'm currently experimenting with (it solves all the issues reported by Stavros and also the last example above, but in light of the other example it is certainly far from being a complete solution. It might even be totally wrong since I have no reason to believe that it is more than a simple palliative and that it would make things more consistent). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Index: simp.lisp =================================================================== RCS file: /cvsroot/maxima/maxima/src/simp.lisp,v retrieving revision 1.5 diff C2 r1.5 simp.lisp *** simp.lisp 5 Mar 2003 01:36:26 0000 1.5  simp.lisp 8 Aug 2003 19:10:57 0000 *************** *** 1848,1854 **** ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT) (MPLUSP (CADR Y))) (NOT (ORDMEXPT Y X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X)))  1848,1854  ((MEMQ CX '(MPLUS MTIMES)) (COND ((MEMQ CY '(MPLUS MTIMES)) (ORDLIST (CDR X) (CDR Y) CX CY)) ! ((AND (EQ CX 'MPLUS) (EQ CY 'MEXPT)) (NOT (ORDMEXPT Y X))) + ((ALIKE1 (SETQ U (CAR (LAST X))) Y) (NOT (ORDHACK X))) (T (GREAT U Y)))) ((MEMQ CY '(MPLUS MTIMES)) (NOT (ORDFN Y X))) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cut ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  Comment By: Stavros Macrakis (macrakis) Date: 20030805 00:35 Message: Logged In: YES user_id=588346 More amusing consequences: q+r+s => (x+1)^2+x^2+x*(x+2) expand(%,0,0) => x^2+x*(x+2)+(x+1)^2 expand(%,0,0) => x*(x+2)+(x+1)^2+x^2 expand(%,0,0) => (x+1)^2+x^2+x*(x+2) q+r+srqs => (x+1)^2+x^2+x*(x+2)(x+1)^2x^2x* (x+2) expand(%,0,0) => x^2x^2 expand(%,0,0) => 0 I haven't found an example where simptimes fails, though. Fateman reports that this bug is also found in commercial Macsyma 2.4, and calls it a Methuselah bug because it has persisted for so long  presumably it has been around for 30+ years.  Comment By: Stavros Macrakis (macrakis) Date: 20030725 10:26 Message: Logged In: YES user_id=588346 This not only screws up SORT etc., but even basic simplification, since simplus, simptimes, etc. depend on great: q+r+s => (x+1)^2+x^2+x*(x+2) q+s+r => x^2+x*(x+2)+(x+1)^2 (q+s+r)(q+s+r) => x^2x^2 (q+s+r)(s+q+r) => x^2x^2 (q+r+s)(q+s+r) => x (x + 2)  x (x + 2)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=776441&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 22:52:13

Bugs item #593351, was opened at 20020810 04:48 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593351&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Limit Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit/sin(inf)etc. should give 0, not IND Initial Comment: limit(cos(1/x)*sin(x)sin(x),x,inf) should give 0, not IND.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 23:52 Message: Fixed in limit.lisp revision 1.88. Closing this bug report as fixed. Dieter Kaiser  Comment By: Rupert Swarbrick (rswarbrick) Date: 20090215 19:00 Message: This happens for limit ( (cos(1/x)1) * sin(x), x, inf) because $limit is somehow refactoring before it gets around to calling limit. Tracing shows: (LIMIT ((MPLUS SIMP) ((MTIMES SIMP) 1 ((%SIN SIMP) $X)) ((MTIMES SIMP) ((%COS SIMP) ((MEXPT SIMP) $X 1)) ((%SIN SIMP) $X))) $X $INF THINK) which then gets evaluated for each term in the plus, giving $ind  $ind = $ind. The following call works: (let ((lhp?)) (declare (special lhp?)) (limit #$(cos(1/x)1) * sin(x)$ '$X '$INF 'THINK)) giving '$zerob. I'm not sure if there's a canonical way to expand the right things in general though. Rupert  Comment By: Stavros Macrakis (macrakis) Date: 20020919 05:55 Message: Logged In: YES user_id=588346 Strangely enough, limit even gets this wrong if you feed it the factored form: limit ( (cos(1/x)1) * sin(x), x, inf) even though it correctly gets limit(cos(1/x)1,x,inf) => 0 and limit(sin(x),x,inf) => ind and 0*ind is always 0. On the other hand, it does get it right if you factor the exponentialized form: limit(factor(ev(...,exponentialize)),x,inf) => 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=593351&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 21:54:23

Bugs item #2911891, was opened at 20091210 10:28 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gcfac gives Lisp error Initial Comment: a : diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); load (scifac)$ gcfac(a); Maxima encountered a Lisp error: Error in AND [or a callee]: The function $MIN is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 22:54 Message: Corrected in scifac.lisp revision 1.5. Closing this bug report as fixed. Dieter Kaiser  Comment By: Dieter Kaiser (crategus) Date: 20091213 19:16 Message: This example is a bit strange. The result should be sin(sqrt(x)), but we get: (%i6) diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); (%o6) 2*(2*(2*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))) sin(sqrt(x))/(4*x)cos(sqrt(x))/(4*x^(3/2))) 2*(2*(sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(3/2)) +3*cos(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^2) 3*sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(5/2)) cos(sqrt(x))*(3*x8)/(8*x^(3/2))+3*sin(sqrt(x))*(3*x8)/(8*x^2) +3*cos(sqrt(x))*(3*x8)/(8*x^(5/2)) 3*sin(sqrt(x))*(3/(4*sqrt(x))2/x^(3/2))/(2*sqrt(x)) 3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x) 9*sin(sqrt(x))/(4*x) +3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x^(3/2)) 9*cos(sqrt(x))/(4*x^(3/2)) +cos(sqrt(x))*(3/(8*x^(3/2))+3/x^(5/2))) +4*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))))) We have a small bug in scifac.lisp. It is easy to correct it: (%i7) gcfac(%); (%o7) 4*(2*((3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)*x/4 +cos(sqrt(x))*(315*x/8)) /x^(5/2) +((3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/49*sin(sqrt(x))/4)*x 3*sin(sqrt(x))*(3*x/42)/2) /x^2 +(3*(sin(sqrt(x))/x^2+cos(sqrt(x))/x^(5/2))/8 cos(sqrt(x))/(8*x^(3/2))) *(3*x8) +(sin(sqrt(x))/(8*x)+3*cos(sqrt(x))/(8*x^(3/2)) 3*sin(sqrt(x))/(8*x^2)) *(8x) +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) +(sin(sqrt(x))/x+cos(sqrt(x))/x^(3/2))/4 +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) Of course ratsimp simplifies the expression immediately to the expected simple answer: (%i8) ratsimp(%); (%o8) sin(sqrt(x)) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 21:11:13

Bugs item #767556, was opened at 20030708 07:00 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767556&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 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Distributing operations over = Initial Comment: x * (a=b) => x*a = x*b x + (a=b) => x+a = x+b (a=b)^2 => a^2 = b^2 so why do we have x . (a=b) => x . (a=b) (??) rather than x . a = x . b (a=b)^^2 => (a=b)^^2 (??) etc. I do understand why we have f(a=b) => f(a=b) rather than f(a)=f(b) ... because in general f may be an operation on equations. Some operations nonetheless do distribute over "=", notably diff, taylor, limit, cabs, rectform, realpart, imagpart, etc. integrate is particularly clever, adding an integration constant though mathematical functions such as sin, log, etc. do not.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 22:11 Message: The distribution over an equation has been implemented in mdot.lisp revision 1.9 for the operators "." and "^^". Closing this bug report as fixed. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=767556&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 19:28:35

Bugs item #2913752, was opened at 20091213 17:13 Message generated for change (Comment added) made by maxim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&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  Plotting Group: None Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(a[x], [x,0,5]); STACK OVERFLOW Initial Comment: Tested on Maxima 5.18.1, Maxima 5.19.2 (with clisp 2.47 and 2.48), Maxima 5.20.0 (with clisp 2.47 and 2.48) on Gentoo Linux amd64. The same error occurs each time I try the following:  Maxima 5.20.0 http://maxima.sourceforge.net using Lisp CLISP 2.47 (20081023) 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) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a := 2 a  1 n n  1 (%i3) plot2d(a[x], [x,0,5]); ***  Program stack overflow. RESET [../src/eval.d:573] reset() found no driver frame (sp=0xb9d812100xb9d7ae40) Exiting on signal 6 Aborted  I know that you shouldn't try graphing discrete values like that but this is still a serious bug because it causes Maxima to crash and you lose all your session!. I noticed that the same bug was reported previously (http://sourceforge.net/tracker/index.php?func=detail&aid=1533584&group_id=4933&atid=104933) and closed but it's still here.  Comment By: m_a_xim (maxim) Date: 20091213 20:28 Message: I still find it very frustrating to lose a whole session (defined variables and functions) because of this. A program that ends with a stack overflow or segmentation fault  whatever the circumstances  has got a bug. I think most programmers would agree that user input should never be trusted and that errors in this input should be dealt with by gracefully telling the user that he made an error and giving him back control. It doesn't seem to me as though implementing a simple check to see if a function is defined for a certain value would be so difficult. Do you think it is acceptable if a TI (or Casio or whatever) calculator crashes losing all your session because you made a slight mistake in your input? And why would it be more acceptable for Maxima?  Comment By: Dieter Kaiser (crategus) Date: 20091213 18:32 Message: The reported problem is not a problem of the plot function. The recursively defined function can not handle floating point numbers which are needed for the plot function.: (%i1) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a[n]:=2*a[n1]1 We try to evaluate the function for a floating point number, but this is not possible. The algorithm of the function loops endlessly: (%i3) a[0.5]; ***  Program stack overflow. RESET [/build/buildd/clisp2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xbfd464a00xbfd407b0) Exiting on signal 6 Aborted The user defined function has to be improved to handle floating point numbers to allow a plot. I think it is by the user to transfer a valid function definition to the plot routine. This problem is not related to the closed bug ID: 1533584. This bug seems to be no longer present. Setting the status to pending and the resolution to "wont fix". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 18:16:15

Bugs item #2911891, was opened at 20091210 10:28 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&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 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: gcfac gives Lisp error Initial Comment: a : diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); load (scifac)$ gcfac(a); Maxima encountered a Lisp error: Error in AND [or a callee]: The function $MIN is undefined. Automatically continuing. To reenable the Lisp debugger set *debuggerhook* to nil.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 19:16 Message: This example is a bit strange. The result should be sin(sqrt(x)), but we get: (%i6) diff(diff(diff(integrate(integrate(integrate(sin(sqrt(x)),x),x),x),x),x),x); (%o6) 2*(2*(2*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))) sin(sqrt(x))/(4*x)cos(sqrt(x))/(4*x^(3/2))) 2*(2*(sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(3/2)) +3*cos(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^2) 3*sin(sqrt(x))*(8*sqrt(x)x^(3/2))/(8*x^(5/2)) cos(sqrt(x))*(3*x8)/(8*x^(3/2))+3*sin(sqrt(x))*(3*x8)/(8*x^2) +3*cos(sqrt(x))*(3*x8)/(8*x^(5/2)) 3*sin(sqrt(x))*(3/(4*sqrt(x))2/x^(3/2))/(2*sqrt(x)) 3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x) 9*sin(sqrt(x))/(4*x) +3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/(4*x^(3/2)) 9*cos(sqrt(x))/(4*x^(3/2)) +cos(sqrt(x))*(3/(8*x^(3/2))+3/x^(5/2))) +4*(sin(sqrt(x))/(2*x)cos(sqrt(x))*(x2)/(8*x^(3/2)) 3*cos(sqrt(x))/(4*x^(3/2)) +3*sin(sqrt(x))*(x2)/(8*x^2) +3*sin(sqrt(x))/(4*x^2) +3*cos(sqrt(x))*(x2)/(8*x^(5/2)) +3*cos(sqrt(x))/(4*x^(5/2))))) We have a small bug in scifac.lisp. It is easy to correct it: (%i7) gcfac(%); (%o7) 4*(2*((3*sin(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)*x/4 +cos(sqrt(x))*(315*x/8)) /x^(5/2) +((3*cos(sqrt(x))*(4/sqrt(x)3*sqrt(x)/2)/49*sin(sqrt(x))/4)*x 3*sin(sqrt(x))*(3*x/42)/2) /x^2 +(3*(sin(sqrt(x))/x^2+cos(sqrt(x))/x^(5/2))/8 cos(sqrt(x))/(8*x^(3/2))) *(3*x8) +(sin(sqrt(x))/(8*x)+3*cos(sqrt(x))/(8*x^(3/2)) 3*sin(sqrt(x))/(8*x^2)) *(8x) +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) +(sin(sqrt(x))/x+cos(sqrt(x))/x^(3/2))/4 +2*(sin(sqrt(x))/(2*x)+cos(sqrt(x))*((x2)/83/4)/x^(3/2) +sin(sqrt(x))*(3*(x2)/8+3/4)/x^2 +cos(sqrt(x))*(3*(x2)/8+3/4)/x^(5/2))) Of course ratsimp simplifies the expression immediately to the expected simple answer: (%i8) ratsimp(%); (%o8) sin(sqrt(x)) Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2911891&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 17:50:12

Bugs item #2912391, was opened at 20091211 03:01 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Rudolf Vyborny (ynrobyvr) Assigned to: Nobody/Anonymous (nobody) Summary: wrong result Initial Comment: Calculating the limit of x+sqrt(1+x^2) as x goes to  infinity gives the wrong result inf instead of correct answer 0  >Comment By: Dieter Kaiser (crategus) Date: 20091213 18:50 Message: I am not sure about the notation of infinities which is used in this bug report. Maxima knows inf, minf, and infinity. infinity represents the complex infinity, inf and minf the real infinities.Furthermore, we have minf = inf. With these notations I get: (%i11) limit(x+sqrt(1+x^2),x,inf); (%o11) inf (%i12) limit(x+sqrt(1+x^2),x,inf); (%o12) 0 (%i13) limit(x+sqrt(1+x^2),x,minf); (%o13) 0 (%i14) limit(x+sqrt(1+x^2),x,infinity); (%o14) infinity I think all results from above are correct. Setting this bug report to pending and the status to "works for me". Dieter Kaiser  Comment By: Martin (mhs) Date: 20091211 10:05 Message: I cannot reproduce this on  Maxima version: 5.19.2 Maxima build date: 8:55 8/31/2009 host type: i686pcmingw32 lispimplementationtype: GNU Common Lisp (GCL) lispimplementationversion: GCL 2.6.8  (%i1) expr: x+sqrt(1+x^2); (%o1) sqrt(x^2+1)+x (%i2) limit(expr, x, inf); (%o2) 0 (%i3) limit(expr, x, minf); (%o3) 0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2912391&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 17:39:49

Bugs item #2913614, was opened at 20091213 11:40 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: LAPACK: dgesvd is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  >Comment By: Dieter Kaiser (crategus) Date: 20091213 18:39 Message: On my system I get: (%i2) build_info(); Maxima version: 5.20post Maxima build date: 17:36 12/13/2009 Host type: i686pclinuxgnu Lisp implementation type: CLISP Lisp implementation version: 2.44.1 (20080223) (built 3436700604) (memory 3469710995) (%o2) (%i3) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i4) dgesvd(A); (%o4) [[3.755933922081446, 1.830035687063915, .7142611635301948, 0.127875116930834], false, false] I do not get a Lisp error. But the result contains boolean values. Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 17:32:49

Bugs item #2913752, was opened at 20091213 17:13 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&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  Plotting Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(a[x], [x,0,5]); STACK OVERFLOW Initial Comment: Tested on Maxima 5.18.1, Maxima 5.19.2 (with clisp 2.47 and 2.48), Maxima 5.20.0 (with clisp 2.47 and 2.48) on Gentoo Linux amd64. The same error occurs each time I try the following:  Maxima 5.20.0 http://maxima.sourceforge.net using Lisp CLISP 2.47 (20081023) 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) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a := 2 a  1 n n  1 (%i3) plot2d(a[x], [x,0,5]); ***  Program stack overflow. RESET [../src/eval.d:573] reset() found no driver frame (sp=0xb9d812100xb9d7ae40) Exiting on signal 6 Aborted  I know that you shouldn't try graphing discrete values like that but this is still a serious bug because it causes Maxima to crash and you lose all your session!. I noticed that the same bug was reported previously (http://sourceforge.net/tracker/index.php?func=detail&aid=1533584&group_id=4933&atid=104933) and closed but it's still here.  >Comment By: Dieter Kaiser (crategus) Date: 20091213 18:32 Message: The reported problem is not a problem of the plot function. The recursively defined function can not handle floating point numbers which are needed for the plot function.: (%i1) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a[n]:=2*a[n1]1 We try to evaluate the function for a floating point number, but this is not possible. The algorithm of the function loops endlessly: (%i3) a[0.5]; ***  Program stack overflow. RESET [/build/buildd/clisp2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xbfd464a00xbfd407b0) Exiting on signal 6 Aborted The user defined function has to be improved to handle floating point numbers to allow a plot. I think it is by the user to transfer a valid function definition to the plot routine. This problem is not related to the closed bug ID: 1533584. This bug seems to be no longer present. Setting the status to pending and the resolution to "wont fix". Dieter Kaiser  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 16:13:50

Bugs item #2913752, was opened at 20091213 16:13 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&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  Plotting Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(a[x], [x,0,5]); STACK OVERFLOW Initial Comment: Tested on Maxima 5.18.1, Maxima 5.19.2 (with clisp 2.47 and 2.48), Maxima 5.20.0 (with clisp 2.47 and 2.48) on Gentoo Linux amd64. The same error occurs each time I try the following:  Maxima 5.20.0 http://maxima.sourceforge.net using Lisp CLISP 2.47 (20081023) 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) a[0] : 3; a[n] := 2*a[n1] 1; (%o1) 3 (%o2) a := 2 a  1 n n  1 (%i3) plot2d(a[x], [x,0,5]); ***  Program stack overflow. RESET [../src/eval.d:573] reset() found no driver frame (sp=0xb9d812100xb9d7ae40) Exiting on signal 6 Aborted  I know that you shouldn't try graphing discrete values like that but this is still a serious bug because it causes Maxima to crash and you lose all your session!. I noticed that the same bug was reported previously (http://sourceforge.net/tracker/index.php?func=detail&aid=1533584&group_id=4933&atid=104933) and closed but it's still here.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913752&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 10:42:35

Bugs item #2913610, was opened at 20091213 11:23 Message generated for change (Comment added) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913610&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  Plotting Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: plot error Initial Comment: build_info()$ Maxima version: 5.20.0 Maxima build date: 22:10 12/8/2009 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 wxplot2d([sin(x)], [x,5,5])$ Error C:/Users/.../maxout_1.png  >Comment By: Andrej Vodopivec (andrejv) Date: 20091213 11:42 Message: This has been fixed in cvs and will work in the final 5.20 release.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913610&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 10:41:02

Bugs item #2913614, was opened at 20091213 11:40 Message generated for change (Settings changed) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) >Summary: LAPACK: dgesvd is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 
From: SourceForge.net <noreply@so...>  20091213 10:40:42

Bugs item #2913614, was opened at 20091213 11:40 Message generated for change (Tracker Item Submitted) made by andrejv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&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: Andrej Vodopivec (andrejv) Assigned to: Nobody/Anonymous (nobody) Summary: LAPACK: dgesvn is broken Initial Comment: (%i4) A:genmatrix(lambda([i,j], random(2.0)), 4, 4)$ (%i5) dgesvd(A); Maxima encountered a Lisp error: Error during processing of eval option "(cluser::run)": The value "G" is not of type (SIMPLEARRAY DOUBLEFLOAT (*)). Automatically continuing. To enable the Lisp debugger set *debuggerhook* to nil. (%i6) build_info(); Maxima version: 5.20post Maxima build date: 8:37 12/12/2009 Host type: i386appledarwin9.8.0 Lisp implementation type: SBCL Lisp implementation version: 1.0.19  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2913614&group_id=4933 