[Date Index] [Thread Index] [Author Index]

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