Note that there's more truth in this fantasy than one might think, at least potentially. IXM nodes don't have the ability to fry each other, but they do supply each other with power, and that power switching is under software control.
So in many configurations, IXM nodes absolutely and literally do have the power to reach a consensus about a misbehaving neighbor and shut it down.
I am definitely, yes, old enough to remember the Transputer. And I hacked artificial life models on the MasPar in the early 90's, which had an architecture in some ways similar to the Connection Machine.
Although the IXM is indeed 'embarrassingly suitable' for assembly into planar grids, it certainly isn't restricted to that. With right angle headers, for example, it's easy to make shapes likes rings and cubes and so forth.
When the global computational geometry of a machine is fixed at design time, before the ultimate task is known, routing can easily become a major problem. And general routing is hard. Maybe too hard.
But part of exploring modular systems in the 'physical computation' space is trying to figure out ways to make the geometry of the particular computer you build better fit the behavior you're implementing, which can help ease the general purpose routing
problem.
And if one really gets into a corner, well, ribbon cable is cheap.
Re:Took mine apart
on
Old Toy Modding?
·
· Score: 2, Interesting
robots as well. To correct for this, one would want to put a sensor which senses the rotating shaft on the motor -- keep rotating motor until it's gone through the proper amount of degrees instead of just
Well, it's possible that this was a non-standard add-on done before I got to it, but when we hacked on a big trak as a summer hardware project in school, that one at least had photocells looking through the teeth on the track drive gears.
So you didn't have to dead-reckon track distance from motor runtime; instead you debounced the photocell output and counted gear teeth passing. You could and did still get screwed by various amounts of slip between the track and the floor, but variable motor speed wasn't as much of an issue.
von Neumann, J. (1948/1963). The general and
logical theory of automata. In A.H. Taub, ed.,
John von Neumann, Collected Works, Volume 5:
Design of Computers, Theory of Automata and
Numerical Analysis. Oxford: Pergamon Press.
E.g., from page 304:
Thus the logic of automata will differ from the
present system of formal logic in two relevant
respects.
1. The actual length of "chains of reasoning,"
that is, of the chains of operations, will have to
be considered.
2. The operations of logic (syllogisms,
conjunctions, disjunctions, negations, etc., that
is, in the terminology that is customary for
automata, various forms of gating, coincidence,
anti-coincidence, blocking, etc., actions) will
all have to be treated by procedures which allow
exceptions (malfunctions) with low but non-zero
probabilities. All of this will lead to theories
which are much less rigidly of an all-or-none
nature than past and present formal logic. They
will be of a much less combinatorial, and much
more analytical, character. In fact, there are
numerous indications to make us believe that this
new system of formal logic will move closer to
another discipline which has been little linked in
the past with logic. This is thermodynamics,
primarily in the form it was received from
Boltzmann, and is that part of theoretical physics
which comes nearest in some of its aspects to
manipulating and measuring information.
So basically he was a'wishin' and a'hopin', but
sadly, as I said, `the present system of formal
logic' from his present is still most all
we've got in our present as well.
Inexperienced and lazy programmers are usually
poor at error-handling, and it's easy to lay the
blame there -- but at a deep level that misses the
point.
This is not about open-source vs closed-source
programs, nor for-fun vs for-money programmers. It's
about computational models such as von Neumann
machines that, at their deepest roots, assume
there will be no errors. That
chain-of-falling-dominos style of thinking so
permeates conventional programming on conventional
machines that it's almost surprising that any code
has any error handling at all.
Of course it's possible to hand-pack
error-handling code all around the main functional
code in an application.. and of course quality
designers and programmers in and out of
open-source will do just that.. but viewed
honestly we must admit it's an huge drag having to
do so, and typically fragile to boot, because the
typical underlying computational and programming
models provide no help with it. Error-handling
code tends to be added on later to applications
just as try/catch was added on later to
C++.
Lest we think this sad state must be
inevitable, let's recall that other computational
models, like many neural network architectures for
example, are inherently robust to low level noise
and error. Then, that underlying
assumption colors and shapes all the `programming'
that gets built on top of it. We're to the point
where trained neural networks, for all the
limitations they currently have, can frequently
do the right thing in the face of entirely
novel and unanticipated combinations of inputs.
Now that's error handling.
The saddest part is that von Neumann knew his
namesake architecture was bogus in just this way,
and expressed hope that future architectures would
move toward more robust approaches. Fifty years
later and pretty much the future's still waiting..
Ah, you're right. I was somehow lala imagining
it was the application of `==' to one or two strings that would yield NaN, but actually `==' just propagates numeric context, so strings get numerified first, and non-numeric strings numerify as NaN in Perl 6.
Hadn't noticed that
`if ($a < $b < $c) {.. }' is
actually illegal in Perl 5. Would've expected it to follow C, where you can be sick with like `int cp = (c!=0); if (a <
b <= cp) {.. }' to say `a less than b implies (in the sense of modus ponens) that c is not zero'.
But, Perl didn't do that, so you can't say twisted stuff like that, so there's no loss to adding multiway comparisons to Perl 6.
Wow, Perl is actually cleaner than something!
On the one hand, Exegesis 3 tells us that in Perl 6, 100 < -s $filepath <= 1e6 is essentially equivalent to:
(100 < -s $filepath) && (-s $filepath <= 1e6) except that the `-s $filepath' only gets evaluated once. We're supposed to be Wow! Neat! about that.
On the other hand, we are also told:
Did you notice that cunning $a == $b != NaN test in operator:EQ? This lovely Perl 6 idiom solves the problem of numerical comparisons between non-numeric strings.
which may be cunning, except of course with wow neat multiway comparisons it is equivalent to
($a == $b) && ($b != NaN),
which doesn't do the advertised job.
Finally, lest we might suspect operators like < and <= are treated differently from == and != for purposes of this `feature', we are told:
binary <, >, lt, gt, ==, !=, etc. become chainable
Predict the ultimate (though probably not imminent) demise of multiway comparisons in Perl 6.
I've yet to find an open source project that
ignored unsolicited code that happened to
be a flat out bug fix. I've submitted bug fix patches for Samba and the xpm library, for
example, and they were both applied no problem,
even though I'm totally nobody in either of those
projects.
At the other extreme, sometimes 'unsolicited code'
contains (more or less plausible attempts at) new
features, switches, or other user-visible or
API-altering changes. In that case, it's really a
set of new design decisions that are being offered, and the fact that it's already embodied in some code is at best secondary.
Design decisions
take time and effort to evaluate--and often,
even if there really is a problem that needs to
be addressed, the first ten or twenty
superficially obvious fixes for it are actually
wrong.
In that sort of case, it's pretty much silly to
think that anything will happen if one
simply drops that sort of code into a project
mailbox with a note saying 'Here are some cool
improvements I've made to your project.
They work real good for me'.
What kinds of unsolicited code have people had accepted and rejected?
Perhaps the biggest point of departure is that biological systems are evolutionary, while computer systems are designed by humans, with knowledge of the possible countermeasures. That means that many immune system strategies just won't translate.
The `humans have forethought' notion is often raised against the idea that living systems concepts apply to engineered systems, but in fact it's unclear how often, in the end, such foresight has made a difference. Engineers designing the original PC knew about concepts like protected kernel mode, per-process address spaces, and so forth, but they left them out of the design anyway. In hindsight we see such decisions virtually created the computer virus deluge that immediately followed.
Why did they do that? Where was the foresight there? Because of the bottom line: There was no immediate need for such measures, and it would've cost money and resources and time-to-market to put them in.
Responding quickly and cheaply to only the immediate needs is a hallmark of both evolutionary systems and market-driven systems.
In the big picture, human foresight is often a good deal less important than we usually think it is. My best working hypothesis is that human ingenuity and intentionality essentially only accelerate what is undeniably an evolutionary system.
I'd seriously watch out for that available-at-CostCo `Mandrake' distribution. A friend got it and got reamed:
The install failed because one of the needed modules was built for the wrong kernel version, so an install-time insmod died.
It turned out that if you read the fine print it's actually a Macmillan product, not even an `official Mandrake' product... so, no Mandrake support. (Not even any Macmillan support, actually, just some third-party um professionals whose name escapes me.)
I think such knock-off slap-together quick-buck distributions do an extreme disservice to the cause, putting bogus software in the hands of those who can least deal with it and thus tending to feed the FUD.
Slashdot Mirror
I love it.
Note that there's more truth in this fantasy than one might think, at least potentially. IXM nodes don't have the ability to fry each other, but they do supply each other with power, and that power switching is under software control.
So in many configurations, IXM nodes absolutely and literally do have the power to reach a consensus about a misbehaving neighbor and shut it down.
Well, I want to say "No brag just fact."
Except it's not quite fact: What I actually said was "under two inches squared" -- which is closer to four square inches.
But hey, I'm glad I didn't say "under 50mm squared".
Also, the specs got a little muddled. The raw hardware on the current board has 58KB RAM, 512KB flash for program store, and 16KB EEPROM for data.
I'm part of the project that produced this board.
I am definitely, yes, old enough to remember the Transputer. And I hacked artificial life models on the MasPar in the early 90's, which had an architecture in some ways similar to the Connection Machine.
Although the IXM is indeed 'embarrassingly suitable' for assembly into planar grids, it certainly isn't restricted to that. With right angle headers, for example, it's easy to make shapes likes rings and cubes and so forth.
When the global computational geometry of a machine is fixed at design time, before the ultimate task is known, routing can easily become a major problem. And general routing is hard. Maybe too hard.
But part of exploring modular systems in the 'physical computation' space is trying to figure out ways to make the geometry of the particular computer you build better fit the behavior you're implementing, which can help ease the general purpose routing problem.
And if one really gets into a corner, well, ribbon cable is cheap.
So you didn't have to dead-reckon track distance from motor runtime; instead you debounced the photocell output and counted gear teeth passing. You could and did still get screwed by various amounts of slip between the track and the floor, but variable motor speed wasn't as much of an issue.
E.g., from page 304:
So basically he was a'wishin' and a'hopin', but sadly, as I said, `the present system of formal logic' from his present is still most all we've got in our present as well.This is not about open-source vs closed-source programs, nor for-fun vs for-money programmers. It's about computational models such as von Neumann machines that, at their deepest roots, assume there will be no errors. That chain-of-falling-dominos style of thinking so permeates conventional programming on conventional machines that it's almost surprising that any code has any error handling at all.
Of course it's possible to hand-pack error-handling code all around the main functional code in an application.. and of course quality designers and programmers in and out of open-source will do just that.. but viewed honestly we must admit it's an huge drag having to do so, and typically fragile to boot, because the typical underlying computational and programming models provide no help with it. Error-handling code tends to be added on later to applications just as try/catch was added on later to C++.
Lest we think this sad state must be inevitable, let's recall that other computational models, like many neural network architectures for example, are inherently robust to low level noise and error. Then, that underlying assumption colors and shapes all the `programming' that gets built on top of it. We're to the point where trained neural networks, for all the limitations they currently have, can frequently do the right thing in the face of entirely novel and unanticipated combinations of inputs. Now that's error handling.
The saddest part is that von Neumann knew his namesake architecture was bogus in just this way, and expressed hope that future architectures would move toward more robust approaches. Fifty years later and pretty much the future's still waiting..
Hadn't noticed that `if ($a < $b < $c) { .. }' is
actually illegal in Perl 5. Would've expected it to follow C, where you can be sick with like `int cp = (c!=0); if (a <
b <= cp) { .. }' to say `a less than b implies (in the sense of modus ponens) that c is not zero'.
But, Perl didn't do that, so you can't say twisted stuff like that, so there's no loss to adding multiway comparisons to Perl 6. Wow, Perl is actually cleaner than something!
100 < -s $filepath <= 1e6
is essentially equivalent to:
(100 < -s $filepath) && (-s $filepath <= 1e6)
except that the `-s $filepath' only gets evaluated once. We're supposed to be Wow! Neat! about that.
On the other hand, we are also told:
which may be cunning, except of course with wow neat multiway comparisons it is equivalent to ($a == $b) && ($b != NaN), which doesn't do the advertised job.Finally, lest we might suspect operators like < and <= are treated differently from == and != for purposes of this `feature', we are told:
Predict the ultimate (though probably not imminent) demise of multiway comparisons in Perl 6.
At the other extreme, sometimes 'unsolicited code' contains (more or less plausible attempts at) new features, switches, or other user-visible or API-altering changes. In that case, it's really a set of new design decisions that are being offered, and the fact that it's already embodied in some code is at best secondary.
Design decisions take time and effort to evaluate--and often, even if there really is a problem that needs to be addressed, the first ten or twenty superficially obvious fixes for it are actually wrong.
In that sort of case, it's pretty much silly to think that anything will happen if one simply drops that sort of code into a project mailbox with a note saying 'Here are some cool improvements I've made to your project. They work real good for me'.
What kinds of unsolicited code have people had accepted and rejected?
Why did they do that? Where was the foresight there? Because of the bottom line: There was no immediate need for such measures, and it would've cost money and resources and time-to-market to put them in.
Responding quickly and cheaply to only the immediate needs is a hallmark of both evolutionary systems and market-driven systems.
In the big picture, human foresight is often a good deal less important than we usually think it is. My best working hypothesis is that human ingenuity and intentionality essentially only accelerate what is undeniably an evolutionary system.
This is the /.er's goofing on me, right?
- The install failed because one of the needed modules was built for the wrong kernel version, so an install-time insmod died.
- It turned out that if you read the fine print it's actually a Macmillan product, not even an `official Mandrake' product... so, no Mandrake support. (Not even any Macmillan support, actually, just some third-party um professionals whose name escapes me.)
I think such knock-off slap-together quick-buck distributions do an extreme disservice to the cause, putting bogus software in the hands of those who can least deal with it and thus tending to feed the FUD.