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

[Mark Janssen]

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.

A dictionary would (then) be a SET of these. (Voila! things have already
gotten simplified.)  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....

mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120209/ff33fe1c/attachment.html>