Re: Re: Taking either a sequence or a list
- To: mathgroup at smc.vnet.net
- Subject: [mg63432] Re: Re: Taking either a sequence or a list
- From: Maxim <m.r at inbox.ru>
- Date: Sat, 31 Dec 2005 06:40:29 -0500 (EST)
- References: <dnm29m$89q$1@smc.vnet.net> <dnopf9$2gp$1@smc.vnet.net> <dnrd16$kqf$1@smc.vnet.net> <200512231008.FAA25950@smc.vnet.net> <dp05eq$g3b$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
On Thu, 29 Dec 2005 08:06:50 +0000 (UTC), Oyvind Tafjord
<tafjord at wolfram.com> wrote:
> ----- Original Message -----
> From: "Maxim" <m.r at inbox.ru>
To: mathgroup at smc.vnet.net
> Subject: [mg63432] Re: Taking either a sequence or a list
>
>
>>>
>>> This definitely looks like an inconsistency:
>>>
>>> In[1]:= MatchQ[{a}, {__Integer | a}]
>>>
>>> Out[1]= True
>>>
>>> In[2]:= MatchQ[{a}, {x : __Integer | a}]
>>>
>>> Out[2]= False
>
> This is a known issue (inconsistent handling of Alternatives) which is
> fixed
> in future versions.
>
>>>
>>> It is also unclear exactly what value is assigned to x here:
>>>
>>> In[4]:= tmp = {a} /. {x : __} -> x
>>>
>>> Out[4]= a
>>>
>>> In[5]:= tmp2 = {a} /. {x : __ | __} -> x
>>>
>>> Out[5]= Sequence[a]
>
> The result should be "a" in both cases (don't wrap Sequence around
> single-element sequences), fixed in future versions (by the same fix as
> the
> above).
>
>>>
>>
>> Here's another curious inconsistency:
>>
>> In[1]:= MatchQ[{a, a}, {s_, s_} /; True /; False]
>>
>> Out[1]= False
>>
>> In[2]:= MatchQ[{a, a}, {s__, s__} /; True /; False]
>>
>> Out[2]= True
>
> This is a bug I haven't seen before, involving nested
> Conditions/PatternTests surrounding "non-unique" patterns. Will be fixed
> in
> future versions. Thanks for pointing it out.
>
> Oyvind Tafjord
> Wolfram Research
>
In fact, I posted a very similar example (with nested Condition`s) on
MathGroup more than two years ago:
http://forums.wolfram.com/mathgroup/archive/2003/Oct/msg00429.html .
One problem is that if we need to know whether the result should be a or
Sequence[a], we cannot find the answer in the documentation. So even if we
know that {a} /. {x : __ | __} -> x will return a, does it mean that
{a, b, c} /. {s__, s2__} -> s
will be 'fixed' too (currently it also returns Sequence[a])? If that it
also a bug, this time it doesn't involve Alternative.
Or if {a} /. {x : __Integer | a} -> 0 is going to be fixed, does it mean
that
a + b + c /. s : a + b -> 0
will work differently as well (here we also have an example where the
pattern name changes the outcome)?
And these are relatively simple cases, where the inconsistency can be
pointed out quite unambiguously -- the contradiction between two examples
is obvious. But sometimes we can't even be sure what the expected
behaviour is. For example, the following function generates all subsets of
a list:
In[1]:= pset = Module[{f},
Attributes[f] = {Flat, Orderless};
ReplaceList[f @@ #, f[s___, s2___] -> {s}]
]&;
In[2]:= pset[{1, 2, 3}]
Out[2]= {{}, {1}, {2}, {3}, {1, 2}, {1, 3}, {2, 3}, {1, 2, 3}}
But should it work this way? Why doesn't it generate the list {2, 1} as
well? The general idea behind patterns containing Orderless/Flat functions
is that the expression is rearranged in all the ways allowed by the
attributes, and each variant is checked against the pattern. But then f[2,
1, 3] is a perfectly legal rearrangement, f being Orderless. Moreover, we
might expect to get f[1, 2] as one of the possible matches for s as well,
because f is Flat and so f[1, 2, 3] is identical to f[f[1, 2], f[3]]. So
exactly what combinations does Mathematica try here? I think that either
the behaviour of Flat has to be changed, or we have to document quite a
lot of complicated rules describing how Flat works in combination with
Orderless, in combination with sequences, etc.
Maxim Rytin
m.r at inbox.ru
- References:
- Re: Taking either a sequence or a list
- From: Maxim <m.r@inbox.ru>
- Re: Taking either a sequence or a list