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}
(18) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3
(2) 
4

5

6

7
(1) 
8
(3) 
9

10
(1) 
11
(4) 
12
(4) 
13
(1) 
14

15
(1) 
16

17

18

19

20
(1) 
21
(4) 
22
(5) 
23
(1) 
24

25

26
(2) 
27
(4) 
28
(4) 
29
(3) 
30
(6) 
31
(1) 
From: SourceForge.net <noreply@so...>  20040131 02:00:58

Bugs item #887152, was opened at 20040129 13:02 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=887152&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: translate matrix[1], list[1,2] wrong/FIX Initial Comment: firstrow(m):=m[1]$ firstrow(matrix([a,b],[c,d])) => [a,b] OK translate(firstrow)$ firstrow(matrix([a,b],[c,d])) => false NO! oneone(m):=m[1,1]$ oneone([1,2,3]) => error OK translate(oneone)$ oneone([1,2,3]) => 1 NO! Here is the patch to maref1 to fix these cases: ((and (= (length inds) 1) (or ($listp ar) ($matrixp ar))) (nth (first inds) ar)) ((and ($matrixp ar) (= (length inds) 2)) (nth (second inds) (nth (first inds) ar)))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887152&group_id=4933 
From: SourceForge.net <noreply@so...>  20040130 22:31:09

Bugs item #887025, was opened at 20040129 16:19 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=887025&group_id=4933 Category: Lisp Core Group: Fix for 5.9.0 Status: Open Resolution: None Priority: 5 Submitted By: Giammanco Raimondo (rongten) Assigned to: Nobody/Anonymous (nobody) Summary: linsolve/algsys erroneous behavior Initial Comment: The linsolve and algsys command are used to solve two different linear systems: ####################### kill (all)$ array(coe,4)$ list_eq : [coe[4]+coe[3]+coe[2]+coe[1] = 1, coe[2]*DY/(2*coeff_y)coe[1]*DY/(2*coeff_y)+coe[4]*DY/2+coe[3]*DY/2 = 0, coe[4]*DX/(2*coeff_x)+coe[3]*DX/(2*coeff_x)coe[2]*DX/(2*coeff_x) + coe[1]*DX/(2*coeff_x) = 0]$ list_un : [coe[1],coe[2],coe[3],coe[4]]$ sol : linsolve(list_eq,list_un)$ test : ratsimp(subst(sol,list_eq))$ display(test)$ sol_bis : (algsys(list_eq,list_un))[1]$ test_bis : ratsimp(subst(sol_bis,list_eq)); display(test_bis)$ array(coe_2,6)$ list_eq_2 : [coe_2[3]+coe_2[2]+coe_2[1] = 0,coe_2[3]*DXcoe_2[2]*DX+coe_2[6]+coe_2[5]+coe_2[4] = 1, coe_2[3]*DX^2/2+coe_2[2]*DX^2/2+coe_2[6]*DXcoe_2[5]*DX = 0, coe_2[3]*DX^3/6coe_2[2]*DX^3/6+coe_2[6]*DX^2/2+coe_2[5]*DX^2/2 = 0, coe_2[3]*DX^4/24+coe_2[2]*DX^4/24+coe_2[6]*DX^3/6coe_2[5]*DX^3/6 = 0]$ list_un_2 : [coe_2[1],coe_2[2],coe_2[3],coe_2[4],coe_2[5],coe_2[6]]$ sol_2 : linsolve(list_eq_2,list_un_2)$ test_2 : ratsimp(subst(sol_2,list_eq_2)); display(test_2)$ sol_2_bis : (algsys(list_eq_2,list_un_2))[1]$ test_2_bis : ratsimp(subst(sol_2_bis,list_eq_2)); display(test_2_bis)$ ##################### For the first system linsolve provide an erroneous result, while algsys gives the correct answer. For the second one, linsolve is correct, while algsys crashes with output: ############################## Typeerror in KERNEL::OBJECTNOTLISTERRORHANDLER: #:G4445 is not of type LIST ############################## This behavior has been reported to the maxima mailing list with the initial thread of "linsolve strange behavior" on 26 Jan 2004. According to a response to the thread: >>>> My guess is this is yet (another) bug related to expressions that are made into CRE expressions in some incorrect manner, jumbling the correspondence between internal generated symbols and external names. <<<< System Specs: Gentoo/GNU/Linux Kernel: 2.4.24 Glibc: glibc2.3.2 Gcc: gcc3.2.3 GCL: gcl2.5.2 CMUCL: cmucl18e MAXIMA:5.9.0 Reported the same problem on W2K, 5.9.0, GCL 2.5. Best Regards  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887025&group_id=4933 
From: SourceForge.net <noreply@so...>  20040130 20:52:09

