
Boost : 
From: FlSt_at_[hidden]
Date: 20050802 13:19:11
Rob Stewart wrote:
>From: FlSt_at_[hidden]
>
>
>>Rob Stewart wrote:
>>
>>
>>>
>>>[...]
>>> 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!
>>
>>
>
>It does sound a little like a container type, but what container
>would be named like those? That is, I don't think they would
>make good container names, so I think they fit our purposes
>reasonably well.
>
I aggree that they wouldn't make good container names (multivalues could
be another name for array). And I think multivalues are a better name
than junctions, because the concept we are discussing differs a lot from
the perl idea, what is a good reason for an other name. The name
"junctions" distinguishes the relation between the values, which would
fit better to my interpretation I described in my previous posting. So I
will aggree with "multivalues" until someone has a better idea.
>>>[...]
>>>
>>>
>>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'm not certain I can agree. I understand that using that
>definition does simplify the implementation, but "all" doesn't
>quite evoke "and," nor "any" "or," nor "none" "not." "one" does
>reasonably evoke "xor," however.
>
My interpretation (and i think also perl does so) is based on the
boolean algebra where the operators "All of" (the A on it's head) and
"Exists" (the mirrored E) are used in analogy to the sum and product
operators in numeric algebra. So i think the names have sense. Your
interpretation has is a higherlevel approach. The longer I think about
this, the more I belife there are justifications for both
interpretations. What do you think? BTW: Today I tried to install the
Perl 6 interpreter Pugs, but I didn't get it to work. I wanted to
analyze the Perl 6 implementation of junctions especially the behaivor
of comparisons, because I don't want to tell something wrong here. The
only experiences I have are with the Quantum::Superpositions module
which behaves like my implementation, except that my current
implementation doesn't return a new junction and doesn't support
algebraic operations.
>I didn't pay enough attention to the details of the Perl
>approach, so I didn't get mired in them. That left me to
>interpret "all," "and," "none," and "or" at face value. That
>also left me to find some strange combinations that were
>confusing. (More below.)
>
>
That is want I meant above. I really don't think that your approach is
wrong or bad, but I must rethink completely to follow your thoughts.
>>false < different result! This is the proove that in my
>>interpretation not all equality comparisons are symetric
>>
>>
>
>I think allowing asymmetry in these expressions will cause great
>confusion. This is especially true when it isn't required.
>
From your viewport of multivalues I aggree and understand what you mean.
>[...]
>
>I think it would be more sensible when read, and remains easy
>enough to explain if we provide symmetry and these definitions:
>
> all_of: every value must satisfy the test with the same other
> value
> any_of: at least one value must satisfy the test
> each_of: every value must satisfy the test
> n_of: exactly n values must satisfy the test
> none_of: no value may satisfy the test
> one_of: exactly one value must satisfy the test
>
I must admit that I can't say something useful about this now, I need
some more time to think about it, because I'm still affected by the Perl
implementation.
>I invented n_of (n_values) when I was considering none_of and
>one_of and I thought to generalize it.
>
You can generalize it a step further when you can give a range to
n_m_of(): n minimum number of values that must satisfy the test and m
maximum number of values that must satisfy the test. Ok, ok no more
complexity as necessary ;) Your n_of would also be useful with the
junctions approach (This provides all steps between "and" and "or"
inclusive "xor" in one function).
>[..]
>
>For the one_of(x) == one_of(y) example, I think it is reasonable
>to think of it as finding exactly one value from x and exactly
>one from y that satisfies x[n] == y[m]. That's how it reads. (I
>haven't even attempted to see whether that's how your
>interpretation would answer.)
>
In my interpretation this would be equivalent to:
( x[1] == y[1] ^^ x[1] == y[2] ^^ ... ^^ x[1] == y[m] ) ^^
( x[2] == y[1] ^^ x[2] == y[2] ^^ ... ^^ x[2] == y[m] ) ^^
...
( x[n] == y[1] ^^ x[n] == y[2] ^^ ... ^^ x[n] == y[m] )
What means this expression is true when x has exactly one value which is
equal to exactly one value of y.
>I have to review my design to make sure I'm doing everything
>correctly, and I have a couple of tests that fail still. Once I
>finish, I'll upload it for your inspection.
>
I'm very courious about it.
Sincerly
Florian
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk