On 2/20/24 13:51, Kaz Kylheku wrote:
> On 2024-02-20, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Tue, 20 Feb 2024 18:10:30 +0000, Richard Harnden wrote:
....
>>> Why wouldn't light be travelling in a straight line?
>>
>> Refraction, either by a change in medium or gravity (or some other force).
>
> Pockets or layers of air at different temperature? That would never
> affect a view of the horizon, right?

Why not? Air density drops rapidly with altitude, causing refraction as
light travels through the air. The net result is that, if the air were
perfectly clear and the Earth perfectly spherical, you could see
significantly more of Earth from any given position than you would
expect if you didn't take refraction into effect. You can still see the
setting Sun for many minutes after you might otherwise expect it to
disappear below the horizon, because it's light in bent by refraction
(and, of course, see the rising Sun several minutes earlier for the same
reason).

On 2/20/24 18:10, Lawrence D'Oliveiro wrote:
> On Tue, 20 Feb 2024 03:32:19 -0500, James Kuyper wrote:
>
>> On 2/19/24 20:37, Lawrence D'Oliveiro wrote:
>>> On Tue, 20 Feb 2024 00:05:56 +0000, Ben Bacarisse wrote:
>>>
>>>> Now, can we find a good mnemonic for C's operator precedence levels?
>>>
>>> “RTFM”.
>>
>> The standard doesn't describe operator precedence levels. It provides
>> grammar rules, and precedence must be inferred from the grammar. I've
>> found that it is not widely understood how to infer precedence from the
>> grammar.
>
> Wasn’t BNF covered in one of your undergraduate CS courses?

No. I'm mostly self-taught in computer programming. My degree was in
Physics, not CS. I took a few CS courses, but not many. I had planned to
be a scientist who could write his own data analysis and simulation
programs. I ended up with a career writing scientific computer programs
rather than coming up with new scientific theories of my own. I was
always very good at understanding scientific theories, but I lacked the
imagination needed to come up with new ones.

However, despite lacking a CS background, as I've already said, I have
no trouble figuring out precedence levels by examining the grammar. My
point was that I've talked with many people who found it less obvious
than you or I do.

On Wed, 21 Feb 2024 00:34:02 -0500, James Kuyper wrote:

> My point was that I've talked with many people who found it less obvious
> than you or I do.

Did they know how to read a BNF grammar?

On Wed, 21 Feb 2024 01:57:42 +0000, bart wrote:

> On 21/02/2024 00:45, Lawrence D'Oliveiro wrote:
>
>> On Wed, 21 Feb 2024 00:33:21 +0000, bart wrote:
>>
>>> On 20/02/2024 23:03, Lawrence D'Oliveiro wrote:
>>>>
>>>> final PointF ThisMouse =
>>>> ThisMouse1 != null ?
>>>> ThisMouse2 != null ?
>>>> new PointF
>>>> (
>>>> (ThisMouse1.x + ThisMouse2.x) / 2.0f,
>>>> (ThisMouse1.y + ThisMouse2.y) / 2.0f
>>>> )
>>>> :
>>>> ThisMouse1
>>>> :
>>>> ThisMouse2;
>>>
>>> But you wouldn't write that would you?
>>
>> I did. That is from actual, working code.
>
> So why didn't you use 'if' and 'else'?

Then it couldn’t have been “final”.

On 20/02/2024 23:37, Lawrence D'Oliveiro wrote:
> On Tue, 20 Feb 2024 09:00:39 +0100, David Brown wrote:
>
>> No, you'd still have a horizon if you were standing on an infinite plane
>
> On an infinite plane, objects moving away from you on the plane would
> never disappear over any horizon.

Correct, but you would still see the line of the horizon between the
"land" and the "sky". So it would look the same, but it would not act
the same as objects moved into the distance.

So I guess in your previous post you meant that the existence of a
horizon that things disappear over is proof of a round Earth? (Snipping
posts is helpful - snipping too much context is not.)

If the air were perfectly clear, and people's long-distance eyesight
were perfect, then what you say would be true. But objects "disappear"
with distance even if they don't go over the horizon - it is very
difficult with the naked eye to realise there is a fundamental
difference between a ship disappearing over the horizon, and a bird
flying off out of sight. It was not until people starting building
things like the lighthouse at Alexandria that you could really be sure
of the effect of disappearing over the horizon.

