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

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2
(3) 
3

4
(4) 
5

6

7

8

9

10
(1) 
11

12
(1) 
13
(6) 
14

15
(13) 
16
(5) 
17
(5) 
18
(3) 
19
(3) 
20
(1) 
21
(2) 
22
(2) 
23
(3) 
24

25

26

27
(1) 
28

29

30

31
(1) 

From: SourceForge.net <noreply@so...>  20120831 15:03:34

Bugs item #3558096, was opened at 20120815 17:46 Message generated for change (Comment added) made by aleksasd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3558096&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: 5 Private: No Submitted By: JeanYves (jyoberle) Assigned to: Nobody/Anonymous (nobody) Summary: to_poly_solve gives a wrong solution for cos(x)=sin(3x) Initial Comment: Hi, When doing: load(to_poly_solve); algexact:true; to_poly_solve(cos(x)sin(3*x),x); I get: to_poly_solve: to_poly_solver.mac is obsolete; I'm loading to_poly_solve.mac instead. %union([x=(4*%pi*%z0+%pi)/4],[x=(4*%pi*%z1+%pi)/8]) But I think that the first solution should be (based on hand solving): (4*%pi*%z0+%pi)/4 (no minus sign). For example: if we consider %z0 = 0 in the to_poly_solve solution, we get x=%pi/4 which is not a solution of the equation cos(x)sin(3*x). On the other hand, if we set %z0 = 0 in the hand found solution, we get x=%pi/4 which is a solution. The build_info is: build_info("5.27.0","20120508 11:27:57","i686pcmingw32","GNU Common Lisp (GCL)","GCL 2.6.8"). Best regards, JeanYves  Comment By: Aleksas (aleksasd) Date: 20120831 08:03 Message: To finding all solutions of trigonometric equation eq from interval [a, b] we define function "trigsolve": (%i1) trigsolve(eq,a,b):=block([s,i,ats,algebraic], algebraic:true, to_poly_solve([eq], [x],'simpfuncs = ['rootscontract,'expand,'radcan,'nicedummies]), s:makelist(rhs(part(%%,k)[1]),k,1,length(%%)), ats:[], for i:1 thru length(s) do (makelist(ev(s[i],%z0=k),k,10,10), ats:append(ats,%%)), sublist(ats,lambda([e],e>=a and e<=b and float(ev(abs(lhs(eq)rhs(eq)),x=e))<ratepsilon)), sort(%%), setify(%%) )$ Example: solve cos(x)sin(3*x)=0 (%i2) eq:cos(x)sin(3*x)=0$ (%i3) cos(x)cos(y)=2*sin(1/2*x+1/2*y)*sin(1/2*x1/2*y)$ (%i4) subst(y=3*x%pi/2,%),expand; (%o4) cos(x)sin(3*x)=2*sin(x%pi/4)*sin(2*x%pi/4) (%i5) eq1:sin(x%pi/4)=0$ (%i6) eq2:sin(2*x%pi/4)=0$ (%i7) S1:trigsolve(eq1,%pi,%pi); to_poly_solve: to_poly_solver.mac is obsolete; I'm loading to_poly_solve.mac instead. Loading maximagrobner $Revision: 1.6 $ $Date: 20090602 07:49:49 $ (%o7) {(3*%pi)/4,%pi/4} (%i8) S2:trigsolve(eq2,%pi,%pi); (%o8) {(7*%pi)/8,(3*%pi)/8,%pi/8,(5*%pi)/8} (%i9) S:union(S1,S2); (%o9) {(7*%pi)/8,(3*%pi)/4,(3*%pi)/8,%pi/8,%pi/4,(5*%pi)/8} (%i10) float(%), numer; (%o10) {2.748893571891069,2.356194490192345,1.178097245096172,0.39269908169872,0.78539816339745,1.963495408493621} Answer: x=a+2*%pi*k, where a  any from S, k  any integer (%i11) plot2d([cos(x)sin(3*x)], [x,%pi,%pi])$  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3558096&group_id=4933 
From: SourceForge.net <noreply@so...>  20120827 13:13:25

Bugs item #3562136, was opened at 20120827 06:13 Message generated for change (Tracker Item Submitted) made by lvch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3562136&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: Valery Lovchikov (lvch) Assigned to: Nobody/Anonymous (nobody) Summary: function factor() have bug Initial Comment: Maxima 5.28.0 (%i1) factor([sqrt(1u)*(u1),(1u)^(3/2)*(u1)]); (%o1) [sqrt(1  u) (u  1),  sqrt(1  u) (u  1)^2 ] but (%i2) factor([(1u)*sqrt(u1),(1u)*(u1)^(3/2)]); (%o2) [ (u  1)^(3/2) ,  (u  1)^(5/2) ]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3562136&group_id=4933 
From: SourceForge.net <noreply@so...>  20120823 12:20:02

