Comments on: The X=X+1 Issue

By: AdmnUnpwnd

AdmnUnpwnd — Sat, 06 Aug 2011 13:26:28 +0000

Thank You very much! I was thinking about asking this to my mathematics teacher. So the ‘=’ in BASIC, or in any other language, is like the STO -> (store) key in TI BASIC.

By: fernandoaren

fernandoaren — Wed, 30 Nov -0001 00:00:00 +0000

10 Neat.
20 And now you tell me there’s something else than BASIC
30 Geez.
40 GOTO 10

By: tphillips

tphillips — Wed, 30 Nov -0001 00:00:00 +0000

Maybe it's just me, or maybe it's just a clumsy example, but it looks to me as if you are telling the computer how to do the sum. You are just telling it how using recursion rather than looping.

I'm not saying it's completely equivalent, but it doesn't seem to be clearly superior.

Not in this case, anyway.

By: ruzam

ruzam — Wed, 30 Nov -0001 00:00:00 +0000

I’m sure there will be more of a point to this later, but all you’ve demonstrated is recursive style vs non-recursive style which doesn’t have much of anything to do with imperative vs declarative style.

You’re SUM() example could be just as easily coded as a ‘single assignment’ recursive function in any procedural language that support s recursion (in as few lines with as much programmer efficiency). But as you say “how the rules are executed is up the declarative language”. How the rules are executed is also up to the imperative language. Each coding method can be equally tuned (or broken) for parallel execution.

By: lilmikey93

lilmikey93 — Wed, 30 Nov -0001 00:00:00 +0000

This seems fitting.

Hey Hey 16k.

http://www2.b3ta.com/heyhey16k/

Enjoy the video.

By: gsmyth

gsmyth — Wed, 30 Nov -0001 00:00:00 +0000

Is multiple assignment bad in parallel computing? In parallel programming we would essentially look at what level of granularity we want to break down the data to be processed over the number of recursive loops to process and assign the computations to threads over various cores. The issue would be synchronising the partial results into a shared location and the synchronisation overhead in this case although necessary would slow the computation down. (assuming thread-safe libraries).
Or perhaps say a high level of granularity would be better and increase the time period between synchronisation points. This discussion may be useful to mention and further comment in the article.
Checking on metrics via sar or clock execution times will determine how well the granularity is performing.

By: avagothen

avagothen — Wed, 30 Nov -0001 00:00:00 +0000

Very nice idea on a very real problem.
Unfortunately, your recursive solution will not run any faster on a parallel machine as each iteration depends on, and so has to wait for, the result of the next before completing. Likewise, each iteration can only be spawned by the one before.

Any code inserted between "NEW_I=I-1" and "RETURN..." could be run in parallel, but only if NEW_I isn't (or can't be) changed within that block. It would take some dandy compiler or interpreter to work out if/how to parallelise that.

Could such a piece of software be the solution to this whole problem? If so, the procedural/declarative distinction would become largely irrelevant. More likely, the programmer has to be smart, not the software.

On the plus side, it does abstract the problem by a level and gets people thinking about it. Hmmm...

By: rosbif

rosbif — Wed, 30 Nov -0001 00:00:00 +0000

300 baud ???

Boy, your ASR33 was _fast_ ;-)

Mine was 110 baud :(

By: kavadias

kavadias — Wed, 30 Nov -0001 00:00:00 +0000

Interesting!! Your definition of SUM(1) and SUM(I) is close to the definition
SUM(I,J) if (I==J) THEN RETURN J
ELSE RETURN { SUM( I, (I+J)/2 ) + SUM( ((I+J)/2)+1, J ) }

that is easier to parallelize. In this sense it might make easier for programmers to learn how to write parallelizable code. But this can be done all the same in imperative programming, although it may take some (more?) training, and is only because of the more abstract approach to "what" instead of "how" ...
Other than that I'm very curious what you can make out of not using multiple assignment. My SUM(I,J) (implicitely) introduces a tree of intermediate variables that would help parallelization. This is because of recursion that is closer to parallelization of the devide-and-conquer style...

By: loup-vaillant

loup-vaillant — Wed, 30 Nov -0001 00:00:00 +0000

For those who talk about recursive vs iterative: the point isn\'t one being more declarative than the other. The point is we don\'t need while loops. Therefore, we don\'t need that evil multiple assignment¹. If you ban it, or at least isolate it in well defined parts of the program, you will enable or simplify many optimizations. Being more declarative is just a bonus —a huge one, by the way.

Now, using C or C++ without multiple assignment is hardly more suicidal than declarative. Functional languages, on the other hand, make this possible, thanks to \"first class\" functions.

Sure, this particular example was bad. The better one would be:

sum(n) { return fold(+, 0, list(1, n)); }

where we assume that the + function is associative. list() just generates a list, and fold() applies an binary, associative operation to a list. For example, sum(4) could be computed as ((1+2)+3)+4 or (1+2)+(3+4). The first one can be optimized for a single thread and low stack usage, and the second one can be parallelized. In both cases, you can even avoid the construction of the list (it has been done). What makes these optimizations possible is the high abstraction of this code. Such abstraction is nearly impossible if the compiler have to worry about order of execution. If multiple assignment wasn\'t banned or contained, it would have to.

Therefore, multiple assignment is bad for parallel.

[1] http://theroleplayingprogrammer.blogspot.com/2009/06/assignment-considered-harmfull.html