Re: Pattern: x_List with conditions on elements
- To: mathgroup at smc.vnet.net
- Subject: [mg110929] Re: Pattern: x_List with conditions on elements
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Mon, 12 Jul 2010 01:04:33 -0400 (EDT)
Ryan,
Restricting the input patterns for functions does not help Mathematica much,
since it it an interpreted untyped language, but it can help the developer.
In effect, this allows you to introduce types, and control how strong the
types are. For example, the pattern x_ is what I call untyped, the pattern
x_List is "weakly typed", the pattern x:{___Integer} is more "strongly
typed", and if you want the strongest typing, you create a container like
listOfIntegers[] and put your numbers there. Then the pattern becomes
_listOfIntegers, and this can be called strongly typed. Note - this
terminology is mine rather than an accepted one.
Typically this is useful to make a code scale to larger projects, since this
allows lots of errors to be detected and diagnosed easier. Most of the time
one does not go all the way to introducing new data types but just uses this
as argument checks in functions (this seems to be called guards in some
modern languages). Be aware however that this can degrade performance when
inefficient patterns are used in argument checks.
You can use the container-based patterns to improve performance of the
argument checks in some cases (provided that you do the argument checks in
any case): if you have several functions taking an argument of type say
{___Integer} and type-checking it, you can as well define them on the
pattern _listOfIntegers. In this case, the real type-check will happen only
once, in the "constructor" for listOfIntegers (i.e., at the moment you
create an instance of this type), while the checks in functions will be
purely syntactic head checks which cost almost nothing.
There is also function overloading, which you mentioned. This is a pretty
powerful tool as well, given that pattern-based dispatch is quite general,
and that definitions can be manipulated at run-time. This would not be
possible to such extent with unrestricted patterns.
Regards,
Leonid
On Sun, Jul 11, 2010 at 2:19 PM, telefunkenvf14 <rgorka at gmail.com> wrote:
> On Jul 8, 7:34 pm, Peter Breitfeld <ph... at t-online.de> wrote:
> > telefunkenvf14 wrote:
> > > Group:
> >
> > > 1. Can someone provide a clearer way of implementing the following
> > > example? (Goal: I want a pattern that accepts only a list of real
> > > numbers and what I have seems hacky.)
> >
> > > MatchQ[{1, 2, 2.2},x_?(VectorQ[#,(NumericQ[#]&&Im[#]==0)&]&)]
> >
> > > 2. Could someone show me how to create a second pattern which accepts
> > > only a list (vector) of symbols? I feel like I'm spinning my wheels a
> > > bit on this one...
> >
> > > 3. Does anyone else think it would be nice to compile a list of
> > > favorite/useful patterns, along with a very brief explanation of the
> > > intent? (And yes, I know there are a bunch of examples in the
> > > documentation(!), but I'm thinking more in terms of assembling a list
> > > of recipes.) I guess I'm just craving more guided examples.
> >
> > > -RG
> >
> > The answer to question 1 could be:
> > realpatt={_Real..}
> >
> > Question 2 could be done by:
> > vectorpatt=v:{_Symbol..}/;VectorQ[v]
> >
> > There is a plethora of combinations of patterns, but in my opinion some
> > of the fundamental ones are included in the examples above. Mostly it's
> > possible to achieve the same goal in different ways.
> >
> > --
> > _________________________________________________________________
> > Peter Breitfeld, Bad Saulgau, Germany --http://www.pBreitfeld.de
>
> This is actually part of why I broke down and asked. Guidance on 'best
> practices', in regard to different types of pattern-based tasks, seems
> hard to come by. Maybe I just need to sign up for M201, or whatever
> the course number is...
>
> In general, I guess I'm most interested in restricting input patterns
> for functions---but I'm not really sure if it's worth the effort.
>
> How much does Mathematica really benefit by narrowing types of inputs?
> (besides the benefit of overloading symbols) For example, does it help
> above and beyond simply declaring, say,
> SetAttributes[MyFunction]={NumericFunction}?
>
> -RG
>
>