Boost logo

Boost :

From: FlSt_at_[hidden]
Date: 2005-08-01 17:42:10


Rob Stewart wrote:

>From: FlSt_at_[hidden]
>
>
>>have critism on the implementation tell it to me. There is still the
>>naming problem, i don't want call them junctions. Has anyone an idea?
>>
>I've been working on my own implementation which takes a
>different tack from yours (as of v3 or 4, I think, anyway).
>

> That has raised some questions, but first, I have an idea for the
>naming:
>
> namespace: boost::multivalues
> base class: multivalue
> all_of: all_values
> any_of: any_value
> none_of: no_values
> one_of: one_value
>
Sounds a bit like a container type for me. It's nothing more than a
functional extension for ranges (or container), some kind of algorithm.
I don't know!

>Are all (in)equality comparisons symmetric? I was pondering what
>the following expression means:
>
> any_of(s1) == one_of(s2)
>
I understand xxx_of as giving a logical linkage to the values of a list
and I think this is what Perl also does:
all_of = and, any_of = or, one_of = xor and none_of = not any_of. Do
you agree?

 (I define a logical XOR-Operator as ^^ for my explanation: x ^^ y ^^ z
means that this expression is only true if exactly one of x,y,z is true,
which is equivalent to (x && !y && !z ) || ( !x && y && !z ) || ( !x &&
!y && z ) ). So the expression any_of(s1) == one_of( s2 ) is equivalent
to (n is last index of s1 and m is last index of s2):

( s1[1] == s2[1] ^^ s1[1] == s2[2] ^^ ... ^^ s1[1] == s[n] ) ||
( s1[2] == s2[1] ^^ s1[2] == s2[2] ^^ ... ^^ s1[2] == s[n] ) ||
....
( s1[m] == s2[1] ^^ s1[m] == s2[2] ^^ ... ^^ s1[m] == s[n] )

This means if in s1 is one or more value equal to exact one value of s2
then this expression is true.

example: s1 = {1,2,3} and s2 = {2,3,4}

( 1 == 2 ^^ 1 == 3 ^^ 1==4 ) || ( 2 == 2 ^^ 2 == 3 ^^ 2 == 4 ) || ( 3 ==
2 ^^ 3 == 3 ^^ 3 == 4 ) =>
( false ^^ false ^^ false ) || ( true ^^ false ^^ false ) || ( false ^^
true ^^ false ) =>
false || true || true => true

The order of the logical operators in the expression is an analogy to
the comparions with a scalar value:
any_of(s) == 1 would be
s1[1] == 1 || s1[2] == 1 || ... || s1[n] == 1

>You could make that case that as long as any one of the values in
>s1 matches exactly one of the values in s2, the result is true.
>Given that interpretation, should the following expression mean
>the same thing?
>
> one_of(s2) == any_of(s1)
>
This is equivalent to

( s2[1] == s1[1] || s2[1] == s1[2] || ... || s2[1] == s1[m] ) ^^
( s2[2] == s1[1] || s2[2] == s1[2] || ... || s2[2] == s1[m] ) ^^
....
( s2[n] == s1[1] || s2[m] == s1[2] || ... || s2[n] == s1[m] )

This expression is true if there is exactly one value in s2 which is
equivalent to one or more of the values in s1, what means something
different as the expression above.

example with 2nd expression: same values as above

( 2 == 1 || 2 == 2 || 2 == 3 ) ^^ ( 3 == 1 || 3 == 2 || 3 == 3 ) ^^ ( 4
== 1 || 4 == 2 || 4 == 3 ) =>
( false || true || false ) ^^ ( false || false || true ) ^^ ( false ||
false || false ) =>
true ^^ true ^^ false =>
false <---- different result! This is the proove that in my
interpretation not all equality comparisons are symetric

I hope the explanation of my interpretation of junctions was evident.
(It's difficult for me writing texts in englisch, reading is easier for
me ;-)

>When written that way, it seems easy to think that there should
>only be one value in s1 that matches a value in s2. IOW, if more
>than one value in s1 matches exactly one value in s2, the
>expression would be false.
>
>Thus, the first expression could also be true iff there is just
>one value in s1 that matches exactly one value in s2.
>
>If you think the latter interpretation, then how does that differ
>from the following expression?
>
> one_of(s1) == one_of(s2)
>
>That expression clearly says exactly one value in s1 must match
>exactly one value in s2. Consequently, I think it argues for the
>first two expressions to be true if one or more value in s1
>matches exactly one value in s2. Do you agree?
>
>
See above. This should answer all questions if you agree with me of what
the junction comparison does.

>As soon as you open up that interface, you permit opportunity for
>confusion. This is especially true of comparisons with none_of.
>It is also a point of customization that must be documented. Do
>you think there's enough reason to justify that?
>
I think no. I think it's better to concentrate on the operations with
xxx_of for the first.

There are some combinations of "xxx_of(s1) OP yyy_of(s2)" which are not
useful. I think it would be a good idea to extract useful and not so
useful expressions and document it. At the first sight it seems that
junctions (multivalues) are trivial, but i must admit they aren't.

Sincerly,
Florian.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk