On 2024-01-05 17:08:13 +0000, Rich Ulrich said:

> On Fri, 5 Jan 2024 10:56:58 +0000, Hibou
> <vpaereru-unmonitored@yahoo.com.invalid> wrote:
>
>> Le 05/01/2024 à 10:16, Silvano a écrit :
>>> Hibou hat am 05.01.2024 um 07:41 geschrieben:
>>>> Le 04/01/2024 à 14:44, Silvano a écrit :
>>>>> Hibou hat am 04.01.2024 um 10:05 geschrieben:
>>>>>>
>>>>>> And that one has to be your native language. In a current discussion in
>>>>>> fr.lettres.langue.francaise ('C'est quelque chose...'), there is broad
>>>>>> agreement that it is impossible to speak a foreign language (in this
>>>>>> case French) with native proficiency, the problem being narrowness of
>>>>>> experience. How many foreign speakers of English understand what is
>>>>>> conjured up by 'dead parrot' or 'four candles' or 'And everywhere that
>>>>>> Mary went...'?
>>>
>>> I don't agree. Narrowness of experience may cause you to miss the
>>> meaning of a set phrase, and therefore your _understanding_ of a foreign
>>> language, but you can nevertheless _speak_ it with native proficiency.
>>> These are different skills, two of the four basic skills in any
>>> (written) language: read, write, listen, speak.
>>
>> Narrowness of experience restricts vocabulary, and that is directly
>> relevant to writing and speaking. If one has used only one's mother
>> tongue in, say, working with computers, how is one going to know all the
>> relevant terms in a foreign language? What's the lift algorithm called
>> in German, Italian, Spanish?
>>
>> It's breadth of experience, width of vocabulary, knowledge of nuance -
>> aye, and cultural references too - that gives writing its sparkle, and
>> peppers speech with nods and winks. This sort of proficiency is the
>> preserve of natives.
>
> Few of us approach Shakespearean competence. My own writing
> is hampered by having to translate from my brain's language into
> conventional English.
>
> Now I'm reminded of this critical opinion, that Joseph Conrad wrote
> in English (not his native tongue) better than almost anyone. That
> may have been in the intro to whatever Conrad story I once read,
> which was written nicely (so far as I recall).

Nabokov is another example

--
athel cb : Biochemical Evolution, Garland Science, 2016

"Hibou":
>>> What's the lift algorithm called in German, Italian, Spanish?

Mark Brader:
>> I'll bite. What's it called in English?

"Hibou":
> Good question. It would seem that its Sunday name is 'SCAN', though
> 'lift algorithm' is more descriptive - and indeed 'Algoritmo
> dell'ascensore' seems to be the term used in Italian.

Oh, "elevator".
> (It's an algorithm used in hard-disc controllers, more efficient than
> FCFS (first-come, first-served) while avoiding the possible starvation
> of SSTF (shortest seek-time first).)

Got it.
--
Mark Brader | "The conversation never became heated, which would
Toronto | have been difficult in any argument where there
msb@vex.net | is a built-in cooling-down period between any
| remark and its answer." --Hal Clement, STAR LIGHT

My text in this article is in the public domain.

Rich Ulrich wrote:

> I believe I have seen elsewhere the convention for initializing
> valules written like above, X = Y = Z = 0 without ambiguity.

It works in C, C++, PHP and Python and maybe other languages. It began
with C.

--
Bertel, Denmark

On 05/01/24 23:05, Mark Brader wrote:
> "Hibou":

>> relevant to writing and speaking. If one has used only one's mother
>> tongue in, say, working with computers, how is one going to know
>> all the relevant terms in a foreign language? What's the lift
>> algorithm called in German, Italian, Spanish?
>
> I'll bite. What's it called in English?

I too had to look it up.

ObDrift: I used to teach a first-year subject on digital logic. Boolean
algebra, gates, how to design an adder, logic devices with memory, that
sort of thing. Student projects required designing a logic circuit,
tested on a logic simulator, to perform some function.

One of my favourite examples was driving a lift up and down in response
to the press of call buttons. To solve that, you have to devise a policy
about what the current direction should be. (Should you go up or down,
given that there are outstanding requests in both directions?)

My preferred policy was "keep going in the same direction, unless there
are no current requests in that direction". To me, and probably to most
people here, that is obviously the best strategy. I was surprised,
however, to discover that that point was not at all obvious to many
students.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

On 06/01/24 07:15, Bertel Lund Hansen wrote:
> Rich Ulrich wrote:
>
>> I believe I have seen elsewhere the convention for initializing
>> valules written like above, X = Y = Z = 0 without ambiguity.
>
> It works in C, C++, PHP and Python and maybe other languages. It
> began with C.

You can't do it in Modula-2, my preferred programming language. You may
write things like
X := Y = (Z = 0)
but that means something completely different. The essential point here
is that the symbols for assignment (:=) and equality (=) are not the
same. The Fortran designers made a big mistake, in my opinion, in
overloading the = symbol; and many subsequent language designers made a
bigger mistake in copying that flaw.

Strangely enough, the distinction between = and := appeared as early as
Algol 58, a language that achieved considerable popularity once it
turned into Algol 60. But many, perhaps most, programming languages
designed after 1958 ignored that improvement.

I seem to recall that some languages used <- for assignment, an equally
good idea, but nobody does that now.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

* Peter Moylan <peter@pmoylan.org.invalid>:
> On 06/01/24 07:15, Bertel Lund Hansen wrote:
>> Rich Ulrich wrote:
>>
>>> I believe I have seen elsewhere the convention for initializing
>>> valules written like above, X = Y = Z = 0 without ambiguity.
>>
>> It works in C, C++, PHP and Python and maybe other languages. It
>> began with C.
>
> You can't do it in Modula-2, my preferred programming language. You may
> write things like
> X := Y = (Z = 0)
> but that means something completely different. The essential point here
> is that the symbols for assignment (:=) and equality (=) are not the
> same. The Fortran designers made a big mistake, in my opinion, in
> overloading the = symbol; and many subsequent language designers made a
> bigger mistake in copying that flaw.
>
> Strangely enough, the distinction between = and := appeared as early as
> Algol 58, a language that achieved considerable popularity once it
> turned into Algol 60. But many, perhaps most, programming languages
> designed after 1958 ignored that improvement.

Nope, almost all programming languages designed after 1958 use
different symbols for assignment ans equality.

Fortran does not overload "=". Fortran uses = for assignment and .EQ.
for equality. Most languages used today use = for assignment and == for
equality (C, Perl, PHP, Python, Java). Your assignment in C, Java or
Python looks like this:

X = Y == (Z == 0)

Maybe you mixed this up with BASIC, but even early BASIC made this
distinction. True, it used = for both assignment and equality, but an
assignment had do be preceeded by "LET". In many later BASICs the "LET"
was optional, though.

One could argue that := and = is somewhat cleaner than =/==, because it
retains the meaning of = from mathematics.

Modula-2 (R.I.P. Niklaus Wirth) is a very old-fashioned programming
language by now.

- Andi

On 06/01/24 11:22, Andreas Karrer wrote:
> * Peter Moylan <peter@pmoylan.org.invalid>:

>> same. The Fortran designers made a big mistake, in my opinion, in
>> overloading the = symbol; and many subsequent language designers
>> made a bigger mistake in copying that flaw.
>>
>> Strangely enough, the distinction between = and := appeared as
>> early as Algol 58, a language that achieved considerable popularity
>> once it turned into Algol 60. But many, perhaps most, programming
>> languages designed after 1958 ignored that improvement.
>
> Nope, almost all programming languages designed after 1958 use
> different symbols for assignment ans equality.
>
> Fortran does not overload "=". Fortran uses = for assignment and
> .EQ. for equality. Most languages used today use = for assignment and
> == for equality (C, Perl, PHP, Python, Java).

Sorry. You're right. It's so many years since I've used Fortran that I
forgot about .EQ., even though (see below) I started using .EQ. in my C
code.

Writing '=' when it should have been '==' used to be my commonest error
when writing C code. (Many C compiiers fail to give a warning when that
happens. The problem is that it's usually not an error, according to the
C rules; it just changes the meaning.) It got so bad than I starting putting

#define .EQ. ==

near the beginning of my C modules. That helped, a little.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

On Friday, January 5, 2024 at 3:55:05 PM UTC-7, Peter Moylan wrote:
> On 05/01/24 23:05, Mark Brader wrote:
> > "Hibou":
>
> >> relevant to writing and speaking. If one has used only one's mother
> >> tongue in, say, working with computers, how is one going to know
> >> all the relevant terms in a foreign language? What's the lift
> >> algorithm called in German, Italian, Spanish?
> >
> > I'll bite. What's it called in English?
> I too had to look it up.
>
> ObDrift: I used to teach a first-year subject on digital logic. Boolean
> algebra, gates, how to design an adder, logic devices with memory, that
> sort of thing. Student projects required designing a logic circuit,
> tested on a logic simulator, to perform some function.
>
> One of my favourite examples was driving a lift up and down in response
> to the press of call buttons. To solve that, you have to devise a policy
> about what the current direction should be. (Should you go up or down,
> given that there are outstanding requests in both directions?)
>
> My preferred policy was "keep going in the same direction, unless there
> are no current requests in that direction". To me, and probably to most
> people here, that is obviously the best strategy. I was surprised,
> however, to discover that that point was not at all obvious to many
> students.

It's the only one I've ever experienced or heard of, but for an infrequently
used, slow elevator in a tall building, it might not be the most efficient
use of the users' time.

--
Jerry Friedman

Peter Moylan:
> Writing '=' when it should have been '==' used to be my commonest error
> when writing C code.

You shouldn't've started with a language where "=" means equality.

> (Many C compiiers fail to give a warning when that
> happens. The problem is that it's usually not an error, according to the
> C rules; it just changes the meaning.)

True.

> It got so bad than I starting putting
>
> #define .EQ. ==

Syntax error.
--
Mark Brader, Toronto "This quote is very memorable."
msb@vex.net --Randall Munroe

My text in this article is in the public domain.

On 2024-01-05 23:06:46 +0000, Peter Moylan said:

> On 06/01/24 07:15, Bertel Lund Hansen wrote:
>> Rich Ulrich wrote:
>>
>>> I believe I have seen elsewhere the convention for initializing
>>> valules written like above, X = Y = Z = 0 without ambiguity.
>>
>> It works in C, C++, PHP and Python and maybe other languages. It
>> began with C.
>
> You can't do it in Modula-2, my preferred programming language.

Nor in Pascal. Modula-2 would probably have become my preferred
programming language if there had been a compiler easily available for
the computer I used 35 years.

> You may
> write things like
> X := Y = (Z = 0)
> but that means something completely different. The essential point here
> is that the symbols for assignment (:=) and equality (=) are not the
> same. The Fortran designers made a big mistake, in my opinion, in
> overloading the = symbol;

To be fair, though, the symbols were different, = for assignment, and
..EQ. for equality.

> and many subsequent language designers made a
> bigger mistake in copying that flaw.
>
> Strangely enough, the distinction between = and := appeared as early as
> Algol 58, a language that achieved considerable popularity once it
> turned into Algol 60. But many, perhaps most, programming languages
> designed after 1958 ignored that improvement.
>
> I seem to recall that some languages used <- for assignment, an equally
> good idea, but nobody does that now.

--
Athel -- French and British, living in Marseilles for 36 years; mainly
in England until 1987.

On 2024-01-06 00:22:40 +0000, Andreas Karrer said:

> * Peter Moylan <peter@pmoylan.org.invalid>:
>> On 06/01/24 07:15, Bertel Lund Hansen wrote:
>>> Rich Ulrich wrote:
>>>
>>>> I believe I have seen elsewhere the convention for initializing
>>>> valules written like above, X = Y = Z = 0 without ambiguity.
>>>
>>> It works in C, C++, PHP and Python and maybe other languages. It
>>> began with C.
>>
>> You can't do it in Modula-2, my preferred programming language. You may
>> write things like
>> X := Y = (Z = 0)
>> but that means something completely different. The essential point here
>> is that the symbols for assignment (:=) and equality (=) are not the
>> same. The Fortran designers made a big mistake, in my opinion, in
>> overloading the = symbol; and many subsequent language designers made a
>> bigger mistake in copying that flaw.
>>
>> Strangely enough, the distinction between = and := appeared as early as
>> Algol 58, a language that achieved considerable popularity once it
>> turned into Algol 60. But many, perhaps most, programming languages
>> designed after 1958 ignored that improvement.
>
> Nope, almost all programming languages designed after 1958 use
> different symbols for assignment ans equality.
>
> Fortran does not overload "=". Fortran uses = for assignment and .EQ.
> for equality.

Oh dear. Preplagiarized again. I should have read to the end of the thread.

> Most languages used today use = for assignment and == for
> equality (C, Perl, PHP, Python, Java). Your assignment in C, Java or
> Python looks like this:
>
> X = Y == (Z == 0)
>
> Maybe you mixed this up with BASIC, but even early BASIC made this
> distinction. True, it used = for both assignment and equality, but an
> assignment had do be preceeded by "LET". In many later BASICs the "LET"
> was optional, though.
>
> One could argue that := and = is somewhat cleaner than =/==, because it
> retains the meaning of = from mathematics.
>
> Modula-2 (R.I.P. Niklaus Wirth) is a very old-fashioned programming
> language by now.
>
>
> - Andi

--
Athel -- French and British, living in Marseilles for 36 years; mainly
in England until 1987.

Peter Moylan wrote:

> Strangely enough, the distinction between = and := appeared as early as
> Algol 58, a language that achieved considerable popularity once it
> turned into Algol 60. But many, perhaps most, programming languages
> designed after 1958 ignored that improvement.

I have forgotten what Basic used. I seem to remember that Comal had the
distinction (= and :=). I also think that it accepted = in both cases,
but changed it to := where appropriate. TurboPascal, which I used a lot,
had this distinction.

The C-family has = and ==.

There are no smileys in this message.

--
Bertel, Denmark

Le 05/01/2024 à 14:06, Bertel Lund Hansen a écrit :
> Hibou wrote:
>>
>> Narrowness of experience restricts vocabulary, and that is directly
>> relevant to writing and speaking. If one has used only one's mother
>> tongue in, say, working with computers, how is one going to know all the
>> relevant terms in a foreign language? What's the lift algorithm called
>> in German, Italian, Spanish?
>>
>> It's breadth of experience, width of vocabulary, knowledge of nuance -
>> aye, and cultural references too - that gives writing its sparkle, and
>> peppers speech with nods and winks. This sort of proficiency is the
>> preserve of natives.
>
> But not all natives master these categories. If one has used only one's
> mother tongue in, say, closed family and friends circles, how is one
> going to know all the relevant terms in one's mother tongue?

Well, I'd say it's not about comparing native with native - they vary,
of course. The proposition is that, whatever skill individuals have, it
will always be greater in their L1 than in their L2.

A possible exception comes to mind (if there's an exception, there must
be a rule): people who move from one country to another when very young.
In this case their mother tongue likely remains undeveloped, and they
probably become more skilled in the new language.

Running parallel to this are other linguistic skills - knowing how to
shape and structure a piece of writing, metaphor, dialogue, rhetoric...
- which are transferable from language to language. Someone who
possesses them may well be able to use a foreign language with verve,
while still not knowing what infants call a po.

On 06/01/24 12:04, Jerry Friedman wrote:
> On Friday, January 5, 2024 at 3:55:05 PM UTC-7, Peter Moylan wrote:

>> ObDrift: I used to teach a first-year subject on digital logic.
>> Boolean algebra, gates, how to design an adder, logic devices with
>> memory, that sort of thing. Student projects required designing a
>> logic circuit, tested on a logic simulator, to perform some
>> function.
>>
>> One of my favourite examples was driving a lift up and down in
>> response to the press of call buttons. To solve that, you have to
>> devise a policy about what the current direction should be.
>> (Should you go up or down, given that there are outstanding
>> requests in both directions?)
>>
>> My preferred policy was "keep going in the same direction, unless
>> there are no current requests in that direction". To me, and
>> probably to most people here, that is obviously the best strategy.
>> I was surprised, however, to discover that that point was not at
>> all obvious to many students.

To avoid ambiguity, I'd better add that that preferred rule usually has
a side condition: whenever there are no outstanding requests, the lift
remains stationary at its most recent destination. There is no strong
reason for this, but it leads to the simplest implementation.

> It's the only one I've ever experienced or heard of, but for an
> infrequently used, slow elevator in a tall building, it might not be
> the most efficient use of the users' time.

If it's _very_ infrequently used, there is a low probability of there
being more than one outstanding request. In that case, almost every
reasonable design policy will have the same outcome: the lift will move
towards the (only) requested floor. You can cut down on average response
time with an auxiliary rule: when there are no outstanding requests, the
lift should start moving towards the middle floor, with the possibility
of aborting that motion when a new request arrives. That's assuming that
all floors have equal probability of making a request. If that
assumption is false, replace "middle floor" by "weighted average floor".

For a slightly busier lift, there will often be times when there are two
or more outstanding requests. Note, though, that this is not the same as
two simultaneous requests. The probability that two people will hit the
button at precisely the same time is very small. In an idealised model,
the probability is precisely zero. In real life, where logic gates have
nonzero response times, the logic is still going to make the decision
that one of the requests came first. By the time the second request is
seen, the logic has already made the decision about which way to go. In
principle the decision can be reversed, but that could lead to an
indecisive lift that keeps changing its direction, which would
disadvantage most users.

What alternative policy could be viable? One possibility is to keep the
outstanding requests on an ordered list, where the ordering is either
first-come-first-served or some modification of FCFS, such as one that
gives higher priority to some floors. That, however, can lead to the
lift travelling longer distances as it follows a sort of zigzag path,
which might (I haven't done the calculations) lead to an increase in the
average wait time.

In brief, I still support the policy I suggested (and which is used by
most lifts in practice) as the best compromise solution. For every user
there is an easily calculated maximum wait time which is moderately low.

By the way, for teaching purposes I distinguished between "policy" and
"design". The policy is a statement of what you want to achieve. The
logic design must turn that policy into a combination of logic gates,
which was mostly what the subject was about. For the policy I described,
a good solution involves designed two subcircuits to calculate "maximum
requested floor" and "minimum requested floor". Then you can throw in a
couple of comparators to ... well, I won't go into the details, since
the only people likely to be interested are those who can figure it out
for themselves.

A slightly more challenging problem is to work out what to do when there
are multiple lifts. I considered that to be too difficult for a
first-year student. From my observation of real buildings, it seems to
be also too difficult for the people who install multi-lift systems.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

On 06/01/2024 11:43, Peter Moylan wrote:
> On 06/01/24 12:04, Jerry Friedman wrote:
>> On Friday, January 5, 2024 at 3:55:05 PM UTC-7, Peter Moylan wrote:
>
>>> ObDrift: I used to teach a first-year subject on digital logic.
>>> Boolean algebra, gates, how to design an adder, logic devices with
>>> memory, that sort of thing. Student projects required designing a
>>> logic circuit, tested on a logic simulator, to perform some
>>> function.
>>>
>>> One of my favourite examples was driving a lift up and down in
>>> response to the press of call buttons. To solve that, you have to
>>> devise a policy about what the current direction should be.
>>> (Should you go up or down, given that there are outstanding
>>> requests in both directions?)
>>>
>>> My preferred policy was "keep going in the same direction, unless
>>> there are no current requests in that direction". To me, and
>>> probably to most people here, that is obviously the best strategy.
>>> I was surprised, however, to discover that that point was not at
>>> all obvious to many students.
>
> To avoid ambiguity, I'd better add that that preferred rule usually has
> a side condition: whenever there are no outstanding requests, the lift
> remains stationary at its most recent destination. There is no strong
> reason for this, but it leads to the simplest implementation.
>
>> It's the only one I've ever experienced or heard of, but for an
>> infrequently used, slow elevator in a tall building, it might not be
>> the most efficient use of the users' time.
>
> If it's _very_ infrequently used, there is a low probability of there
> being more than one outstanding request. In that case, almost every
> reasonable design policy will have the same outcome: the lift will move
> towards the (only) requested floor. You can cut down on average response
> time with an auxiliary rule: when there are no outstanding requests, the
> lift should start moving towards the middle floor, with the possibility
> of aborting that motion when a new request arrives. That's assuming that
> all floors have equal probability of making a request. If that
> assumption is false, replace "middle floor" by "weighted average floor".
>
> For a slightly busier lift, there will often be times when there are two
> or more outstanding requests. Note, though, that this is not the same as
> two simultaneous requests. The probability that two people will hit the
> button at precisely the same time is very small. In an idealised model,
> the probability is precisely zero. In real life, where logic gates have
> nonzero response times, the logic is still going to make the decision
> that one of the requests came first. By the time the second request is
> seen, the logic has already made the decision about which way to go. In
> principle the decision can be reversed, but that could lead to an
> indecisive lift that keeps changing its direction, which would
> disadvantage most users.
>
> What alternative policy could be viable? One possibility is to keep the
> outstanding requests on an ordered list, where the ordering is either
> first-come-first-served or some modification of FCFS, such as one that
> gives higher priority to some floors. That, however, can lead to the
> lift travelling longer distances as it follows a sort of zigzag path,
> which might (I haven't done the calculations) lead to an increase in the
> average wait time.
>
> In brief, I still support the policy I suggested (and which is used by
> most lifts in practice) as the best compromise solution. For every user
> there is an easily calculated maximum wait time which is moderately low.
>
> By the way, for teaching purposes I distinguished between "policy" and
> "design". The policy is a statement of what you want to achieve. The
> logic design must turn that policy into a combination of logic gates,
> which was mostly what the subject was about. For the policy I described,
> a good solution involves designed two subcircuits to calculate "maximum
> requested floor" and "minimum requested floor". Then you can throw in a
> couple of comparators to ... well, I won't go into the details, since
> the only people likely to be interested are those who can figure it out
> for themselves.
>
> A slightly more challenging problem is to work out what to do when there
> are multiple lifts. I considered that to be too difficult for a
> first-year student. From my observation of real buildings, it seems to
> be also too difficult for the people who install multi-lift systems.
>

Hannah Fry (Maths Professor) has recently done a new series of The
Secret Genius of Modern Life for BBC. The last episode was about lifts
(elevators) including how they get to various floors. You may be interested.
https://www.bbc.co.uk/iplayer/episode/m001td7x/the-secret-genius-of-modern-life-series-2-6-lift

--
Chris Elvidge, England
I WILL TRY TO RAISE A BETTER CHILD

On Saturday, January 6, 2024 at 4:44:00 AM UTC-7, Peter Moylan wrote:
> On 06/01/24 12:04, Jerry Friedman wrote:
> > On Friday, January 5, 2024 at 3:55:05 PM UTC-7, Peter Moylan wrote:
>
> >> ObDrift: I used to teach a first-year subject on digital logic.
> >> Boolean algebra, gates, how to design an adder, logic devices with
> >> memory, that sort of thing. Student projects required designing a
> >> logic circuit, tested on a logic simulator, to perform some
> >> function.
> >>
> >> One of my favourite examples was driving a lift up and down in
> >> response to the press of call buttons. To solve that, you have to
> >> devise a policy about what the current direction should be.
> >> (Should you go up or down, given that there are outstanding
> >> requests in both directions?)
> >>
> >> My preferred policy was "keep going in the same direction, unless
> >> there are no current requests in that direction". To me, and
> >> probably to most people here, that is obviously the best strategy.
> >> I was surprised, however, to discover that that point was not at
> >> all obvious to many students.
> To avoid ambiguity, I'd better add that that preferred rule usually has
> a side condition: whenever there are no outstanding requests, the lift
> remains stationary at its most recent destination. There is no strong
> reason for this, but it leads to the simplest implementation.
>
> > It's the only one I've ever experienced or heard of, but for an
> > infrequently used, slow elevator in a tall building, it might not be
> > the most efficient use of the users' time.
>
> If it's _very_ infrequently used, there is a low probability of there
> being more than one outstanding request. In that case, almost every
> reasonable design policy will have the same outcome: the lift will move
> towards the (only) requested floor. You can cut down on average response
> time with an auxiliary rule: when there are no outstanding requests, the
> lift should start moving towards the middle floor, with the possibility
> of aborting that motion when a new request arrives. That's assuming that
> all floors have equal probability of making a request. If that
> assumption is false, replace "middle floor" by "weighted average floor".
>
> For a slightly busier lift, there will often be times when there are two
> or more outstanding requests. Note, though, that this is not the same as
> two simultaneous requests. The probability that two people will hit the
> button at precisely the same time is very small. In an idealised model,
> the probability is precisely zero. In real life, where logic gates have
> nonzero response times, the logic is still going to make the decision
> that one of the requests came first. By the time the second request is
> seen, the logic has already made the decision about which way to go. In
> principle the decision can be reversed, but that could lead to an
> indecisive lift that keeps changing its direction, which would
> disadvantage most users.

"Most" depends on how often the elevator is used.

> What alternative policy could be viable? One possibility is to keep the
> outstanding requests on an ordered list, where the ordering is either
> first-come-first-served or some modification of FCFS, such as one that
> gives higher priority to some floors. That, however, can lead to the
> lift travelling longer distances as it follows a sort of zigzag path,
> which might (I haven't done the calculations) lead to an increase in the
> average wait time.

The case I had in mind was that someone on the ground floor calls for
an elevator going up and pushes the button for the hundredth floor. When
the elevator is halfway to the second floor (that's the one immediately
above the ground floor), someone on the ground floor calls for an
elevator going up. If the elevator turns around to pick up the person on
the ground floor, the person on it already loses the time of a one-floor
trip. If it keeps going up, the person waiting at the bottom loses the time
of a hundred-floor round trip.

A policy of making the shortest requested trip (allowing for turnaround
time) would solve that, and I'd say it would be viable in the case that a
third person requesting the elevator during the trip up to the hundredth
(actually before the elevator passes the fiftieth floor) is very low, and
that the probability of two or more people getting on or off together is
also very low. Viable, but I'm not in favor of it.

One could also modify the policy to say that if there are already two, or
three etc., people going the same direction, the elevator doesn't reverse.
One could even assume a utility should be Utilitarian and find the shortest
total waiting time, assuming that the person calling the elevator is going
to make an average trip. Maybe some of your students tried that.

> In brief, I still support the policy I suggested (and which is used by
> most lifts in practice)

Most?

> as the best compromise solution. For every user
> there is an easily calculated maximum wait time which is moderately low.

I agree it's the best--among other reasons, because it follows what I
think is the normal expectation in my country and probably yours, namely
that the people on the elevator have priority over the people waiting.
But I'm not sure that it should be obvious.

> By the way, for teaching purposes I distinguished between "policy" and
> "design". The policy is a statement of what you want to achieve. The
> logic design must turn that policy into a combination of logic gates,
> which was mostly what the subject was about.

Though coming up with or understanding the policy is crucial for people
who are going to solve problems.

> For the policy I described,
> a good solution involves designed two subcircuits to calculate "maximum
> requested floor" and "minimum requested floor". Then you can throw in a
> couple of comparators to ... well, I won't go into the details, since
> the only people likely to be interested are those who can figure it out
> for themselves.

(Not me, at the moment.)

> A slightly more challenging problem is to work out what to do when there
> are multiple lifts. I considered that to be too difficult for a
> first-year student. From my observation of real buildings, it seems to
> be also too difficult for the people who install multi-lift systems.

(Not going to work on that one ATM either.)

--
Jerry Friedman

On 2024-01-06 07:38, Chris Elvidge wrote:
> On 06/01/2024 11:43, Peter Moylan wrote:
>> On 06/01/24 12:04, Jerry Friedman wrote:
>>> On Friday, January 5, 2024 at 3:55:05 PM UTC-7, Peter Moylan wrote:
>>
>>>> ObDrift: I used to teach a first-year subject on digital logic.
>>>> Boolean algebra, gates, how to design an adder, logic devices with
>>>> memory, that sort of thing. Student projects required designing a
>>>> logic circuit, tested on a logic simulator, to perform some
>>>> function.
>>>>
>>>> One of my favourite examples was driving a lift up and down in
>>>> response to the press of call buttons. To solve that, you have to
>>>> devise a policy about what the current direction should be.
>>>> (Should you go up or down, given that there are outstanding
>>>> requests in both directions?)
>>>>
>>>> My preferred policy was "keep going in the same direction, unless
>>>> there are no current requests in that direction". To me, and
>>>> probably to most people here, that is obviously the best strategy.
>>>> I was surprised, however, to discover that that point was not at
>>>> all obvious to many students.
>>
>> To avoid ambiguity, I'd better add that that preferred rule usually has
>> a side condition: whenever there are no outstanding requests, the lift
>> remains stationary at its most recent destination. There is no strong
>> reason for this, but it leads to the simplest implementation.
>>
>>> It's the only one I've ever experienced or heard of, but for an
>>> infrequently used, slow elevator in a tall building, it might not be
>>> the most efficient use of the users' time.
>>
>> If it's _very_ infrequently used, there is a low probability of there
>> being more than one outstanding request. In that case, almost every
>> reasonable design policy will have the same outcome: the lift will move
>> towards the (only) requested floor. You can cut down on average response
>> time with an auxiliary rule: when there are no outstanding requests, the
>> lift should start moving towards the middle floor, with the possibility
>> of aborting that motion when a new request arrives. That's assuming that
>> all floors have equal probability of making a request. If that
>> assumption is false, replace "middle floor" by "weighted average floor".
>>
>> For a slightly busier lift, there will often be times when there are two
>> or more outstanding requests. Note, though, that this is not the same as
>> two simultaneous requests. The probability that two people will hit the
>> button at precisely the same time is very small. In an idealised model,
>> the probability is precisely zero. In real life, where logic gates have
>> nonzero response times, the logic is still going to make the decision
>> that one of the requests came first. By the time the second request is
>> seen, the logic has already made the decision about which way to go. In
>> principle the decision can be reversed, but that could lead to an
>> indecisive lift that keeps changing its direction, which would
>> disadvantage most users.
>>
>> What alternative policy could be viable? One possibility is to keep the
>> outstanding requests on an ordered list, where the ordering is either
>> first-come-first-served or some modification of FCFS, such as one that
>> gives higher priority to some floors. That, however, can lead to the
>> lift travelling longer distances as it follows a sort of zigzag path,
>> which might (I haven't done the calculations) lead to an increase in the
>> average wait time.
>>
>> In brief, I still support the policy I suggested (and which is used by
>> most lifts in practice) as the best compromise solution. For every user
>> there is an easily calculated maximum wait time which is moderately low.
>>
>> By the way, for teaching purposes I distinguished between "policy" and
>> "design". The policy is a statement of what you want to achieve. The
>> logic design must turn that policy into a combination of logic gates,
>> which was mostly what the subject was about. For the policy I described,
>> a good solution involves designed two subcircuits to calculate "maximum
>> requested floor" and "minimum requested floor". Then you can throw in a
>> couple of comparators to ... well, I won't go into the details, since
>> the only people likely to be interested are those who can figure it out
>> for themselves.
>>
>> A slightly more challenging problem is to work out what to do when there
>> are multiple lifts. I considered that to be too difficult for a
>> first-year student. From my observation of real buildings, it seems to
>> be also too difficult for the people who install multi-lift systems.
>>
>
> Hannah Fry (Maths Professor) has recently done a new series of The
> Secret Genius of Modern Life for BBC. The last episode was about lifts
> (elevators) including how they get to various floors. You may be
> interested.
> https://www.bbc.co.uk/iplayer/episode/m001td7x/the-secret-genius-of-modern-life-series-2-6-lift

That URL is blocked for anyone outside the UK, so I went looking for it
on YouTube. I did ot find it, and will fire up the VPN later and watch it.

Meanwhile, I did find an interesting video on Youtube called ?The Secret
Life of the Lift - remastered/. It's basically the history of the list
from a mechanical point of view.

Included in that, at about 10:59 a bathroom scale is shown to illustrate
the effects of acceleration as a high-speed lift starts and stops. It
has two scales; pounds and stone.

He mentions that different countries tolerate different accelerations,
Japan the least, and Australia the most.

--
I don't have an accent.
This is just how things sound when they're pronounced properly.
~ Jimmy Carr

On 2024-01-06 09:38, Jerry Friedman wrote:
> On Saturday, January 6, 2024 at 4:44:00 AM UTC-7, Peter Moylan wrote:
>> On 06/01/24 12:04, Jerry Friedman wrote:

>> For the policy I described,
>> a good solution involves designed two subcircuits to calculate "maximum
>> requested floor" and "minimum requested floor". Then you can throw in a
>> couple of comparators to ... well, I won't go into the details, since
>> the only people likely to be interested are those who can figure it out
>> for themselves.
>
> (Not me, at the moment.)
>
>> A slightly more challenging problem is to work out what to do when there
>> are multiple lifts. I considered that to be too difficult for a
>> first-year student. From my observation of real buildings, it seems to
>> be also too difficult for the people who install multi-lift systems.
>
> (Not going to work on that one ATM either.)

I can envision an AI solution, where not only traffic patterns are
analyzed, but users are recognized as well, remembering their usual
starting and stopping floor, dates, days of week, days of month, and
times spent on each floor.

--
I didn’t think orthopedic shoes would help, but I stand corrected.

On Fri, 5 Jan 2024, at 06:41:32, Hibou posted:
>Le 04/01/2024 à 14:44, Silvano a écrit :
>> Hibou hat am 04.01.2024 um 10:05 geschrieben:
>>>
>>> And that one has to be your native language. In a current discussion in
>>> fr.lettres.langue.francaise ('C'est quelque chose...'), there is broad
>>> agreement that it is impossible to speak a foreign language (in this
>>> case French) with native proficiency, the problem being narrowness of
>>> experience. How many foreign speakers of English understand what is
>>> conjured up by 'dead parrot' or 'four candles' or 'And everywhere that
>>> Mary went...'?
>> Mary had a little lamb ...
>> For that matter, how many native speakers of English under (30, just
>>
>> wild guess) or from India, South Africa etc. would understand the
>> reference to the "dead parrot sketch" or the "four candles" sketch
>> I found out looking for these words in the English Wikipedia?
>> You'll find similar problems in German, French, Italian, Spanish and
>> several other languages in the cases of references to old TV broadcasts
>> from the time where almost everybody saw the same programmes because
>> there were only one or two channels.
>
>Well, you can criticise my examples, and English is a peculiar case,
>being spoken so widely, but I stand by the principle. Native speakers
>have lived with the language from the cradle, and used it in all
>they've experienced. No foreigner can match that. Bilingual people, who
>have a father-tongue as well as a mother-tongue, may have native
>proficiency in two languages, but even then their vocabulary from the
>playground, from the workplace, from consultations with their GP, from
>religion, is likely to be in one language and not the other.
>
>Quant à moi, je nage dans l'anglais comme un poisson ; en français,
>j'aime toujours avoir mon scaphandre à portée de main.

I'm much worse than that: I had to look up scaphandre in mon
dictionnaire.
>
>Or, to take an earthier and less wet analogy: English goes to my core;
>French is only a crust or mantle.
>

--
Paul W

On Sat, 6 Jan 2024 09:41:04 +0100, Bertel Lund Hansen
<gadekryds@lundhansen.dk> wrote:

>Peter Moylan wrote:
>
>> Strangely enough, the distinction between = and := appeared as early as
>> Algol 58, a language that achieved considerable popularity once it
>> turned into Algol 60. But many, perhaps most, programming languages
>> designed after 1958 ignored that improvement.
>
>I have forgotten what Basic used.

Whose Basic? So far as I know, Basic never had a 'standard' so
anyone could do what they wanted.

I did some programming on a 'workstation' made by HP --
a high-powered PC designed for laboratory work. Using the
name 'HP-Basic' was their solution for having I/O (and something
else?) that did not meet a Fortran standard. It was a compiled
language rather than an 'interpreted' one (most Basic's?).

> I seem to remember that Comal had the
>distinction (= and :=). I also think that it accepted = in both cases,
>but changed it to := where appropriate. TurboPascal, which I used a lot,
>had this distinction.
>
> The C-family has = and ==.
>
>There are no smileys in this message.

--
Rich Ulrich

On 06-Jan-24 15:38, Jerry Friedman wrote:
> The case I had in mind was that someone on the ground floor calls for
> an elevator going up and pushes the button for the hundredth floor. When
> the elevator is halfway to the second floor (that's the one immediately
> above the ground floor), someone on the ground floor calls for an
> elevator going up. If the elevator turns around to pick up the person on
> the ground floor, the person on it already loses the time of a one-floor
> trip. If it keeps going up, the person waiting at the bottom loses the time
> of a hundred-floor round trip.
>
> A policy of making the shortest requested trip (allowing for turnaround
> time) would solve that, and I'd say it would be viable in the case that a
> third person requesting the elevator during the trip up to the hundredth
> (actually before the elevator passes the fiftieth floor) is very low, and
> that the probability of two or more people getting on or off together is
> also very low. Viable, but I'm not in favor of it.
>
> One could also modify the policy to say that if there are already two, or
> three etc., people going the same direction, the elevator doesn't reverse.
> One could even assume a utility should be Utilitarian and find the shortest
> total waiting time, assuming that the person calling the elevator is going
> to make an average trip. Maybe some of your students tried that.

The lift/elevator's operator might ask for an algorithm which minimised
energy use, whilst offering a tolerable service to users.

(Does a lift/elevator expend less energy when descending?)

--
Sam Plusnet

On Saturday, January 6, 2024 at 9:45:47 AM UTC-7, lar3ryca wrote:
> On 2024-01-06 09:38, Jerry Friedman wrote:
> > On Saturday, January 6, 2024 at 4:44:00 AM UTC-7, Peter Moylan wrote:
> >> On 06/01/24 12:04, Jerry Friedman wrote:
>
> >> For the policy I described,
> >> a good solution involves designed two subcircuits to calculate "maximum
> >> requested floor" and "minimum requested floor". Then you can throw in a
> >> couple of comparators to ... well, I won't go into the details, since
> >> the only people likely to be interested are those who can figure it out
> >> for themselves.
> >
> > (Not me, at the moment.)
> >
> >> A slightly more challenging problem is to work out what to do when there
> >> are multiple lifts. I considered that to be too difficult for a
> >> first-year student. From my observation of real buildings, it seems to
> >> be also too difficult for the people who install multi-lift systems.
> >
> > (Not going to work on that one ATM either.)
>
> I can envision an AI solution, where not only traffic patterns are
> analyzed, but users are recognized as well, remembering their usual
> starting and stopping floor, dates, days of week, days of month, and
> times spent on each floor.

Also priorities: people with disabilities, emergency responders when
no fire has been detected, the owner and their friends and family,
teenagers who found a way to break into the system...

--
Jerry Friedman

on 1/2/2024, Snidely supposed :
> On Tuesday, lar3ryca pointed out that ...
>> On 2024-01-02 03:44, Hibou wrote:
>>> Le 02/01/2024 à 09:39, henh...@gmail.com a écrit :
>>>>>>> young people don't say         "Bob's your uncle"
>>>>
>>>> Among younger folks (20 -- 40 y.o.)  in the USA  today,
>>>> where
>>>>              10= Commonly used       (like Cool!)
>>>>                0=  Never heard of it
>>>>
>>>>
>>>> 4 (?)      =   it doesn't play in Peoria
>>>> 3 or 2    =  Kit and Caboodle
>>>> 1  or  0    =  life of Riley
>>>>
>>>>     "Bob's your uncle"  in the UK must be  5 or 6 ?
>>
>> This Canuck has used it often.
>
> I think I've heard it from a 30 yo Pennsylvanian heavy equipment operator and
> ewtewber.

He also says "ruh-row" a lot (while working on old diesel engines), so
I think he was exposed to Scooby Doo. My kids are about the same age,
and they got exposed to Scooby Doo thanks to cable channels that
recirculate, um, classic content.

I'm less of a Scooby Doo type; I remember Astro saying "ruh-row" on the
Jetsons, and the Great Scoob was a bit later, so I saw him more in
re-runs than in first runs.

/dps

--
Yes, I have had a cucumber soda. Why do you ask?

Sam Plusnet explained :
> On 06-Jan-24 15:38, Jerry Friedman wrote:

>> The case I had in mind was that someone on the ground floor calls for
>> an elevator going up and pushes the button for the hundredth floor. When
>> the elevator is halfway to the second floor (that's the one immediately
>> above the ground floor), someone on the ground floor calls for an
>> elevator going up. If the elevator turns around to pick up the person on
>> the ground floor, the person on it already loses the time of a one-floor
>> trip. If it keeps going up, the person waiting at the bottom loses the
>> time
>> of a hundred-floor round trip.
>>
>> A policy of making the shortest requested trip (allowing for turnaround
>> time) would solve that, and I'd say it would be viable in the case that a
>> third person requesting the elevator during the trip up to the hundredth
>> (actually before the elevator passes the fiftieth floor) is very low, and
>> that the probability of two or more people getting on or off together is
>> also very low. Viable, but I'm not in favor of it.
>>
>> One could also modify the policy to say that if there are already two, or
>> three etc., people going the same direction, the elevator doesn't reverse.
>> One could even assume a utility should be Utilitarian and find the shortest
>> total waiting time, assuming that the person calling the elevator is going
>> to make an average trip. Maybe some of your students tried that.
>
>
> The lift/elevator's operator might ask for an algorithm which minimised
> energy use, whilst offering a tolerable service to users.
>
> (Does a lift/elevator expend less energy when descending?)

Depends on the type of elevator. Counter-weight systems (usually more
than 4 floors served), no. Hydraulic systems, yes.

/dps

--
"It wasn't just a splash in the pan"
-- lectricbikes.com

On Saturday, Peter Moylan yelped out that:

[cutting to the chase]

> To avoid ambiguity, I'd better add that that preferred rule usually has
> a side condition: whenever there are no outstanding requests, the lift
> remains stationary at its most recent destination. There is no strong
> reason for this, but it leads to the simplest implementation.

Many elevators seem to stay at the current floor for at least a minute
or two, but then return to lobby level, apparently priotizing new
arrivals. I don't have enough sight inside to know if a "idle return
to lobby" can be reversed in-flight by a request above.

[ I was going to write
[ [cut to some appropriate cameo from Laugh-In]
[ but I want to add a moment of silence
[ for the passing of Tommy Smothers
] ]
] ]

/dps

--
"What do you think of my cart, Miss Morland? A neat one, is not it?
Well hung: curricle-hung in fact. Come sit by me and we'll test the
springs."
(Speculative fiction by H.Lacedaemonian.)