CBFalconer wrote:
> Already done, in the tall buildings.  There the problem is to
> conserve elevator shaft space.  Works something like airline hubs
> and feeder lines.

The WTC AFAIK had two sorts of elevators: express ones, which could go up to
levels divided by 20 or so (each of them single source/single destination,
so that the elevators took less from the office space in the precious upper
floors), and slower ones, which shared the shaft space, and could only
reach up within the express lift granularity. To use the vertical space
even better, it could be possible to have a several-level express lift,
i.e. with entrances in several levels, but still with the +-20 floors (or
whatever) granularity.

If I was to build a skyscraper, I would build a big, fast, several-level
wide-granularity express elevator (a "vertical subway") in the core of the
building, complete with own air supply and water coolant for fire emergency
use, and the slow elevators as panorama elevators on the outside. That way,
no shaft space is used for the slow elevators (all elevator doors are
windows when no elevator is there).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

In comp.arch Del Cecchi <cecchinospam@us.ibm.com> wrote:
> Ed Beroset wrote:
> > Terje Mathisen wrote:
> > 
> >>
> >> I have noted previously here in c.a that most of the _really_ good 
> >> low-level/systems programmers I know seem to have an engineering 
> >> instead of computer science background.
> >>
> >> A coincidence?
> > 
> > 
> > I have also noticed that the programmers from a computer science 
> > background tend to be much better at working out a system architecture 
> > and planning first.
> > 
> > My hypothesis:  the more detail-oriented people tend to gravitate toward 
> > the engineering side, and tend to excel at detail-oriented tasks, while 
> > the computer science people tend to be better at big picture and 
> > abstract concepts.
> > 
> > Just MHO.
> > 
> > Ed
> > 
> Those comp-sci geniuses are the ones that gave us a software paradigm 
> that is susceptible to attacks as simple as buffer overruns, and store 
> data in randomly scattered chunks linked by pointers.   And put multiple 
> unrelated locks in the same cache line?  That the ones you are talking 
> about?

Compared to the quality of say the "average" ethernet controller 
out there these don't seem to be all that major bloopers?

> 
> Del cecchi

-- 
	Sander

+++ Out of cheese error +++

> I would expect better algorithms would await better input methods. 
> For example, instead of selecting from 'up' or 'down', the
> prospective rider could select the destination floor.  

I've been in two buildings in recent years where the elevator user interface
works just in that way. One is ~30 stories, but the other is only 14, IIRC.
Both have access control via RFID cards, and those cards can be programmed
to either just allow a single floor - no need to enter the data then - or
a range of floors. Once the desired floor has been entered (explicitly or
implicitly), the display will show the letter of the elevator that will
service you. For larger parties, it is recommended to enter the data more
than once.

	Jan

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:421237FB.FB33D465@yahoo.com...
> Stephen Fuld wrote:
>> "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
>>> CBFalconer <cbfalconer@yahoo.com> writes:
>>>>
>>>> I would expect better algorithms would await better input methods.
>>>> For example, instead of selecting from 'up' or 'down', the
>>>> prospective rider could select the destination floor.  Now an
>>>> arriving car has to display which floors it will handle, and
>>>> separate the sheep from the goats.  The sheep and goats have to be
>>>> sufficiently alert to be separated.  Maybe something along the
>>>> lines of "take a ticket" based on rfids would work.
>>>
>>> Yes.  As with all such issues, a very small amount of extra
>>> information can make a great deal of difference.
>>
>> The key word here is "can".  In thinking about this particular
>> possibility, it seems the big advantage would be if one could have
>> multiple elevators where one would service the "higher" floors and
>> one the "lower".  Then the people going to the higher ones wouldn't
>> have to wait for all the stops in the lower ones.  This is probably
>> only usefull for fairly tall buildings.  In fact, for such
>> buildings, something like this is frequently done.  I have been in
>> buildings with multiple banks of elevators each clearly labeled
>> with the range of floors they service.  While this doesn't have the
>> flexibility of being able to change the floors serviced
>> dynamically, it avoids the need for dynamic "sheep/goat
>> separation", (with presumably a higher mistake rate than a static
>> system) as described above.
>
> Already done, in the tall buildings.  There the problem is to
> conserve elevator shaft space.  Works something like airline hubs
> and feeder lines.

That is a different solution.  What you are talking about is "stacked" 
elevators, where you have to get off at some intermediate floor and switch 
to another elevator.  That is the only way to conserve shafts.   What I was 
talking about was where all the elevators went to the lobby, but only to a 
subset of the upper floors.  Doesn't conservve shafts, but reduces total 
time for those wanting to go to the upper floors, as they don't have to wait 
through all the stops on the lower ones.

-- 
 - Stephen Fuld
   e-mail address disguised to prevent spam 

