[ExI] Destructive uploading.

Eugen Leitl eugen at leitl.org
Wed Sep 7 19:39:27 UTC 2011


On Wed, Sep 07, 2011 at 01:59:16PM -0400, Mike Dougherty wrote:
> On Wed, Sep 7, 2011 at 1:28 PM, Kelly Anderson <kellycoinguy at gmail.com> wrote:
> > So my assertion is that only an emulation of MY brain can be remerged
> > into my brain, at least easily. Do you understand my point? And this
> > may be something that only happens for a brief period of time before
> > we fully understand the brain enough to translate changes in my brain
> > to changes in yours... but that seems many orders of magnitude more
> > complex.
> 
> I had a similar thought today:  Suppose there is some unique character
> to the computing substrate, will we find a measure of preference and

I think there are local optima in the space of data models and
transformations implemented by hardware and that co-evolution
will drive up the consensus interaction rate to the maximum
physically feasible and affordable (energetically). Being too 
slow has a dramatic negative fitness impact. So the more things change
the more they stay the same, welcome to the new and improved
rat race. Welcome the new boss, same as the old boss (Darwin).

> affordability?  Sure we might love to be running at high clock rates

You can't have global clocks for relativistic raisins, only 
systems of coupled but otherwise asynchronous/free-running 
oscillators. If you want to slow things down, you could use 
programmable volume wave generators (with wavefronts passing 
through acting as clock), which act a bit like a higher order clock. 
This is extremely inefficient as it needs dedicated substrates,
or higher-order emulation layers on the generic/optimal substrate
which are very much like today's pure-software emulators,
and hence terribly inefficient.

Same thing for halting state evolution: you need both means to stop
the free-running volume in a consistent state and to read it out
through the bounding volume to pickle it up and stream it to a
remote location, either for backup or reinstantiation purposes.
It might be that this is enough handicap that it never happens,
and you just stop the thing (assuming it's fully static, and
of course the encoding is sufficiently redundant by necessity
of being able to deal with runtime hardware damage so that 
some inconsistency will be self-correcting) by
pulling the juice (or switch off the pumping laser, assuming
it's optically powered; probably you'd have some kind of power
distribution bar in there, though). It would be pickled that way,
so you'd only have to read the static pattern out, given that
powering the reading infrastructure is distinct from powering
the execution infrastructure. Of course having both in the
same place dilutes functionality concentration, natch.

Above is probably too compressed to make much sense, unless you are me.
It does make sense though, honest. I can expand, if necessary.

> on CPU, but will that life be the uniquely squishy experience of human
> wetware?  Suppose we grow so bored with the day to day that we run

The squishiness is completely subjective. Of course morphogenesis
makes direct/implicit use of squishiness, but you don't have to 
carry evolutionary luggage to new substrate where it's expensive
and rather use its new, intrinsic cheap features instead.
But how do you engineer it from here to there, to cross the 
discontinuity nonembodied? Those built de novo don't have that handicap.

> orders of magnitude slower on, for example, a contraption powered by
> tides (one cycle per ebb/flow on a beach).  Is it something you'd be

Inert statues are crunchy, and good with ketchup.

> willing to try just for kicks? (of course you'll keep your existing
> processes as they are)

How can you afford it? People will eat your lunch.
 
> I wonder if it would be like the difference between sitting in a chair
> made of plastic vs. wood or covered in cloth vs. leather.  In all
> examples the task is merely "sitting" but with subtle variations in
> texture and style.

Sten Nadolny will hate the future.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE



More information about the extropy-chat mailing list