How hard is to build a processor?

Sun Feb 28, 2010 12:59 am   

Hi John,

John Nagle wrote:

The appeal/beauty of using something like a water source
is that folks don't see "discrete motion" in it -- though
recognize that it *is* moving.

E.g., a gear turning is less "magical" than water flowing.
Especially as adjusting the flow rate can be virtually
imperceptible. Anything that moves quickly (perceptibly)
defeats the purpose. If, OTOH, you look at something...
then look at it again 5 minutes later and have to *work*
to figure out what has changed (and *how*), then you're
never quite sure that it actually *did* change.

I.e., someone would have to invest a fair bit of effort to
figure out:
1) that it does move
2) that it moves predictably
3) that it is a timepiece
4) *how* to tell the time based on that

It would be impossible (impractical) to hide the fact that there
is a pump recirculating the water. But, it's relatively easy to
hide the feedback loop so it appears (to mere mortals) to be
"magic" :>

For example, I use a pocketwatch as a compass and always
confuse the hell out of observers trying to deduce the "trick"
from the 10 second observation. Leave people with puzzles to solve
so it makes the experience more memorable. :>

Sun Feb 28, 2010 2:24 am   

"Don McKenzie" <5V_at_2.5A> wrote in message
news:7uoa2jF5dnU1_at_mid.individual.net...

actually build one, and large chunks of source code for the monitor. It's
fascinating to see such sophisticated code from an era when few of todays
accepted standards were in place.

According to the website, the Apollo 11 machine was made entirely with early
3-input Nor gate ICs, thousands of them, and core memory. The construction
technique was wirewrap, with the backplane encapsulated.

Sun Feb 28, 2010 3:01 pm   

On Feb 27, 11:11 am, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:


I'm not sure where I got this image in my mind, but I seem to recall
that the motion of the end of the shadow at a given time each day
moves in a figure eight over the course of the year. Ok, I got over
my laziness and googled it. This is called the "analemma" and is
caused by the tilt of the Earth's axis and the elliptical orbit around
the sun. This still does not make the position at all times and days
unique, but it does help a bit (and hurt since it becomes a lot more
complex to label).

Rick

Sun Feb 28, 2010 3:17 pm   

On Fri, 26 Feb 2010 23:06:50 -0700, D Yuniskis
<not.going.to.be_at_seen.com> wrote:


The elevation of the sun varies very little close to the solstice,
about the solar diameter (0.5 degrees) at +/-8 days from solstice and
only about 12 arc secs at +/- 1 day from the solstice.

Various tropospheric refractions can alter the apparent elevation. The
refraction is worst close to horizon, so the winter solstice will be
worse. Trying to determine sunrise and sun set times is even worse,
since average refraction is just slightly less than one degree and can
vary quite a bit from day to day (even mirages).

The solar elevation changes rapidly close to the equinoxes (about the
solar diameter/day), so this is the best time to determine the date.

Determining the local solar time is easy, just determine when the sun
transmits the meridian (i.e is directly in the South in Northern
hemisphere). Some local clocks are required to divide the time until
the next solar transit into 24 hours. The time between two transits is
not usually 86400 (atomic) seconds, but varies slightly according to
the equation of time (which is due to the elliptical orbit of the
Earth).

Averaging these variation over the year, you can calculate the mean
solar time, in which the day is exactly 86400 seconds long.

Waiting for a year to determine the mean solar time or using a
sufficient accurate local frequency standard, you can determine, if
the actual solar day is longer or shorter than 24 hours, which may
help some ambiguity problems in the elevation measurements.

Determining the date is much harder due to the refractions, but
averaging over a sufficient number of measurements (days), this should
give relative accurate results at the equinoxes.

Once you know the mean solar time and know your longitude, you know
the time at the zone meridian (0, 15, 30, 45 ... degrees E/W). Knowing
your latitude, you can determine in which country you are in and hence
which time zone is actually used at that area. Finally by knowing your
date, will allow you to calculate, if daylight saving time should be
used .

Sun Feb 28, 2010 7:48 pm   

Bill Cooke wrote:


The IBM 1620 was the first computer I used. It had
some interesting features, a BCD machine with variable length
data words.

I ran a fibonacci series on it to 2000 terms it took 18 hours.

A lot of neat things could be done with the math tables which
could be set at run time. The math tables were also the target
some elaborate pranks in IBM 1620 labs