On 20/02/2024 19:30, Richard Harnden wrote:
> On 20/02/2024 18:26, Lew Pitcher wrote:
>> On Tue, 20 Feb 2024 18:10:30 +0000, Richard Harnden wrote:
>>
>>> On 20/02/2024 10:09, Malcolm McLean wrote:
>>>> On 20/02/2024 05:45, Lawrence D'Oliveiro wrote:
>>>>> On Mon, 19 Feb 2024 18:30:08 +0100, Janis Papanagnou wrote:
>>>>>
>>>>>> (And some more people, like Pythagoras and Platon, assumed a
>>>>>> spherical
>>>>>> earth ...
>>>>>
>>>>> Isn’t the simple fact of the existence of the horizon sufficient
>>>>> evidence
>>>>> that the Earth is round?
>>>>
>>>> The horizon is curved, which boys sometimes advanced as proof that the
>>>> Earth must indeed be round. (The geography teacher taught that).
>>>> But, as
>>>> Selby pointed out, that only holds if we assume that the light is
>>>> travelling in straight lines.
>>>>
>>>
>>> Why wouldn't light be travelling in a straight line?
>>
>> Refraction, either by a change in medium or gravity (or some other
>> force).
>> That's the stuff lenses (physical and gravitational) are made of :-)
>>
>>
>
> The Earth is not a black-hole, and the atmostphere is not that thick.
>

Black holes don't bend light any more than any other object with the
same mass. It's just that you can get closer to a black hole without
being inside it. (And gravity does not "bend" light - mass bends
space-time, and the light goes in a straight line in the bent space-time.)

And the atmosphere /is/ that thick. The refractive index of air is
usually negligible, but the earth's atmosphere is big enough that we see
the sun half a degree out at sunset and sunrise.

But refraction needs changes in the density or composition of the air -
and when you are talking about measurements close to the earth's
surface, the refractive index does not change much so there is usually
very little refraction. (How thick the atmosphere is has nothing to do
with it - only differences matter for refraction.)

On 20/02/2024 18:20, bart wrote:
> On 20/02/2024 02:19, Tim Rentsch wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> [...]
>>>
>>> Now, can we find a good mnemonic for C's operator precedence levels?
>>> Extra credit if left/right associativity is also covered.
>>
>> Let me ask, which areas give people the most trouble, or where do
>> they find that they need help remembering?  My reason for asking is
>> I myself find most of C's expression syntax behaves the way I expect
>> without having to think about it, so I need relatively few memory
>> aids to feel confident in knowing the whole stack.  But what are the
>> stumbling blocks for other folks?
>
>
> I like to intuitively think of binary operators as belonging to three
> groups:
>
>   (1) Within expressions (arithmetic, but also bitwise ops)
>
>   (2) Comparisons (with one precedence level)
>
>   (3) Logical and/or (only 2 precedence levels)
>
> All (1) have higher precendence than (2), which are higher than (3). (In
> my code, groups (2) and (3) mostly occur in conditional expressions such
> as 'f (expr)'.)
>
> C mixes up some operators between (1) and (2), that's one thing.
> For example, ^ is bizarrely lower precedence than ==.
>

I agree that this is strange. I suspect it was the result of the
historical split of the logical and bitwise operators - it makes sense
to have logical operators as lower than equality, and bitwise operators
presumably stayed there after the split instead of being moved up.

> Even within the same group (1), I think of << and >> as scaling
> operators of the same rank as * and /, since they really do the same job
> (any shift can be implemented with multiple or divide by a power of two).

I agree on that too (with the caveat that signed division by powers of
two is not just a shift in C - and that's another decision that could
certainly be questioned).

>
> Yet C puts the precedence of << and >> the other side of + and -. This
> means that:
>
>    1 << 2 + 3
>
> is 1<<(2+3) or 32, not (1<<2)+3 or 7.
>

This is why some of us like to put in the "extra" parentheses :-)

> Another one is ?: as in:
>
>      a ? b ? c : d : e     // or:
>      a ? b : c ? d : e
>
> With more complex terms, it's easy to get lost. Although this one is not
> so much about precedence; I wouldn't class it as an operator all, and
> would insist on parentheses so that the boundaries of this 3-way
> construct are absolutely clear.
>
> With parentheses, I /believe/ the correct grouping that corrresponds is
> repectively:
>
>      (a ? (b ? c : d) : e)
>      (a ? b : (c ? d : e))
>
> Now I can change 'I believe' to 'I know'.
>

That is more about associativity than precedence. There is no way the
expressions could mean anything else - if the associativity were
difference, chaining like your first case would have to be a syntax
error, and for the second case it would mean the same anyway.

> Remember this is not just about working with C. People may work on
> different languages with their own rules.

Yes, I agree again. (I think this may be a record?) Again, parentheses
and splitting up expressions into parts is the way to keep sane and safe.

>
> `2 + 3 * 4` is near-universally evaluated as 14. With `1 << 2 + 3` most
> languages I managed to try on rextester.com (which supported infix
> `<<`), also gave C's result of 32.
>
> This means a lot of languages that have perpetuated C's bad choices.
>
> A few languages however did not just blindly follow C, such as Pascal,
> Go and Swift; those gave a result of 7.
>
>
>
>

On 20/02/2024 18:12, Kaz Kylheku wrote:
> On 2024-02-20, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>>> On 2024-02-19, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>> In case anyone was curious...
>>>>
>>>> |
>>>> |
>>>> Cause | Armpits
>>>> |
>>>> |
>>>> --------------+--------------
>>>> |
>>>> |
>>>> Termites | Smelly
>>>> |
>>>> |
>>>
>>> I learned
>>>
>>> crazy all
>>>
>>> teachers are science
>>>
>>> from a math teacher who was Scottish. Someone in the class piped up
>>> with "all Scottish teachers are crazy", to great laughter.
>>
>> I don't think it worked! I was maybe too subtle in my last post, but
>> you have to remember something entirely arbitrary with this sort of
>> thing -- where to start and the order of going round (or otherwise
>> naming) the quadrants. All the posted examples I've see have the C and
>> S quadrants swapped over.
>
> Like a Chat AI robot, I just followed my interlocutor's example,
> and pretended it's right.
>
> For a moment, I wondered why the words are going clockwise (negative
> rotation) but didn't give it a moment's thought beyond that.
>
> Part of the value of the "all science teachers are crazy" mnemonic is
> that it starts with the first quadrant and follows the positive angle.
>
> You will not get it wrong, unless you're preloaded with a wrong example
> and don't think about it.
>
> If you think about it for a millisecond, of course sin() is positive
> over the first 180 degrees, but since cos() starts high, that
> function drops and crosses zero at 90. If you know this simple
> thing, you don't need the mnemonic.
>

I don't understand why anyone would feel the need for mnemonics here at
all. I think it is because people are often taught first that sins and
cosines are about right-angled triangles. Then they get confused and
have to unlearn things when the arguments are outside of 0° - 90°.

Think of the unit circle, and draw an angle θ from the x-axis - going
counter-clockwise, as you always do. cos θ is the x coordinate, sin θ
is the y coordinate. It's now all obvious and easy, and there is no
need for even a millisecond's thought about signs.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> [...]
>
>> On 20/02/2024 01:05, Ben Bacarisse wrote:
>>
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>> [...]

>>> Your example shows why I never liked this sort of "help".
>>> Remembering where to start and what order to label the quadrants
>>> is harder (for me) than knowing how trig functions work.
>>
>> Same for me. The trick to getting the signs of sins right is to
>> think of circles, not triangles, when doing trig. Then it is all
>> completely obvious.
>>
>>> Now, can we find a good mnemonic for C's operator precedence
>>> levels? Extra credit if left/right associativity is also
>>> covered. (Few! On topic again.)

[...]

> For me, pretty much the only one I'd have to look up (though only
> in a year or two, since I've recently been reminded!) is ^ vs |.

There are different kinds of memory aids. The ones that tend to
work for me are those with some semantic content, not just rote
memorization or via some cryptic acronym. This idea is similar
to the first two paragraphs quoted above.

For the bitwise logical operators, an example of the kind of
memory aid I find helpful is as follows.

The result of an & operator can have fewer bits on than its
operands, but never more;

The result of an | operator can have more bits on than its
operands, but never fewer;

The result of an ^ operator can have either fewer bits on or
more bits on than its operands (or possibly the same number),
depending on the values of the operands.

Hence it makes sense to put ^ between & and |, and that
is indeed where it is in C's precedence hierarchy --
fewer, fewer or more, more -- & ^ |.

(Of course I expect & binds more tightly than |, as is
conventional in mathematics and hardware design, etc.)

I can't say I ever had a problem with the relative precedences of
the bitwise logical operators, but this description probably did
help cement it for me.

On 21/02/2024 08:27, David Brown wrote:
>
> I don't understand why anyone would feel the need for mnemonics here at
> all.  I think it is because people are often taught first that sins and
> cosines are about right-angled triangles.  Then they get confused and
> have to unlearn things when the arguments are outside of 0° - 90°.
>
> Think of the unit circle, and draw an angle θ from the x-axis - going
> counter-clockwise, as you always do.  cos θ is the x coordinate, sin θ
> is the y coordinate.  It's now all obvious and easy, and there is no
> need for even a millisecond's thought about signs.
>