Bugs item #887174, was opened at 20040129 13:45 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=887174&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: genmatrix/lambda translate problem Initial Comment: f():=genmatrix(lambda([i,j],3),1,1) f() => matrix([3]) OK translate(f) f() => error This is because genmatrix's semantics are screwy. genmatrix allows a lambdaexpression as a first argument (undocumented), but not a named function (because it treats symbols as array names) or a compiled function. This violates referential transparency. It also breaks translate. The translate case can be patched, either by allowing translated functions as first arg (more inconsistency!), or by having translate cons up a lambda expression (yuck!).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887174&group_id=4933 
From: SourceForge.net <noreply@so...>  20040130 20:13:18

Bugs item #886418, was opened at 20040128 13:15 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: featurep believes that most things are complex Initial Comment: featurep believes that most things are complex; some examples (C1) featurep([],complex); (D1) TRUE (C2) featurep(a < b, complex); (D2) TRUE (C3) 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 What featurep should in these (and many other cases) isn't clear... Barton  >Comment By: Barton Willis (willisbl) Date: 20040129 13:18 Message: Logged In: YES user_id=895922 Yes, make that all! A related problem  Function: FEATUREP (a,f) attempts to determine whether the object a has the feature f on the basis of the facts in the current data base. If so, it returns TRUE, else FALSE. But consider: (C1) featurep(asin(x),real); Is (x  1) (x + 1) positive, negative, or zero? neg; (D1) TRUE This is inconsistent with the documentation  featurep is using facts outside the current database! The next case is just plain wrong; my answers imply x == 1. And asin(1) is real. (C2) featurep(asin(x),real); Is (x  1) (x + 1) positive, negative, or zero? zero; Is x positive or negative? pos; (D2) FALSE (C3) Barton  Comment By: Stavros Macrakis (macrakis) Date: 20040129 12:06 Message: Logged In: YES user_id=588346 Not most things, all things!: (defmfun $featurep (e ind) (cond ... ((eq ind '$complex) t) ...))  Comment By: Barton Willis (willisbl) Date: 20040128 14:25 Message: Logged In: YES user_id=895922 I forgot to login; so that comments get sent to me, I'll attach this comment. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 
From: SourceForge.net <noreply@so...>  20040130 19:13:29

Bugs item #887639, was opened at 20040130 08:45 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=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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887639&group_id=4933 
From: SourceForge.net <noreply@so...>  20040130 19:12:14

Bugs item #887646, was opened at 20040130 08:49 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=887646&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: bogus PV integral [defint(exp(a*x),x,0,inf)] Initial Comment: (C1) defint(exp(a*x),x,0,inf); Is a positive, negative, or zero? zero;Principal Value (D1) 0 This isn't a PV integral; the integral diverges when a == 0. (C2) 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  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=887646&group_id=4933 
From: SourceForge.net <noreply@so...>  20040130 03:58:56

Bugs item #886418, was opened at 20040128 14:15 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: featurep believes that most things are complex Initial Comment: featurep believes that most things are complex; some examples (C1) featurep([],complex); (D1) TRUE (C2) featurep(a < b, complex); (D2) TRUE (C3) 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 What featurep should in these (and many other cases) isn't clear... Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040129 13:06 Message: Logged In: YES user_id=588346 Not most things, all things!: (defmfun $featurep (e ind) (cond ... ((eq ind '$complex) t) ...))  Comment By: Barton Willis (willisbl) Date: 20040128 15:25 Message: Logged In: YES user_id=895922 I forgot to login; so that comments get sent to me, I'll attach this comment. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 
From: SourceForge.net <noreply@so...>  20040129 23:20:23

