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}
(47) 
_{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...>  20040227 16:45:04

Bugs item #531469, was opened at 20020318 13:18 Message generated for change (Comment added) made by lemire You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 Category: Documentation Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: need better documentation for "assume" Initial Comment: Maxima allows for the following very powerful syntax... (C1) (assume (y>1), integrate(x*log(x),x,1,y)); 2 2 2 y LOG(y)  y 1 (D1)  +  4 4 However, the documentation is lacking: Info from file /usr/local/info/maxima.info:  Fonction: ASSUME (pred1, pred2, ...) First checks the specified predicates for redundancy and consistency with the current data base. If the predicates are consistent and nonredundant, they are added to the data base; if inconsistent or redundant, no action is taken. ASSUME returns a list whose entries are the predicates added to the data base and the atoms REDUNDANT or INCONSISTENT where applicable. (D3) FALSE  >Comment By: Daniel Lemire (lemire) Date: 20040227 11:32 Message: Logged In: YES user_id=73205 No, you are right, there is no bug here except for a "request for enhancement" regarding the documentation. I'm not bitching about it since, of course, I could just sit down and start writting document. But short of that, I hope it is useful to at least document in which way the documentation is wong. I didn't know about "facts()". Now, looking at the description of facts, I realize that I don't know about "contexts" in maxima as well. Let's not go there today. Info from file /usr/share/info/maxima.info:  Function: FACTS (item) If 'item' is the name of a context then FACTS returns a list of the facts in the specified context. If no argument is given, it lists the current context. If 'item' is not the name of a context then it returns a list of the facts known about 'item' in the current context. Facts that are active, but in a different context, are not listed.  Comment By: Stavros Macrakis (macrakis) Date: 20040227 09:18 Message: Logged In: YES user_id=588346 I agree that the documentation could be made MUCH MUCH clearer. But I am puzzled by some of your other remarks: > if I do assume(y>0); followed byassume(x>0); > I would expect the system to know x>0 and y>0. > It doesn't. It does on my test system, Maxima 5.9.0 gcl 2.5.0 W2k: assume(x>0); assume(y>0); is( x>0 and y>0 ) => true If this fails on your system, please include a transcript of a session, and full configuration information from bug_report(). > each call to assume reset the set of assumptions No. Not on my system, at least. If it does, this is a bug. The only assumptions that are reset are those added by Asksign  that is also explicit in describe(asksign): "recorded in the data base for the duration of the current computation (one 'Cline')". > In D3, I would expect [x>0,y>0] or something similar. As documented explicitly in the text you quote, the return value reports on the predicates **added to** the data base. To see the list of all current assumptions, use facts(). > I guess I'm supposed to understand that "C comma" > means... what... the C language? Yes, the C programming language has the same construct. Of course, if you happen not to know C, that is not very helpful. Again, I agree that the documentation needs to be improved.  Comment By: Daniel Lemire (lemire) Date: 20040227 08:41 Message: Logged In: YES user_id=73205 Two things are lacking: 1) assume is poorly explained or maybe implemented (?). You say it isn't local... right... then if I do assume(y>0); followed by assume(x>0); I would expect the system to know x>0 and y>0. It doesn't. As far as I can tell, each call to assume reset the set of assumptions to whatever you provide. The documentation mention something about the "current database". I think "assume" clears this database or ignores it. (C2) assume(y>0); (D2) [y > 0] (C3) assume(x>0); (D3) [x > 0] (C4) (In D3, I would expect [x>0,y>0] or something similar.) 2) You are damn good if you can know from the documentation that "(a,b,c) evaluates a then b then c, and returns the value of c." But that's good to know. I would like to see that much written up about it... Here's what I get from "Introduction to Expressions"... """ Most things in MAXIMA are expressions. A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression.""" I guess I'm supposed to understand that "C comma" means... what... the C language?  Comment By: Daniel Lemire (lemire) Date: 20040227 08:40 Message: Logged In: YES user_id=73205 Two things are lacking: 1) assume is poorly explained or maybe implemented (?). You say it isn't local... right... then if I do assume(y>0); followed by assume(x>0); I would expect the system to know x>0 and y>0. It doesn't. As far as I can tell, each call to assume reset the set of assumptions to whatever you provide. The documentation mention something about the "current database". I think "assume" clears this database or ignores it. (C2) assume(y>0); (D2) [y > 0] (C3) assume(x>0); (D3) [x > 0] (C4) (In D3, I would expect [x>0,y>0] or something similar.) 2) You are damn good if you can know from the documentation that "(a,b,c) evaluates a then b then c, and returns the value of c." But that's good to know. I would like to see that much written up about it... Here's what I get from "Introduction to Expressions"... """ Most things in MAXIMA are expressions. A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression.""" I guess I'm supposed to understand that "C comma" means... what... the C language?  Comment By: Stavros Macrakis (macrakis) Date: 20040223 19:11 Message: Logged In: YES user_id=588346 What exactly do you think is lacking in this documentation? You talk about the "syntax"  do you mean the comma syntax (xxx, yyy)? That is not specific to assume  and beware, the assumptions are NOT local! The comma syntax is documented under "Introduction to Expressions": >>>>> A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression. <<<<< In other words, (a,b,c) evaluates a then b then c, and returns the value of c.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 
From: SourceForge.net <noreply@so...>  20040227 14:31:25

Bugs item #531469, was opened at 20020318 13:18 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 Category: Documentation Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: need better documentation for "assume" Initial Comment: Maxima allows for the following very powerful syntax... (C1) (assume (y>1), integrate(x*log(x),x,1,y)); 2 2 2 y LOG(y)  y 1 (D1)  +  4 4 However, the documentation is lacking: Info from file /usr/local/info/maxima.info:  Fonction: ASSUME (pred1, pred2, ...) First checks the specified predicates for redundancy and consistency with the current data base. If the predicates are consistent and nonredundant, they are added to the data base; if inconsistent or redundant, no action is taken. ASSUME returns a list whose entries are the predicates added to the data base and the atoms REDUNDANT or INCONSISTENT where applicable. (D3) FALSE  >Comment By: Stavros Macrakis (macrakis) Date: 20040227 09:18 Message: Logged In: YES user_id=588346 I agree that the documentation could be made MUCH MUCH clearer. But I am puzzled by some of your other remarks: > if I do assume(y>0); followed byassume(x>0); > I would expect the system to know x>0 and y>0. > It doesn't. It does on my test system, Maxima 5.9.0 gcl 2.5.0 W2k: assume(x>0); assume(y>0); is( x>0 and y>0 ) => true If this fails on your system, please include a transcript of a session, and full configuration information from bug_report(). > each call to assume reset the set of assumptions No. Not on my system, at least. If it does, this is a bug. The only assumptions that are reset are those added by Asksign  that is also explicit in describe(asksign): "recorded in the data base for the duration of the current computation (one 'Cline')". > In D3, I would expect [x>0,y>0] or something similar. As documented explicitly in the text you quote, the return value reports on the predicates **added to** the data base. To see the list of all current assumptions, use facts(). > I guess I'm supposed to understand that "C comma" > means... what... the C language? Yes, the C programming language has the same construct. Of course, if you happen not to know C, that is not very helpful. Again, I agree that the documentation needs to be improved.  Comment By: Daniel Lemire (lemire) Date: 20040227 08:41 Message: Logged In: YES user_id=73205 Two things are lacking: 1) assume is poorly explained or maybe implemented (?). You say it isn't local... right... then if I do assume(y>0); followed by assume(x>0); I would expect the system to know x>0 and y>0. It doesn't. As far as I can tell, each call to assume reset the set of assumptions to whatever you provide. The documentation mention something about the "current database". I think "assume" clears this database or ignores it. (C2) assume(y>0); (D2) [y > 0] (C3) assume(x>0); (D3) [x > 0] (C4) (In D3, I would expect [x>0,y>0] or something similar.) 2) You are damn good if you can know from the documentation that "(a,b,c) evaluates a then b then c, and returns the value of c." But that's good to know. I would like to see that much written up about it... Here's what I get from "Introduction to Expressions"... """ Most things in MAXIMA are expressions. A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression.""" I guess I'm supposed to understand that "C comma" means... what... the C language?  Comment By: Daniel Lemire (lemire) Date: 20040227 08:40 Message: Logged In: YES user_id=73205 Two things are lacking: 1) assume is poorly explained or maybe implemented (?). You say it isn't local... right... then if I do assume(y>0); followed by assume(x>0); I would expect the system to know x>0 and y>0. It doesn't. As far as I can tell, each call to assume reset the set of assumptions to whatever you provide. The documentation mention something about the "current database". I think "assume" clears this database or ignores it. (C2) assume(y>0); (D2) [y > 0] (C3) assume(x>0); (D3) [x > 0] (C4) (In D3, I would expect [x>0,y>0] or something similar.) 2) You are damn good if you can know from the documentation that "(a,b,c) evaluates a then b then c, and returns the value of c." But that's good to know. I would like to see that much written up about it... Here's what I get from "Introduction to Expressions"... """ Most things in MAXIMA are expressions. A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression.""" I guess I'm supposed to understand that "C comma" means... what... the C language?  Comment By: Stavros Macrakis (macrakis) Date: 20040223 19:11 Message: Logged In: YES user_id=588346 What exactly do you think is lacking in this documentation? You talk about the "syntax"  do you mean the comma syntax (xxx, yyy)? That is not specific to assume  and beware, the assumptions are NOT local! The comma syntax is documented under "Introduction to Expressions": >>>>> A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression. <<<<< In other words, (a,b,c) evaluates a then b then c, and returns the value of c.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 
From: SourceForge.net <noreply@so...>  20040227 13:54:36

Bugs item #531469, was opened at 20020318 13:18 Message generated for change (Comment added) made by lemire You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 >Category: Documentation Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: need better documentation for "assume" Initial Comment: Maxima allows for the following very powerful syntax... (C1) (assume (y>1), integrate(x*log(x),x,1,y)); 2 2 2 y LOG(y)  y 1 (D1)  +  4 4 However, the documentation is lacking: Info from file /usr/local/info/maxima.info:  Fonction: ASSUME (pred1, pred2, ...) First checks the specified predicates for redundancy and consistency with the current data base. If the predicates are consistent and nonredundant, they are added to the data base; if inconsistent or redundant, no action is taken. ASSUME returns a list whose entries are the predicates added to the data base and the atoms REDUNDANT or INCONSISTENT where applicable. (D3) FALSE  >Comment By: Daniel Lemire (lemire) Date: 20040227 08:41 Message: Logged In: YES user_id=73205 Two things are lacking: 1) assume is poorly explained or maybe implemented (?). You say it isn't local... right... then if I do assume(y>0); followed by assume(x>0); I would expect the system to know x>0 and y>0. It doesn't. As far as I can tell, each call to assume reset the set of assumptions to whatever you provide. The documentation mention something about the "current database". I think "assume" clears this database or ignores it. (C2) assume(y>0); (D2) [y > 0] (C3) assume(x>0); (D3) [x > 0] (C4) (In D3, I would expect [x>0,y>0] or something similar.) 2) You are damn good if you can know from the documentation that "(a,b,c) evaluates a then b then c, and returns the value of c." But that's good to know. I would like to see that much written up about it... Here's what I get from "Introduction to Expressions"... """ Most things in MAXIMA are expressions. A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression.""" I guess I'm supposed to understand that "C comma" means... what... the C language?  Comment By: Daniel Lemire (lemire) Date: 20040227 08:40 Message: Logged In: YES user_id=73205 Two things are lacking: 1) assume is poorly explained or maybe implemented (?). You say it isn't local... right... then if I do assume(y>0); followed by assume(x>0); I would expect the system to know x>0 and y>0. It doesn't. As far as I can tell, each call to assume reset the set of assumptions to whatever you provide. The documentation mention something about the "current database". I think "assume" clears this database or ignores it. (C2) assume(y>0); (D2) [y > 0] (C3) assume(x>0); (D3) [x > 0] (C4) (In D3, I would expect [x>0,y>0] or something similar.) 2) You are damn good if you can know from the documentation that "(a,b,c) evaluates a then b then c, and returns the value of c." But that's good to know. I would like to see that much written up about it... Here's what I get from "Introduction to Expressions"... """ Most things in MAXIMA are expressions. A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression.""" I guess I'm supposed to understand that "C comma" means... what... the C language?  Comment By: Stavros Macrakis (macrakis) Date: 20040223 19:11 Message: Logged In: YES user_id=588346 What exactly do you think is lacking in this documentation? You talk about the "syntax"  do you mean the comma syntax (xxx, yyy)? That is not specific to assume  and beware, the assumptions are NOT local! The comma syntax is documented under "Introduction to Expressions": >>>>> A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression. <<<<< In other words, (a,b,c) evaluates a then b then c, and returns the value of c.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 
From: SourceForge.net <noreply@so...>  20040227 13:52:51

Bugs item #531469, was opened at 20020318 13:18 Message generated for change (Comment added) made by lemire You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 Category: None Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: need better documentation for "assume" Initial Comment: Maxima allows for the following very powerful syntax... (C1) (assume (y>1), integrate(x*log(x),x,1,y)); 2 2 2 y LOG(y)  y 1 (D1)  +  4 4 However, the documentation is lacking: Info from file /usr/local/info/maxima.info:  Fonction: ASSUME (pred1, pred2, ...) First checks the specified predicates for redundancy and consistency with the current data base. If the predicates are consistent and nonredundant, they are added to the data base; if inconsistent or redundant, no action is taken. ASSUME returns a list whose entries are the predicates added to the data base and the atoms REDUNDANT or INCONSISTENT where applicable. (D3) FALSE  >Comment By: Daniel Lemire (lemire) Date: 20040227 08:40 Message: Logged In: YES user_id=73205 Two things are lacking: 1) assume is poorly explained or maybe implemented (?). You say it isn't local... right... then if I do assume(y>0); followed by assume(x>0); I would expect the system to know x>0 and y>0. It doesn't. As far as I can tell, each call to assume reset the set of assumptions to whatever you provide. The documentation mention something about the "current database". I think "assume" clears this database or ignores it. (C2) assume(y>0); (D2) [y > 0] (C3) assume(x>0); (D3) [x > 0] (C4) (In D3, I would expect [x>0,y>0] or something similar.) 2) You are damn good if you can know from the documentation that "(a,b,c) evaluates a then b then c, and returns the value of c." But that's good to know. I would like to see that much written up about it... Here's what I get from "Introduction to Expressions"... """ Most things in MAXIMA are expressions. A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression.""" I guess I'm supposed to understand that "C comma" means... what... the C language?  Comment By: Stavros Macrakis (macrakis) Date: 20040223 19:11 Message: Logged In: YES user_id=588346 What exactly do you think is lacking in this documentation? You talk about the "syntax"  do you mean the comma syntax (xxx, yyy)? That is not specific to assume  and beware, the assumptions are NOT local! The comma syntax is documented under "Introduction to Expressions": >>>>> A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression. <<<<< In other words, (a,b,c) evaluates a then b then c, and returns the value of c.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 
From: SourceForge.net <noreply@so...>  20040226 22:25:29

Bugs item #531469, was opened at 20020318 13:18 Message generated for change (Settings changed) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 Category: None Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: need better documentation for "assume" Initial Comment: Maxima allows for the following very powerful syntax... (C1) (assume (y>1), integrate(x*log(x),x,1,y)); 2 2 2 y LOG(y)  y 1 (D1)  +  4 4 However, the documentation is lacking: Info from file /usr/local/info/maxima.info:  Fonction: ASSUME (pred1, pred2, ...) First checks the specified predicates for redundancy and consistency with the current data base. If the predicates are consistent and nonredundant, they are added to the data base; if inconsistent or redundant, no action is taken. ASSUME returns a list whose entries are the predicates added to the data base and the atoms REDUNDANT or INCONSISTENT where applicable. (D3) FALSE  Comment By: Stavros Macrakis (macrakis) Date: 20040223 19:11 Message: Logged In: YES user_id=588346 What exactly do you think is lacking in this documentation? You talk about the "syntax"  do you mean the comma syntax (xxx, yyy)? That is not specific to assume  and beware, the assumptions are NOT local! The comma syntax is documented under "Introduction to Expressions": >>>>> A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression. <<<<< In other words, (a,b,c) evaluates a then b then c, and returns the value of c.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 
From: SourceForge.net <noreply@so...>  20040226 15:24:13

Bugs item #904522, was opened at 20040225 14:30 Message generated for change (Comment added) made by willisbl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=904522&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylorinfo fatal err in multivar case Initial Comment: taylorinfo(taylor(x,[x,y],0,1)) fatal error Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  >Comment By: Barton Willis (willisbl) Date: 20040226 09:12 Message: Logged In: YES user_id=895922 If you fix this bug, also fix (the easy to fix) bug 867310. Barton  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=904522&group_id=4933 
From: SourceForge.net <noreply@so...>  20040225 21:08:53

Bugs item #904543, was opened at 20040225 15: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=904543&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ratcoeff incompatible with taylor [x,y] Initial Comment: t: taylor(sin(x+y),[x,y],0,5) => y+x.... ratcoeff(t,x,1) => 0+... but ratcoeff(ratdisrep(t),x,1) => (y^412*y^2+24)/24 The ratdisrep case should be taken as the definition. If we don't want to do that, it should at least give an error, saying that it doesn't handle multivariate series. It would be nicer, though, if ratcoeff took multiple arguments, e.g. ratcoeff(t,x,1,y,0) == ratcoeff(ratcoeff(t,x,1),y,0) => x+y ratcoeff(t,[x,y],1) => x+y ratcoeff(t,[x,y],2) => 0 ratcoeff(t,[x,y],3) => (y^3+3*x*y^2+3*x^2*y+x^3)/6 but that's another matter....  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=904543&group_id=4933 
From: SourceForge.net <noreply@so...>  20040225 20:41:44

Bugs item #904522, was opened at 20040225 15:30 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=904522&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: taylorinfo fatal err in multivar case Initial Comment: taylorinfo(taylor(x,[x,y],0,1)) fatal error Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=904522&group_id=4933 
From: SourceForge.net <noreply@so...>  20040225 20:17:27

Bugs item #903935, was opened at 20040225 00:03 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903935&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) >Summary: mul2* doesn't handle floats/FIX Initial Comment: mul2* is the twoargument nonsimplifying symbolic multiplication function (defined in opers.lisp). I think it is incorrect that if its args are numbers, it uses fixnum multiplication (f*) rather than general multiplication (*), though I can't find any cases where it matters. All the other XXX, XXX*, XXX2 and XXX2* operations in opers use general Lisp arithmetic, not fixnum.  >Comment By: Stavros Macrakis (macrakis) Date: 20040225 15:05 Message: Logged In: YES user_id=588346 (defmfun mul2* (x y) (cond #+cl ((and (numberp x) (numberp y)) (* x y)) ;;;;;;;;;;;;; used to be (f* x y) ((=1 x) (simplifya y nil)) ((=1 y) (simplifya x nil)) (t (simplifya `((mtimes) ,x ,y) nil))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903935&group_id=4933 
From: SourceForge.net <noreply@so...>  20040225 20:16:22

Bugs item #904504, was opened at 20040225 15:04 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=904504&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sign1 needs specrepcheck/FIX Initial Comment: Hmm. Bug 769985 reported no specrepcheck in $sign, but it turns out we *also* need a specrepcheck in sign1 (the internal entry). For example, minimax calls sign1 without specrepcheck, so max(rat(x),1) => fatal error. I suppose we could fix this in minimax, but I don't know if there are other callers of sign1 who also don't do specrepcheck. Ideally, we'd have a clear notion of which functions are supposed to have arguments that are already specrepchecked, but if that was part of the design at some point, The Knowledge has been lost. Fix: compar.lisp (defun sign1 (x) (setq x (specrepcheck x)) ;;; new (setq x (infsimp* x)) ........  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=904504&group_id=4933 
From: SourceForge.net <noreply@so...>  20040225 15:37:41

Bugs item #904295, was opened at 20040225 10: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=904295&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ratweight expt coredump/FIX Initial Comment: ratweights(x,1,y,1); rat((1+x+y)^10000),ratwtlvl:3; coredumps (too deep recursion) The fix is simple, and improves the algorithm to boot: In rat3b.lisp: (defun wtpexpt (x n) (cond ((= n 0) 1) ((= n 1) x) ((evenp n) (let ((xn2 (wtpexpt x (/ n 2)))) (wtptimes xn2 xn2 0))) (t (wtptimes x (wtpexpt x (1 n)) 0)))) Now even rat((1+x+y)^(10^30)),ratwtlvl:5; works. Maxima 5.9.0 GCL 2.5.0 mingw32 W2k Athlon  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=904295&group_id=4933 
From: SourceForge.net <noreply@so...>  20040225 05:14:42

Bugs item #903935, was opened at 20040225 00:03 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=903935&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: mul2* doesn't handle floats Initial Comment: mul2* is the twoargument nonsimplifying symbolic multiplication function (defined in opers.lisp). I think it is incorrect that if its args are numbers, it uses fixnum multiplication (f*) rather than general multiplication (*), though I can't find any cases where it matters. All the other XXX, XXX*, XXX2 and XXX2* operations in opers use general Lisp arithmetic, not fixnum.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903935&group_id=4933 
From: SourceForge.net <noreply@so...>  20040225 05:13:03

Bugs item #903933, was opened at 20040224 23:51 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=903933&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: ratweights: must be integer (check) Initial Comment: ratweights can currently only be integers, but there is no check for this: ratweight(x,1.5);  no error ratweight(y,3/2);  no error p: sum(x^i,i,0,10); rat(p),ratwtlvl:1 => 0 rat(p),ratwtlvl:2 => 0 rat(p),ratwtlvl:10 => 0 rat(p),ratwtlvl:100 => 0 ratweight should give an error if the weight isn't integral. Alternatively, fractional (rat and float) weights could be supported. It wouldn't be that hard, though there would be a bit of a performance hit. Most ratweight manipulation is in ratout/wtptimesXXX, and uses f*. It could use * or even MUL instead.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903933&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 05:14:24

Bugs item #625278, was opened at 20021018 11:18 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 Category: Lisp Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: simpsum bug Initial Comment: Hi! Unfortunately I have found a bug in simpsum (it seems): (C1) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),simpsum; (D1) 3 ***************** wrong ********************** (C2) 'SUM(BINOMIAL(2,2k)BINOMIAL(2,1k),k,1,2),sum; (D2) 2 ***************** correct ******************** ***************** however : ****************** (C3) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),simpsum; (D3) x (C4) 'SUM(BINOMIAL(x,2k)BINOMIAL(x,1k),k,1,2),sum; (D4) x (C5) bug_report(); Maxima version: 5.9.0rc1 Maxima build date: 11:40 9/3/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 Martin  >Comment By: Stavros Macrakis (macrakis) Date: 20040224 00:04 Message: Logged In: YES user_id=588346 Thanks for the patch. You might also be interested to know that nusum does very nicely on this case (generalized) with a little massaging: summand: binomial(q,2k)binomial(q,1k); sum0: nusum( minfactorial(makefact(summand)), k,1,n); factcomb(minfactorial(sum0)) => qq!/((1n)!*(q+n1)!) For more fun, try summand: binomial(q,7k)binomial(q,3k); PS Could you please post the complete patched 'sum' function? I am more confident with that than with merged patches. Thanks.  Comment By: Martin Rubey (kratt5) Date: 20021126 14:16 Message: Logged In: YES user_id=651552 sorry, below was a typo (a parenthesis didn't get deleted) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 14:04 Message: Logged In: YES user_id=651552 > Can you explain why there is a conditionalization > for #+cl there? I don't see any reason for this > code to depend on common lisp or not. My thought > on fixing the code previously displayed was to > just remove #cl > RJF Yes, I can explain it. It's there because I was very stupid. Here is the right fix: (and THANK YOU, I feel a little ashamed...) diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 933,935c927,929 < ;; nil ;; Kratt5 26.11.2002 < ; #cl < (let (*a *n) (var *var*)) ; freevar expects "var", not "*var*"  > nil > #cl > (let (*a *n)  Comment By: Martin Rubey (kratt5) Date: 20021126 08:49 Message: Logged In: YES user_id=651552 OK, I got the bug now: The fix is rather obvious (except that I had to dig through all of sum, see below) and the bug is rather serious (I can produce lots of everyday examples, (C1) sum(f(k)+1,k,1,n),simpsum; (D2) n so I propose to include it in 5.9.0 !!! I didn't change some things I would like to, I think this is for after 5.9.0... fix and explanation below Martin fix diff combin.lisp combin.lisp.~1.2.~ 915,920d914 < ; Kratt5, 26.11.2002 < ; adsum's and adusum's the sum of e. < < ; It's result is discarded. (at least I think that this function is < ; only called by sumsum, but there are lots of places where a variable < ; is called "sum"...) 930,939d923 < ; this is to deal with linearity Kratt5, 26.11.2002 < ((let (*a *n (var *var*)) < (cond ((prog2 (m2 e '((mtimes) ((coefftt) (var* (set) *a freevar)) < ((coefftt) (var* (set) *n true))) < nil) < (not (equal *a 1))) < ;; we have to return T, so that sum is exited if the test was successful < (prog2 (sum *n (list '(mtimes) y *a)) < T))))) < ;; 943,944c927 < #+cl (adusum (list '(mtimes) e y)) ;; Kratt5 26.11.2002 < ;; nil  > nil end fix I tested it with Maxima version: 5.9.0rc3 Maxima build date: 13:52 11/18/2002 host type: i686pclinuxgnu lispimplementationtype: Kyoto Common Lisp lispimplementationversion: GCL25.0 explanation  (lisp level) the structure of $sum is roughly as follows: $sum: argcheck, call dosum with meval'd bounds dosum: didn't look at this too much after this, meval calls simpsum **** if you type 'sum(f(k),k,1,n),simpsum; meval calls only simpsum **** $simpsum: call simpsum1 simpsum1: checks lo=hi, otherwise exp not depending on the summation index, otherwise if $simpsum, call simpsum2 **** simpsum2 is found in combin.lisp **** simpsum2: sets up a variable *plus, which will contain all the stuff which is added together at the end calls sumsum sumsum: returns the part of the expression it was able to sum up (this is the contents of the variable "usum"), all the rest (the contents of the variable "sum") is put into the variable *plus, which is then used by simpsum2 calls sum sum: adsum's and adusum's the sum of e. It's result is discarded. (at least I think that this function is only called by sumsum, but there are lots of places where a variable is called "sum"...)  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=625278&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 03:25:57

Bugs item #903190, was opened at 20040223 22: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=903190&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: sin(%pi+%pi*x) doesn't simplify Initial Comment: sin(%pi+%pi*x) doesn't simplify (cf 580721) ...similarly for other trig functions. The problem is that the %piargs code only looks for xxx+k*%pi/2 where xxx is %pifree. Even sin(f(%pi)+%pi) doesn't simplify! There are two main ways to try to fix this: 1) *Add* a purely syntactic check before or after the existing semantic check. This is appealing because a) it will clearly work and b) it can't screw up the form of the expression. 2) Replace the current semantic check with one which looks for a k*%pi/2 term among other terms. For example, sin((%pi+1)^3) has a 12*%pi term, so could simplify to sin(%pi^3+6*%pi^2+8). But is that really useful? I don't think so, and if the user wanted it with the syntactic approach, s/he could just use expand. Even less useful would be sin((%pi+1)^312*%pi). So I think solution (1) is better, even if it seems inelegant to do two independent checks.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903190&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 02:14:58

Bugs item #903166, was opened at 20040223 21:04 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=903166&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 works for real values only Initial Comment: assume(notequal(x,%i)) causes an error. cf 752332 Though of course there is no order relation on complexes, equal/notequal are perfectly meaningful. If we can't fix this easily (which we probably can't, alas), then at least it should be documented that assume only handles reals.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903166&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 01:49:12

Bugs item #903145, was opened at 20040223 20:31 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=903145&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: make_array arrays not well integrated Initial Comment: make_array arrays are useful but ugly. They don't print properly: ar: make_array(any,3)$ ar[1]: sin(x)$ ar => #(NIL ((%SIN SIMP) $x) NIL) and even worse: string(ar) => ?\#\(NIL\ \(\(\%SIN\ SIMP\)\ \\)\ NIL\) There is no way to write a constant array, so you can't save it in Maxima form. It's a pity that the function name "array" is taken... but we could define the external form of an array to be something like: array_constant( <<type and maybe size>>, [ ...contents... ] ) e.g. array_constant(any,[2,3,4]) is the same as block([arr],arr:make_array(any,3), for i:0 thru 2 do arr[i]:[2,3,4][i]) etc.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903145&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 01:21:17

Bugs item #903130, was opened at 20040223 20:10 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=903130&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: make_array doesn't check arg types Initial Comment: make_array(any,hello) => #() empty array ??? make_array(any,hello+1) => relocatable blocks exhausted Obviously make_array isn't checking that its args are integers.... cf. 546077  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903130&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 01:16:33

Bugs item #546077, was opened at 20020419 07:35 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=546077&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pedro Fortuny Ayuso (pfortuny) Assigned to: Nobody/Anonymous (nobody) >Summary: array: not dynamical sizes/FIX Initial Comment: The following code does not work: text.mac use_fast_arrays : true; trial(a):= block([myvar, i], /*local (i)*/ /* Comment this or not, it's the same */ array(i,a), for myvar : 1 thru 7 do i[myvar] : [], i[1])$ text.mac end It might be an (undocumented) issue, in which case the bug is in the doc, or it might be a real bug (I think one should be able to dimension arrays using variables, not only numbers). ====================follows session=================== Session: bash2.05$ maxima GCL (GNU Common Lisp) Version(2.4.0) Sat Jul 14 20:26:43 GMT 2001 Licensed under GNU Library General Public License Contains Enhancements by W. Schelter Maxima 5.6 Sat Jul 14 20:26:37 GMT 2001 (with enhancements by W. Schelter). Licensed under the GNU Public License (see file COPYING) (C1) load("text.mac"); (D1) text.mac (C2) trial(30); Error: $a is not of type NUMBER. Fast links are on: do (si::usefastlinks nil) for debugging Error signalled by MACSYMATOPLEVEL. Broken at MACSYMATOPLEVEL. Type :H for Help. MAXIMA>>:q (C3) ===============end of session===================  >Comment By: Stavros Macrakis (macrakis) Date: 20040223 20:06 Message: Logged In: YES user_id=588346 The blocks, loops, etc. are irrelevant; any nonconstant argument causes this problem: use_fast_arrays: true$ array(wer,3+3) => Error: ((MPLUS) 3 3) is not of type NUMBER. Fix in $ARRAY: ($use_fast_arrays (mset (car x) (apply '$make_array '$any (mapcar #'(lambda (dim) ;;let make_array catch bad vals (add 1 (meval dim))) (cdr x)))))  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=546077&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 00:22:56

Bugs item #531469, was opened at 20020318 13:18 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: need better documentation for "assume" Initial Comment: Maxima allows for the following very powerful syntax... (C1) (assume (y>1), integrate(x*log(x),x,1,y)); 2 2 2 y LOG(y)  y 1 (D1)  +  4 4 However, the documentation is lacking: Info from file /usr/local/info/maxima.info:  Fonction: ASSUME (pred1, pred2, ...) First checks the specified predicates for redundancy and consistency with the current data base. If the predicates are consistent and nonredundant, they are added to the data base; if inconsistent or redundant, no action is taken. ASSUME returns a list whose entries are the predicates added to the data base and the atoms REDUNDANT or INCONSISTENT where applicable. (D3) FALSE  >Comment By: Stavros Macrakis (macrakis) Date: 20040223 19:11 Message: Logged In: YES user_id=588346 What exactly do you think is lacking in this documentation? You talk about the "syntax"  do you mean the comma syntax (xxx, yyy)? That is not specific to assume  and beware, the assumptions are NOT local! The comma syntax is documented under "Introduction to Expressions": >>>>> A sequence of expressions can be made into an expression by separating them by commas and putting parentheses around them. This is similar to the C comma expression. <<<<< In other words, (a,b,c) evaluates a then b then c, and returns the value of c.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531469&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 00:07:24

Bugs item #707256, was opened at 20030320 20:02 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=707256&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: asksign/signum of ind and infinity/FIX Initial Comment: signum(ind) and signum(infinity) return noun forms. Since signum works correctly on inf (1), minf (1), and und (error), it might as well give errors for ind and infinity, too. The fix is in sign1 (compar.lisp). OLD>>>>>>>>> (if (eq x '$UND) (if limitp '$PNZ (merror "SIGN called on UND."))) NEW>>>>>>>>> (if (memq x '($UND $IND $INFINITY)) (if limitp '$PNZ (merror "The sign of ~:M is undefined" x)))  >Comment By: Stavros Macrakis (macrakis) Date: 20040223 18:57 Message: Logged In: YES user_id=588346 Actually, if you're computing with IND etc., perhaps signum (ind) should be ind rather than an error. Signum(infinity) should probably be an error because the sign of complex infinities isn't defined.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=707256&group_id=4933 
From: SourceForge.net <noreply@so...>  20040224 00:01:21

Bugs item #531466, was opened at 20020318 13:09 Message generated for change (Comment added) made by macrakis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531466&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Lemire (lemire) Assigned to: Nobody/Anonymous (nobody) Summary: float needs to be eval. with numer Initial Comment: See below... we'd like to see "float(exp(exp(2)))" evaluated to 1618.177991912654. (C1) float(exp(exp(2))); 2 %E (D1) 2.718281828459045 (C2) float(exp(exp(2))),numer; (D2) 1618.177991912654 (C3)  >Comment By: Stavros Macrakis (macrakis) Date: 20040223 18:51 Message: Logged In: YES user_id=588346 More cases: float(%pi^%pi)=> 3.14^%pi; float(2^%pi) =>2.0^%pi; but float((%e+%pi)^2) => 34.3. The intent is to avoid floating powers of symbolic objects. For example, you don't want float(x^2)=>x^2.0 or float(x^ (1/3)) => x^0.333. But obviously this has been taken too far. If we can get a numerical result for the whole expression, we should (2^%e, %e^2, even %e^%pi). Numer and float just aren't very well thoughtout.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=531466&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 23:35:24

Bugs item #903074, was opened at 20040223 18:25 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=903074&group_id=4933 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: limit(1/inf1/minf) => 0+0 Initial Comment: limit(1/inf1/minf) returns the pseudosimplified form 0+0, internally ((mplus simp) 0 0).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=903074&group_id=4933 
From: SourceForge.net <noreply@so...>  20040223 23:33:48

Bugs item #903072, was opened at 20040223 18:22 Message generated for change (Settings changed) made by macrakis 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 23:33:24

Bugs item #903072, was opened at 20040223 18:22 Message generated for change (Settings changed) made by macrakis 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 