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}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

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

5

6

7

8

9
(2) 
10

11

12
(2) 
13
(1) 
14

15

16
(1) 
17
(2) 
18

19

20
(1) 
21

22
(3) 
23
(8) 
24
(9) 
25
(7) 
26
(2) 
27
(4) 
28

29







From: SourceForge.net <noreply@so...>  20040223 23:32:31

Bugs item #903072, was opened at 20040223 18:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903072&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: is(x<inf) =>true Initial Comment: Compare apparently assumes that everything is smaller than inf: is(x < inf) => true ?? is(1/x < inf) => true ?? is(tan(x)^2 < inf) => true ?? is(und < inf) => error OK These are reasonable questions to ask, I think. Even if we consider that expressions' values range over standard, finite reals (and not inf/minf, which we reserve for return results), comparing to infinity has a reasonable mathematical interpretation, namely: is the expression bounded by a finite value. Clearly x is not. On the other hand, x <= inf should always be true, even for x:'UND (which currently causes an error). But perhaps we need a global theory of all this stuff.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903072&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 22:28:00

Bugs item #697476, was opened at 20030304 15:06 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisb) Assigned to: Nobody/Anonymous (nobody) Summary: formating doubles / really minor Initial Comment: fpprec has an undocumented feature; its value determines the number of decimal digits that are displayed for a double. (C1) fpprec : 8; (D1) 8 (C2) sin(0.1d0); (D2) 0.099833 (C3) fpprec : 30; (D3) 30 (C4) sin(0.1d0); (D4) 0.09983341664682816 (C5) fpprec : 16; (D5) 16 (C6) sin(0.1d0); (D6) 0.09983341664683 (C7) I was surprised by this; the setting of fpprec changes the formatting of doubles, but nothing else about them. For bfloat numbers, the setting of fpprec changes the formating and the number of bits in the fractional part. The documentation for fpprec is unclear and misleading  Variable: FPPREC default: [16]  Floating Point PRECision. Can be set to an intger representing the desired precision. Maybe Maxima has too many globals already, but I might suggest that the formating of doubles be controlled by something other than fpprec. (An option for scientific notation, etc might be nice.) Maxima version: 5.9.0.rc4 Maxima build date: 12:4 1/30/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040223 17:17 Message: Logged In: YES user_id=588346 for fpprec:1 thru 6 do print(fpprec," ", 1.0e3/3," ", 1.0e2/3," ", 1.0e1/3," ", 1.0e+0/3," ", 1.0e+1/3," ", 1.0e+2/3," ", 1.0e+6/3," ", 1.0e+10/3); 1 3.E4 .0 .0 .0 3. 30. 300000. 3.E+9 2 3.3E4 0.0 0.0 0.3 3.3 33. 330000. 3.3E+9 3 3.33E4 0.0 0.03 0.3 3.33 33.3 333000. 3.33E+9 4 3.333E4 0.003 0.03 0.33 3.333 33.33 333300. 3.333E+9 5 3.3333E4 0.003 0.033 0.333 3.3333 33.333 333330. 3.3333E+9 6 3.33333E4 0.0033 0.0333 0.3333 3.33333 33.3333 333333. 3.33333E+9 There are several problems here. First of all, in all but the .003, 0.03, and 0.3 cases, fpprec refers to the number of significant digits, not the number of printed digits. Those cases should read: 1 0.003 0.03 0.3 2 0.0033 0.033 0.33 3 0.00333 0.0333 0.333 4 0.003333 0.03333 0.3333 5 0.0033333 0.033333 0.33333 6 0.00333333 0.0333333 0.333333 Secondly, 3. and 30. in Maxima read in as integers, not floats, so should presumably be output in a consistent way. Finally, it is confusing (though arguably consistent) that 333333.0 prints as 300000. with fpprec=1. Nonsignificant zeroes can be avoided by using scientific form, as C does with %g format.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=697476&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 16:36:19