Bugs item #3560981, was opened at 20120823 04:54 Message generated for change (Comment added) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560981&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Xmaxima or other UI Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: killoneshark () Assigned to: Nobody/Anonymous (nobody) Summary: Vertical rotation angle limit Initial Comment: Hello, I would like rotate 3d image with view = [ v,h ] (over horizontal 360º and vertical 360º axes) Xmaxima reports and error , when angle > 180 >>>> \"draw: vertical rotation angle must be in [0, 180]\"<<<< Gnuplot manual mode, allow arrows rotate all 360º vertical axe. grcommon.lisp lines 555,556  (and (numberp rv) (>= rv 0) (<= rv 180) ) (merror \"draw: vertical rotation angle must be in [0, 180]\"))  When rw <= 360 it seems to work OK too, Can you check this. Thank you  >Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20120823 05:20 Message: This was an issue related to package draw, not xMaxima. You can download new draw version from the repository. Thanks.  Mario  Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20120823 05:20 Message: The reported bug is not present in the current cvs version of Maxima. Thank you for your report. If you see this bug in a later version of Maxima, please submit a new bug report.  Comment By: killoneshark () Date: 20120823 05:03 Message: reported here too https://sourceforge.net/projects/wxmaxima/forums/forum/435775/topic/5563669  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560981&group_id=4933 
From: SourceForge.net <noreply@so...>  20120823 12:03:29

Bugs item #3560981, was opened at 20120823 04:54 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560981&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Xmaxima or other UI Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: killoneshark () Assigned to: Nobody/Anonymous (nobody) Summary: Vertical rotation angle limit Initial Comment: Hello, I would like rotate 3d image with view = [ v,h ] (over horizontal 360º and vertical 360º axes) Xmaxima reports and error , when angle > 180 >>>> \"draw: vertical rotation angle must be in [0, 180]\"<<<< Gnuplot manual mode, allow arrows rotate all 360º vertical axe. grcommon.lisp lines 555,556  (and (numberp rv) (>= rv 0) (<= rv 180) ) (merror \"draw: vertical rotation angle must be in [0, 180]\"))  When rw <= 360 it seems to work OK too, Can you check this. Thank you  >Comment By: killoneshark () Date: 20120823 05:03 Message: reported here too https://sourceforge.net/projects/wxmaxima/forums/forum/435775/topic/5563669  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560981&group_id=4933 
From: SourceForge.net <noreply@so...>  20120823 11:55:01

Bugs item #3560981, was opened at 20120823 04:54 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560981&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Xmaxima or other UI Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: killoneshark () Assigned to: Nobody/Anonymous (nobody) Summary: Vertical rotation angle limit Initial Comment: Hello, I would like rotate 3d image with view = [ v,h ] (over horizontal 360º and vertical 360º axes) Xmaxima reports and error , when angle > 180 >>>> \"draw: vertical rotation angle must be in [0, 180]\"<<<< Gnuplot manual mode, allow arrows rotate all 360º vertical axe. grcommon.lisp lines 555,556  (and (numberp rv) (>= rv 0) (<= rv 180) ) (merror \"draw: vertical rotation angle must be in [0, 180]\"))  When rw <= 360 it seems to work OK too, Can you check this. Thank you  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560981&group_id=4933 
From: SourceForge.net <noreply@so...>  20120822 16:12:43

Bugs item #3560390, was opened at 20120821 08:42 Message generated for change (Comment added) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&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: Fixed Priority: 5 Private: No Submitted By: Jerry W. Lewis (statsman) Assigned to: Nobody/Anonymous (nobody) Summary: negative_binomial overly restrictive Initial Comment: The negative binomial distribution need not be restricted to integer values of the argument n; cf. http://en.wikipedia.org/wiki/Negative_binomial_distribution Indeed, the noninteger case as an overdispersed generalization of the Poisson distribution is important in many fields, including ecology, environmental monitoring, epidemiology, industrial safety, insurance, medicine, microbiology, etc. Here are function definitions for the general negative binomial pdf and cdf pdf_negative_binomial2(x,n,p) := pdf_beta(p,n,x+1)*p/(n+x)$ /* negative binomial for real n>0 */ cdf_negative_binomial2(x,n,p) := cdf_beta(p,n,x+1)$ /* negative binomial for real n>0 */ The functions for mean, var, std, skewness, and kurtosis should be fine if you just remove the trap for noninteger n. Assuming that the quantile function numerically inverts the cdf, then it would likely be fine too.  >Comment By: Mario Rodriguez Riotorto (riotorto) Date: 20120822 09:12 Message: Thanks for bringing this to our attention. It's now fixed in git repository. Instead of using pdf_beta, we call beta_incomplete_regularized and the floor function to take into account the discrete nature of the r.v. Also, quantile_negative_binomial needed a bug fix.  Mario  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&group_id=4933 
From: SourceForge.net <noreply@so...>  20120822 11:31:01

Bugs item #3560650, was opened at 20120822 04:31 Message generated for change (Tracker Item Submitted) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560650&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: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: diff with respect to a declared integer Initial Comment: (%i4) declare(x,integer)$ I would favor no error, I think. But the error message is confusing: (%i5) diff(x,x); diff: second argument must be a variable; found x  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560650&group_id=4933 
From: SourceForge.net <noreply@so...>  20120821 15:50:06

Bugs item #3560390, was opened at 20120821 08:42 Message generated for change (Settings changed) made by statsman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&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: Jerry W. Lewis (statsman) Assigned to: Nobody/Anonymous (nobody) >Summary: negative_binomial overly restrictive Initial Comment: The negative binomial distribution need not be restricted to integer values of the argument n; cf. http://en.wikipedia.org/wiki/Negative_binomial_distribution Indeed, the noninteger case as an overdispersed generalization of the Poisson distribution is important in many fields, including ecology, environmental monitoring, epidemiology, industrial safety, insurance, medicine, microbiology, etc. Here are function definitions for the general negative binomial pdf and cdf pdf_negative_binomial2(x,n,p) := pdf_beta(p,n,x+1)*p/(n+x)$ /* negative binomial for real n>0 */ cdf_negative_binomial2(x,n,p) := cdf_beta(p,n,x+1)$ /* negative binomial for real n>0 */ The functions for mean, var, std, skewness, and kurtosis should be fine if you just remove the trap for noninteger n. Assuming that the quantile function numerically inverts the cdf, then it would likely be fine too.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&group_id=4933 
From: SourceForge.net <noreply@so...>  20120821 15:42:07

Bugs item #3560390, was opened at 20120821 08:42 Message generated for change (Tracker Item Submitted) made by statsman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&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: Jerry W. Lewis (statsman) Assigned to: Nobody/Anonymous (nobody) Summary: negative_binomial overly retrictive Initial Comment: The negative binomial distribution need not be restricted to integer values of the argument n; cf. http://en.wikipedia.org/wiki/Negative_binomial_distribution Indeed, the noninteger case as an overdispersed generalization of the Poisson distribution is important in many fields, including ecology, environmental monitoring, epidemiology, industrial safety, insurance, medicine, microbiology, etc. Here are function definitions for the general negative binomial pdf and cdf pdf_negative_binomial2(x,n,p) := pdf_beta(p,n,x+1)*p/(n+x)$ /* negative binomial for real n>0 */ cdf_negative_binomial2(x,n,p) := cdf_beta(p,n,x+1)$ /* negative binomial for real n>0 */ The functions for mean, var, std, skewness, and kurtosis should be fine if you just remove the trap for noninteger n. Assuming that the quantile function numerically inverts the cdf, then it would likely be fine too.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3560390&group_id=4933 
From: dan hayes <zmth@ya...>  20120820 12:04:34

Per this original of mine below why hasn't it gotten the attention and replies from whoever as for example the many other peoples do as they are sent to my emails ? This is a very simple definite bug so what do i have to do to get some attention and action taken on it ? Thanks.  On Fri, 8/3/12, dan hayes <zmth@...> wrote: From: dan hayes <zmth@...> Subject: wxMaxima 12.04.0 Declarations and inferences To: maximabugs@... Date: Friday, August 3, 2012, 11:02 PM /*bugs,declarations,inferences*/ (declare([k,j,m,mp],integer),assume(k>1,j>1,k>j1,j>m1,j>m1,j>mp1,j>mp1),disp(is(k>m1))); gives output: unknown When it is obvious it should be TRUE and in fact also for all 3 of the following should be ' true ' and it still gives 'unknown' for all: is(k>m1),is(k>mp1),is(k>mp1), 
From: SourceForge.net <noreply@so...>  20120819 17:54:30

Bugs item #3559526, was opened at 20120819 10: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=3559526&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: elllptic_f(2*%pi,1/2) not simplified. Initial Comment: elliptic_f(2*%pi,1/2) can be simplified to 4*elliptic_kc(1/2). Maxima doesn't do this. In fact ellpitic_f(x,m) when abs(x) > %pi/2 could be simplified to elliptic_f(rem(x,%pi/2), m) + floor(x,%pi/2)*elliptic_kc(m) from the periodicity of elliptic_f.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3559526&group_id=4933 
From: SourceForge.net <noreply@so...>  20120819 17:27:06

