MathGroup Archive 2001

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

Search the Archive

Re: pattern matching quirks

  • To: mathgroup at smc.vnet.net
  • Subject: [mg29396] Re: pattern matching quirks
  • From: "Orestis Vantzos" <atelesforos at hotmail.com>
  • Date: Sat, 16 Jun 2001 22:43:46 -0400 (EDT)
  • Organization: National Technical University of Athens, Greece
  • References: <9gcm4p$35q$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Well, I would use g[a:(x...|y...)] which seems to be working just fine.
I don't find the described incombatibility so absurd though:
The pattern x|y... provides y... (which is inheretingly a Sequence
expression) as an alternative to a single symbol. I don't find it very
rational to do so:
either use (x|y) and expect a to be a Symbol or (x...|y...) and expect a
Sequence for a. The use of patterns seems to follow a set of logical but
undocumented internal rules, such that the default argument should match the
pattern you provide for it.
Wolfram Res. should step forward and clear the situation IMHO, by
documenting these features better.
Orestis


Andrzej Kozlowski" <andrzej at tuins.ac.jp> wrote in message
news:9gcm4p$35q$1 at smc.vnet.net...
> That the default value for a pattern in a function definition must much a
> pattern seems to me obvious. After all, it is by matching the default
value
> to the pattern that Mathematica finds out what it should return. How else
> could this be accomplished?
>
> As for your problem, it seems to be due to a your use of RepeatedNull. It
> can be demonstrated on a simpler example:
>
> In[1]:=
> f[a:Alternatives[x,y...]]:=1
> In[2]:=
> f[x]
> Out[2]=
> f[x]
> In[3]:=
> f[y]
> Out[3]=
> 1
>
>
> But,
>
> In[4]:=
> MatchQ[x,Alternatives[x,y...]]
> Out[4]=
> True
> In[5]:=
> MatchQ[y,Alternatives[x,y...]]
> Out[5]=
> True
>
> The same thing without RepeatedNull (...) works as expected.
>
> On the other hand,
>
> In[6]:=
> Clear[f]
> In[7]:=
> f[x|y...]:=1
> In[8]:=
> f/@{x,y}
> Out[8]=
> {1,1}
>
> so it looks like the problem is with the combination of RepeatedNull and
> Pattern. In fact it seems it can be further  reduced to the following
> behaviour:
>
> In[9]:=
> MatchQ[x,a:(x|y...)]
> Out[9]=
> True
> In[10]:=
> MatchQ[g[x],g[a:(x|y...)]]
> Out[10]=
> False
>
> but
>
> In[11]:=
> MatchQ[g[y],g[a:(x|y...)]]
> Out[11]=
> True
>
> and
>
> In[12]:=
> MatchQ[g[x],g[(x|y...)]]
> Out[12]=
> True
>
> I admit that this does seem like a "quirk". On the other hand I can't see
> why you should ever need to use a pattern like
> Alternatives[x,RepeatedNull[y]] which ought to be equivalent to simple
> Alternatives[x,y].
>
>
> --
> Andrzej Kozlowski
> Toyama International University
> JAPAN
>
> http://platon.c.u-tokyo.ac.jp/andrzej/
> http://sigma.tuins.ac.jp/~andrzej/
>
>
>
> on 01.6.14 3:27 PM, Michael at michael at science.edu wrote:
>
> > I am trying to write a function which matches only on a specific pattern
of
> > arguments, some of which can be optional.  The problem I am having is
that
> > certain complex patterns aren't being matched under conditions which
should
> > match.
> >
> > For example:
> >
> > In[1] := test[1, inputs : (X["4"] | X[X[_Integer]] ...) : X["4"]] :=
inputs
> >
> > In[2] := test[1]
> > Out[2] := X[4]
> >
> > This is the expected behavior.  However if I redefine the function so
that
> > the alternatives are collected within a single head, it doesn't work:
> >
> > In[3] := Clear[test];
> > test[1, inputs : (X["4" | X[_Integer] ...]) : X["4"]] := inputs
> >
> > In[4] := test[1]
> > Out[4] := test[1]
> >
> > In[5] := MatchQ[X["4"], (X["4" | X[_Integer] ...])]
> > Out[5] := True
> >
> > MatchQ says that my default values matches the given pattern.  Through
some
> > experimentation I had discovered that the function will NOT be called if
the
> > default value does not match the pattern for the optional argument.
This is
> > annoying (and undocumented I think) because I would like to insert a
> > function call to generate the default value.  This does not work right
> > either because the default value appears to be evaluated when the
function
> > is defined, and wrapping it with Hold causes it to fail the above
pattern
> > match.  So instead I have to assign it to some inane value (hence the
> > alternatives) and then do a rule transformation in the function itself
(not
> > shown above).
> >
> > So here are my questions:
> > 1. Why does the default value for a pattern have to match that pattern?
> > 2. Why is the default value seeming to be evaluated when the function is
> > defined?
> > 3. Why do some patterns pass MatchQ but not result in a function call?
> > Notably, X[a|b] versus X[a]|X[b]?
> > 4. What other quirks should I be aware of that I haven't run into yet?
:-)
> >
> > Regards,
> >
> > Michael Schmidt
> > michael at science.edu
> >
> >
> >
> >
> >
>
>




  • Prev by Date: RE: roots
  • Next by Date: How to produce "thick" lines in 3D?
  • Previous by thread: RE: Re: pattern matching quirks
  • Next by thread: calculating a distribution of separation of two means