Tim Wescott wrote:
> CBFalconer wrote:
> 
>>
>> Already done, in the tall buildings.  There the problem is to
>> conserve elevator shaft space.  Works something like airline hubs
>> and feeder lines.
>>
> And I've seen proposals (still in the gee-whiz) stage to have an "up" 
> shaft, a "down" shaft and a few cross-shafts, with motors in the 
> elevator cars so they have more autonomy for getting up and down.
> 
> It was a popular science kind of thing -- I have no idea if it's being 
> seriously developed (but it'd be fun to do the software!).

Google "wonkavator"  (:

In article <1114jf5fbfah663@corp.supernews.com>,
Tim Wescott  <tim@wescottnospamdesign.com> wrote:
>CBFalconer wrote:
>And I've seen proposals (still in the gee-whiz) stage to have an "up" 
>shaft, a "down" shaft and a few cross-shafts, with motors in the 
>elevator cars so they have more autonomy for getting up and down.

Sounds like the "Tower of Terror" ride at the MGM Studios park at
Disney World.  The elevator "car" seats 12 people or so, and starts
out running vertically.  It then switches into a horizontal haunted
house mode of operation before finishing vertically again.  Think
of the fun the BOFH would have.  He he. :-)
-- 

Craig Ruff      	NCAR			cruff@ucar.edu
(303) 497-1211  	P.O. Box 3000
			Boulder, CO  80307

CBFalconer wrote:

> 
> Already done, in the tall buildings.  There the problem is to
> conserve elevator shaft space.  Works something like airline hubs
> and feeder lines.
> 
And I've seen proposals (still in the gee-whiz) stage to have an "up" 
shaft, a "down" shaft and a few cross-shafts, with motors in the 
elevator cars so they have more autonomy for getting up and down.

It was a popular science kind of thing -- I have no idea if it's being 
seriously developed (but it'd be fun to do the software!).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Stephen Fuld wrote:
> "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
>> CBFalconer <cbfalconer@yahoo.com> writes:
>>>
>>> I would expect better algorithms would await better input methods.
>>> For example, instead of selecting from 'up' or 'down', the
>>> prospective rider could select the destination floor.  Now an
>>> arriving car has to display which floors it will handle, and
>>> separate the sheep from the goats.  The sheep and goats have to be
>>> sufficiently alert to be separated.  Maybe something along the
>>> lines of "take a ticket" based on rfids would work.
>>
>> Yes.  As with all such issues, a very small amount of extra
>> information can make a great deal of difference.
> 
> The key word here is "can".  In thinking about this particular
> possibility, it seems the big advantage would be if one could have
> multiple elevators where one would service the "higher" floors and
> one the "lower".  Then the people going to the higher ones wouldn't
> have to wait for all the stops in the lower ones.  This is probably
> only usefull for fairly tall buildings.  In fact, for such
> buildings, something like this is frequently done.  I have been in
> buildings with multiple banks of elevators each clearly labeled
> with the range of floors they service.  While this doesn't have the
> flexibility of being able to change the floors serviced
> dynamically, it avoids the need for dynamic "sheep/goat
> separation", (with presumably a higher mistake rate than a static
> system) as described above.

Already done, in the tall buildings.  There the problem is to
conserve elevator shaft space.  Works something like airline hubs
and feeder lines.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message 
news:cut7cl$c0o$1@gemini.csx.cam.ac.uk...
>
> In article <4211F82F.3035D23D@yahoo.com>,
> CBFalconer <cbfalconer@yahoo.com> writes:
> |>
> |> I would expect better algorithms would await better input methods.
> |> For example, instead of selecting from 'up' or 'down', the
> |> prospective rider could select the destination floor.  Now an
> |> arriving car has to display which floors it will handle, and
> |> separate the sheep from the goats.  The sheep and goats have to be
> |> sufficiently alert to be separated.  Maybe something along the
> |> lines of "take a ticket" based on rfids would work.
>
> Yes.  As with all such issues, a very small amount of extra
> information can make a great deal of difference.

The key word here is "can".  In thinking about this particular possibility, 
it seems the big advantage would be if one could have multiple elevators 
where one would service the "higher" floors and one the "lower".  Then the 
people going to the higher ones wouldn't have to wait for all the stops in 
the lower ones.  This is probably only usefull for fairly tall buildings. 
In fact, for such buildings, something like this is frequently done.  I have 
been in buildings with multiple banks of elevators each clearly labeled with 
the range of floors they service.  While this doesn't have the flexibility 
of being able to change the floors serviced dynamically, it avoids the need 
for dynamic "sheep/goat separation", (with presumably a higher mistake rate 
than a static system) as described above.

> Similarly,
> you could have a special program for rush hours (and the morning
> one might be very different from the evening one).

I think this is pretty standard for tall buildings.

> What becomes
> very clear on a fairly casual inspection is that understanding
> the properties of the input data is a prerequisite to designing
> good algorithms.

Absolutely.  And, since the elevator companies have been at this for 
something like a century now, the have worked out an awful lot of the "best 
practices".

> This is very, very relevant to telecommunications and many
> aspects of computing, as all experts in the relevant aspects know
> very well.

Absolutely.

> I know just enough to have a glimmering of the depths
> of my ignorance :-)

Me too.  :-)

-- 
 - Stephen Fuld
   e-mail address disguised to prevent spam 

In article <4211F82F.3035D23D@yahoo.com>,
CBFalconer <cbfalconer@yahoo.com> writes:
|> 
|> I would expect better algorithms would await better input methods. 
|> For example, instead of selecting from 'up' or 'down', the
|> prospective rider could select the destination floor.  Now an
|> arriving car has to display which floors it will handle, and
|> separate the sheep from the goats.  The sheep and goats have to be
|> sufficiently alert to be separated.  Maybe something along the
|> lines of "take a ticket" based on rfids would work.

Yes.  As with all such issues, a very small amount of extra
information can make a great deal of difference.  Similarly,
you could have a special program for rush hours (and the morning
one might be very different from the evening one).  What becomes
very clear on a fairly casual inspection is that understanding
the properties of the input data is a prerequisite to designing
good algorithms.

This is very, very relevant to telecommunications and many
aspects of computing, as all experts in the relevant aspects know
very well.  I know just enough to have a glimmering of the depths
of my ignorance :-)


Regards,
Nick Maclaren.