Bugs item #877719, was opened at 20040115 13:07 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=877719&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrate and assume Initial Comment: This is okay: (C1) integrate(exp(a*x),x,0,inf); Is a positive, negative, or zero? pos; Integral is divergent The assumption on "a" is local  (C2) is(a > 0); MACSYMA was unable to evaluate the predicate: But integrate remembers the assumption on "a." I think this is a bad feature: (C3) integrate(exp(a*x),x,0,inf); Integral is divergent Wait! Look what happends if we trace ?assume. It seems that integrate forgets the assumption on "a" and once again asks for the sign of "a." (C4) trace(?assume)$ (C5) integrate(exp(a*x),x,0,inf); 1 Enter ?ASSUME [*Z* > 0] 1 Exit ?ASSUME *Z* > 0 ... (stuff deleted) Is a positive, negative, or zero? neg; 1 Enter ?ASSUME [x > 0] 1 Exit ?ASSUME x > 0 1 Enter ?ASSUME [x > 0] 1 Exit ?ASSUME x > 0 1 Enter ?ASSUME [INF > x] ...(stuff deleted) (D5) 1/a Is this a bug with gcl's trace? (C8) 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: 20040125 14:14 Message: Logged In: YES user_id=588346 Same bug as 626607.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=877719&group_id=4933 
From: SourceForge.net <noreply@so...>  20040129 07:55:56

Bugs item #880767, was opened at 20040120 13:32 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't plot 1/0, but won't stop trying... Initial Comment: plot2d(1/x,[x,1,1]); The foregoing sends maxima into an infinite loop. Also, simply typing y=1e999; causes an overflow error, requiring a restart. Is it supposed to be this fragile? system is windows XP quiasmox@...  Comment By: Raymond Toy (rtoy) Date: 20040122 13:43 Message: Logged In: YES user_id=28849 If this is important to you, you'll have to get a CVS version, where this is fixed.  Comment By: Nobody/Anonymous (nobody) Date: 20040121 10:03 Message: Logged In: NO The version was 5.5. Today I downloaded 5.9, and I don't know what happened, because I downloaded the 5.5 just Monday this week. In any case, the version 5.9 doesn't show the business about y=1e999. I put in y=1e10000, and it dutifully printed 10000 zeroes on the screen. I suppose I need to read the documentation about formatting. There is still a problem with plotting, though. I tried plot2d(x,[x,1,1]); and plot2d(x/1000,[x,1,1]); they both plot instantaneously. However, plot2d(x/0.001,[x,1,1]); took 55 seconds to plot. This is on the windows version 5.9 of maxima, just downloaded and installed today, 1/21/04. John  Comment By: Raymond Toy (rtoy) Date: 20040120 20:20 Message: Logged In: YES user_id=28849 What version of maxima? This doesn't happen in the CVS version of maxima, which has adaptive plotting.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 
From: SourceForge.net <noreply@so...>  20040129 06:37:51

Bugs item #883121, was opened at 20040123 12:02 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=883121&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Toy (rtoy) Assigned to: Nobody/Anonymous (nobody) Summary: plot2d(1,[x,0,10] no longer works Initial Comment: plot2d(<number>,...) no longer works. It used to work in maxima 5.6 and I think it worked in 5.9, but current CVS doesn't.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=883121&group_id=4933 
From: SourceForge.net <noreply@so...>  20040128 20:25:08

Bugs item #886418, was opened at 20040128 13:15 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: featurep believes that most things are complex Initial Comment: featurep believes that most things are complex; some examples (C1) featurep([],complex); (D1) TRUE (C2) featurep(a < b, complex); (D2) TRUE (C3) 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 What featurep should in these (and many other cases) isn't clear... Barton  >Comment By: Barton Willis (willisbl) Date: 20040128 14:25 Message: Logged In: YES user_id=895922 I forgot to login; so that comments get sent to me, I'll attach this comment. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 
From: SourceForge.net <noreply@so...>  20040128 19:15:27

Bugs item #886418, was opened at 20040128 11:15 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=886418&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: featurep believes that most things are complex Initial Comment: featurep believes that most things are complex; some examples (C1) featurep([],complex); (D1) TRUE (C2) featurep(a < b, complex); (D2) TRUE (C3) 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 What featurep should in these (and many other cases) isn't clear... Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886418&group_id=4933 
From: SourceForge.net <noreply@so...>  20040128 18:36:12

