Re: Bruno's argument

From: Brent Meeker <meekerdb.domain.name.hidden>
Date: Tue, 01 Aug 2006 16:54:50 -0700

1Z wrote:
>
> Stathis Papaioannou wrote:
>
>>John M writes:
>>
>>
>>>Peter Jones writes:
>>>
>>>
>>>>Hmm. Including limitations in time?
>>>
>>>Yes, if an infinite number of finite computations are run simultaneously on
>>>a system with a finite number of physical states.
>>>
>>>Stathis Papaioannou
>>>-------------------------------------
>>>So if I have a system with finite number of physical states, it will take a
>>>matching finite number of (base)-computations leaving an infinite number
>>>untreated. Out of them I can take a deduction for muiltiplying the finite
>>>number of physical states by the finite number of the base-states to get to
>>>the total number of computability on that system in parallel - still a
>>>finite number. I still have an infinite number of unbtreated cases left.
>>>Damn that infinite! Cantor's curse.
>>>
>>>John M
>>
>>Suppose there is a very simple physical system that goes through two states,
>>"on" and "off". You wish to map these states onto a binary sequence which at
>>first glance seems too long: 10110100... You write down the following: on the
>>first run, on->1 and off->0; on the second run, on->1 and off->1; on the
>>third run, on->0 and off->1; and so on, for as long as you like. It is not common
>>practice to change the code from run to run when designing a computer, but
>>that is just a matter of convenience. If you specify exactly how the code
>>changes the meaning is unambiguous, and in principle the two physical states
>>can encode any number of binary states, or even more complex computations.
>
>
> A computation is not a series of states. A computation is an
> implementation
> of an algorithm, and algorithms include conditional statements which
> must be modelled by something with counterfactual behaviour --
> by something which *could have* execute the other branch.

I think this "something" is an interaction with something outside the
computer, i.e. a different input or a real-time sensor input. I could
also be a random variable generated internally - but I'm not clear on
whether that satisfies lz's idea - it doesn't satisfy mine.

Brent Meeker

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Everything List" group.
To post to this group, send email to everything-list.domain.name.hidden
To unsubscribe from this group, send email to everything-list-unsubscribe.domain.name.hidden
For more options, visit this group at http://groups.google.com/group/everything-list
-~----------~----~----~----~------~----~------~--~---
Received on Tue Aug 01 2006 - 19:56:55 PDT

This archive was generated by hypermail 2.3.0 : Fri Feb 16 2018 - 13:20:11 PST