The Original Pile Engine Demystified

If you´ve followed my postings on associative/relationalistic approaches to information representation and were interested in implementations of the Pile concepts (see [1] and [2] for words from the horse´s mouth) you might also have stumbled across a C implementation of a so called Pile Engine at the sourceforge site of the project. (You can find my implementation there, too. But it´s in C#.)

Now, the C implementation has boggled quite some mind for quite some time. It was fast and used little memory - but was very, very hard to understand due to a couple of reasons. Unfortunately this has led to some misunderstandings of the basic Pile concept. To some it seemed, as if the concept/theory somehow was tightly coupled to this specific C implementation. It seemed as if "something magic" was happening in this Pile Engine which was essential and needed to be understood first or even be copied by future Pile Engine implementations.

Well, to make a long story short: this is not the case! And to prove it, I wrote up my findings in a paper you can read here.

I undertook the effort of explaining the Original C based Pile Engine (OPE) in order to finally and clearly separate theory from implementation. Any research on the potential benefits of the Pile concept needs to be independent of a particular Pile implementation - even if this implementation stems from the Pile originators.

After digging into the unfortunately not well documented intricacies of the OPE I can now say: It´s interesting and still holds some records in terms of performance and memory usage. Well done, Erez and Miriam! But there´s nothing in it, that couldn´t or shouldn´t be done differently (within a certain range) in order to get a working Pile Engine.

And I´m relieved to say: The Pile concept nevertheless is very interesting and needs much more research. View Pile relations as a different kind of bytes, i.e. smallest unit of information processing, and take a Pile Engine as an API on the same level of abstraction as System.IO of the .NET Framework.

Then: How would working with and "thinking in" relations change how we do information processing? Think of the implications... What would it mean to easily connect any (!) piece of information with any (!) other piece on any (!) level of abstraction? And such connections would be the only thing to worry about. No dichotomy of data and connections anymore. But I´m getting carried away... :-)

Links

[1] Pile Systems - the commercial side of Pile, www.pilesys.com

[2] Pileworks - the open source Pile forum, www.pileworks.org

 

3 Comments

  • Hi,



    I've recently read an article in the dotnetpro about Pile. I didn't go to the original site, but in my opinion I've seen these "central" concepts long before: Lisp (or the more modern Scheme language or Prolog) implements these concepts since the 1960s. Think of Atom as "any piece of information" and List as a representation of "relation". Do some variable binding of lists (containing lists or other atoms) to atoms and you're done. Engine prepared, ready to do some information processing.



    So where is the new concept of Pile? What new thinking can one do that couldn't be done with the very very basic language elements of lisp?



    Best regards,

    Martin

  • @Martin: I´m not saying that relations are new. They don´t even have to do with programming in particular, as I tried to make clear in my postings.



    However, (to put it a little bluntly) Lisp is, well, about lists. The interesting part being that lists could be programs in itself.



    And Prolog is about knowledge inference using nested structures. (If I remember correctly.)



    Both are about single hierarchies of information. They are about single trees.



    But none is about an alternative way to represent any data. However, Pile is. Its radical view: There´s no data (inside the system), but only relations. And Pile´s question is: How could information processing be done differently if we started to connect everything?



    Pile thus is more low level then Lisp or Prolog. It´s a different way to represent information, not a different way to just model programs or data, or to just infer knowledge.



    -Ralf

  • @Martin: What distinguishes Pile from Lisp is, I´d say: 1.) No data in a Pile, 2.) multiple trees of relations interconnected. As far as I´m aware of, at least the Lisp community has not researched how to best represent information in an associative manner (which avoids redundancy) using just relations.

Comments have been disabled for this content.