It was also the first computer that I wrote a compiler for. I
have a lot of good memories of the 1620.

That was a long time ago.

Regards,

Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com











--- news://freenews.netfront.net/ - complaints: news_at_netfront.net ---

Sat Mar 06, 2010 8:43 am   

On 2010-02-27, D Yuniskis <not.going.to.be_at_seen.com> wrote:

yes.


that may happen for some dates of some years :)

--- news://freenews.netfront.net/ - complaints: news_at_netfront.net ---

Mon Mar 08, 2010 9:30 pm   

rickman wrote:

So (thinking in terms of a *truly* unique hack), if you *watched*
the motion over the course of a particular day (e.g., 'yesterday'),
could you *uniquely* determine that day?

Mon Mar 08, 2010 9:57 pm   

On Mar 6, 1:43 am, Jasen Betts <ja...@xnet.co.nz> wrote:

Actually, it happens for every day of every year other than the
solstices. The two solstices (actually a day or two on either side
depending of the season) has the lowest or highest path across the
sky, so no other day will have quite in that same path. But every
time of every other day (excluding a few seconds at the start and end
of the day when one day has sunshine and the other does not) will
match a time of two days, between spring to fall and one between fall
to spring. The path of the sun may not be the same on those two days,
but each point will map to two different times and days.

Rick

Mon Mar 08, 2010 11:29 pm   

rickman <gnuarm_at_gmail.com> writes:


In terms of the project I've got in mind, people are really
over-thinking this..... I'll be very surprised if the shadow ends up
distinguishing the day with better than a couple-of-days precision
anyway.

That said, two days won't follow *exactly* the same path: a fall day's
shadow is going to be between two spring days' shadows, and so forth.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Mon Mar 08, 2010 11:36 pm   

Arrrgh -- I misread what you were saying, so my response didn't make
much sense.

But, I still don't expect a point to necessarily correspond to two
date/time pairs. Time is continuous, but days aren't. There will be a
gap between any two days' shadow tracks (probably smaller than the
fuzziness of the shadow caused by diffraction but there all the same).
Unless two tracks exactly overlay for some meaningful part of the
tracks, a given track can only intersect other days' tracks at a finite
number of points points.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Tue Mar 09, 2010 1:20 am   

On Feb 27, 6:47 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

Sounds like a cool idea.
Would need this sort of correction :
http://www.swanstrom.net/sundial/gnomon.htm

which means it could take a couple of days to 'train',
in order to be certain.

For the best precision, you'd probably do a simple sliding-data-
match, where maybe the last 7? days of readings, are moved along to a
point of least-errors.
(and maybe a cloudy-day default, where it just increments the day ?

I don't see why you think you can't get 'correct day'
precision out of this ?

Pushing the actual-time precision is likely to be
more challenging ?
-jg

Tue Mar 09, 2010 3:36 am   

On Mon, 8 Mar 2010 14:20:46 -0800 (PST), -jg <jim.granville_at_gmail.com>
wrote:


Possibly in March or September, but absolutely not in July or
December, just look at the graph.

A 7 day period would be sufficient to figure out, if it is March or
September by checking the direction of the solar movement.


That is trivial. The apparent solar diameter is 30 arc minutes and
since the sun moves 15 degrees each hour, it only takes 2 minutes to
move its own diameter, thus the actual noon can be determined with
much better precision.

In order to get the solar mean time noon, you also need to know the
approximate date to apply the equation of time.

Tue Mar 09, 2010 11:00 am   

On 2010-03-08, rickman <gnuarm_at_gmail.com> wrote:

The solstice is not a day it is an instant,
and it does not happen same the date and wall time every year.

most years have no days equidistant from the solstice.

therefore noon (or any other hour) on most days will duplicate the same
elevation of the sun above the horzon.


--- news://freenews.netfront.net/ - complaints: news_at_netfront.net ---

Tue Mar 09, 2010 11:04 am   

On 2010-03-08, D Yuniskis <not.going.to.be_at_seen.com> wrote:

Given lattitude and longitude (or equivalent) and sufficiently good
instruments, and the right data and skills, yes.


--- news://freenews.netfront.net/ - complaints: news_at_netfront.net ---

Tue Mar 09, 2010 7:20 pm   

Jasen Betts wrote:

So, a *device* that watched these things could deduce date/time (?)
How much more would it have to do to deduce location (or, at least,
latitude)? Probably just watch for a longer period of time?