Bugs item #902792, was opened at 20040223 11:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902792&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: describe interaction parser not robust Initial Comment: When describe() finds more than one match, it offers the interactive choice: Enter n, all, none, or multiple choices eg 1 3 : If you enter anything but a spaceseparated list of numbers and all/none then semicolon, it tends to error out in stupid, ugly, unfriendly ways. Try, for example, describe(ratp), which prompts: 0: RATP :(maxima.info)Definitions for Polynomials. 1: RATPRINT :Definitions for Polynomials. Enter n, all, none, or multiple choices eg 1 3 : ratp; The following produce internal errors: 0,1; '0; The following print nothing, and give no error: 1 $ 01; ratprint; 4; The following give incomplete results: 0 <newline> 1; (shows only ratp) The following give syntax errors: 0 <newline> ; (note that the prompt doesn't say you need to terminate with semicolon  I suspect that originally, the <newline> terminated the input, and the semicolon wasn't necessary) xmaxima 5.9.0  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902792&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 16:02:43

Bugs item #902757, was opened at 20040223 10:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902757&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylor(x,[x],inf,...) garbage Initial Comment: taylor(x,[x],inf,1) => (inf^2+1)/inf1/(x*inf^2)+... ??? taylor(x,[x],[inf],1) => same thing but variants all work: taylor(x,x,inf,1) => x+... OK taylor(x,[x,inf,1]) => x+... OK taylor(x,[x],0,1) => x+... OK taylor(x,[x],[0],1) => x+... OK taylor(x,x,q,1) => q+(xq)+... OK taylor(x,[x],q,1) => q+(xq)+... OK taylor(x,[x],[q],1) => q+(xq)+... OK The original failure was of course in a more realistic case, with more than one variable: taylor(atan(x^2+y^2),[x,y],inf,4) => error should be %pi/21/(y^2+x^2)+... but taylor(atan(x^2+y^2),[x,y],0,2) => %pi/2y^2*x^2/(x^2+y^2)+...  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902757&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 14:08:33

Bugs item #902694, was opened at 20040223 08:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: equal(ind,ind) should be false; also und, NaN Initial Comment: is(ind=ind) => true OK, is/= is syntactic is(equal(ind,ind)) => true NO! is/equal should be semantic Unlike IEEE floating point, Maxima carefully distinguishes syntactic and semantic equality tests. Clearly everything, including ind / und / IEEE_NaN, is syntactically equal to itself. However, not everything is semantically equal to itself. In particular, equal(und,und), equal(ind,ind), and equal(IEEE_NaN, IEEE_NaN) (when we support it) should be false.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902694&group_id=4933 
From: SourceForge.net <noreply@so...>  20040222 21:26:12

Bugs item #900860, was opened at 20040219 22:53 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Simplifications involving abs Initial Comment: abs(q)/q^2 and q^2/abs(q) currently don't simplify. These should simplify to 1/abs(q) and abs(q). This is especially useful since things like sqrt(q^2) simplify to abs(q). It would be even nicer if GCD understood this case, but I can understand that that would be harder, e.g. gcd(abs(q)+q^2,abs(q)) => 1+abs(q) This seems practically justifiable; is there any theoretical reason it might not be justifiable?  >Comment By: Stavros Macrakis (macrakis) Date: 20040222 16:16 Message: Logged In: YES user_id=588346 With declare(q,complex), q/abs(q) should presumably simplify to carg(q), except for the problems with that (620246, 902290). Assuming definition by continuity, q/abs(q) and carg (q) even have the same 'value' (ind) at q=0. With *real* r, r/abs(r) = signum(r) *except* at r=0, where the first is undefined, but the second is welldefined (=0).  Comment By: Barton Willis (willisbl) Date: 20040222 15:35 Message: Logged In: YES user_id=895922 When 'domain' is complex or q has been declared complex, the simplification abs(q) / q^2 > 1/abs(q) shouldn't happen. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&group_id=4933 
From: SourceForge.net <noreply@so...>  20040222 21:21:00

Bugs item #902290, was opened at 20040222 16:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 
From: SourceForge.net <noreply@so...>  20040222 20:44:46

Bugs item #900860, was opened at 20040219 21:53 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Simplifications involving abs Initial Comment: abs(q)/q^2 and q^2/abs(q) currently don't simplify. These should simplify to 1/abs(q) and abs(q). This is especially useful since things like sqrt(q^2) simplify to abs(q). It would be even nicer if GCD understood this case, but I can understand that that would be harder, e.g. gcd(abs(q)+q^2,abs(q)) => 1+abs(q) This seems practically justifiable; is there any theoretical reason it might not be justifiable?  >Comment By: Barton Willis (willisbl) Date: 20040222 14:35 Message: Logged In: YES user_id=895922 When 'domain' is complex or q has been declared complex, the simplification abs(q) / q^2 > 1/abs(q) shouldn't happen. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&group_id=4933 
From: SourceForge.net <noreply@so...>  20040220 04:00:50