Bugs item #866706, was opened at 20031228 12:00 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866706&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ('m)[1] (meval) Initial Comment: ('m)[1] currently returns m(1). It should return m[1].  >Comment By: Stavros Macrakis (macrakis) Date: 20040128 13:36 Message: Logged In: YES user_id=588346 cf bug 866706  Comment By: Stavros Macrakis (macrakis) Date: 20040108 14:59 Message: Logged In: YES user_id=588346 Peculiarly, (m)[1] => m[1]  actually parses as m[1] (1,'m)[1] => m[1] (0+'m)[1] => m[1]  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=866706&group_id=4933 
From: SourceForge.net <noreply@so...>  20040128 18:34:22

Bugs item #886392, was opened at 20040128 13: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=886392&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ('[a,b,c])[2] and ('v)[2] Initial Comment: arrayapply('[a,b],[2]) => b OK ('[a,b])[2] => Illegal form  SIMPLIFYA: ((((MLIST) $a $b)) 2) cf bug 866706: ('m)[1] => m(2), not v[2] What is going on here is that Maxima wants to treat ('f)(x) == funmake('f,[x]) == apply('('f),[x]) which I find a very poor convention, because it means that the (...)(...) construction is noncompositional. After all, ('f+0)(x) == apply('f,[x]) So, ... how do you explain this? Do you consider ('...)() == ('(...))() to be a special *syntactic* construction, even though the parser doesn't parse it into any sort of special internal form? Yuck, yuck, yuck. The fact that apply('('f),...) is specialcased is less problematic, but still weird, since apply('('f+0),...) does the same thing, though apply('(factor('fff)),[x]) gives an error. More yuck. Ayway it doesn't use funmake to construct the result, so screws up the error. I am not sure what the best fix is. I am tempted to completely eliminate ('f)(x) and apply('('f)...) as special cases. Then everything "just works". True, you need to use funmake to avoid evaluating, but that should be OK.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=886392&group_id=4933 
From: SourceForge.net <noreply@so...>  20040127 21:38:36

Bugs item #549226, was opened at 20020426 09:31 Message generated for change (Comment added) made by fjoliveira You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=549226&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with user input Initial Comment:  Some remarks on Userinput of GPL Maxima/Win. (W. Lindner)  Problems with TSETUP(), METRIC(), ENTERTENSOR(), TTRANSFORM() etc.: 1. Studying a Log session of Valerij Pipin, the following behaviour seems intended: (C16) PRINT( Please input tensor name and others,like, name : A; covariant indices: [I,J]; contravariant indices: K; derivative indices: [];, ENTERTENSOR()) Enter tensor name: A; Enter a list of the covariant indices: [I,J]; Enter a list of the contravariant indices: K; Enter a list of the derivative indices: []; K (D16) A I/J Please input tensor name and others,like, name : A; covariant indices: [I,J]; contravariant indices: K; derivative indices: []; A([I, J], [K]) 2. BUT actually it goes like this: (C16) PRINT( Please input tensor name and others,like, name : A; covariant indices: contravariant indices: derivative indices: , ENTERTENSOR()) A; [I,J]; K; [];Enter tensor name: Enter a list of the covariant indices: Enter a list of the contravariant indices: Enter a list of the derivative indices: K (D16) A I J Please input tensor name and others,like, name : A; covariant indices: [I,J]; contravariant indices: K; derivative indices: []; A([I, J], [K]) 3. To sum up, a. ENTERTENSOR() does not make an dialog with the user, but is SEEMS hanging in a loop. Giving the input 'A; [I,J]; K; [];' nevertheless at demo prompt _; (bug in maximal help page: space don't work  use _; !), the input is taken correctly by ENTERTENSOR, and AT THE END all dialog text is shipped out, what makes now no sense, see above. b. Similar behavier found in METRIC(), TTRANSFORM(), TSETUP(): After input METRIC()$, the system seems hanging; giving y; (for YES), the output comes with user query appended (! instead of coming first).  OStR Wolfgang Lindner Tel : +49 (0203) 3791326 GerhardMercatorUniversität Duisburg Fax : +49 (0203) 3792528 Fakultät 4  Naturwissenschaften eMail: Lindner@... Institut fuer Mathematik, LE 424 Lotharstr. 65 D 47048 Duisburg (Germany)  Comment By: Firmin Joseph Oliveira (fjoliveira) Date: 20040127 11:38 Message: Logged In: YES user_id=961659 Maxima version: 5.9.0 Maxima build date: 13:50 4/15/2003 host type: i686pclinuxgnu lispimplementationtype: CMU Common Lisp lispimplementationversion: 18e Problem with CTENSR package: TSETUP(); I did not get any prompting for input (such as "Enter the dimension...", or "Do you wish to change the coordinate names?", etc. However I was able to get things to work by entering the expected input information along with a carriage return after each input item. For example, what worked was the following: tsetup();<cr>4;<cr>[r,h,p,t];<cr>1;<cr>1;<cr>A;<cr>r^2;<cr>r^2*sin(h)^2;<cr>D;<cr>depends([A,D],r);<cr>y;<cr>y;<cr> after which the metric tensor and it's inverse were displayed and I could proceed. Upon initial start up of 'xmaximalocal' the following error messages were reported:  maia:maxima5.9.0> Maxima 5.9.0 http://maxima.sourceforge.net Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (C1) ; ; Warning: These variables are undefined: ; *SOCKETCONNECTION* ME ; ; ; Warning: These functions are undefined: ; HOSTENTNAME RESOLVEHOSTIPADDR maia:maxima5.9.0>  User comment: it may be that the problem is with the socket errors above?  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=549226&group_id=4933 
From: SourceForge.net <noreply@so...>  20040127 21:02:51