Now I've read many Mike Terry posts here, and the last thing I would say
about him is that he strikes me as someone who doesn't know very much
abut maths. But he got it wrong. And I thought that there must be some
convention that I wasn't aware of. But in fact there wasn't. He admitted
that he simply got it wrong.

So even people who are good at maths think about it in different ways.
And they may not help everyine. But mnemonics can be extremely helpful.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 21/02/2024 05:14, James Kuyper wrote:
> On 2/20/24 13:10, Richard Harnden wrote:
>> On 20/02/2024 10:09, Malcolm McLean wrote:
>>> On 20/02/2024 05:45, Lawrence D'Oliveiro wrote:
>>>> On Mon, 19 Feb 2024 18:30:08 +0100, Janis Papanagnou wrote:
>>>>
>>>>> (And some more people, like Pythagoras and Platon, assumed a spherical
>>>>> earth ...
>>>>
>>>> Isn’t the simple fact of the existence of the horizon sufficient evidence
>>>> that the Earth is round?
>>>
>>> The horizon is curved, which boys sometimes advanced as proof that the
>>> Earth must indeed be round. (The geography teacher taught that). But, as
>>> Selby pointed out, that only holds if we assume that the light is
>>> travelling in straight lines.
>>>
>>
>> Why wouldn't light be travelling in a straight line?
>
> In the real world, two reasons: refraction, and gravity. However, if
> Selby were trying to teach skepticism, the important thing is not
> whether there are known reasons why light would not travel in straight
> lines. The important point is that it must be established that it does
> travel in straight lines, it cannot simply be assumed.
>
> You can't prove that light always travels in straight lines, for the
> same reason why you can't prove the truth of any other general statement
> about the real world. The most you can do is collect enough evidence to
> justify a high level of confidence in the truth of such a statement.
> In particular, it is possible to collect evidence sufficient to support
> an accurate theory about how light travels through space, including the
> effects of both refraction and gravity. Such a theory can then be used
> to show that a horizon remains inconsistent with a flat earth, even
> taking those effects into consideration.
>
> However, the end result of teaching skepticism properly should have been
> boys who were competent to explain the evidence that rules out a flat
> earth. From Malcolm's own description, none of them were able to do so,
> and that makes Selby a bad teacher.
>
Any idiot can teach the argument against a flat Earth. The hard part is
teaching people how to construct that argument, off their own bat,
without other people telling them what it is, and so that it stands up
to deep-seated misconceptions which are not without considerable
justification (historically, not that the earth is flat, but that it is
the centre of the universe).

That's what Selby was tryng to do. And he might not have been perfect at
it. But he had a pretty good go. And he was only a maths teacher. He
wasn't formally qualified to teach philosophy.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2/21/24 02:52, David Brown wrote:
....
> Black holes don't bend light any more than any other object with the
> same mass. It's just that you can get closer to a black hole without
> being inside it. (And gravity does not "bend" light - mass bends
> space-time, and the light goes in a straight line in the bent space-time.)

Not quite. Light follows null geodesics in the curved space-time. A
geodesic is an extension of the idea of straight lines to curved
spacetimes. In flat space time (which implies no gravity), geodesics are
straight lines. However, in curved space times, geodesics can be much
more complicated shapes.

On 20.02.2024 19:26, Lew Pitcher wrote:
> On Tue, 20 Feb 2024 18:10:30 +0000, Richard Harnden wrote:
>>
>> Why wouldn't light be travelling in a straight line?
>
> Refraction, either by a change in medium or gravity (or some other force).
> That's the stuff lenses (physical and gravitational) are made of :-)

There's an interesting atmospheric condition seen at the Alps (Europe)
that's called "Föhn". Warm winds from the south (Italy) are streaming
over the mountains. At the German side there's cold air and the warm
air streams over that cold air. The different density of the cold/warm
air "bends" the line of sight so that the mountains appear to be much
higher than they effectively are (i.e. as seen on non-Föhn condition).
This refraction effect is depicted in the picture behind the link[*];
blue is the line of sight, and red is the perceived line of sight.

Janis

[*]
https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Foehn_Lichtweg.svg/640px-Foehn_Lichtweg.svg.png

On Fri, 9 Feb 2024 22:14:19 -0000 (UTC), Kaz Kylheku
<433-929-6894@kylheku.com> wrote:

> On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> > If I were designing a new language, I'd consider using ":=" for
> > assignment, "==" for equality, and not using "=" for anything.
> >
> > In (nearly?) all languages I'm aware of, ":=" either doesn't exist or
> > means assignment, and "==" either doesn't exist or means equality. I'd
> > avoid "=" because it's ambiguous across languages (and that's almost
> > entirely C's fault, inherited from B).
>
> Some of the credit must go to classic BASIC!
>
> I seem to remember than in classic, line-numbered BASICs on 8 bit
> micros, the = token was used both for assignment and comparison!
>
> 300 I = I + 1
> 310 IF I = 10 GOTO 340
>
BASIC itself predates (B and) C, but 8 bit micros are at least 5 years
too late.

> If you have a dedicated assignment statement, you can pull this kind
> of stunt. Just like C can distinguish initialization from assignment.

And I'm pretty sure Dartmouth BASIC required LET var = expr, which
(more) clearly distinguished it from IF.

COBOL used = for both one type of assignment (requiring keyword
COMPUTE) and equality. (The other types of assignment didn't use any
punctuator at all.) PL/I used it for both, with assignment 'bare'.

On 26.02.2024 10:22, dave_thompson_2@comcast.net wrote:
> On Fri, 9 Feb 2024 22:14:19 -0000 (UTC), Kaz Kylheku
> <433-929-6894@kylheku.com> wrote:
>> On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>>> If I were designing a new language, I'd consider using ":=" for
>>> assignment, "==" for equality, and not using "=" for anything.
>>>
>>> In (nearly?) all languages I'm aware of, ":=" either doesn't exist or
>>> means assignment, and "==" either doesn't exist or means equality.

In Simula you have '=' (equality) and '==' (identity; for references),
and of course ':=' (value assignments) and ':-' (reference assignments).

>>> I'd
>>> avoid "=" because it's ambiguous across languages (and that's almost
>>> entirely C's fault, inherited from B).
>>
>> Some of the credit must go to classic BASIC!

Don't forget FORTRAN (appearing before BASIC). And here also the syntax
ambiguity it had with loops and assignments (but I forgot the details).

>>
>> I seem to remember than in classic, line-numbered BASICs on 8 bit
>> micros, the = token was used both for assignment and comparison!
>>
>> 300 I = I + 1
>> 310 IF I = 10 GOTO 340
>>
> BASIC itself predates (B and) C, but 8 bit micros are at least 5 years
> too late.
>
>> If you have a dedicated assignment statement, you can pull this kind
>> of stunt. Just like C can distinguish initialization from assignment.
>
> And I'm pretty sure Dartmouth BASIC required LET var = expr, which
> (more) clearly distinguished it from IF.

Not all BASIC dialects "required" 'LET'. (A BASIC pocket calculator
from the 1970's that I still have allows omitting the keyword. But
wasn't that quite typical for the BASIC home PCs that came later?)

Janis

> [...]

On 27/02/2024 11:40, Janis Papanagnou wrote:
> On 26.02.2024 10:22, dave_thompson_2@comcast.net wrote:
>> On Fri, 9 Feb 2024 22:14:19 -0000 (UTC), Kaz Kylheku
>> <433-929-6894@kylheku.com> wrote:
>>> On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>>> If I were designing a new language, I'd consider using ":=" for
>>>> assignment, "==" for equality, and not using "=" for anything.
>>>>
>>>> In (nearly?) all languages I'm aware of, ":=" either doesn't exist or
>>>> means assignment, and "==" either doesn't exist or means equality.
>
> In Simula you have '=' (equality) and '==' (identity; for references),
> and of course ':=' (value assignments) and ':-' (reference assignments).
>
>>>> I'd
>>>> avoid "=" because it's ambiguous across languages (and that's almost
>>>> entirely C's fault, inherited from B).
>>>
>>> Some of the credit must go to classic BASIC!
>
> Don't forget FORTRAN (appearing before BASIC). And here also the syntax
> ambiguity it had with loops and assignments (but I forgot the details).

do 100 i = 1,10
do 100 i = 1.10

(FORTRAN ignores embedded white space.) The first is a loop over 1..10
delimited by label 100.

The second assigns 1.10 to variable `do100i`.

So it's not really ambiguous, but it is error prone.

On Mon, 26 Feb 2024 04:22:06 -0500, dave_thompson_2 wrote:

> And I'm pretty sure Dartmouth BASIC required LET var = expr, which
> (more) clearly distinguished it from IF.

And they brought out their own “True BASIC” which did exactly this, to try
to compete against Microsoft BASIC, which they saw as being not “true” to
their original idea of BASIC.

I don’t think it did very well.