Bugs item #900860, was opened at 20040219 22:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Simplifications involving abs Initial Comment: abs(q)/q^2 and q^2/abs(q) currently don't simplify. These should simplify to 1/abs(q) and abs(q). This is especially useful since things like sqrt(q^2) simplify to abs(q). It would be even nicer if GCD understood this case, but I can understand that that would be harder, e.g. gcd(abs(q)+q^2,abs(q)) => 1+abs(q) This seems practically justifiable; is there any theoretical reason it might not be justifiable?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=900860&group_id=4933 
From: SourceForge.net <noreply@so...>  20040217 18:07:38

Bugs item #895581, was opened at 20040212 04:35 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=895581&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with diff Initial Comment: Hi, i view which the diff command don't function correctly. Example: diff(x+1,x); d  ( x+1) dx Why i don't view the correct result?  >Comment By: Stavros Macrakis (macrakis) Date: 20040217 12:03 Message: Logged In: YES user_id=588346 This was a known bug in certain builds (clisp, I think). Please provide full configuration information as given by bug_report();  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=895581&group_id=4933 
From: SourceForge.net <noreply@so...>  20040217 17:07:29

Bugs item #896638, was opened at 20040213 12:38 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=896638&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: equation and equality Initial Comment: Hello, I don't know if it's a bug, I've done : (C5) is((x=2)=(x=1+1)); (D5) TRUE (C6) is((x=2)=(x=3)); (D6) FALSE (C7) is((x^5=1)=(x*x*x*x*x=1)); (D7) TRUE and every thing was ok for me, but : (C11) is((x*x=1)=(1=x*x)); (D11) FALSE I do not understand ... Can you help me ? Best for you, Denis. (reply to Denis.Bouhineau@... ) note : I have verified ;) (C14) solve(x*x=1); (D14) [x =  1, x = 1] (C15) solve(1=x*x); (D15) [x =  1, x = 1] (C16) is(d14=d15); (D16) TRUE It should be true.  >Comment By: Stavros Macrakis (macrakis) Date: 20040217 12:01 Message: Logged In: YES user_id=588346 This is not a bug. is(A = B) tests A and B for syntactic equality, and Maxima always smiplifies. (C1) x=2; (D1) x = 2 (C2) x=1+1; (D2) x = 2 (C3) is(d1=d2); (D3) TRUE (C4) x^5=1; (D4) x^5 = 1 (C5) x*x*x*x*x=1; (D5) x^5 = 1 (C6) is(d4=d5); (D6) TRUE For semantic equality, you need is(equal(A,B)). But equal currently does nothing useful if A and B are equations. I can't think of any simple way to see whether Q=R is equivalent to S=T. You could of course 'encode' the condition algebraically, e.g. signum((QR)^2)signum((ST)^2) but that won't help because "is" knows very little about signum. Of course, the general question of whether two algebraic expression represent the same function is very difficult. In simple cases, you can use ratsimp, radcan, etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=896638&group_id=4933 
From: SourceForge.net <noreply@so...>  20040216 17:43:53