Bugs item #885795, was opened at 20040127 16:02 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=885795&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: f(i)==f(j) where i==j (is/equal fails) Initial Comment: As a shorthand in this note, I'll use a==b to mean is (equal(a,b)). assume(equal(i,j)) x[i] == x[j] => Unknown NO! f(i) == f(j) => Unknown NO! sin(i) == sin(j) => Unknown NO! sinh(i) == sinh(j) => True OK!!!! It turns out that it has to do with the Increasing property, even though of course that is completely irrelevant: declare(g,increasing) g(i) == g(j) => true OK Strangely, Decreasing doesn't work: declare(h,decreasing) h(i) == h(j) => Unknown ??? I guess that technically this is an enhancement request (Unknown is always a valid way to give up), but....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=885795&group_id=4933 
From: SourceForge.net <noreply@so...>  20040127 20:48:41

Bugs item #884947, was opened at 20040126 13:34 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&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/equal doesn't work for [], matrix, etc./FIX Initial Comment: Currently, IS doesn't understand semanticequality of bags (lists, matrices, sets) at all: is(equal([1],[1])) => true OK is(equal([0],[1])) => Unknown NO The first case only works because the two expressions are syntactically equal (is/= or ?like). The problem is that meqp uses compare, which compares x and y by comparing xy to (scalar) 0, obviously irrelevant here. The solution is to explicitly add bags to meqp and mnqp. See code attached. With this code, we have: is(equal([1],[1])) => true is(equal([0],[1])) => false is(equal([a,0],[a,1])) => false is(equal([a,b],[a,c])) => unknown HOWEVER: a) this code ignores doscmxplus, so lists are never considered equal to matrices; b) the assume database is not consulted in cases like equal(x,[a,b]), because compar thinks this is the same as equal([xa,x b],0). I considered also adding ordering inequalities (< etc.), but I don't think it's worth it right now given the limited capabilities of compar. Also, it's not clear whether lexicographic ([a,b]<[c,d] iff (a<c or (a=c and b<d)) or dominating order (a<c and b<d  nontrichotomic) is more useful. This was originally reported by Robert Dodier in email.  >Comment By: Stavros Macrakis (macrakis) Date: 20040127 15:48 Message: Logged In: YES user_id=588346 These are some design notes I posted to the Maxima mailing list on this subject. Robert Dodier said: > is(equal([1],[[1]]))) => UNKNOWN. > I would expect that different structures are always not > equal, unless they're equivalent (i.e., you could substitute > one for the other in any expression and get the same result). > So either TRUE or FALSE seems possible here, but not UNKNOWN. I had written code to assume that objects of differing dimensions were different (in particular, that nonscalars can never be equal to scalars), but ran into a whole bunch of inconsistencies in Maxima semantics. These are not accidental inconsistencies, they are not bugs; they are in fact design features to make the use of Maxima more convenient. But as is often the case, convenience conflicts with consistency. Clearly is(1=[1]) is false; remember, = performs structural (syntactic) comparison. However, it is not at all clear whether is(equal(1,[1])) is false. (And whether it is False or True depends not only on various flag settings, but also the context of use.) Consider: Lists, 1xn, and nx1 matrices are coerced into each other in various ways and with Scalarmatrixp=True (the default), a 1x1 matrix is converted to a scalar: [1,2] . matrix([3],[4]) => 11 [1,2] . matrix([3,4]) => 11 matrix([1,2]).matrix([3,4]) => 11 matrix([1],[2]).matrix([3],[4]) => 11 So perhaps 11 == [11] and [1,2] == matrix([1,2]) == matrix ([1],[2]) ? On the other hand, matrix([11]) by itself does not automatically simplify to 11 and 11[11]=>[0], not 0. Of course, outside the context of vector/matrix operations, lists, 1xn matrices, and nx1 matrices are completely distinct: after all, member(a,[a,b]) => true and member(a,matrix([a,b])) => false. Now consider symbolic expressions. You might think that a==b must be false if nonscalar(a) and scalar(b). But that's not true. If you declare(vec,nonscalar), then nonscalar (vec.vec) => True, though in fact the .product of two vectors is a scalar (nonscalar is a *syntactic* check for the presence of nonscalar objects within the expression tree). So it is wrong to assume that is(equal(vec1.vec2,0)) is false because nonscalar(vec1.vec2)=True and nonscalar(0)=False. This is not theoretical. I think it perfectly reasonable that a user might check whether q and r are perpendicular by checking is(equal(q.r,0)), where q and r are sometimes concrete vectors  in which case you might well get a valid True or False , sometimes symbols (in which case the answer should be Unknown, not False). There is another simple case that has nothing to do with vector/matrix semantics. To do bag comparisons correctly, you need to solve conjunctions: [x,x] =? [1,2] is equivalent to (x==1 and x==2), which is clearly false, but Is doesn't know it. Similarly for [x,1] =? [1,x+1]. Another limitation on the power of is/equal/bag: the compar subsystem is not currently terribly useful for vectors etc. For example, assume(equal(q,[a,b])), is(equal(q,[a,b+1])) => Unknown. I think there are several possible conclusions for all this: 1) Make Maxima more rigorous. Distinguish between lists, vectors, and 1xn matrices everywhere. Distinguish between scalars, 1vectors, and 1x1 matrices everywhere. In that case, the correct results for is/equal are much clearer. But pragmatism is one of the central characteristics of Maxima; there are certainly other systems which emphasize rigor, with its advantages and disadvantages. 2) Decide that is/equal/bag always refers to .product semantics (not list semantics and not + or * semantics): if two objects act the same in the context of a .product, then they are the same. 2ay) The result of is/equal depends on the various switches controlling vector/matrix operations. So if Scalarmatrixp and Listarith are true, then 1 == [1] == matrix([1]). 2by) Assume default settings for the various switches. 2xa) Consider an nlist, an nrow, and an ncolumn equal (with appropriate switches set), even though they don't act equally in all contexts. 2xb) Consider an nlist and an nrow equal, but not an n column. 3) Decide that is/equal/bag is true iff there is NO context in which the objects can be distinguished. This emphasizes the programmingtype aspect of Maxima over the mathematical aspect. But 'equal' is supposed to be about mathematical equality. After all, is/equal considers 1/2, 0.5, and 0.5b0 to be equal, even though 1/2 is an exact number and 0.5 and 0.5b0 are approximate. 3a) Assume that nonscalar *identifiers* (but not nonscalar expressions) are never equal to scalars. 3b) Do not take into account the nonscalar property of identifiers. 4) Maintain the current behavior, which gives Unknown for all the difficult cases. What I had started out trying to program was 2aa, but it was too messy (because when I started, I was also trying to take into account the behavior of + and *). Now that I've written out this design note, it seems like the two reasonable alternatives are 3a and 2ax (not sure whether 2aa or 2ab is better). But I suspect that in actual fact, I have already spent too much time on this, that no one but Robert will ever care, and that 4 is just fine....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&group_id=4933 
From: SourceForge.net <noreply@so...>  20040127 14:20:30

Bugs item #875102, was opened at 20040111 16:43 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875102&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barton Willis (willisbl) Assigned to: Nobody/Anonymous (nobody) Summary: integrands involving false Initial Comment: When ?defint isn't able to find the value of a definite integral, it returns false, and it's the job of $defint to return a correct noun form. Maxima allows false to be used as an identifer  this allows $defint to get mixed up; for example (C1) defint(false,x,0,1); (D1) 'INTEGRATE(FALSE,x,0,1) (C2) defint(false,x,0,2); (D2) 2*FALSE (C3) 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 This bug may not be worth fixing; it might be better to disallow true, false, und, ... to be used this way. Barton  >Comment By: Stavros Macrakis (macrakis) Date: 20040125 14:11 Message: Logged In: YES user_id=588346 The true/false and ind/und/inf cases are different. integrate(true,...) doesn't make sense, because true is a boolean constant, and there is no good reason to arbitrarily convert boolean functions to real functions (e.g. false=0). So either a noun form or an error or even (ba)*true seem like perfectly OK (non)results. Sure, it would be nice if it were perfectly consistent, but.... The ind/und/inf cases, on the other hand, are not even Integrate issues. Integrate(nnn,x,a,b) where nnn is one of those is = (ba)*nnn. If the simplifier gets that right, then Integrate will get that right. So integrate(inf,a,0,1)=>inf, integrate(inf,a,0,0)=inf*0=und, integrate(ind,a,0,1) =ind*1=ind, integrate(ind,a,0,0)=ind*0=0, integrate (ind,a,0,inf)=ind*inf=und, etc. But currently the simplifier does NOT get simplifications involving nonstandard numbers (inf, minf, infinity, ind, und) right.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=875102&group_id=4933 
From: SourceForge.net <noreply@so...>  20040126 18:34:49

Bugs item #884947, was opened at 20040126 13: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=884947&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/equal doesn't work for [], matrix, etc./FIX Initial Comment: Currently, IS doesn't understand semanticequality of bags (lists, matrices, sets) at all: is(equal([1],[1])) => true OK is(equal([0],[1])) => Unknown NO The first case only works because the two expressions are syntactically equal (is/= or ?like). The problem is that meqp uses compare, which compares x and y by comparing xy to (scalar) 0, obviously irrelevant here. The solution is to explicitly add bags to meqp and mnqp. See code attached. With this code, we have: is(equal([1],[1])) => true is(equal([0],[1])) => false is(equal([a,0],[a,1])) => false is(equal([a,b],[a,c])) => unknown HOWEVER: a) this code ignores doscmxplus, so lists are never considered equal to matrices; b) the assume database is not consulted in cases like equal(x,[a,b]), because compar thinks this is the same as equal([xa,x b],0). I considered also adding ordering inequalities (< etc.), but I don't think it's worth it right now given the limited capabilities of compar. Also, it's not clear whether lexicographic ([a,b]<[c,d] iff (a<c or (a=c and b<d)) or dominating order (a<c and b<d  nontrichotomic) is more useful. This was originally reported by Robert Dodier in email.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884947&group_id=4933 
From: SourceForge.net <noreply@so...>  20040126 12:43:50

Bugs item #884300, was opened at 20040125 13:57 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=884300&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: solve and ALL Initial Comment: Solve/algsys is inconsistent in how it represents the solution "all values satisfy the equation": solve([x=x],x) returns ALL solve([y=y],x) returns ALL solve([x=x],[x]) returns ALL solve([x=x],[x,y]) returns [[x = %R10, y = %R9]] solve([],[x]) returns [] First of all, the last case is simply wrong. The solution to "find all x such that the empty set of constraints is satisfied" is "all x", not "no x" (which is what [] means). After all, the y=y case above includes an equation which doesn't even mention x. The other cases are inconsistent. We should use one or the other. The %R10 approach (from algsys) seems better, because it is completely consistent with the non all case. Any program using Solve will have to make a special case for ALL otherwise. I would also argue that SOLVE_INCONSISTENT_ERROR should default to FALSE. That is, inconsistent systems should return [], not give an error.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=884300&group_id=4933 
From: SourceForge.net <noreply@so...>  20040123 02:48:34

Bugs item #882270, was opened at 20040122 18:45 Message generated for change (Comment added) made by diemer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=882270&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas Diemer (diemer) Assigned to: Nobody/Anonymous (nobody) Summary: Can't plot over a singularity Initial Comment: Hi! Right now, if you try plot2d(1/x,[x,1,1]); xmaxima hangs... Can you make it possible to plot over a singularity? Regards Jonas  >Comment By: Jonas Diemer (diemer) Date: 20040122 19:30 Message: Logged In: YES user_id=154672 version 5.9.0. I will try the cvs version then, thanks  Comment By: Raymond Toy (rtoy) Date: 20040122 19:12 Message: Logged In: YES user_id=28849 What version? This bug is fixed in the CVS sources.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=882270&group_id=4933 
From: SourceForge.net <noreply@so...>  20040122 18:43:41

Bugs item #880767, was opened at 20040120 13:32 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't plot 1/0, but won't stop trying... Initial Comment: plot2d(1/x,[x,1,1]); The foregoing sends maxima into an infinite loop. Also, simply typing y=1e999; causes an overflow error, requiring a restart. Is it supposed to be this fragile? system is windows XP quiasmox@...  >Comment By: Raymond Toy (rtoy) Date: 20040122 13:43 Message: Logged In: YES user_id=28849 If this is important to you, you'll have to get a CVS version, where this is fixed.  Comment By: Nobody/Anonymous (nobody) Date: 20040121 10:03 Message: Logged In: NO The version was 5.5. Today I downloaded 5.9, and I don't know what happened, because I downloaded the 5.5 just Monday this week. In any case, the version 5.9 doesn't show the business about y=1e999. I put in y=1e10000, and it dutifully printed 10000 zeroes on the screen. I suppose I need to read the documentation about formatting. There is still a problem with plotting, though. I tried plot2d(x,[x,1,1]); and plot2d(x/1000,[x,1,1]); they both plot instantaneously. However, plot2d(x/0.001,[x,1,1]); took 55 seconds to plot. This is on the windows version 5.9 of maxima, just downloaded and installed today, 1/21/04. John  Comment By: Raymond Toy (rtoy) Date: 20040120 20:20 Message: Logged In: YES user_id=28849 What version of maxima? This doesn't happen in the CVS version of maxima, which has adaptive plotting.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=880767&group_id=4933 
From: SourceForge.net <noreply@so...>  20040122 18:42:03

Bugs item #882270, was opened at 20040122 12:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=882270&group_id=4933 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jonas Diemer (diemer) Assigned to: Nobody/Anonymous (nobody) Summary: Can't plot over a singularity Initial Comment: Hi! Right now, if you try plot2d(1/x,[x,1,1]); xmaxima hangs... Can you make it possible to plot over a singularity? Regards Jonas  >Comment By: Raymond Toy (rtoy) Date: 20040122 13:42 Message: Logged In: YES user_id=28849 Closed.  Comment By: Jonas Diemer (diemer) Date: 20040122 13:30 Message: Logged In: YES user_id=154672 version 5.9.0. I will try the cvs version then, thanks  Comment By: Raymond Toy (rtoy) Date: 20040122 13:12 Message: Logged In: YES user_id=28849 What version? This bug is fixed in the CVS sources.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=882270&group_id=4933 
From: SourceForge.net <noreply@so...>  20040122 18:12:06

Bugs item #882270, was opened at 20040122 12:45 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=882270&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas Diemer (diemer) Assigned to: Nobody/Anonymous (nobody) Summary: Can't plot over a singularity Initial Comment: Hi! Right now, if you try plot2d(1/x,[x,1,1]); xmaxima hangs... Can you make it possible to plot over a singularity? Regards Jonas  >Comment By: Raymond Toy (rtoy) Date: 20040122 13:12 Message: Logged In: YES user_id=28849 What version? This bug is fixed in the CVS sources.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=882270&group_id=4933 
From: SourceForge.net <noreply@so...>  20040122 17:45:10

Bugs item #882270, was opened at 20040122 18:45 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=882270&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonas Diemer (diemer) Assigned to: Nobody/Anonymous (nobody) Summary: Can't plot over a singularity Initial Comment: Hi! Right now, if you try plot2d(1/x,[x,1,1]); xmaxima hangs... Can you make it possible to plot over a singularity? Regards Jonas  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=882270&group_id=4933 