You can subscribe to this list here.
2002 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(67) 
_{Jul}
(61) 
_{Aug}
(49) 
_{Sep}
(43) 
_{Oct}
(59) 
_{Nov}
(24) 
_{Dec}
(18) 

2003 
_{Jan}
(34) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(42) 
_{May}
(46) 
_{Jun}
(15) 
_{Jul}
(64) 
_{Aug}
(62) 
_{Sep}
(22) 
_{Oct}
(41) 
_{Nov}
(57) 
_{Dec}
(56) 
2004 
_{Jan}
(48) 
_{Feb}
(47) 
_{Mar}
(33) 
_{Apr}
(39) 
_{May}
(6) 
_{Jun}
(17) 
_{Jul}
(19) 
_{Aug}
(10) 
_{Sep}
(14) 
_{Oct}
(74) 
_{Nov}
(80) 
_{Dec}
(22) 
2005 
_{Jan}
(43) 
_{Feb}
(33) 
_{Mar}
(52) 
_{Apr}
(74) 
_{May}
(32) 
_{Jun}
(58) 
_{Jul}
(18) 
_{Aug}
(41) 
_{Sep}
(71) 
_{Oct}
(28) 
_{Nov}
(65) 
_{Dec}
(68) 
2006 
_{Jan}
(54) 
_{Feb}
(37) 
_{Mar}
(82) 
_{Apr}
(211) 
_{May}
(69) 
_{Jun}
(75) 
_{Jul}
(279) 
_{Aug}
(139) 
_{Sep}
(135) 
_{Oct}
(58) 
_{Nov}
(81) 
_{Dec}
(78) 
2007 
_{Jan}
(141) 
_{Feb}
(134) 
_{Mar}
(65) 
_{Apr}
(49) 
_{May}
(61) 
_{Jun}
(90) 
_{Jul}
(72) 
_{Aug}
(53) 
_{Sep}
(86) 
_{Oct}
(61) 
_{Nov}
(62) 
_{Dec}
(101) 
2008 
_{Jan}
(100) 
_{Feb}
(66) 
_{Mar}
(76) 
_{Apr}
(95) 
_{May}
(77) 
_{Jun}
(93) 
_{Jul}
(103) 
_{Aug}
(76) 
_{Sep}
(42) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(75) 
2009 
_{Jan}
(103) 
_{Feb}
(105) 
_{Mar}
(121) 
_{Apr}
(59) 
_{May}
(103) 
_{Jun}
(82) 
_{Jul}
(67) 
_{Aug}
(76) 
_{Sep}
(85) 
_{Oct}
(75) 
_{Nov}
(181) 
_{Dec}
(133) 
2010 
_{Jan}
(107) 
_{Feb}
(116) 
_{Mar}
(145) 
_{Apr}
(89) 
_{May}
(138) 
_{Jun}
(85) 
_{Jul}
(82) 
_{Aug}
(111) 
_{Sep}
(70) 
_{Oct}
(83) 
_{Nov}
(60) 
_{Dec}
(16) 
2011 
_{Jan}
(61) 
_{Feb}
(16) 
_{Mar}
(52) 
_{Apr}
(41) 
_{May}
(34) 
_{Jun}
(41) 
_{Jul}
(57) 
_{Aug}
(73) 
_{Sep}
(21) 
_{Oct}
(45) 
_{Nov}
(50) 
_{Dec}
(28) 
2012 
_{Jan}
(70) 
_{Feb}
(36) 
_{Mar}
(71) 
_{Apr}
(29) 
_{May}
(48) 
_{Jun}
(61) 
_{Jul}
(44) 
_{Aug}
(54) 
_{Sep}
(20) 
_{Oct}
(28) 
_{Nov}
(41) 
_{Dec}
(137) 
2013 
_{Jan}
(62) 
_{Feb}
(55) 
_{Mar}
(31) 
_{Apr}
(23) 
_{May}
(54) 
_{Jun}
(54) 
_{Jul}
(90) 
_{Aug}
(46) 
_{Sep}
(38) 
_{Oct}
(60) 
_{Nov}
(92) 
_{Dec}
(17) 
2014 
_{Jan}
(62) 
_{Feb}
(35) 
_{Mar}
(72) 
_{Apr}
(30) 
_{May}
(97) 
_{Jun}
(81) 
_{Jul}
(63) 
_{Aug}
(64) 
_{Sep}
(28) 
_{Oct}
(45) 
_{Nov}
(48) 
_{Dec}
(109) 
2015 
_{Jan}
(106) 
_{Feb}
(36) 
_{Mar}
(65) 
_{Apr}
(63) 
_{May}
(95) 
_{Jun}
(56) 
_{Jul}
(48) 
_{Aug}
(55) 
_{Sep}
(100) 
_{Oct}
(57) 
_{Nov}
(33) 
_{Dec}
(46) 
2016 
_{Jan}
(76) 
_{Feb}
(53) 
_{Mar}
(88) 
_{Apr}
(79) 
_{May}
(62) 
_{Jun}
(65) 
_{Jul}
(37) 
_{Aug}
(22) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(4) 
2
(4) 
3
(10) 
4
(13) 
5
(1) 
6
(4) 
7
(2) 
8
(4) 
9
(1) 
10
(3) 
11
(1) 
12
(7) 
13
(6) 
14
(4) 
15
(7) 
16
(2) 
17
(5) 
18