Bugs item #3559064, was opened at 20120817 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3559064&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: elliptic_f(2,1) is wrong Initial Comment: Maxima says elliptic_f(2,1) is log(tan(%pi/4+1)). That's not right because elliptic_f(%pi/2,1) is infinity. elliptic_f(x,1) also simplifies to log(tan(%pi/4+x/2)), but that's only corrrect if abs(x) <= %pi/2. Not sure what to do about the latter, but for numeric arguments, we should either return infinity or an error.  >Comment By: Raymond Toy (rtoy) Date: 20120819 10:27 Message: Signal an error in this case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3559064&group_id=4933 
From: SourceForge.net <noreply@so...>  20120819 16:35:29

Bugs item #3381301, was opened at 20110728 12:31 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&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: 1 Private: No Submitted By: Dieter Kaiser (crategus) Assigned to: Nobody/Anonymous (nobody) Summary: log(1.0b0) has small realpart Initial Comment: The result of log(1.0b0) has a small realpart within the numerical precision. To be more consistent with log(1.0b0) >0.0b0 I think the small realpart should be omitted. Maxima version: 5.24post Maxima build date: 20:27 7/28/2011 Host type: i686pclinuxgnu Lisp implementation type: SBCL Lisp implementation version: 1.0.45 (%i2) log(1.0b0); (%o2) 3.141592653589793b0*%i1.084202172485504b19 Dieter Kaiser  >Comment By: Raymond Toy (rtoy) Date: 20120819 09:35 Message: Fixed by adding a special case in bigfloatlog which had no special code to handle log(1b0). simpln handled the case of log(1), but nothing else.  Comment By: Barton Willis (willisbl) Date: 20110729 05:53 Message: Using Clozure CL, I get the same three test failures.  Comment By: Dieter Kaiser (crategus) Date: 20110729 04:08 Message: With the proposed change I get the desired result for log(1.0b0) > 3.141592653589793b0 %i. With SBCL I get three changes in the testsuite. I have not looked at the examples in detail, but it seems to me that failures are due to a slightly loss of accuracy in the numerical calculation of special functions. Perhaps the results have changed only within the predictable accuracy. Because we have no checks in the testsite for the numerical precision of the log function, it might be difficult to say if there is a small problem in the bigfloat package. At the end, it would be nice if we can implement one scheme of numerical evaluation, or if both available schemes give equivalent results. These are the changed results: Running tests in rtest15: ********************** Problem 233 *************** Input: ev(Y1, numer) Result: [.1601071267287311, .3182173976481846, .6792822087245607,  .2554475201086612, .4550000458216386, 1.513096652187913, 1.631906796078438, 1.153564994895108,  1.9459101, .9354375628925464, 6.548062940247827, 1.427448757889531 %i, .1438410362258904  1.570796326794897 %i, 2.644120761058629, 2.633915793849634, .1423756431678044, .1438410362258905, 1.010221447322645, 7.047554385466547, 6.976247043798604, .9898819735517056, .1433435475724631, .1418931937669325, .3779644730092272, 1.427448757889531, 1.428899272190733, 1.570796326794897  2.633915793849634 %i, 2.633915793849634 %i, .1433475689053653, .1418970546041639, .9898132604466151, 6.952316038379696, 7.023866335396166, 1.010291577169605, .1423717297922636, .1438369594361909, .1541506798272584, .1483117974987926, .1455231696984896,  7.363980242224349, 50.3574714369117,  687.6815220686585] This differed from the expected result: [0.16010712672873, 0.31821739764818, 0.67928220872456,  0.25544752010866, 0.45500004582164, 1.513096652187913, 1.631906796078438, 1.153564994895108,  1.945910149055313, 0.93543756289255, 6.548062940247834, 1.427448757889531 %i, 0.14384103622589  1.570796326794897 %i, 2.644120761058629, 2.633915793849633, 0.1423756431678, 0.14384103622589, 1.010221447322645, 7.047554385466551, 6.976247043798608, 0.98988197355171, 0.14334354757246, 0.14189319376693, 0.37796447300923, 1.427448757889531, 1.428899272190733, 1.570796326794897  2.633915793849634 %i, 2.633915793849634 %i, 0.14334756890537, 0.14189705460416, 0.98981326044662, 6.952316038379697, 7.023866335396166, 1.010291577169605, 0.14237172979226, 0.14383695943619, 0.15415067982726, 0.14831179749879, 0.14552316969849,  7.363980242224349, 50.3574714369117,  687.6815220686585] 251/252 tests passed The following 1 problem failed: (233) Running tests in rtest_gamma: ********************** Problem 654 *************** Input: 1 beta_incomplete(1.0b0, 2, ) 2 Result: 3.750000000000002b1 This differed from the expected result: 3.75b1 702/703 tests passed (not counting 2 expected errors) The following 1 problem failed: (654) Running tests in rtest_expintegral: ********************** Problem 66 *************** Input: ev(test_value(%, expintegral_e(3, 0.5), 15), numer) Result: 1.190408882578708e10 and 5.463923757886846e9 This differed from the expected result: true 184/185 tests passed The following 1 problem failed: (66) Dieter Kaiser  Comment By: Barton Willis (willisbl) Date: 20110729 03:14 Message: Correction: ((and (complexnumberp y #'mnump) (or $numer (not (complexnumberp y #'$ratnump)))) (maxima::to (bigfloat::log (bigfloat::to y))))  Comment By: Barton Willis (willisbl) Date: 20110728 20:39 Message: rest_log #11 is a known failure: Running tests in rtest_log: ********************** Problem 11 *************** Input: log( 1.0b0)  bfloat(%i %pi) Inserting ((or (complexnumberp y #'(lambda(s) (or (floatp s) ($bfloatp s)))) (and $numer (complexnumberp y #'mnump))) (maxima::to (bigfloat::log (bigfloat::to y)))) into simpln fixes this bug, and it changes some expected results.  Comment By: Barton Willis (willisbl) Date: 20110728 19:38 Message: The bigfloat package handles this better: MAXIMA> (bigfloat::log (bigfloat::to (maxima::meval '$x))) +0.0b0+3.141592653589793b0*%i Would it be possible to use the bigfloat package in simpln?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3381301&group_id=4933 
From: SourceForge.net <noreply@so...>  20120818 23:54:28

Bugs item #3311100, was opened at 20110603 07:05 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3311100&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: sergio pesenti (sergiopesenti) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d problem from 5.24.0 Initial Comment: The following plot does not execute in recent releases of MAXIMA. y(x):=log(abs(1/(1+exp(%i*x))))$ plot2d( y(x),[x,0.1,1])$ MAXIMA complains with "sign: argument cannot be imaginary; found %i" but works with MAXIMA 5.20.1  >Comment By: Raymond Toy (rtoy) Date: 20120818 16:54 Message: Closing bug again (already was marked fixed).  Comment By: sergio pesenti (sergiopesenti) Date: 20110614 01:13 Message: Thanks alex. It works fine. However, I had some other trouble while defining my functions with cabs. For instance, the code simp:false$ define(y(x),log(cabs(1/(1+exp(%i*x)))))$ simp:true$ y(1.0); does not evaluate completely the numerical value. But it works if I use ":=" to define the function. Here the code simp:false$ y(x):=log(cabs(1/(1+exp(%i*x))))$ simp:true$ y(1.0); evaluates perfectly. I actually need to set "simp" to "false" because the expressions I deal with in my real case are quite complicated. I need to prevent a simplification at this stage to avoid MAXIMA to start an endless evaluation while defining my expressions.  Comment By: Aleksas (aleksasd) Date: 20110607 14:18 Message: abs change to cabs: y(x):=log(cabs(1/(1+exp(%i*x))))$ plot2d( y(x),[x,0.1,1])$ work with maxima 5.24.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3311100&group_id=4933 
From: SourceForge.net <noreply@so...>  20120818 23:52:52

Bugs item #3337674, was opened at 20110627 08:46 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3337674&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: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Dženan Zukić (dzenanz) Assigned to: Nobody/Anonymous (nobody) Summary: Symmetric matrix yields complex eigenvalues Initial Comment: When using eigenvectors command in wxMaxima, the following symmetric matrix yields complex eigenvalues: matrix([2621.4397,7823.3599,1111.2726],[7823.3599,23347.842,3316.4543],[1111.2726,3316.4543,471.08722]) All eigenvalues of a symmetric matrix should be real: http://en.wikipedia.org/wiki/Symmetric_matrix Maxima version: 5.24.0 Maxima build date: 20:39 4/5/2011 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20120818 16:52 Message: In addition, I think algorithms for symmetric matrices should be used, instead of a general eigen solver. I don't consider this a bug in maxima. Marking as pending/wontfix.  Comment By: Barton Willis (willisbl) Date: 20110628 21:00 Message: For a floating point evaluation of eigenvalues, you should use a purely numeric method, not a symbolic method. One (not the only) option is eigens_by_jacobi (symmetric and either binary64 or bigfloat entries).  Comment By: Dženan Zukić (dzenanz) Date: 20110628 05:37 Message: Thanks for suggestions, but I was using Maxima trying to verify some results obtained using numeric library. However after getting this nonsensical result from Maxima I used another numeric library and obtained similar results (difference was after some decimal points). I am not a frequent user of Maxima, and this problem has significantly lowered my faith in it.  Comment By: Barton Willis (willisbl) Date: 20110628 05:23 Message: I think the problem is that the default value of ratepsilon is too small; try this: (also do this same with ratepsilon : 1.0e8) (%i1) load(hypergeometric)$ (%i2) ratepsilon : 1.0e18$ (%i3) m : matrix([2621.4397,7823.3599,1111.2726],[7823.3599,23347.842,3316.4543],[1111.2726,3316.4543,471.08722])$ (%i4) first(eigenvalues(m)), ratprint : false$ (%i5) nfloat(%  conjugate(%),[],100); (%o5) [8.0266455652163197256568351091[46 digits]5913348171925384517960952b197*%i1.3377742608693866209428058515[46 digits]0985558028654230752993492b197,5.3510970434775464837712234061[46 digits]3942232114616923011973968b197*%i1.3377742608693866209428058515[46 digits]0985558028654230752993492b197,1.9934389902195135071021405630[46 digits]0374693317196116973450023b205*%i2.6755485217387732418856117030[46 digits]1971116057308461505986984b197] See also http://en.wikipedia.org/wiki/Casus_irreducibilis  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3337674&group_id=4933 
From: SourceForge.net <noreply@so...>  20120818 23:41:20

Bugs item #3428734, was opened at 20111026 05:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3428734&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: 2 Private: No Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate(bessel_y(1,z),z) with ?z : 1 Initial Comment: The code for the antiderivative of bessel_y has an (ignore unused) declaration that seems wrong: (%i2) integrate(bessel_y(1,z),z); (%o2) bessel_y(0,z) (%i3) ?z : 1; (%o3) 1 (%i4) integrate(bessel_y(1,z),z); (%o4) integrate(bessel_y(1,z),z)  >Comment By: Raymond Toy (rtoy) Date: 20120818 16:41 Message: That's a pretty funny bug. How did you find this? Anyway, it should be fixed now. Some the the expressions were using the free variable z. I changed that so the second arg to the integration routine actually uses the second arg.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3428734&group_id=4933 
From: SourceForge.net <noreply@so...>  20120817 22:21:13

Bugs item #3559135, was opened at 20120817 15:21 Message generated for change (Tracker Item Submitted) made by riotorto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3559135&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: Mario Rodriguez Riotorto (riotorto) Assigned to: Nobody/Anonymous (nobody) Summary: noninteractive and value assignment Initial Comment: I found this issue when trying to make use of noninteractive in a Maxima web interface context: (%i1) load(noninteractive)$ (%i2) display2d:false$ (%i3) w: integrate(x^a,x); (%o3) if equal(a+1,0) then log(x) else x^(a+1)/(a+1) (%i4) %; (%o4) if equal(a+1,0) then log(x) else x^(a+1)/(a+1) (%i5) %o3; (%o5) if equal(a+1,0) then log(x) else x^(a+1)/(a+1) But ... (%i6) w; (%o6) x^(a+1)/(a+1) The output returned by integrate after calling noninteractive is not assigned to variable w as it should, but it is correctly assigned to variable %.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3559135&group_id=4933 
From: SourceForge.net <noreply@so...>  20120817 17:05:51

Bugs item #3220118, was opened at 20110317 08:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: erf(1+5*%i) not accurate Initial Comment: erf(1.0+5*%i) returns  2.7837671212125964e+9 %i  1.0786562260474622e+9 But the true answer (as given by Wolfram/Alpha) is  2.7837702922089653e+9 %i  1.0786931161985406e+9 Only about 4 digits are correct.  >Comment By: Raymond Toy (rtoy) Date: 20120817 10:05 Message: Appears to have been fixed some time ago.  Comment By: Raymond Toy (rtoy) Date: 20110328 19:41 Message: Actually, the continued fraction http://functions.wolfram.com/06.06.10.0009.01 appears to converge faster and to be more accurate. The previously mentioned fraction has some issues for points near the negative real axis where the accuracy is not as good as we might expect.  Comment By: Raymond Toy (rtoy) Date: 20110324 15:17 Message: Here is an alternative method of computing gamma_incomplete: http://functions.wolfram.com/06.06.10.0007.01 There appear to be no restrictions on the range of validity of this continued fraction, so it can probably be used for other areas. I've tested this a bit (with oct), and it converges quickly for things on or near the negative real axis. The few tests I've done indicate that accuracy is good.  Comment By: Dieter Kaiser (crategus) Date: 20110324 12:06 Message: Hello Ray, you are right. The problem is the function gamma_incomplete. The continued fraction expansion of the function tends to converge to a wrong value for some ranges of the argument. In the past, I had searched for some hints in the literature to solve this problem more general. But I had not found a simple solution. Therefore, I had done a heuristic approach and checked several ranges for the arguments to achieve a better approximation of the function gamma_incomplete. I have to work again on this problem. Dieter Kaiser  Comment By: Raymond Toy (rtoy) Date: 20110324 06:27 Message: I think the inaccuracy comes from gammaincomplete, which is used to evaluate erf. For this particular argument, gammaincomplete uses the series. I think the test of when to use the series could be relaxed a bit. When I set *gammaimag* to 0.1, the continued fraction is used, which gives  2.7837770292209086e+9 %i  1.0786931161985383e+9 This is better. I've done some experiments using the continued fraction http://functions.wolfram.com/06.06.10.0005.01. This seems to work a bit better.  Comment By: Barton Willis (willisbl) Date: 20110317 19:51 Message: By the way: using a 1F1 representation for erf, the values agree with Wolfram  Alpha. But the hypergeometric code has to switch to bigfloats to do this: (%i11) my_erf(x) := nfloat(2*x*hypergeometric([1/2],[3/2],x^2)/sqrt(%pi),[]); (%o11) my_erf(x):=nfloat((2*x*hypergeometric([1/2],[3/2],x^2))/sqrt(%pi),[]) (%i12) load(hypergeometric)$ (%i14) my_erf(1.0+5*%i); (%o14) 2.783777029220896b9*%i1.078693116198541b9  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220118&group_id=4933 
From: SourceForge.net <noreply@so...>  20120817 17:04:41

