To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 17569
17568  |  17570
Subject: 
Re: lego turing machine
Newsgroups: 
lugnet.off-topic.geek, lugnet.robotics, lugnet.robotics.rcx.nqc
Date: 
Fri, 29 Mar 2002 16:54:01 GMT
Viewed: 
176 times
  
Hi JDF,
Thanks for the feedback.

I know it's not a Turing machine in the true sense, but let me tell you what
I'm trying to do. At the moment I realize that I have built a sort of binary
adder. But what I am currently implementing is a change in code whereby
instead of adding the two numbers using a typical algorithm like I have
used, the numbers will be added using a turing algorithm. The algorithm is
available on this site:
http://cgi.student.nada.kth.se/cgi-bin/d95-aeh/get/umexeng Check that part
on adding to binary numbers.

As I can't use a read/write head because of obvious construction
difficulties I have stretched Turing's idea, implementing that actual moving
head with multiple states in the software itself. (yes, I know that's a big
liberty but I had to as a write head (i.e. actually swap bricks) would be
near impossible. Though I'm not going to say impossible after having seen a
rubik's cube solving bot.) So the only change I need to make to my machine
is to change the binary adding algorithm with a turing one. Please note that
then it will be a part simulated, part actual, yet a complete turing
machine. (barring infinite tape which I think would be hard to move with the
little lego motor)

Let me explain whats going to happen:
1) first card is fed in and the value is stored in a integer array
2) same for second card
3) These two arrays are merged into a larger third array, the final turing
tape. So all data to work with is on one single tape on which the answer
will be written.
4) Now the RCX (in the software) starts from the first element. It has a
number of states each of which have well defined behaviours depending on the
contents of the element. The state is stored in an external variable and
that is, as you say,  the only memory. So half way through I'm basically
taking the interesting bit into the code.

So now you have one tape, a number of states, well defined behaviours for
each state. Infinite tape is out, so what I've got is a hybrid turing
machine, part carried out mechanicaly (reading) and part on software (the
actual computational work). This was done only because a write head would be
too complicated. However to any onlooker who doesn't know that a turing
machine simulation is going on in the code, it would seem a binary adder. On
the site mentioned in the first paragraph, there is also a beautiful visual
of whats actually going on inside the RCX. I only need to adapt it to NQC.

Also the code is yet to be completed. If anyone reading can adapt the
algorithm on the site mentioned above into my code (on the part labelled
binary addition) that would be very cool of you. I've been thinking of ways
to implement it, and I think I'll get down to it tonight.

hope that clarifies all doubts. sorry i didn't mention this on the site, I'm
gonna put this thread up onto the site as an explanation if you don't mind.
thanks
aatish
aatish@mac.com
www.geocities.com/aatishb/

P.S.- this is offtopic but if anyone has code on using rcx as a morse code
reader pls. mail it to me.

"The better you luck gets, the less you learn." ;-)


"J.D. Forinash" <foxtrot@cc.gatech.edu> wrote in message
news:GtqoG7.Fr@lugnet.com...
In article <Gtp9FI.62A@lugnet.com>, Aatish Bhatia <aatish@mac.com> wrote:
murphy's law at its best: due to bandwith problems, my server has cut off • my
page. it now 1:30 am., and i've finally got a mirror up on an old yahoo
account. it should do fine. looks like 0catch.com had a very big catch.
www.geocities.com/aatishb/

An interesting idea, but the pedant and geek in me has to note that
this isn't a Turing machine.

Even ignoring Turing's original idea that the tape is infinite, the • problem
is that the Turing machine placed its output back on the tape. It would
read input from one cell of the tape, and depending on a) the state the
machine is in (defined by the program), b) the input under the read head,
and c) what the program says to do for those two inputs, proceeds to write
output to the tape and then move the read head left or right.

The second problem is that a Turing machine has only one concept of • memory,
and that's state.

What you have is pretty cool, a lego-tape binary adder, and its • functionality
could be abstracted to that of a Turing machine,  but it's certainly not a
Turing machine.

-JDF
--
J.D. Forinash                                     ,-.
jd@forinash.not                                  ( <
The more you learn, the better your luck gets.    `-'



Message has 1 Reply:
  Re: lego turing machine
 
(...) I got to thinking, maybe this isn't so impossible after all. Imagine if you used 2x2 blocks with 2x2 tiles on top. Now you have something the RCX can lift. Run two pieces of train track parallel to each other, with four spots' width separating (...) (23 years ago, 29-Mar-02, to lugnet.off-topic.geek, lugnet.robotics, lugnet.robotics.rcx.nqc)

Message is in Reply To:
  Re: lego turing machine
 
(...) An interesting idea, but the pedant and geek in me has to note that this isn't a Turing machine. Even ignoring Turing's original idea that the tape is infinite, the problem is that the Turing machine placed its output back on the tape. It (...) (23 years ago, 29-Mar-02, to lugnet.off-topic.geek, lugnet.robotics, lugnet.robotics.rcx.nqc)

9 Messages in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR