Re: [boost] Interest for a perl6-like-junctions-class?

From: FlSt_at_[hidden]
Date: 2005-08-02 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 higher-level 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