Bugs item #3559064, was opened at 20120817 10:04 Message generated for change (Tracker Item Submitted) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3559064&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: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: elliptic_f(2,1) is wrong Initial Comment: Maxima says elliptic_f(2,1) is log(tan(%pi/4+1)). That's not right because elliptic_f(%pi/2,1) is infinity. elliptic_f(x,1) also simplifies to log(tan(%pi/4+x/2)), but that's only corrrect if abs(x) <= %pi/2. Not sure what to do about the latter, but for numeric arguments, we should either return infinity or an error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3559064&group_id=4933 
From: SourceForge.net <noreply@so...>  20120817 16:57:01

Bugs item #3220071, was opened at 20110317 07:46 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220071&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_incomplete should document gamma_expand Initial Comment: The documentation for gamma_incomplete (and friends) should metnion gamma_expand. (And gamma_expand should be documented, but that's a different bug.)  >Comment By: Raymond Toy (rtoy) Date: 20120817 09:57 Message: Fixed some time ago.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220071&group_id=4933 
From: SourceForge.net <noreply@so...>  20120817 16:56:00

Bugs item #3440046, was opened at 20111118 12:55 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3440046&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: Raymond Toy (rtoy) Summary: elliptic_f(0.5,1) signals error Initial Comment: elliptic_f(0.5,1) signals an error, but it is welldefined. This is an error in the routine that does numerical evaluation because elliptic_f(x,1) returns log(tan(x/2+%pi/4)).  >Comment By: Raymond Toy (rtoy) Date: 20120817 09:56 Message: Fixed in git  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3440046&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 16:30:44

Bugs item #3220078, was opened at 20110317 07:48 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220078&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_expand not documented Initial Comment: gamma_expand should be documented (and mentioned in the docs for gamma_incomplete and friends). A nice feature enhancement would be allow gamma_expand to have a value so that gamma_incomplete(a,z) is expanded if a < gamma_expand.  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:30 Message: This was fixed some time ago. ? gamma_expand gives documentation now.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220078&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 16:29:34

