[Python-ideas] [Python-Dev] matrix operations on dict :)
Guido van Rossum
guido at python.org
Fri Feb 10 01:18:22 CET 2012
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>
More information about the Python-ideas
mailing list