19
(3) 
20

21
(2) 
22

23

24

25
(14) 
26

27
(4) 
28
(2) 
29

30

31

From: SourceForge.net <noreply@so...>  20090111 14:05:12

Bugs item #902290, was opened at 20040222 22:11 Message generated for change (Settings changed) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Simplification >Group: Includes proposed fix Status: Open Resolution: None Priority: 8 Private: No Submitted By: Stavros Macrakis (macrakis) Assigned to: Nobody/Anonymous (nobody) Summary: Nonsimplifying nounforms: abs, realpart, carg, etc. Initial Comment: declare(q,complex)$ expr: rectform(q) => 'realpart(q) + %i * 'imagpart(q) subst(1,q,expr) => 'realpart(1) + %i * 'imagpart(1) (no simplification!)  Several Maxima mathematical functions do not simplify correctly as nounforms. As a general rule, simplifications should happen with all mathematicalfunction nounforms. For example, sin(0) == 'sin(0) == cos(%pi/2) == 'cos(%pi/2) == 0 But the following don't simplify: 'abs(1) 'realpart(1) 'imagpart(1) 'carg(1) Note also that cabs/carg are not treated symmetrically. cabs is an expressionmanipulating function (like factor) which can return the mathematical operator abs. But there is no mathematical operator corresponding to the expressionmanipuating function carg (cf also bug 620246).  >Comment By: Dieter Kaiser (crategus) Date: 20090111 15:05 Message: It seems to be not difficult to extend the functions realpart and imagpart to simplifying functions. That is the code which is necessary: ;;; Implementation of realpart as a simplifying function (defmfun $realpart (xx) (car (trisplit xx))) (defprop %realpart simprealpart operators) (defprop $realpart %realpart alias) (defprop $realpart %realpart verb) (defprop %realpart $realpart reversealias) (defprop %realpart $realpart noun) (defun simprealpart (x y simpflag) (oneargcheck x) (setq y (simpcheck (cadr x) simpflag)) (cond ((taylorize (mop x) (second x))) (t (car (trisplit y))))) ;;; Implementation of imagpart as a simplifying function (defmfun $imagpart (xx) (cdr (trisplit xx))) (defprop %imagpart simpimagpart operators) (defprop $imagpart %imagpart alias) (defprop $imagpart %imagpart verb) (defprop %imagpart $imagpart reversealias) (defprop %imagpart $imagpart noun) (defun simpimagpart (x y simpflag) (oneargcheck x) (setq y (simpcheck (cadr x) simpflag)) (cond ((taylorize (mop x) (second x))) (t (cdr (trisplit y))))) We have to change also the one function (The extra call to simplify has been removed to avoid an endless loop): (defun risplitnoun (l) (cons (list '(%realpart) l) (list '(%imagpart) l))) Implementing realpart and imagpart this way does not dublicate any code. The functions work as expected as simlifying functions. The handling of taylor expansion as an argument has been added too. In addition the problem of the bug report SF [2135806 ] "noun/verb confusion for real/imag part" vanish. The testsuite has no problems with a change to simplifying functions. Further work is possible for the functions carg and cabs. Dieter Kaiser  Comment By: Harald Geyer (hgeyer) Date: 20070715 01:36 Message: Logged In: YES user_id=929336 Originator: NO >> Yes, I know that nouns usually have simplifications, but IMHO these >> should do different things than the verb operation and avoid code >> duplication. > > What are the "different things" you have in mind here? For example: the program: integrate(cos(x),x) > sin(x) simplification: integrate(f(x),x,a,b)+integrate(f(x),x,b,c) > integrate(f(x),x,a,c) Unfortunately this isn't implemented ... :( > Much of Maxima simplification deals with cases where there is no clear > line. I don't consider that a valid reason to make it worse. :) > Why does x/x simplify to 1, but (x^2x)/(x1) not simplify to x? The second problem involves the distributive law and the core simplifier (rightly) doesn't touch it, because you can't (gnerally) tell which side of the distributive law is more useful. I.e. it depends on what you want to do with the result. > In the case of rectform or integrate or limit, I think normal users would > find it strange for the constantargument case not to simplify, and of > course this is easy to implement. This I don't believe. In my experience, users fit into three classes: a) unexperienced: Don't know the difference between evaluation and simplification. They will get confused whenever these behave differently. b) semiexperienced: They will wonder why the quote operator doesn't work in 'integrate(q,x). Actually this is the only complaint I remember to have heard by a user. c) experienced: They don't care as long as it is easy to predict what maxima will do. >> I'm not against convenience features. I only think these should be >> clearly encapsulated rather than mixed with the core functionality. > Why is sin(x)+sin(x)=>0 "core functionality" but > 'realpart(x)+'realpart(x)=>0 a "convenience feature"? Because there is no program sin(). >> Actually I'm quite happy with subst(), even if it returns things like >> 'abs(1). > But it *doesn't* return 'abs(1). Sorry for the lapsus, I meant 'realpart(1) of course. But I wouldn't mind if it *did* return 'abs(1) in the appropriate case. I do mind if I get subst(1,z,'realpart(z)) > 'abs(1). ;) >> It should do the same as if I had typed in the expression with >> all substitutions in the first place. > Simplification does exactly that. Only if you implement the full logic of the program into the simplifier! In case this isn't clear from my previous posts: I'm not on a crusade against simplification, I'm just concerned with a) code duplication leading to less maintainable code b) confusing our users with inconsistent behaviour of nouns and verbs. After looking at the code a bit, I can follow up on my last post: I think the reason why realpart() and imagpart() are programs is because you get them for free (one liners) after implementing rectform(). But perhaps the same code could be used in the simplifier or the simplifier could just convert nouns into verbs whenever resimplification is due? Do you think such an approach is reasonable and feasible?  Comment By: Stavros Macrakis (macrakis) Date: 20070714 22:24 Message: Logged In: YES user_id=588346 Originator: YES > Yes, I know that nouns usually have simplifications, but IMHO these > should do different things than the verb operation and avoid code > duplication. What are the "different things" you have in mind here? > As you say yourself there is no clear line. Much of Maxima simplification deals with cases where there is no clear line. Why does x/x simplify to 1, but (x^2x)/(x1) not simplify to x? Why does tan(%pi/4) simplify to 1, but tan(%pi/16) not simplify to sqrt(sqrt(2)1)*(2^(3/4)+(sqrt(2)+1)^(3/2)2*2^(1/4))? The answer is a combination of a) what the user might find reasonable and useful; what causes the rest of simplification to produce reasonable results; and c) what can be implemented to run reasonably fast. In the case of rectform or integrate or limit, I think normal users would find it strange for the constantargument case not to simplify, and of course this is easy to implement. > I think adding simplification for simple cases just because > they can be done efficiently is a cosmetic (or annoying  depending on > your POV) enhancement without adding functionality. Then what exactly would simplification handle? Surely you want x+0 and 2*xx to simplify to x, sin(0), cos(%pi/2), sin(x)+sin(x), and cos(1x)cos(x1) to simplify to 0, and gamma(1) to simplify to 1. I would think you would analogously want 'realpart(0) and 'realpart(x)+'realpart(x) to simplify to 0. > I'm not against convenience features. I only think these should be > clearly encapsulated rather than mixed with the core functionality. Why is sin(x)+sin(x)=>0 "core functionality" but 'realpart(x)+'realpart(x)=>0 a "convenience feature"? > Actually I'm quite happy with subst(), even if it returns things like 'abs(1). But it *doesn't* return 'abs(1). > It should do the same as if I had typed in the expression with > all substitutions in the first place. Simplification does exactly that. s  Comment By: Harald Geyer (hgeyer) Date: 20070713 11:28 Message: Logged In: YES user_id=929336 Originator: NO It is not a problem per se, but I see two issues: 1) It will make the code less maintainable if the same functionality is implemented twice in different places. For example I know three different implementations of testing whether an expression is integer valued. All have different capablities, because nobody keeps them in sync. 2) It's potentially confusing if there is no clear line between how a noun behaves and what a verb does. It's easier to explain to new users, that 'realpart(1) doesn't evaluate because 'abs is a noun than to explain why 'realpart(1) is simplified but 'realpart(sin(z)) isn't. Of course the above could be avoided if realpart() and co would get entirely converted to nouns as is done with sin(). I wonder why this wasn't done in the first place? BTW, why do you think that 'realpart(1) is more a problem (bug) than 'realpart(sin(z)) or even 'realpart(very_complicated_expr)?  Comment By: Robert Dodier (robert_dodier) Date: 20070713 03:13 Message: Logged In: YES user_id=501686 Originator: NO For my part, I am convinced that failing to simplify 'realpart(1) and 'imagpart(1) is very definitely a bug. Harald, a simplification is just the application of some identity. If the same identity is applied by both a verb and simplification of a noun, that is no problem.  Comment By: Harald Geyer (hgeyer) Date: 20070713 02:04 Message: Logged In: YES user_id=929336 Originator: NO Yes, I know that nouns usually have simplifications, but IMHO these should do different things than the verb operation and avoid code duplication. As you say yourself there is no clear line. Why is 'integrate(sin(x),x) ok? Why 'integrate(q,x) not? Why 'rectform(1) not? I think adding simplification for simple cases just because they can be done efficiently is a cosmetic (or annoying  depending on your POV) enhancement without adding functionality. Actually this makes the line less clear and maxima more confusing. I'm not against convenience features. I only think these should be clearly encapsulated rather than mixed with the core functionality. I.e. specify() would be such a function. On what specify() should do: I'm not sure. Actually I'm quite happy with subst(), even if it returns things like 'abs(1). It should do the same as if I had typed in the expression with all substitutions in the first place. I guess the minimum requirement would be to replace certain nouns by their corresponding verbs. But probably somebody has a better idea. Some examples: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) specify(sin, f, %); (%o4)  cos(x); (%i1) declare(z1, complex, z2, complex); (%o1) done (%i2) realpart(z1); (%o2) realpart(z1) (%i3) specify(sin(z2), z1, %); (%o3) cosh(imagpart(z2)) sin(realpart(z2))  Comment By: Stavros Macrakis (macrakis) Date: 20070712 23:59 Message: Logged In: YES user_id=588346 Originator: YES You are mistaken about noun/verb; it is perfectly normal for nounforms to simplify. Integrate, diff, and limit all have simplifications. There is no clear line between noun simplifications and verb operations, but in general noun simplifications are "shallow" and efficient, while verb operations are "deep" and potentially very expensive. Also, I should think that noun simplifications must be correct for all substitions of values for variables, but diff and integrate are not consistent on this: 'diff(q,x) => 'diff(q,x) correct for arbitrary q's 'integrate(q,x) => q*x assumes q is freeof x I am not sure what you mean about subst vs. ev. Subst has clear and (I think) reasonable semantics, and I don't know what you'd want to change in your "specify" function.  Comment By: Harald Geyer (hgeyer) Date: 20070712 23:39 Message: Logged In: YES user_id=929336 Originator: NO I'm not sure I agree these are bugs and I can't think how to this could be fixed without questioning the whole noun/verb concept. For example consider the following session: (%i3) integrate(f(x), x); (%o3) 'integrate(f(x),x) (%i4) subst(sin, f, %); (%o4) 'integrate(sin(x),x) It has the same problem as rectform(), but how should maxima guess what the user wants? I think the real problem is, that we recommend subst() to users for things that it wasn't meant for, because ev() has it's own sets of problems. We might try to fix subst() but most likely we would end up with something as messy as ev(). IMO the this problem should be addressed by a) better explaining the noun/verb concept to users b) invent a new function  say specify()  which fills the gap between subst() and ev()  Comment By: Barton Willis (willisbl) Date: 20070112 19:55 Message: Logged In: YES user_id=895922 Originator: NO One observation about the simpabs code: if the special expandp is 1, signum1 will always return 1 for a sum. Since mminusp uses signum1, this means that the absolute value function will not apply the reflection simplification: (%i2) :lisp(setf expandp t); T (%i2) abs(ab)  abs(ba); (%o2) abs(ab)abs(ba) I don't think expandp ever gets set to true. So it's not a bug, I guess. If we want to make the simpabs reflection rule work the same as the trig reflection rules, we could: (setf (get '%mabs 'operators) 'simpabs) (setf (get 'mabs 'reflectionrule) #'evenfunctionreflect) (defmfun simpabs (x y z) (oneargcheck x) (setq y (simpcheck (cadr x) z)) (cond ((numberp y) (abs y)) ((or (ratnump y) ($bfloatp y)) (list (car y) (abs (cadr y)) (caddr y))) ((eq (setq z (csign y)) t) (cabs y)) ((memq z '($pos $pz)) y) ((memq z '($neg $nz)) (neg y)) ((eq z '$zero) 0) ((and (mexptp y) (integerp (caddr y))) (list (car y) (simpabs (list '(mabs) (cadr y)) nil t) (caddr y))) ((mtimesp y) (muln (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)) t)) ((applyreflectionsimp (mop x) y t)) ;;((mminusp y) (list '(mabs simp) (neg y))) ((and (mbagp y) $listarith) ;; < I appended this!!! (cons (car y) (mapcar #'(lambda (u) (simpabs (list '(mabs) u) nil t)) (cdr y)))) (t (eqtest (list '(mabs) y) x))))  Comment By: Barton Willis (willisbl) Date: 20070112 12:25 Message: Logged In: YES user_id=895922 Originator: NO Isn't the 'abs(1) > abs(1) bug a noun / verb confusion (mabs vs %mabs)? Just doing (setf (get '%mabs 'operators) 'simpabs) allows 'abs(1) > 1. The test suite is OK with (setf (get '%mabs 'operators) 'simpabs).  Comment By: Robert Dodier (robert_dodier) Date: 20060723 20:41 Message: Logged In: YES user_id=501686 Observed in 5.9.3cvs. Also increasing the priority  this is a very weak point for Maxima.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=902290&group_id=4933 