Re^3: Representing all data as Lists

I'm exploring whether or not the implementation of Perl would become simpler if there was one datatype used to represent the things we see as strings, lists, and hashes.

It might be simpler, but it would never happen. You seem to view this as just a "matter of time" since computers will be so fast they will make up for the "inefficiency" of this LISP-y implementation. The speed of a computer is a factor, but it is probably the least important factor when it comes to "efficiency."

Constant speedups are one thing, but if you have a bad algorithm (like blindly searching a list to implement an associative array), the problem will scale poorly no matter how fast your computer is. The only way a futuristic computer running a linear-time algorithm could keep up with another computer running a constant-time algorithm would be if it could somehow compress time.

If I had to choose between a fast computer and fast algorithms, I'd choose fast algorithms ;)

You'd have a better chance of convincing me that this is a good idea if the implementation stays efficient and the everything-is-a-list is just a unifying interface to whatever the underlying structure is. Although I still don't see what this does that LISP doesn't already do.

blokhead

Comment on Re^3: Representing all data as Lists

Replies are listed 'Best First'.
Re^4: Representing all data as Lists by Anonymous Monk on Sep 20, 2005 at 20:19 UTC
Constant speedups are one thing, but if you have a bad algorithm (like blindly searching a list to implement an associative array), the problem will scale poorly no matter how fast your computer is. The only way a futuristic computer running a linear-time algorithm could keep up with another computer running a constant-time algorithm would be if it could somehow compress time. The good thing about these types of mental exercises is that it helps expose our shared set of (mostly hidden) assumptions. For example, we like to think that we can do array lookup (and by extension, hash lookup) in O(1) time. Geometrically though, RAM is really a tree structure, and we have wait for signals to propogate through O(log n) row and column decoders. But even this is optimistic, because if bits take up a finite volume (and the speed of light is constant), then we're really looking at O(n**(1/3)) time for a lookup.	[reply]
Re^5: Representing all data as Lists by blokhead (Monsignor) on Sep 20, 2005 at 22:18 UTC
because if bits take up a finite volume (and the speed of light is constant), I really can't tell if you're trying to mock the value of the kinds of theoretical claims I made, or you really think that the mass & volume of photons are a significant factor in algorithmic analysis. You are right that there are a lot of factors when dealing with physical machines instead of theoretical ones. But on my computer, the amount of pyhsical RAM does not depend on the input size to algorithms I'm running. And in my exercise, we are fixing two computers & two competing algorithms, and varying only the input sizes to these algorithms. So I prefer to treat memory lookup time as a constant. The point of my previous reply is that if I upgrade computers, then memory access time, CPU cycle time, etc, are each smaller constants, but still constants. Eventually, as the input sizes increase, the algorithm with the best asymptotic performance will win. And in the case of a reasonable O(1) or even O(log n) algorithm (where "reasonable" means the constants are not insanely large) on a slow machine vs a reasonable O(n) algorithm on a fast machine, the better algorithm starts winning perhaps sooner that you'd expect. blokhead	[reply]
Re^6: Representing all data as Lists by Anonymous Monk on Sep 20, 2005 at 23:28 UTC
And in my exercise, we are fixing two computers & two competing algorithms, and varying only the input sizes to these algorithms. So I prefer to treat memory lookup time as a constant. Sure, when you start performing your algorithmic analysis, there's nothing preventing from stating as an axiom... memory lookup is O(1) ... Just be aware that this is an axiom after all and only true for a particular set of von Neumann type machines. Or stated another way, for certain given problems and the same finite amount of silicon, there are better ways to arrange the wires between the transistors (like say into a shift register instead of a tree (RAM)). And your complexity analysis (with Axiom #1 from above) will be incorrect and lead to answers which aren't consistent with the actual performance of the physical machine.	[reply]


The stupid question is the question not asked
	PerlMonks