[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
Prev by Date:
**Re: Combining Slider and SetterBar in Manipulate**
Next by Date:
**FillingStyle -> Striped ?**
Previous by thread:
**Re: pattern bugs and comment on intuitive syntax for the New Year**
Next by thread:
**Re: pattern bugs and comment on intuitive syntax for the New Year**
| |