Bugs item #611141, was opened at 20020918 10:06 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611141&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: BFloat(1.11e16) > zero divisor err Initial Comment: BFloat(1.11e16) gives a zero divisor err inside maxima rationalize, as does BFloat(11.11e16) Maxima 5.5 on Windows  >Comment By: Barton Willis (willisbl) Date: 20040216 11:39 Message: Logged In: YES user_id=895922 One needn't work all that hard to break the float to bigfloat conversion  (C4) 0.79999999999999999; (D4) 0.8 (C5) bfloat(%); Warning: Float to bigfloat conversion of 0.79999999999999993 Error: Zero divisor. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by CATCH. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q (C6) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 I still think that the float > rational > bigfloat route is bad. I much prefer the integerdecodefloat approach. Barton  Comment By: Stavros Macrakis (macrakis) Date: 20030102 00:35 Message: Logged In: YES user_id=588346 Other cases worth trying. Using float.lisp 1.6, they either give very wrong answers or infinite loops: bfloat(1.0e310) bfloat(1.0e320)  Comment By: Stavros Macrakis (macrakis) Date: 20030102 00:27 Message: Logged In: YES user_id=588346 Other cases worth trying. Using float.lisp 1.6, they either give very wrong answers or infinite loops: bfloat(1.0e310) bfloat(1.0e320)  Comment By: Barton Willis (willisb) Date: 20020927 11:55 Message: Logged In: YES user_id=570592 I think the problem has to do with the value of $ratepsilon set by the function fixfloat (defined in float.lisp). One fix is to correct the value of $ratepsilon; another fix is to use Lisp's rational function instead of maximarationalize. ;; If this version of fixfloat is buggy, your Lisp may be ;; buggy! (function I added) #+cl (defun fixfloat (x) (cond ((floatp x) (setq x (rationalize x)) (cons (numerator x) (denominator x))) (t x))) ;; New machineindependent version of FIXFLOAT. This may be buggy.  CWH ;; It is buggy! On the PDP10 it dies on (RATIONALIZE 1.16066076E7) ;; which calls FLOAT on some rather big numbers. ($RATEPSILON is approx. ;; 7.45E9)  JPG #(or PDP10 cl) (DEFUN FIXFLOAT (X) (LET (($RATEPSILON #.(EXPT 2.0 (f MACHINEMANTISSAPRECISION)))) (MAXIMARATIONALIZE X)))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=611141&group_id=4933 
From: SourceForge.net <noreply@so...>  20040213 17:41:28

Bugs item #896638, was opened at 20040213 09:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=896638&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: equation and equality Initial Comment: Hello, I don't know if it's a bug, I've done : (C5) is((x=2)=(x=1+1)); (D5) TRUE (C6) is((x=2)=(x=3)); (D6) FALSE (C7) is((x^5=1)=(x*x*x*x*x=1)); (D7) TRUE and every thing was ok for me, but : (C11) is((x*x=1)=(1=x*x)); (D11) FALSE I do not understand ... Can you help me ? Best for you, Denis. (reply to Denis.Bouhineau@... ) note : I have verified ;) (C14) solve(x*x=1); (D14) [x =  1, x = 1] (C15) solve(1=x*x); (D15) [x =  1, x = 1] (C16) is(d14=d15); (D16) TRUE It should be true.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=896638&group_id=4933 
From: SourceForge.net <noreply@so...>  20040212 17:56:26

Bugs item #893633, was opened at 20040209 13:38 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893633&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 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: Barton Willis (willisbl) Date: 20040212 11: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...>  20040212 09:37:11

Bugs item #895581, was opened at 20040212 01:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=895581&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with diff Initial Comment: Hi, i view which the diff command don't function correctly. Example: diff(x+1,x); d  ( x+1) dx Why i don't view the correct result?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=895581&group_id=4933 
From: SourceForge.net <noreply@so...>  20040209 19:50:41

Bugs item #893638, was opened at 20040209 14:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893638&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: declare evenfun/oddfun Initial Comment: declare(f,evenfun) declare(f,oddfun) => Inconsistent Declaration: ...  an error. But if f(x):=0 it is both an evenfun (i.e. f(x)=f(x)) and an oddfun (f(x)=f(x)). So this should be a warning, e.g. Warning: f is being declared as both an evenfun and an oddfun; therefore f is the constant function 0.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893638&group_id=4933 
From: SourceForge.net <noreply@so...>  20040209 19:38:44

Bugs item #893633, was opened at 20040209 14:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893633&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 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)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=893633&group_id=4933 
From: SourceForge.net <noreply@so...>  20040203 21:36:22

Bugs item #889922, was opened at 20040203 14:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=889922&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 1 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: linnew.lisp broken Initial Comment: The file src/linnew.lisp is a "new linear algebra" package. For matrices larger that 9 by 9, it's broken. (There is a switch in the package that handles something differently for matrices that are 10 by 10 or larger.) (C1) h[i,j] := 1/(i + j 1)$ (C2) m : genmatrix(h,10,10)$ (C3) tminverse(m); Error: Too many args (10) to aref Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at AREF. Type :H for Help. MAXIMA>>:q (C4) m : genmatrix(h,3,3)$ (C5) tminverse(m); (big mess deleted ... it's okay.) I don't think linnew.lisp belongs in the src directory. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=889922&group_id=4933 
From: SourceForge.net <noreply@so...>  20040202 23:12:35

