[Python-ideas] [Python-Dev] matrix operations on dict :)

[Guido van Rossum]

On Thu, Feb 9, 2012 at 4:11 PM, Mark Janssen <dreamingforward at gmail.com>wrote:

> On Wed, Feb 8, 2012 at 9:54 AM, julien tayon <julien at tayon.net> wrote:
>
>> 2012/2/7 Mark Janssen <dreamingforward at gmail.com>:
>>
>> > On Mon, Feb 6, 2012 at 6:12 PM, Steven D'Aprano <steve at pearwood.info
>> > wrote:
>>
>
>>
> > I have the problem looking for this solution!
>> >
>> > The application for this functionality is in coding a fractal graph (or
>> > "multigraph" in the literature).  This is the most powerful structure
>> that
>> > Computer Science has ever conceived.  If you look at the evolution of
>> data
>> > structures in compsci, the fractal graph is the ultimate.  From lists to
>> > trees to graphs to multigraphs.  The latter elements can always
>> encompass
>> > the former with only O(1) extra cost.
>>
>> { "a" : 1 } + { "a" : { "b" : 1 } } == KABOOM. This a counter example
>> proving it does not handle all structures.
>>
>> Okay, I guess I did not make myself very clear.  What I'm proposing
> probably will (eventually) require changes to the "object" model of Python
> and may require (or want) the addition of the "compound" data-type (as in
> python's predecessor ABC).  The symbol that denotes a compound would be the
> colon (":") and associates a left hand side with right-hand side value, a
> NAME with a VALUE.
>

That was not a user-visible data type in ABC. ABC had dictionaries (with
somewhat different semantics due to the polymorphic static typing) and the
':' was part of the dictionary syntax, not of the type system.


> A dictionary would (then) be a SET of these. (Voila! things have already
> gotten simplified.)
>

Really? So {a:1, a:2} would be a dict of length 2?


>   Eventually, I also think this will seque and integrate nicely into Mark
> Shannon's "shared-key dict" proposal (PEP 410).
>
> The compound data-type would act as the articulation point, around which
> the recursive, fractal data structure would revolve:  much like the decimal
> point forms in (non-integer) number.  (In theory, you could even do a
> reciprocal or __INVERT__ operation on this type.)  OR perhaps a closer
> comparison is whatever separates the imaginary from the real part in a
> complex number on the complex plane -- by virtue of such, creates two
> orthogonal and independent spaces.  The same we want to do with this new
> fractal dictionary type.
>
> While in the abstract one might think to allow any arbitrary data-type for
> right-hand-side values, in PRACTICE, integers are sufficient.  The reason
> is thus.  In the fractal data type, you simply need to define the
> bottom-most and top-most layers of the fractalset abstraction, which is the
> same as saying the relationship between the *atomic* and the *group* --
> everything in-between will be taken care of by the power of the type
> itself.  It makes sense to use a maximally atomic, INTEGER data type
> (starting with the UNIT 1) for the bottom most level., and a maximally
> abstract top-most level -- this is simply an abstract grouping type (i.e. a
> collection).  I'm going to suggest a SET is the most abstract (i.e.
> sufficient) because it does not impose an order and for reasons regarding
> the CONFLATION rule (RULE1).
>
> The CONFLATION rule is thus:  items of the same name are combined ({'a':1,
> 'a':3} ==> {'a':4}, and non-named (atomic) items are summed.  To simplify
> representation, values should be conflated as much as possible, the idea is
> maximizing reduction.  This rule separates a set from a list, because
> non-unique items will be conflated into one.  Such a set or grouping should
> be looked at as an arbitrary n-dimensional space.  An interesting thing to
> think about is how this space can be mapped into a unique 1-dimensional,
> ordered list and vice versa.  Reflectively, a list can be converted
> uniquely into this fractal set thusly:  All non-integer, non-collection
> items will be considered NAMES and counted.  If an item is another list, it
> will recurse and create another set.  If a set it will simply add it, as
> is.  These rules could be important in object serialization (we'll call
> this EXPANSION).
>
> In any case, for sake of your example.  In the above KABOOM example,
> unnamed, atomic elements can just be considered ANONYMOUS (using None as
> the key).   In this case, the new dict becomes:
>
>  { "a" : 1 } + { "a" : { "b" : 1 } } ==> { "a" :  {None: 1, "b" : 1 } } ,
> OR if have a compound data-type, we can remove the redundant pseudo-name:
>  { "a" :  { 1,  "b" : 1 } }.
> Furthermore we can assume a default value of 1 for non-valued "names", so
> we could express this more simply:
> { 'a' } +  { 'a" : { 'b' } } ==> { ''a': { 1, 'b' } }  No ambiguity! as
> long as we determine a convention.
>
> As noted, one element is named, and the other is not.  Consider unnamed
> values within a grouping like a GAS and *named* values as a SOLID.  You're
> adding them into the same room where they can co-exist just fine.  No
> confusion!
>
> To clarify the properties of this fractal data type more clearly:  there
> is only 1 key in the the second, inner set ('b').  We can remove the
> values() method as they will always be the atomic INTEGER type and conflate
> to a single number.  We'll call this other thing, this property "mass"; in
> this case = 2.)  The use of physical analog is helpful and will inform the
> definition.
>
> (Could one represent a python CLASS heirarchy more simply with this
> fractalset object somehow....?)
>
> Further definitions:
>
> RULE2:  When an atomic is added to a compound, a grouping must be created:
>
> 1 + "b" : 1 = { None : 1, "b" : 1 }
>
> RULE3:  Preserve groupings where present:
>
> 'b' : 7 + { 'b' : 1 } =  { 'b' : 8 }
>
> I think this might be sufficient.  Darn, I hope it makes some sense....
>

Maybe you should reduce your coffee intake. There's too much SHOUTING in
your post... :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120209/a61bf499/attachment.html>