Bugs item #3220128, was opened at 20110317 08:06 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: gamma_incomplete(1/2, 24+10*%i) not accurate Initial Comment: Maxima says gamma_incomplete(1/2,20+10*%i),float is 4.93408396056858e+9 %i + 1.91200542673871e+9 Wolfram/Alpha says the value is 4.9341163e+9 + 1.911933e+9 Maxima's answer is only accurate to about 5 digits.  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:29 Message: This was fixed sometime ago.  Comment By: Raymond Toy (rtoy) Date: 20120131 13:27 Message: Yes, this is a known bug with gamma_incomplete: it's totally wrong for large arguments. There's already a bug filed for that, I think.  Comment By: Dan Gildea (dgildea) Date: 20120131 13:18 Message: (%i6) i : integrate(sin(x)^2/x,x); (%o6) (2*log(x)+gamma_incomplete(0,2*%i*x)+gamma_incomplete(0,2*%i*x))/4 I think that the indefinite integral above is correct. However, if we evaluate it numerically: (%i7) i,x:10,numer,expand; (%o7) 1.129082636318599 (%i8) i,x:100,numer,expand; (%o8) 1.167036722342424e+67 we get something that does not match the result of numerical integration: (%i12) quad_qags(sin(x)^2/x,x,10,100); (%o12) [1.175691679966213,1.71048903216243e11,651,0] Not sure if this is a branch cut issue or what, but the results for gamma_incomplete here do not match wolfram alpha.  Comment By: Raymond Toy (rtoy) Date: 20120131 11:52 Message: Sorry. The description text is wrong. The subject line has the correct parameters for the gamma function: gamma_incomplete(1/2, 24+10*%i), float; 4.934116315504894e+9 %i + 1.911933769523827e+9 Wolfram alpha says 1.911933769523828402749347154173060427220404029989163... × 10^9 + 4.934116315504895269147935150892571896585283827123923... × 10^9 i So it looks like we are accurate to full precision now. Marking as pending/worksforme.  Comment By: Dan Gildea (dgildea) Date: 20120128 14:32 Message: Maxima 5.26.0_26_gc4216e7 http://maxima.sourceforge.net using Lisp CMU Common Lisp 20a (20A Unicode) (%i1) gamma_incomplete(1/2,20+10*%i),float; (%o1) 9.902410782885888e+7 %i + 3.4166055039087765e+7  Comment By: Raymond Toy (rtoy) Date: 20110324 06:32 Message: Setting *gammaimag* to .1d0 (so the region where we use the continued fraction is enlarged), improves the result to 4.93411631550489e+9 %i + 1.911933769523828e+9 Wolfram/Alpha gives 4.9341163155048952691479351508925718965852838271239234... × 10^9 i + 1.9119337695238284027493471541730604272204040299891632... × 10^9 Essentially full accuracy.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3220128&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 16:10:39

Bugs item #3479091, was opened at 20120124 10:55 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3479091&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Ted Woollett (woollett) Assigned to: Nobody/Anonymous (nobody) Summary: realpart(1/e) # 1/realpart(e) case Initial Comment: Example in which e = sqrt ( sin (x) ) using gcl (%i1) fpprintprec:8$ (%i2) r1(x):= realpart(1/sqrt(sin(x)))$ (%i3) map('r1,[2,5,8,11,13]); (%o3) [1/sqrt(sin(2)),0,1/sqrt(sin(8)),0,1/sqrt(sin(13))] (%i4) float(%); (%o4) [1.0486897,0.0,1.0053637,0.0,1.5427268] (%i5) r2(x) := 1/realpart(sqrt(sin(x)))$ (%i6) map('r2,[2,5]); expt: undefined: 0 to a negative exponent. #0: r2(x=5)  an error. To debug this try: debugmode(true); (%i7) build_info()$ Maxima version: 5.26.0 Maxima build date: 22:48 1/15/2012 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:10 Message: What exactly is the issue? I expect 1/realpart(e) to give a divide by zero error for x=5 since sqrt(sin(5)) is purely imaginary.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3479091&group_id=4933 
From: SourceForge.net <noreply@so...>  20120816 16:06:01

Bugs item #3435971, was opened at 20111110 00:02 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3435971&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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: eigenvectors produces wrong results Initial Comment: [vals,vec]:eigenvectors(matrix([0.2273,0.0852],[0.193,0.1794])); rat: replaced 0.0164436 by 1134/68963 = 0.01644360019141 rat: replaced 0.1794 by 897/5000 = 0.1794 rat: replaced 0.2273 by 2273/10000 = 0.2273 rat: replaced 0.01644360019141 by 1091/66348 = 0.01644360040996 rat: replaced 0.1794 by 897/5000 = 0.1794 rat: replaced 0.2273 by 2273/10000 = 0.2273 rat: replaced 1.2057635497678905E12 by 1/829350000000 = 1.2057635497678905E12 rat: replaced 2.1637741760636258E+11 by 216377417606/1 = 2.16377417606E+11 rat: replaced 2.1637741760636258E+11 by 216377417606/1 = 2.16377417606E+11 (%o40) [[[0.07289999842889,0.33380000157111],[1,1]],[[[1,1.812206572769953]],[[1, 1.25]]]] However, the eigenvectors should be [0.62166748, 0.78328126] and [0.46864735,0.88338534].  >Comment By: Raymond Toy (rtoy) Date: 20120816 09:06 Message: The eigenvalues computed by maxima are correct. A : matrix([0.2273,0.0852],[0.193,0.1794]); A . vec[1][1]  vals[1][1] * vec[1][1] > matrix([0.0],[0.0]) A . vec[2][1]  vals[1][2] * vec[2][1] > matrix([0.2609],[.4728046948356808]) You were probably expecting the eigenvectors to be normalized to unit length. Eigenvectors are unique only up to a scale factor.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3435971&group_id=4933 