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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(1) 
2
(1) 
3
(10) 
4

5

6
(3) 
7
(2) 
8
(3) 
9
(1) 
10

11
(4) 
12
(3) 
13

14
(2) 
15
(1) 
16

17
(2) 
18

19

20
(1) 
21

22

23
(1) 
24
(2) 
25
(3) 
26

27

28

29
(1) 
30
(1) 



From: SourceForge.net <noreply@so...>  20030403 23:56:32

Bugs item #714966, was opened at 20030403 19:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714966&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: part/nformat loses simp flags: part(factor(12),1) Initial Comment: part(factor(12),1) yields 4, not 2^2. This is because part (as opposed to inpart) calls nformat, and nformat drops simp flags. This is actually not trivial to fix in general, since nformat does create unsimplified expressions (involving quotient) which need to be resimplified. There are two solutions I can think of: 1) Instead of using nformat in part, do the reformatting on the fly, only creating new unsimplified list structure where necessary (e.g. part(x*y/z,1)). This is bad because it means that the logic of nformat would exist in two different versions, which would have to be kept in synch. 2) Have nformat preserve simp flags to the largest extent possible. This might appear inconsistent in some cases, although I don't think there are any such cases in current Maxima. I vote for (2). s  >Comment By: Stavros Macrakis (macrakis) Date: 20030403 19:11 Message: Logged In: YES user_id=588346 This also affects other functions that use nformat, such as args, so that args(factor(12)) returns [4,3], not [2^2,3]. Also map. So the only way to extract the exponents of a numbered factor appears to be to use inpart to get directly to the exponent. It is also incorrect that factor doesn't put a factored flag on the individual mexpt's. (reported separately)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714966&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 23:49:34

Bugs item #714966, was opened at 20030403 19:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714966&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: part/nformat loses simp flags: part(factor(12),1) Initial Comment: part(factor(12),1) yields 4, not 2^2. This is because part (as opposed to inpart) calls nformat, and nformat drops simp flags. This is actually not trivial to fix in general, since nformat does create unsimplified expressions (involving quotient) which need to be resimplified. There are two solutions I can think of: 1) Instead of using nformat in part, do the reformatting on the fly, only creating new unsimplified list structure where necessary (e.g. part(x*y/z,1)). This is bad because it means that the logic of nformat would exist in two different versions, which would have to be kept in synch. 2) Have nformat preserve simp flags to the largest extent possible. This might appear inconsistent in some cases, although I don't think there are any such cases in current Maxima. I vote for (2). s  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714966&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 18:10:53

Bugs item #701677, was opened at 20030311 12:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701677&group_id=4933 >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) >Assigned to: Raymond Toy (rtoy) Summary: plot2d evaluates outside range Initial Comment: plot2d evaluates the function being plotted outside the given range. Try: f(x):= if (x>1) then 0 else x^2$ plot2d(f,[x,0,1]) The plot shows the function dropping to 0 at x=1+eps. This is bad for three reasons: 1) I explicitly asked for the range [0,1]. I do not want to see the behavior for x>1. 2) I don't want the yrange to be distorted by an outlier at x=1+eps. 3) the function may not be welldefined, and may cause errors, outside the range I gave. (This is how I discovered the issue.) Plot2d also evaluates the function at twice as many values as it uses (to check for smoothness)  I'd think we could do better than that, but maybe not.  >Comment By: Raymond Toy (rtoy) Date: 20030403 13:25 Message: Logged In: YES user_id=28849 I agree. This is very annoying. I think the reason is due to round off and the way extra samples are taken. I have a fix for this so we don't go outside the range, and every computed point is used in the plot instead of throwing away half the points. Needs work. I think we should give up on being smart.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701677&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 18:08:29

Bugs item #694770, was opened at 20030227 19:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=694770&group_id=4933 >Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) >Assigned to: Raymond Toy (rtoy) Summary: plot2d stunningly slow in some simple cases Initial Comment: plot2d(x*1.01,[x,0,1]) is fast (16mS). plot2d(x*1.01e2,[x,0,1]) is surprisingly slower (2683mS) plot2d(x*1.01e4,[x,0,1]) is so slow I didn't bother to wait. What is going on here? This is ridiculous! Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  >Comment By: Raymond Toy (rtoy) Date: 20030403 13:23 Message: Logged In: YES user_id=28849 This is caused by draw2d. It tries to be smart so that if the dy is larger than dx, a smaller step is taken. For the second example, EVERY dy is too large, so we generate many extra samples. The third is even worse because even more samples are computed. I don't know how to fix this. Perhaps if we use the slope and extrapolate a point and the computed point is reasonably close, we don't try extra samples. If it's very far off, we use more samples. However, I think we should just give up being smart. Let the user specify more grid points ore a smaller range.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=694770&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 18:00:22

Bugs item #691941, was opened at 20030223 20:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=691941&group_id=4933 Category: Lisp Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: M. L. Murphy (mlmurphy) Assigned to: Raymond Toy (rtoy) Summary: plot3d fails with bessel funcs Initial Comment: Hello, Maxima team. I'm a new user and am amazed with what I'm able to accomplish in Maxima. I'm having a little trouble. I'm trying to make a bessel function plot, and it keeps failing. For instance: (C1) plot3d(bessel_j[0](x),[x,0,10],[y,0,2*%pi],['transform_xy,polar_to_xy]); Error: ((MQAPPLY SIMP) (($BESSEL_J SIMP ARRAY) 0) 0.33333333333333331) is not of type (OR RATIONAL LISP:FLOAT). Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by LISP:FLOAT. Broken at LISP:FLOAT. Type :H for Help. Nothing I do seems to allow the plot to complete, including using BESSELEXPAND and making the order 1/2: (C1) besselexpand:true; (D1) TRUE (C2) plot3d(bessel_j[1/2](x),[x,0.0001,10],[y,0,2*%pi],['transform_xy,polar_to_xy]); Error: ((MTIMES SIMP) 0.0099999999833333339 ((MEXPT SIMP) 2 (# 1 2)) ...) is not of type (OR RATIONAL LISP:FLOAT). Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by LISP:FLOAT. Broken at LISP:FLOAT. Type :H for Help. My maxima information:  Maxima version: 5.9.0 Maxima build date: 22:24 2/9/2003 host type: i386redhatlinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  (I'm using the Redhat RPMs on Redhat 8.0.) A bug fix would be great, but if it's not possible, I really would like to get a workaround, as I'd like to get a picture of the plot for a paper. If there is a simple workaround, could you please let me know?  Comment By: M. L. Murphy (mlmurphy) Date: 20030227 19:51 Message: Logged In: YES user_id=719178 Thank you very much! Using numer:true; works great. The plots look very pretty. You can consider this bug closed as far as I'm concerned (but maybe you might want to keep it open at a lower priority, in case you might want to fix bessel_j in the future...). Thanks again.  Comment By: Raymond Toy (rtoy) Date: 20030225 11:32 Message: Logged In: YES user_id=28849 Yes, this is a bug in bessel_j wherein it doesn't give a numerical answer even when the arg is a float. As a workaround, use j0(x) insetad of bessel_j[0](x). Or you can set numer:true before plotting, or use plot3d(bessel_j[0](x),[x,0,10],[y,0,2*%pi],['transform_xy,polar_to_xy]), numer;  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=691941&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 17:56:56

Bugs item #701169, was opened at 20030310 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701169&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stavros Macrakis (macrakis) >Assigned to: Raymond Toy (rtoy) Summary: plot3d scaling problems Initial Comment: Plot3d seems to do something horrible with scaling. Look at the following simple plot. plot3d(x*y,[x,0,.1],[y,0,.1]) This gives a stepped plot, with only 10 distinct z values. Along the same lines, plot3d(x*y/1000,[x,0,1],[y,0,1]); gives a plot with only *2* distinct zvalues. And for plot3d(x*y,[x,0,.01],[y,0,.01]) and plot3d(x*y/10000,[x,0,1],[y,0,1]); I get division by zero. Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  >Comment By: Raymond Toy (rtoy) Date: 20030403 13:12 Message: Logged In: YES user_id=28849 Applied the fix ",3g". Both examples plot just fine now.  Comment By: Raymond Toy (rtoy) Date: 20030402 20:52 Message: Logged In: YES user_id=28849 Found the problem: (defun printpt1 (f str) (format str "~,3f " f)) Thus, only 3 decimal places are printed. Using either ~f or even ~,3g gives much better results.  Comment By: Stavros Macrakis (macrakis) Date: 20030324 14:34 Message: Logged In: YES user_id=588346 A simpler error: plot3d(1,[x,0,1],[y,0,1]) => Error: divide by zero (tcl)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701169&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 16:06:32

Bugs item #714697, was opened at 20030403 16:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714697&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: another taylor bug Initial Comment: (C1) display2d:false; (D1) FALSE (C2) psi(yb,n):=yb^n/(n*(1/2(yb+1)/((yb+1)^2+1))^(n/2)); (D2) PSI(yb,n):=yb^n/(n*(1/2(yb+1)/((yb+1)^2+1))^(n/2)) (C3) taylor(psi(yb,2),yb,0,1); (D3) +0 (C4) taylor(ratsimp(psi(yb,2)),yb,0,1); (D4) 2+2*yb (which is correct) Martin  >Comment By: Martin Rubey (kratt5) Date: 20030403 16:21 Message: Logged In: YES user_id=651552 In fact, that was only half the story: Taylor always gives zero when the order of expansion is one less than the second argument to psi. I tried to set taylordepth to a higher value, but that doesn't change anything... (C3) taylor(psi(yb,5),yb,0,4); (D3) +0 (C4) taylor(psi(yb,5),yb,0,5); (D4) 32/5+16*yb+20*yb^2+14*yb^3+23*yb^4/4+43*yb^5/40 unfortunately, the ratsimp trick doesn't work here: (C5) taylor(ratsimp(psi(yb,5)),yb,0,5); TAYLOR encountered an unfamiliar singularity in: ABS(yb)  an error. Quitting. To debug this try DEBUGMODE(TRUE);) Martin  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714697&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 15:46:24

Bugs item #714697, was opened at 20030403 16:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714697&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Rubey (kratt5) Assigned to: Nobody/Anonymous (nobody) Summary: another taylor bug Initial Comment: (C1) display2d:false; (D1) FALSE (C2) psi(yb,n):=yb^n/(n*(1/2(yb+1)/((yb+1)^2+1))^(n/2)); (D2) PSI(yb,n):=yb^n/(n*(1/2(yb+1)/((yb+1)^2+1))^(n/2)) (C3) taylor(psi(yb,2),yb,0,1); (D3) +0 (C4) taylor(ratsimp(psi(yb,2)),yb,0,1); (D4) 2+2*yb (which is correct) Martin  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=714697&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 04:26:25

Bugs item #713711, was opened at 20030402 00:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=713711&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: cf(sqrt(2)) cf(sqrt(2)/sqrt(5)) cf...fpprec incorrect Initial Comment: cf(sqrt(2)) => [1,2] NO cf(sqrt(2)),cflength=3 => [1,2,2,2] NO But those are the CF's for sqrt(2). (I show the results for cflength=1 and =3 to show repetition pattern.) cf(sqrt(2)/sqrt(5)) => [0,1,2,13] NO cf(sqrt(2)/sqrt(5)),length=3 => [0,1,1,1,2,1,2,4,2,3,4] NO The correct result (as you can see from cf(sqrt(.4))) is [0,1,1,1,2] (repeat 1,1,2) Apparently cf computes the *truncated* CF for sqrt(2) and the *truncated* CF for sqrt(5) and then combines them. That is the wrong way to do it. Gosper's algorithm (1972) as documented in Hakmem 101B (http://www.inwap.com/pdp10/hbaker/hakmem/cf.html#it em101b) and even more clearly in http://www.lix.polytechnique.fr/~ilan/pseudo_code.ps. The strange thing is that CF uses Gosper's algorithm correctly for finitelength CFs. Another (unrelated) bug: block([fpprec:25],cf(1.0b25)) == cf(1.0b25),fpprec:25 => [0, 10000000000000000189023153, 2] NO! as opposed to fpprec:25; cf(1.0b25) => [0, 10000000000000000000000000] Compare the correct behavior of block([fpprec:25],1.0b0+1.0b221.0b0); == 1.0b0+1.0b221.0b0,fpprec:25; == fpprec:25; 1.0b0+1.0b221.0b0; => 1.000113059364895023149213B22 1.000113059364895023149213B22 Presumably this has something to do with the weird way CF is an MFEXPR* to avoid LISTARITH arithmetic....  >Comment By: Stavros Macrakis (macrakis) Date: 20030402 23:40 Message: Logged In: YES user_id=588346 My "(unrelated) bug" is bogus. Sorry about that. The problem is that the Bfloats are being *read in* using the value of fpprec prevailing at the time of the *read*!! And bfloats are represented internally as binary floatingpoint, not decimal floating point. Naturally, setting fpprec during the calculation doesn't change anything. To demonstrate the effect: fix(1.0b25) => 10000000000000000100663296 fpprec:25$ fix(1.0b25) => 10000000000000000000000000 But the other CF problems are still legit. Teaches me to put two different problems in one bugnote  now I can't mark the second problem as "user error" and make it disappear....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=713711&group_id=4933 
From: SourceForge.net <noreply@so...>  20030403 01:37:04

Bugs item #701169, was opened at 20030310 17:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701169&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: plot3d scaling problems Initial Comment: Plot3d seems to do something horrible with scaling. Look at the following simple plot. plot3d(x*y,[x,0,.1],[y,0,.1]) This gives a stepped plot, with only 10 distinct z values. Along the same lines, plot3d(x*y/1000,[x,0,1],[y,0,1]); gives a plot with only *2* distinct zvalues. And for plot3d(x*y,[x,0,.01],[y,0,.01]) and plot3d(x*y/10000,[x,0,1],[y,0,1]); I get division by zero. Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0  >Comment By: Raymond Toy (rtoy) Date: 20030402 20:52 Message: Logged In: YES user_id=28849 Found the problem: (defun printpt1 (f str) (format str "~,3f " f)) Thus, only 3 decimal places are printed. Using either ~f or even ~,3g gives much better results.  Comment By: Stavros Macrakis (macrakis) Date: 20030324 14:34 Message: Logged In: YES user_id=588346 A simpler error: plot3d(1,[x,0,1],[y,0,1]) => Error: divide by zero (tcl)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=701169&group_id=4933 