<div class="gmail_quote">On Thu, Feb 9, 2012 at 4:11 PM, Mark Janssen <span dir="ltr"><<a href="mailto:dreamingforward@gmail.com">dreamingforward@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Wed, Feb 8, 2012 at 9:54 AM, julien tayon <span dir="ltr"><<a href="mailto:julien@tayon.net" target="_blank">julien@tayon.net</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/2/7 Mark Janssen <<a href="mailto:dreamingforward@gmail.com" target="_blank">dreamingforward@gmail.com</a>>:<div class="im"><br>
<div>> On Mon, Feb 6, 2012 at 6:12 PM, Steven D'Aprano <<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>> wrote: </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> I have the problem looking for this solution!</div><div class="im"><div>
><br>
> The application for this functionality is in coding a fractal graph (or<br>
> "multigraph" in the literature). This is the most powerful structure that<br>
> Computer Science has ever conceived. If you look at the evolution of data<br>
> structures in compsci, the fractal graph is the ultimate. From lists to<br>
> trees to graphs to multigraphs. The latter elements can always encompass<br>
> the former with only O(1) extra cost.<br>
<br>
</div></div><div class="im">{ "a" : 1 } + { "a" : { "b" : 1 } } == KABOOM. This a counter example<br>
proving it does not handle all structures.<br><br></div></blockquote><div>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. </div>
</div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote">
<div>A dictionary would (then) be a SET of these. (Voila! things have already gotten simplified.)</div></div></blockquote><div><br>Really? So {a:1, a:2} would be a dict of length 2?<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div> Eventually, I also think this will seque and integrate nicely into Mark Shannon's "shared-key dict" proposal (PEP 410).</div>
<div><br></div><div><div>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. </div>
</div><div><br></div><div>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).</div>
<div><br></div><div>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).</div>
<div>
<br></div><div><div>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:</div><div>
<br></div><div> { "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 } }. </div>
<div>Furthermore we can assume a default value of 1 for non-valued "names", so we could express this more simply:</div><div>{ 'a' } + { 'a" : { 'b' } } ==> { ''a': { 1, 'b' } } No ambiguity! as long as we determine a convention. </div>
<div><br></div><div>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! </div>
<div><br></div><div>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.</div>
<div><div><div><br></div></div></div></div><div>(Could one represent a python CLASS heirarchy more simply with this fractalset object somehow....?)</div><div><br></div><div>Further definitions:</div><div><br></div><div>RULE2: When an atomic is added to a compound, a grouping must be created: </div>
<div><br></div><div>1 + "b" : 1 = { None : 1, "b" : 1 }</div><div> </div><div>RULE3: Preserve groupings where present:</div><div><br></div><div>'b' : 7 + { 'b' : 1 } = { 'b' : 8 }</div>
<div><br></div><div>I think this might be sufficient. Darn, I hope it makes some sense....</div></div></blockquote><div><br>Maybe you should reduce your coffee intake. There's too much SHOUTING in your post... :-)<br>
</div></div><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>