Re: pattern bugs and comment on intuitive syntax for the New Year
- To: mathgroup at smc.vnet.net
- Subject: [mg115226] Re: pattern bugs and comment on intuitive syntax for the New Year
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Tue, 4 Jan 2011 18:49:04 -0500 (EST)
- References: <ifs30a$oor$1@smc.vnet.net> <4D21F917.2020209@cs.berkeley.edu> <48AEFA8B-880D-4B9A-B9CC-C1C7414D1384@mimuw.edu.pl> <4D224D50.7030706@eecs.berkeley.edu>
Well, I guess it's time for a little "summing up" of my own ;-) First, I concede that while replying to your post I (briefly) forgot that you wanted to recognize polynomials of degree exactly two rather than at most two and that your two line code was fine (except for the lack of Collect). My excuse is that I amused to dealing with spaces of both kinds of polynomials (the latter is a vector space, the former isn't) so I sometimes refer to both kinds as "quadratics". Also, since I have almost never found anything new of useful in your posts (except, perhaps, for one or two book references), there is a clear limit on the time I can devote to replying to them. However, this "concession" cannot hide the following facts: 1. That you failed to understand the basic fact: that a patter like x_. can refer to a single default value, which is 0 for addition and 1 for multiplication, which made you try to use it to do what obviously can't be done. 2. That you than tried to use BlankNullSequence[], which is completely un-appropriate in this context. 3. That having observed behaviour involving BlankNullSequence[] in pattern matching that you could not understand you declared it a "bug" and attributed to the presence of the Flat attribute in Plus, without checking that it actually has nothing to do with the Flat attribute and is part of the general behaviour of BlankNullSequence[] in pattern matching. 4. That after your "investigation" you "discovered" what is pointed out several times every year on this forum: that pattern matching is not intended to be a tool solving of problems of algebraic nature, and that they almost always can be done much more efficiently by different means. That does not mean pattern matching is useless; there is no better way (In Mathematica of course, it is always in Mathematica!) to deal with exceptions, anticipating user errors and so on. Pattern matching is also an excellent tool for certain type of mathematical programming - cellular automata, for example, but not for general problems of algebraic nature. 5. Concerning my program: quadp[f_, x_] /; PolynomialQ[f, x]&& Exponent[f, x] == 2 := qq @@ CoefficientList[f, x] which I claim to be the right way to solve your problem, your objection based on the example (x^3+x)/x carries no weight. The built in function PolynomialQ is deliberately designed to recognize only explicit polynomials. Since it is impossible to actually recognize all "implicit" polynomials, it is up to the user to modify it to include the cases that the user wants to include. Thus, if you want the function to work with rational functions such as your "counter-example" (which are not considered polynomials for some purposes) then you need to modify quadp as follows: quadp[f_, x_] /; PolynomialQ[Cancel[f], x] && Exponent[f, x] == 2 :== qq @@ CoefficientList[f, x] This will not work with "implicit polynomials" such as (Cos[x]^2+Sin[x]^2) x and lots of others of this type. If you wish to recognize the largest class of "implicit" polynomials you could use: quadp[f_, x_] /; PolynomialQ[FullSimplify[f], x] && Exponent[f, x] == 2 := qq @@ CoefficientList[f, x] but that will also inevitable fail in complicated cases. Finally this: > Obviously my meaning was that in Mathematica in most cases > a procedural program can be replaced by a more compact and, > to most people, more elegant looking, "functional" one. > Of course we know that generally >>>>they<<<< are both something > else, but the latter kind tend to be more elegant and more > efficient (without compiling, of course, which can't be > used for programs that perform symbolic computation > - an obvious thing that somehow you decided to forget). > " > > I have marked >>>>they<<<<.. > > I thought that the pronoun "they" meant "procedural and functional programs". > > You intended the pronoun to mean Mathematica programs in versions 8 and earlier, > and "the latter" to be what you call Mathematica functional programs in version 8 and earlier, and > the parenthetical remark to pertain to non-"functional" Mathematica programs > which you claim can't be compiled if they perform symbolic computation, and therefore > can't be made more efficient.) I think nothing shows better the pointlessness of discussing anything with you here. Let me make it clear: when I write a "program" I always, unless explicitly stated otherwise, mean: "Mathematica program in versions 8 and earlier" and so does almost everyone else here with of course one exception. All of the discussion of Lisp, the meaning of "compiled" outside of Mathematica etc. etc., beside consisting of stuff that is well known to anyone with a cursory knowledge of programing and computers, is utterly irrelevant on this forum and introduced by you only for purposes of your own, which have nothing to do with the reasons why others participate in this forum. Andrzej Kozlowski