Bugs item #887639, was opened at 20040130 09:45 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887639&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: listarray when use_fast_arrays : true Initial Comment: Outputs (D2) and (D4) are okay. But the list (D6) should not contain 'true'. (C1) a[0] : 1$ (C2) listarray(a); (D2) [1] (C3) use_fast_arrays : true$ (C4) listarray(a); (D4) [1] (C5) b[0] : 1$ (C6) listarray(b); (D6) [TRUE, 1] (C7) build_info(); Maxima version: 5.9.0 Maxima build date: 19:10 2/9/2003 host type: i686pcmingw32 lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040202 18:12 Message: Logged In: YES user_id=588346 use_fast_arrays:true has lots of problems: use_fast_arrays: false$ a: [1,2]$ a[3]$ => error OK a[3]: 5$ => error OK a[1,1] => error OK Now compare with the use_fast_arrays: true case. use_fast_arrays: true$ b: [1,2]$ b[3] => error OK b[3]: 5$ => no error ??? b[3] => error ??? b => [1,2] ??? setting b[3] didn't give an error, but has no effect on b c[1]: 5$ c => #<hashtable 234234234> (ridiculous internal thingy prints out) limit(c,x,inf) => internal error, limit doesn't know about arrays d[1,1]:5$ d[1] => false ????  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887639&group_id=4933 
From: SourceForge.net <noreply@so...>  20040202 22:01:15

Bugs item #889329, was opened at 20040202 16:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=889329&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 1 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: user documentation for direc Initial Comment: The user documentation for direc is outdated. The actual value of direc is JRMU. (C1) direc; (D1) JRMU (C2) describe('direc);  Variable: DIREC  The value of this variable is the default file directory for SAVE, STORE, FASSAVE, and STRINGOUT. It is initialized to the user's login name, if he has a disk directory, and to one of the USERSi directories otherwise. DIREC determines to what directory disk files will be written. (D2) FALSE (C3)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=889329&group_id=4933 
From: SourceForge.net <noreply@so...>  20040202 21:43:53

Bugs item #888396, was opened at 20040131 20:34 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=888396&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume conflates programming and math vrbls Initial Comment: Assume/is is not consistent in its treatment of programming vs. mathematical variables x:1$ assume(x<0) => Inconsistent OK, this presumably is equivalent to assume(1<0) assume('x<0) => Inconsistent Questionable. Should 'x really refer to the *programming variable* x here even though it's quoted? but assume(y<0)$ y:1$ => no error This is inconsistent with the situation above. But I certainly don't want every variable assignment to be checking the Assume database! is(y<0) => false OK, 1<0 is false. is('y<0) => true OK if 'y is treated as a *mathematical variable* and uses the assume database, not the programming variable y. But above, assume('x<0) treats them as the same.  >Comment By: Stavros Macrakis (macrakis) Date: 20040202 16:43 Message: Logged In: YES user_id=588346 Clearer demonstration: assume(equal('r,0)) r:10 is(equal('r,0)) => true assume(equal('r,0)) => [inconsistent] assume(not(equal('r,0))) => [redundant] facts() => [ equal(r,0) ] is(equal('r,10)) => false assume(equal('r,10)) => [redundant] is(not(equal('r,10))) => true  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=888396&group_id=4933 
From: SourceForge.net <noreply@so...>  20040201 01:34:35

Bugs item #888396, was opened at 20040131 20:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=888396&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: assume conflates programming and math vrbls Initial Comment: Assume/is is not consistent in its treatment of programming vs. mathematical variables x:1$ assume(x<0) => Inconsistent OK, this presumably is equivalent to assume(1<0) assume('x<0) => Inconsistent Questionable. Should 'x really refer to the *programming variable* x here even though it's quoted? but assume(y<0)$ y:1$ => no error This is inconsistent with the situation above. But I certainly don't want every variable assignment to be checking the Assume database! is(y<0) => false OK, 1<0 is false. is('y<0) => true OK if 'y is treated as a *mathematical variable* and uses the assume database, not the programming variable y. But above, assume('x<0) treats them as the same.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=888396&group_id=4933 