David Brown <david.brown@hesbynett.no> writes:

> On 28/09/2023 02:34, Ben Bacarisse wrote:

>> One variation (I think it was used in S-Algol) is to have a case
>> statement where the arms can have arbitrary expressions. A multi-way
>> if then looks like this:
>>
>> case true of
>> x > 0: return +1
>> x == 0: return 0
>> x < 0: return -1
>> esac
>
> Is that really much different from :
>
> if (x > 0) return -1;
> if (x == 0) return 0;
> if (x < 0) return -1;
>
> ?

Well, for one thing, the same syntax[1] supports other forms of case
like C's switch and so on. Another difference is that it can obviously
be an expression:

sign := case true of x > 0: +1 | x = 0: 0 | x < 0: -1 esac

But I suppose it all depends on your metric for "really much different
from".

[1] I doubt that exact syntax would be used since the cases are only
recognised by <expression> ':' which is not a fixed-length look-ahead.
There would likely be a separator as I've added in the expression
example.

--
Ben.

Kaz Kylheku:

> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (list) {
> val a = car(list);
> if (nilp(a)) {
> list = cdr(list);
> } else if (atom(a)) {
> return list;
> } else do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> } else if (*escape) {
> list = pop(escape);
> } else {
> return nil;
> }
> }
> }

I took this as an exercise in linearising nested if's:

static val lazy_flatten_scan(val list, val *escape)
{ for (;;) {
if (!list) {
if( !*escape ) return nil; /* Ant: no need of else after return */
/* Ant: henceforth, *escape */
list = pop( escape );
continue;
}
/* Ant: henceforth, list != NULL */
val a = car(list);
/* Ant: henceforth, we have a */

if(nilp(a)) {
list = cdr(list);
continue;
}
/* Ant: henceforth, !nilp(a) */

if (atom(a)) return list; /* Ant: no need of else after return */
/* Ant: henceforth, !atom(a) */

do {
push(cdr(list), escape); /* safe mutation: *escape is a local var */
list = a;
a = car(list);
} while (consp(a));
return list;
}
}

I deal with conditions step by step, adding invariants as
execution moves down. I start with the shorter branches, to
minimise amount of highly indented code, until at the end I
can write the `do' loop (the most complex branch) without
any encircling conditionals.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

David Brown to Ben Bacarisse:

> > case true of
> > x > 0: return +1
> > x == 0: return 0
> > x < 0: return -1
> > esac
>
> Is that really much different from :
>
> if (x > 0) return -1;
> if (x == 0) return 0;
> if (x < 0) return -1;
>
> ?

Yes. The perfect alignment of Ben's code assists
comprehension by arranging the elements meaninfully, so that
analogous parts are stricly under one another. It also
utilises a higher-level structure directly to express the
programmer's conceptual intent of dispatching by a
condition. Your code lacks horsontal alignment and is just
a sequence of syntatically independent `if' statements,
leaving a gap between the programmer's concuptual intent and
its expression in the code.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Malcolm McLean:

> If C allowed for nested functions then it would start to
> become hard for programmers to understand when the nesting
> level exceeded three.
>
> But the rule of three doesn't apply to metrics which don't
> bear a relationship to dimensions, like the number of
> lines in a function, or the number of fields in a struct.
> Here there may be other psychological limits, but they
> arise from different underlying causes.
>
> The rule of three does apply to parentheses. Here you can
> easily verify it. Simply write some expressions and note
> when the nesting starts to make understanding the
> expression harder rather than easier.
>
> Nesting has hierarchy whilst dimensions don't. And nesting
> doesn't have to be balanced, but nesting which represents
> a multi-dimensional array does have to be balanced. So
> it's related but not exactly the same thing (I really
> shouldn't have to make this simple point, however I do).
> You can't visualise a four-dimensional structure in your
> mind, and you can't take in more than three levels of
> nesting without consciously matching either.

Your argumentation apart, I tend to agree with your
conclusion. I freely use nesting levels up to three, but
beyond that I start having compunctions and seconds
thoughts, and reviewing the functioon to check again if it
cannot be split up. The rule of three is not is not a hard
rule, but is there alright.

Now I see how nesting is connected to dimentions: they both
manifest the curse of deminsionality, or the exponential
growth of complexity as the number of dimensions or the
depth of nesting grows, for the number of (leaf) nodes in a
tree is an exponent of its depth.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Thursday, 28 September 2023 at 14:56:46 UTC+1, Anton Shepelev wrote:
> Malcolm McLean:
> > If C allowed for nested functions then it would start to
> > become hard for programmers to understand when the nesting
> > level exceeded three.
> >
> > But the rule of three doesn't apply to metrics which don't
> > bear a relationship to dimensions, like the number of
> > lines in a function, or the number of fields in a struct.
> > Here there may be other psychological limits, but they
> > arise from different underlying causes.
> >
> > The rule of three does apply to parentheses. Here you can
> > easily verify it. Simply write some expressions and note
> > when the nesting starts to make understanding the
> > expression harder rather than easier.
> >
> > Nesting has hierarchy whilst dimensions don't. And nesting
> > doesn't have to be balanced, but nesting which represents
> > a multi-dimensional array does have to be balanced. So
> > it's related but not exactly the same thing (I really
> > shouldn't have to make this simple point, however I do).
> > You can't visualise a four-dimensional structure in your
> > mind, and you can't take in more than three levels of
> > nesting without consciously matching either.
> Your argumentation apart, I tend to agree with your
> conclusion. I freely use nesting levels up to three, but
> beyond that I start having compunctions and seconds
> thoughts, and reviewing the functioon to check again if it
> cannot be split up. The rule of three is not is not a hard
> rule, but is there alright.
>
Yes. Whilst Linus Torvalds and I largely agree, I don't impose the rule
of three on C function curly braces. There are several reasons. Most
C programmers use vertical alignment to increase the visual prominence
of the nesting. Then nesting can be for nested iteration (in which case
maximum three levels are appropriate), but it can also be for nested
if statements. The whilst it is helpful to be able to read a function as one
unit, taking it all in as a whole, in a procedural programming language
like C, it isn't really necessary. The fundamental basic structure of a C
function is a list, not a nest.
So for those reasons, my own view is that we can tolerate C functions
which break the rule of three.
But Linus Torvalds is an exceptionally able programmer.
>
> Now I see how nesting is connected to dimentions: they both
> manifest the curse of deminsionality, or the exponential
> growth of complexity as the number of dimensions or the
> depth of nesting grows, for the number of (leaf) nodes in a
> tree is an exponent of its depth.
>
Exactly. Another psychological rule is that you can take in seven objects
without counting them. Now imagine we have a binary tree. The number of
nodes per level is 1, 2 ,4, 8, 16. So what's the nesting level at which you can
take in all of the tree at a glance?

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>David Brown <david.brown@hesbynett.no> writes:
>
>> On 27/09/2023 14:32, Bart wrote:
>>> On 27/09/2023 10:37, David Brown wrote:
>>>
>>>> I will even write something like this on occasion :
>>>>
>>>> �����if (<complicated condition>) {
>>>> �������� // Everything is fine, nothing to do
>>>> �����} else {
>>>> �������� do_something();
>>>> �����}
>>>>
>>>> rather than
>>>>
>>>> �����if (!(<complicated condition>)) {
>>>> �������� do_something();
>>>> �����}
>>>>
>>>> It is all about what is clearest to read.
>>> I have a version of 'if' called 'unless', which sometimes reads better,
>>> but not always.
>>> In particular, although 'unless' can have an 'else' branch, it doesn't
>>> have 'else-unless'; I couldn't work out what it meant!
>>
>> There are a few different varieties of conditionals that have been tried in
>> different programming languages. That includes syntaxes roughly like "x =
>> x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I have
>> remembered the details correctly. I don't think it really helps to have
>> too many ways of doing the same thing - there has to be very clear gains to
>> make it worth the effort.
>
>The biggest departure are multi-way ifs like
>
> if C1 -> S1
> C2 -> S2
> ...
> fi
>
>I've even come across a language where the while loop had the same
>structure with do ... od in place of if .. fi. For example
>
> do a > b -> a :=: b
> b > c -> b :=: c
> od
>
>where :=: is a swap operator ensures that the values in a, b and c are
>in non-decreasing order.
>
>One variation (I think it was used in S-Algol) is to have a case
>statement where the arms can have arbitrary expressions. A multi-way
>if then looks like this:
>
> case true of
> x > 0: return +1
> x == 0: return 0
> x < 0: return -1
> esac

Then there is BPL:

DEFINE IN_ = BEGIN BEGIN UNSEGMENTED #,
OUT_ = END ELSE BEGIN UNSEGMENTED #,
ELSE_ = END ELSE BEGIN UNSEGMENTED #,
ELIF_ = END ELSE IF #,
THEN_ = THEN BEGIN UNSEGMENTED #,
UNTIL_(C) = ; IF C THEN EXITLOOP; #,
WHILE_(C) = ; IF NOT C THEN EXITLOOP; #,
END_ = END #,
FI_ = FI #,
OD_ = OD #,
ESAC_ = ESAC #,
EXITBLOCK_ = EXITBLOCK #,
EXITCOND_ = EXITCOND #,
EXITLOOP_ = EXITLOOP #,
EXITCASE_ = EXITCASE #,
GOTOTOPLOOP_ = TOPLOOP #,
TOPLOOP_ = TOPLOOP #;
...
DO_ IF_ voiding 01031000
THEN_ DO_ WHILE_ (input_sequence_number 01032000
<= last_image_to_void) 01033000
READ INPDOC [endfile]; &72 TEXT CHARACTERS 01034000
input_line := inp_dummy; & P_00001035000
OD &8 SEQUENCE NUMBERS 01036000
ELSE_ READ INPDOC [endfile]; 01037000
input_line := inp_dummy; & P_00001038000
save_seq_numb := input_sequence_number; & P_00201039000
FI; 01040000
01041000
text_ptr := [input_line.+67]; &BEGINNING OF LAST 5 01042000
DO_ WHILE_ (next_5_input_characters = blank) 01043000
adr_dec (text_ptr,10); 01044000
UNTIL_ (text_ptr <= [input_line.+5]) 01045000
OD; 01046000
01047000
adr_inc (text_ptr, 8); &END OF FIRST NON 01048000
&BLANK PENTAD OR LEFT 01049000
&MOST PENTAD 01050000
DO_ WHILE_ (next_input_character = blank) 01051000
adr_dec (text_ptr, 2); 01052000
UNTIL_ (text_ptr <= [input_line]) 01053000
OD; 01054000
WHILE_ (current_mode ^= as_entered_mode) 01055000
&EMPTIES 01056000
UNTIL_ (text_ptr >= [input_line]) &ENTERED 01057000
OD; 01058000

Malcolm McLean:

> Another psychological rule is that you can take in seven
> objects without counting them.

It is not pshychologica rule, but rather an experimentally
determined established fact from cognitive scence. I had it
in mind but never mentioned somehow. You beat me to it.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
> Kaz Kylheku:
>
>> static val lazy_flatten_scan(val list, val *escape)
>> {
>> for (;;) {
>> if (list) {
>> val a = car(list);
>> if (nilp(a)) {
>> list = cdr(list);
>> } else if (atom(a)) {
>> return list;
>> } else do {
>> push(cdr(list), escape); /* safe mutation: *escape is a local var */
>> list = a;
>> a = car(list);
>> } while (consp(a));
>> return list;
>> } else if (*escape) {
>> list = pop(escape);
>> } else {
>> return nil;
>> }
>> }
>> }
>
> I took this as an exercise in linearising nested if's:
>
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (!list) {
> if( !*escape ) return nil; /* Ant: no need of else after return */
> /* Ant: henceforth, *escape */
> list = pop( escape );
> continue;
> }
> /* Ant: henceforth, list != NULL */
> val a = car(list);
> /* Ant: henceforth, we have a */
>
> if(nilp(a)) {
> list = cdr(list);
> continue;
> }
> /* Ant: henceforth, !nilp(a) */
>
> if (atom(a)) return list; /* Ant: no need of else after return */
> /* Ant: henceforth, !atom(a) */
>
> do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> }
> }

I might have had that function in tail recursive form
initially, which would look like:

static val lazy_flatten_scan(val list, val *escape)
{
// nothing in list: consume the escape stack.
if (!list) {
// nothing in escape stack: we are done
if( !*escape )
return nil;
return lazy_flatten_scan(pop(escape), escape);
}

val a = car(list);

// first element is empty list: scan the rest

if (nilp(a))
return lazy_flatten_scan(cdr(list), escape);

// first element is atom: return this list
// (caller consumes the atom and marches down the list)

if (atom(a))
return list;

// first element is a list: we drill into it, and keep iterating
// until we hit a list whose first element isn't another non-empty
// list, all the while while pushing the return path of lists we
// have visited into the escape stack.

do {
push(cdr(list), escape); /* safe mutation: *escape is a local var */
list = a;
a = car(list);
} while (consp(a)); // we found a list whose first item isn't

return list;
}

The do/while could probably be eliminated via a suitable tail call also;
I'm not going into it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
> Your argumentation apart, I tend to agree with your
> conclusion. I freely use nesting levels up to three, but
> beyond that I start having compunctions and seconds
> thoughts, and reviewing the functioon to check again if it
> cannot be split up. The rule of three is not is not a hard
> rule, but is there alright.

If you split up a function into pieces that are only called
once, for the sake of reducing nesting, it is not a given that
it will improve readability or maintainability.

The function becomes more abstract. Readability now depends on how
well-defined those subtasks are if considered on their own, and in
relation to that, how well they are named. Someone following the code
carefully, looking for bugs, has to jump around now between the
definitions and calls.

In a language in which you don't have nested functions, like the
standard dialect of C, splitting a function into helpers can create a
problem of delocalization of state. Whereas the original nested
statements operated on a common set of local variables, the helper
functions don't have access to that. You either have to pass the
entire state into the helpers by parameters, and then accept new
states that are returned, or pass pointers to individual variables as
arguments, or gather the state into a structure ("object based"
programming).

Any of these could affect readability in either direction.

That object-based/object-oriented approach has been heavily flogged over
the last forty years or so.

If all the state variables are members of a structure, and there are
only a few locals (sometimes none), then breaking up is a lot more
casual. Oh, let's move this block into a method. Copy, paste, done.
All the references are to members, they work there just as they did
here.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 28/09/2023 17:38, Anton Shepelev wrote:
> Malcolm McLean:
>
>> Another psychological rule is that you can take in seven
>> objects without counting them.
>
> It is not pshychologica rule, but rather an experimentally
> determined established fact from cognitive scence. I had it
> in mind but never mentioned somehow. You beat me to it.
>

It is not a rule at all. It's a myth.

When I was a kid, these kind of things spread around the playground -
you can only hold 7 bits of information in your mind at a time, you can
count up to but not more than 7 objects in a glance, you can fold a
piece of paper at most 7 times, and so on. Then we grew older and
realised it was all nonsense - it all depends on the person, the
information, the objects and their arrangements, the type of paper.

Now there is social media to keep adults drenched in this kind of easily
digested urban myth, and lots of people fall for "proof by repeated
assertion" rather than rubbing two brain cells together and thinking
about reality.

Please put some thought into this, and perhaps a little research,
instead of assuming random things someone once told you are
scientifically established fact.

David Brown:

> Wirth's languages tended to have strong separation of data
> and code. But remember, the focus of his languages were
> on two things - being good for teaching and learning, and
> being simple to implement (when optimisation is not
> important). C does not fit into either category. Nor do
> other major languages used for "real" programming.

Even so, I think Wirth considered these noble goals as
/conductive/ to the production use of his languages, rather
than contrary to it, as do his critics.

> (Of course there are "real" programs written in Pascal -
> but for the most part, you'll see Wirth's languages in
> academic institutions, not in the software industry).

Free market evaluates things not according to their
intrinsic value, but always through the ultimate criterium
of profit, where sponsorship, adverisment, and lobbism play
an important role -- factors sufficiently suppressed in the
academia.

> Also remember that Wirth wrote that (and languages like
> Pascal) some 40-50 years ago. We've learned a lot since
> then, and developed better coding techniques over time.

Yes, but very often at the expense of a rapid growth of the
complexity in the later programming languages, think C++!

> Wirth's most modern language, Oberon, is object oriented -
> data and code are much more integrated and mixed in such
> code.

They are, but not so tightly as in typical OOP of our day.
Instead of complete class inheritance, Wirth introduced two
simple facilities: extension of record types and the IS
operator. His methods are still pointers to normal
procedures and functions exsiting outside record types and
executed in their natural context, that is without an
implied `this' or `self' parameter.

> I can see that putting the variables at the start of the
> function lets you make a list like that. I cannot,
> however, see any advantage of having such a list.

One reason is that finding the type and annotaition to a
variable is simplified. With interleaved combined
declarations and initialisations, one has to scan through
the entire wall of text backwards, and that the typical
intialisaion does not /start/ with the variable name only
aggravates the situation: examining the start of every line
is not enough.

> Local variables are temporary - they are just there to
> hold intermediary results and give convenient names to
> things so that it's easier to see what is going on.

/Just/ is understatement. Their role is very important.

> A list of variables does not aid understanding of a
> function - rather, it detracts from it because you are
> splitting the information (how the variable is declared,
> and how it is used) into two separate parts.

You can see it that way, but the contrary extreme of mixing
everything into one homogenious mess does not help either.
Separate declarations introduce some order and make the
operational code more regular, by having all the assignments
start with the name of the variable.

> > Upon encountering a new variable, the reader can glance
> > at the top of function to find its type and desctiption,
> > whereas intermixed style is requires scanning the entire
> > text, unless, of course, you count IDE helper tools,
> > which I do not. Code should read smooth off a printed
> > page.
>
> With your style, the reader encountering a new variable
> has to deal with two wildly separate parts of the text -
> the definition at the start of the function, and the use
> of the variable in the code. It is particular bad for
> large functions or when you have a small screen or window
> (this can be the case when you are debugging, for
> example), and you have to scroll around.

I partially disagree. My approach is indeed particularly
bad for large functions on a small screen, but at the same
time I find it particulartly good for small functions, and
quite good for medium ones.

> With my style, everything is there clearly in one spot.

Yes -- because of better spacial cohesion. "Everything" is
an exagerration, however. Variables having different
lifespans, some may be used from way up above.

> No scanning or searching is needed - it's all there on the
> same line or two.

Not at all, because /any/ variable may have been declared
and initialised /anywhere/ above. It may be two lines, five
lines, or even fifteen lines up.

> > Interleaved initialisation makes the code visually
> > ragged and uneven -- to my taste. The declarations
> > "data" it works with are scatterd all over the place
>
> I write code, I don't draw pictures. The aim is to make
> things clear to human programmers reading the code, not to
> match the aesthetic tastes of art critics in a gallery.
> The visual appearance of code matters if - and only if -
> it affects the readability.

Each thing has its own beauty, so that beautiful code is as
admirable as a Turner landscape. Code beauty is of course
different, for its purpose is not only to evoke pleasure in
the observer, but neither is the that of the typography of
technical documents or literary works! It is the same kind
of beauty to which Tufte refers in the title of his book
"Beautiful evidence" -- ergonomic, perceptively optimised.

You are right on the spot in that code is not a picture, yet
it is of two-dimensional structure, and to use both
dimensions to advatage is only natural, whence indentation,
horisontal alignment, and the table-like formatting that I
propose for everything that is conceptually a table, even if
syntatically it is a series of function falls:

register_menu( "Start a new game", on_start );
register_menu( "Settings" , on_settings );
register_menu( "Exit" , on_exit );

> > When maintaining a unified section with declarations
> > becomes uncomfortable -- it is a natural signal the
> > function should be split or otherwise simplified.
>
> That is always the case for functions, no matter the style
> used.

With your method, adding new code paragrahs is very cheap
regardless of function size, because you do not have to go
all they way up to declare a new variable.

> The reality, however, is often different. Many functions
> start off small, but grow bigger than desirable as the
> code evolves. Your style gets more and more tedious,
> uncomfortable, and error-prone, to a much greater extent
> than defining local variables as an when they are needed.

In this wise my style signals to the programmer that the
time has come to split the function up.

> This is exasperated by C90 styles from the days of weaker
> compilers and no "inline" functions, when people wrote
> longer functions and hideous function-like macros because
> splitting up functions made code slower.

"exasperated by C90" ?-)
Even back then the entire programming style cannot have been
dictated by reasons of performance. The smart programmer
always designes and writes for the human, optimising only
the bottlenecks he finds, which typically constitute a minor
part of the program.

> Extensive use of "goto" is a strong indicator of poorly
> structured code, functions that are far too long, or a
> programmer doing "micro-optimisations" that are better
> left to the compiler. (There are some types of code for
> which "goto" makes things clearer, but I think they are
> rare.)

I believe that in many common situaions goto's can be used
/in/tensively and to an advantage in code structure and
readability, even as `break' and `continue' statements.
Incidentally, you did not comment on the article about
Gotophobia[1] mentioned here on the 1st of March.

> And I would say that defining variables at the top of the
> function is the worst choice you could have if you use
> "goto" often. It is better to consider labelled parts of
> the function as "sub-functions", each with their own local
> variables defined and initialised within their local
> areas.

Sometimes I do view /certain/ labelled secitons as sub-
functons. Even if the C stanards and the compiler will let
me jump over variable initialisations, I myself feel chary
of doing so because I my mentail model of code execution
does not empbrace it. I will rather turn such a sub-
function into a true function and invoke it...

> That's the focus here - the /human/ knows that the
> variable is always valid. They don't have to wonder if it
> has been set yet, no matter where they look in the code.

The compiler will detect the use of unininialised/undeclared
variables in both our styles. If the human does not rely in
this on the compiler, then he must determine the question by
examining context.

Manually to determine whether a varible is initialised at a
certain line, the programmer must scan the code from that
line upwards till he find the initialisation or an
assignment (in your style), or till he find an assignment
(in my style). There is not much difference, except that in
your case the occurence of either of two possible statements
is being sought. I have a hunch that I misunderstood this
argument of yours, though.

Kaz Kylheku:

> If you split up a function into pieces that are only
> called once, for the sake of reducing nesting, it is not a
> given that it will improve readability or maintainability.
>
> The function becomes more abstract. Readability now
> depends on how well-defined those subtasks are if
> considered on their own, and in relation to that, how well
> they are named. Someone following the code carefully,
> looking for bugs, has to jump around now between the
> definitions and calls.

Yes, this kind of refactoring can be both hard and
unrewarding, so that havng an extra nesting level is better.

> You either have to pass the entire state into the helpers
> by parameters, and then accept new states that are
> returned, or pass pointers to individual variables as
> arguments, or gather the state into a structure ("object
> based" programming).
>
> Any of these could affect readability in either direction.
>
> That object-based/object-oriented approach has been
> heavily flogged over the last forty years or so.
>
> If all the state variables are members of a structure, and
> there are only a few locals (sometimes none), then
> breaking up is a lot more casual. Oh, let's move this
> block into a method. Copy, paste, done. All the
> references are to members, they work there just as they
> did here.

It often happens that the object-based way requires the
creatio of heterogenous nonsenscial structure, or a code
small (whose name I forget) that consists in passing in way
more than is needed. This may be the cause the flogging you
mention.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

David Brown:

> When I was a kid, these kind of things spread around the
> playground - you can only hold 7 bits of information in
> your mind at a time, you can count up to but not more than
> 7 objects in a glance, you can fold a piece of paper at
> most 7 times, and so on. Then we grew older and realised
> it was all nonsense - it all depends on the person, the
> information, the objects and their arrangements, the type
> of paper.
> [...]
> Please put some thought into this, and perhaps a little
> research, instead of assuming random things someone once
> told you are scientifically established fact.

<https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two>

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Thursday, 28 September 2023 at 20:47:37 UTC+1, David Brown wrote:
> On 28/09/2023 17:38, Anton Shepelev wrote:
> > Malcolm McLean:
> >
> >> Another psychological rule is that you can take in seven
> >> objects without counting them.
> >
> > It is not pshychologica rule, but rather an experimentally
> > determined established fact from cognitive scence. I had it
> > in mind but never mentioned somehow. You beat me to it.
> >
> It is not a rule at all. It's a myth.
>
> When I was a kid, these kind of things spread around the playground -
> you can only hold 7 bits of information in your mind at a time, you can
> count up to but not more than 7 objects in a glance, you can fold a
> piece of paper at most 7 times, and so on. Then we grew older and
> realised it was all nonsense - it all depends on the person, the
> information, the objects and their arrangements, the type of paper.
>
> Now there is social media to keep adults drenched in this kind of easily
> digested urban myth, and lots of people fall for "proof by repeated
> assertion" rather than rubbing two brain cells together and thinking
> about reality.
>
> Please put some thought into this, and perhaps a little research,
> instead of assuming random things someone once told you are
> scientifically established fact.
>
You can do further experiments to derive more sophisticated rules
than the rule of seven. But it's not "all nonsense".

Also, remember that I was introducing subitising (the technical term)
newly into a discussion about something else. I wasn't posting about
subitising itself. So a brief summary is adequate.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Thursday, 28 September 2023 at 20:47:37 UTC+1, David Brown wrote:
>> On 28/09/2023 17:38, Anton Shepelev wrote:
>> > Malcolm McLean:
>> >
>> >> Another psychological rule is that you can take in seven
>> >> objects without counting them.
>
> You can do further experiments to derive more sophisticated rules
> than the rule of seven. But it's not "all nonsense".
>
> Also, remember that I was introducing subitising (the technical term)
> newly into a discussion about something else. I wasn't posting about
> subitising itself. So a brief summary is adequate.

The subitising limit is usually given as four or sometimes five. What
is the rule of seven? And do you now have a citation for the "rule of
three" in programming? (I say now because you didn't the last time I
asked.)

--
Ben.

On Friday, 29 September 2023 at 02:31:51 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Thursday, 28 September 2023 at 20:47:37 UTC+1, David Brown wrote:
> >> On 28/09/2023 17:38, Anton Shepelev wrote:
> >> > Malcolm McLean:
> >> >
> >> >> Another psychological rule is that you can take in seven
> >> >> objects without counting them.
> >
> > You can do further experiments to derive more sophisticated rules
> > than the rule of seven. But it's not "all nonsense".
> >
> > Also, remember that I was introducing subitising (the technical term)
> > newly into a discussion about something else. I wasn't posting about
> > subitising itself. So a brief summary is adequate.
> The subitising limit is usually given as four or sometimes five. What
> is the rule of seven? And do you now have a citation for the "rule of
> three" in programming? (I say now because you didn't the last time I
> asked.)
>
I haven't published anything on the rule of three. Setting up rigorous
psychological experiments and collecting the results in a way that is
publishable is quite involved. It's not that case that something has to
appear in academic literature to be true.

If Linus Torvalds and myself independently come to almost the same
conclusion, then that's good enough to say that we've an idea which
is worth taking further. (Not it is necessarily correct and no-one may
disagree, but no one has actually put up any substantive counter-arguments)..
The maximum for subitising is generally reckoned to be seven. It does
depend on circumstances. But under not too contrived circumstances
people can tell that there are seven objects without actually counting
them. The limit of four or five is the limit at which it can always be done,
under any (non-contrived, such as camouflage) circumstances, such
as objects of diffeent types and sizes, widely scattered, no patterning
at all and so on.

Wiki claims that people can be trained to subitise up to fifteen.

"In the 1990s, babies three weeks old were shown to differentiate between
1–3 objects, that is, to subitize.[22] A more recent meta-study summarizing
five different studies concluded that infants are born with an innate ability
to differentiate quantities within a small range, which increases over time..
[25] By the age of seven that ability increases to 4–7 objects. Some practitioners
claim that with training, children are capable of subitizing 15+ objects correctly."

On 9/27/2023 4:32 PM, Chris M. Thomasson wrote:
> On 9/27/2023 4:29 PM, Chris M. Thomasson wrote:
>> On 9/27/2023 10:46 AM, Malcolm McLean wrote:
>>> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>>>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>>>
>>>>>>> (Nesting, indirection, and dimensioning are all related to each
>>>>>>> other).
>>>>>> No, they are not.
>>>>>>
>>>>> You haven't thought this through, have you?
>>>> Yes, I have.
>>>>
>>>> I mean, obviously if you want to have an n-dimensional array and loop
>>>> through it all, you'll have n levels of nesting, and your array access
>>>> is technically through pointers with n levels of indirection.
>>>>
>>> Exactly. Not exactly a controversial idea, is it?
>>> Nesting, indirection, and dimensioning are all related to each other.
>>> And we can visualise three dimensions easily enough, because we live
>>> in a world with three dimensions of space. To visualise four dimensions,
>>> you have to add time, which makes it a different sort of mental
>>> exercise.
>>>
>>> So three is the magic number.
>>
>> I personally think that time is an interesting form of quantitative
>> "special", and not a dimension as is simply because time exists in
>> every dimension. Is that kind of, fair enough?
>
> For instance, think of a 4d being looking into a 3d realm, and noticing
> a clock hanging on a wall. Well, the 4d being can use the clock to sync
> itself with the time in the 3d realm of that room that contains the
> clock. Is this too out there? Sorry. ;^o

I was thinking that this theoretical 4d being can most definitely
observe its lower dimensions, so to speak. And a clock in a lower
dimension is something that this 4d being can look at and sync with.
Fair enough?

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

[discussion regarding the so-called "rule of three"]

> I haven't published anything on the rule of three. [...]

Whatever the merits of your views might be, your comments
have essentially zero overlap with the C language. Please
take any further discussion of your psychological theories
to a forum where they are topical. Thank you.

On Friday, 29 September 2023 at 05:48:22 UTC+1, Tim Rentsch wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> [discussion regarding the so-called "rule of three"]
>
> > I haven't published anything on the rule of three. [...]
>
> Whatever the merits of your views might be, your comments
> have essentially zero overlap with the C language. Please
> take any further discussion of your psychological theories
> to a forum where they are topical. Thank you.
>
Most C code is required to be read by humans. So these questions
like "how many parentheses can I nest?" are highly relevant.

People should maybe spend less time querying the underlying
pyschology, which is pretty obvious and self-evident, and more
time on the implications, I agree there.

On 29/09/2023 00:45, Anton Shepelev wrote:
> David Brown:
>
>> When I was a kid, these kind of things spread around the
>> playground - you can only hold 7 bits of information in
>> your mind at a time, you can count up to but not more than
>> 7 objects in a glance, you can fold a piece of paper at
>> most 7 times, and so on. Then we grew older and realised
>> it was all nonsense - it all depends on the person, the
>> information, the objects and their arrangements, the type
>> of paper.
>> [...]
>> Please put some thought into this, and perhaps a little
>> research, instead of assuming random things someone once
>> told you are scientifically established fact.
>
> <https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two>
>

Did you note the title of that page (and the book it refers to) ? The
error margin of plus/minus 2 ? The wiki page notes that 7 is not
"magic", and that sometimes 4 is equally "magic".

Did you know that while scientists may write books, and some books are
mostly factual, writing a book does /not/ mean something is established
scientific fact? Did you know that psychology and cognitive sciences
are amongst the least "factual" of sciences, because it is almost never
possible to do proper controlled or repeatable experiments? They do the
best they can, but few results rise about the level of "possible
indication", and almost nothing in the field qualifies as "scientific
fact" or "scientific law".

The great thing about scientific laws is that you only need a single
example to disprove them.

Think about situations where you have to deal with long strings of
digits (such as reference codes when paying bills). If there are more
than perhaps 4 repeated digits in a row, most people have to count them,
and with 6 or more digits they'll count them several times to be
confident. So the "magic number" is clearly 4.

Try rolling two normal dice. You'll identify the total spot count
immediately, at a glance, without counting or adding up. So the "magic
number" is clearly 12.

It has been pointed out that Malcolm is pretty much beyond saving in his
beliefs in various "laws" he invents. Please do not follow him.

David Brown to Anton Shepelev:

> > David Brown:
> >
> > > Please put some thought into this, and perhaps a
> > > little research, instead of assuming random things
> > > someone once told you are scientifically established
> > > fact.
> >
> > <https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two>
>
> Did you note the title of that page (and the book it
> refers to) ?

It is not a book, just a paper in a scentific journal.

> The error margin of plus/minus 2?

Yes, and it may be not the error margin but the distribution
width among various people. Metaphorically, this is the
number of our internal "registers". Although it is not an
exact number, neither it is "a random thing once told me".
It is based on research.

It is only mathematics that works with exact quantities,
whereas in science they are always known with a degree of
uncertainly, even the gravity constant G.

> The wiki page notes that 7 is not "magic",

It only reports Miller's "reflection" that

the correspondence between the limits of one-dimensional
absolute judgment and of short-term memory span was only
a coincidence, because only the first limit, not the
second, can be characterized in information-theoretic
terms (i.e., as a roughly constant number of bits).
Therefore, there is nothing "magical" about the number
seven, and Miller used the expression only rhetorically.

It still is magical (special) in the sense that it
characterises our average memory span better than any other
number. What definition of magic do you use? For instance,
I do not believe in the Cabbalah -- the Jewish numeric
magic...

> and that sometimes 4 is equally "magic".

Perhaps you are confusing memory capacity (2-3 bits) and
memory span (5-9) in that article.

> Did you know that while scientists may write books, and
> some books are mostly factual, writing a book does /not/
> mean something is established scientific fact?

A book, or more frequently, a paper) is based on research.
A high-quality research, independently repeated by other
scientists and not yet found to be seriously flawed
establishes a scientific fact. Theoreticaly, another
experiment may disprove or correct it any day.

> Did you know that psychology and cognitive sciences are
> amongst the least "factual" of sciences, because it is
> almost never possible to do proper controlled or
> repeatable experiments?

It is hard, but not almost impossible. There have been
wonderfully deep cognitive experiments that gave insights
into brain physiology, such as Benjamin Libet's.

> They do the best they can, but few results rise about the
> level of "possible indication", and almost nothing in the
> field qualifies as "scientific fact" or "scientific law".

I don't think you are right here. A lot of precise results
have been obtained, such as the lower boundary for reaction
time, or knowledge about color perception.

> Think about situations where you have to deal with long
> strings of digits (such as reference codes when paying
> bills). If there are more than perhaps 4 repeated digits
> in a row, most people have to count them, and with 6 or
> more digits they'll count them several times to be
> confident. So the "magic number" is clearly 4.

This is about readability, as is the grouping of decimal
numbers by three (Malcom's rule of thee!).

> Try rolling two normal dice. You'll identify the total
> spot count immediately, at a glance, without counting or
> adding up. So the "magic number" is clearly 12.

Not at all. It is the limitation of the dice, not of the
thrower.

You have suggested a number of experiemnts with various
results in each. They do not in any way disprove Miller's
conclusion, but measure different quantities (call them
magic, if you will -- I do not). Nor do people who remember
the sequence of cards from four to six shuffled card stacks
in memory contests.

> It has been pointed out that Malcolm is pretty much beyond
> saving in his beliefs in various "laws" he invents.
> Please do not follow him.

I think you exagerrate about his inventing of "laws", but I
for one told him I did not agree with his argumentation by
appeal to the three dimensions of the Euclicdean space,
which looks more like a coincidence to me. In fact, I am
not aware of "laws" that he has purely invented and is
following to the letter (or digit). If, for example, some
fundamental algoritym consists of four nested loops, I
do not believe Malcoms with split it into two functions
simply beause it violates the rule of three. There should
be additonal reasons and considerations.

The number three, for example, has been prominent in culture
of thousands of years. Think of Trinitiy, of the proverb
"Third time pays for all" -- it is not the second or fourth
time, but always the third -- at least in European and
Russian folklore. We often make three attempts before
giving up, not two, nor four. Neither two or four are so
prominent, which makes three somehow special. Perhaps
Malcom is consciously applying this arhetypal knowledge to
his work in programming: three is an agressive upper bound
on the depth of a hierarchy (to keep it easily perceptible),
and seven -- on the number of things one can comfortably
have in focus simultaneosly while reading code. The latter
is a wild conjecture on my part. It is not something I
consiously rely on.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Fri, 29 Sep 2023 14:33:53 +0300
Anton Shepelev <anton.txt@gmail.moc> wrote:
> The number three, for example, has been prominent in culture
> of thousands of years.

And not just human culture. 3 was also special to the beings who made Rama.

> Think of Trinitiy, of the proverb
> "Third time pays for all" -- it is not the second or fourth
> time, but always the third -- at least in European and
> Russian folklore. We often make three attempts before
> giving up, not two, nor four. Neither two or four are so
> prominent, which makes three somehow special.

On Friday, 29 September 2023 at 12:34:08 UTC+1, Anton Shepelev wrote:
> David Brown to Anton Shepelev:
>
> > Did you know that while scientists may write books, and
> > some books are mostly factual, writing a book does /not/
> > mean something is established scientific fact?
> A book, or more frequently, a paper) is based on research.
> A high-quality research, independently repeated by other
> scientists and not yet found to be seriously flawed
> establishes a scientific fact. Theoreticaly, another
> experiment may disprove or correct it any day.
>
Yes. We have to assume that observations have been made by
competent people and not fabricated, for example. You can always
present objections to scientific conclusions, but these become less
and less tenable as time passes and other work is done which
builds on the original work.
>
> > Did you know that psychology and cognitive sciences are
> > amongst the least "factual" of sciences, because it is
> > almost never possible to do proper controlled or
> > repeatable experiments?
> It is hard, but not almost impossible. There have been
> wonderfully deep cognitive experiments that gave insights
> into brain physiology, such as Benjamin Libet's.
>
Actually this is completely false. Psychology is considered by
some non-psychologists to be very fact light, because most of
the observations you can make are so familiar that, unless you
had a scientific training (and a good one) you wouldnt realise that
in fact they are interesting. For instance we can predict with a very
high degree of accuracy that if a group of people are in a room, they
will exit via the door and not through the window, as (for the sake of
argument) is physically possible. How do you explain that?
>
> > They do the best they can, but few results rise about the
> > level of "possible indication", and almost nothing in the
> > field qualifies as "scientific fact" or "scientific law".
> I don't think you are right here. A lot of precise results
> have been obtained, such as the lower boundary for reaction
> time, or knowledge about color perception.
>
Yes, there are many such results. Very highly repeatable. However
we don't know how free will gets into the brain, and whilst we've some
idea about how it gets from the brain to the muscles, it's too complicated
to describe exactly. So fundamentally psychologists don't understand
their subject.
>
> > Think about situations where you have to deal with long
> > strings of digits (such as reference codes when paying
> > bills). If there are more than perhaps 4 repeated digits
> > in a row, most people have to count them, and with 6 or
> > more digits they'll count them several times to be
> > confident. So the "magic number" is clearly 4.
> This is about readability, as is the grouping of decimal
> numbers by three (Malcom's rule of thee!).
> > Try rolling two normal dice. You'll identify the total
> > spot count immediately, at a glance, without counting or
> > adding up. So the "magic number" is clearly 12.
> Not at all. It is the limitation of the dice, not of the
> thrower.
>
> You have suggested a number of experiemnts with various
> results in each. They do not in any way disprove Miller's
> conclusion, but measure different quantities (call them
> magic, if you will -- I do not). Nor do people who remember
> the sequence of cards from four to six shuffled card stacks
> in memory contests.
> > It has been pointed out that Malcolm is pretty much beyond
> > saving in his beliefs in various "laws" he invents.
> > Please do not follow him.
> I think you exagerrate about his inventing of "laws", but I
> for one told him I did not agree with his argumentation by
> appeal to the three dimensions of the Euclicdean space,
> which looks more like a coincidence to me.
>
We know from commonsense that three levels of nesting of
parentheses is about the limit.
So we can say
Maximum three levels of nesting
Maximum three levels of indirection
Maximum three dimensions in an array.

These are all more or less saying the same thing, in different disguises.
But the last is the clue. Why are three dimensional arrays easy to
visualise, four dimensional arrays not? The answer is completely
obvious to anyone who thinks about it for even a moment.
>
> In fact, I am
> not aware of "laws" that he has purely invented and is
> following to the letter (or digit). If, for example, some
> fundamental algoritym consists of four nested loops, I
> do not believe Malcoms with split it into two functions
> simply beause it violates the rule of three. There should
> be additonal reasons and considerations.
>
No. I code for other people as well as myself, which is one
factor. Then a foolish consistency is the bugbear of little minds.
>
> The number three, for example, has been prominent in culture
> of thousands of years. Think of Trinitiy, of the proverb
> "Third time pays for all" -- it is not the second or fourth
> time, but always the third -- at least in European and
> Russian folklore. We often make three attempts before
> giving up, not two, nor four. Neither two or four are so
> prominent, which makes three somehow special. Perhaps
> Malcom is consciously applying this arhetypal knowledge to
> his work in programming: three is an agressive upper bound
> on the depth of a hierarchy (to keep it easily perceptible),
> and seven -- on the number of things one can comfortably
> have in focus simultaneosly while reading code. The latter
> is a wild conjecture on my part. It is not something I
> consiously rely on.
>
I read a very good book on numbers which started with the subitising
numbers and then worked through countable, representable,
and so on numbers, all the way up to infinity. The author then claimed
that there are only three orders of infinity, and if we try to define a
fourth we will find that in doing so we've redefined the other three so
that there are only two. (I'm repeating this parrot fashion, it's beyond my
mathematical ability). He then concluded his book by saying that he had
come full circle,and we're back to the low numbers. One, two, three,
many.

On 29/09/2023 13:28, Malcolm McLean wrote:

> We know from commonsense that three levels of nesting of
> parentheses is about the limit.

It depends on how complex your expression is, and how well you can rely
on people knowing the operator parentheses.

Taking a quick look at some codebases, these are the maximum nesting
levels I've found by looking at consecutive (((... or )))... sequences
(it won't spot all instances of a certain level):

BBX and LibJPEG 4
TCC and SQLite 5
Lua 7
My generated C 8
Preprocessed Lua 11

Counts include those belonging to function calls and casts.

> So we can say
> Maximum three levels of nesting
> Maximum three levels of indirection
> Maximum three dimensions in an array.
>
> These are all more or less saying the same thing, in different disguises.
> But the last is the clue. Why are three dimensional arrays easy to
> visualise, four dimensional arrays not? The answer is completely
> obvious to anyone who thinks about it for even a moment.

You're trying to visualise arrays in 3D space, but that is not always
meaningful.

Start with a string, itself a 1D array of characters, representing a
line of text. A array of lines is a page, and an array of pages is a book.

So far that's 3 dimensions. But we could have had words, paragraphs and
chapters within those 3. And we can have shelves, bookcases and
libraries of books.

That's far more than 3 dimensions, and it's quite easy to visual.

On 29/09/2023 13:28, Malcolm McLean wrote:

> We know from commonsense that three levels of nesting of
> parentheses is about the limit.

It depends on how complex your expression is, and how well you can rely
on people knowing the operator parentheses.

Taking a quick look at some codebases, these are the maximum nesting
levels I've found by looking at consecutive (((... or )))... sequences
(it won't spot all instances of a certain level):

BBX and LibJPEG 4
TCC and SQLite 5
Lua 7
My generated C 8
Preprocessed Lua 11

Counts include those belonging to function calls and casts.

> So we can say
> Maximum three levels of nesting
> Maximum three levels of indirection
> Maximum three dimensions in an array.
>
> These are all more or less saying the same thing, in different disguises.
> But the last is the clue. Why are three dimensional arrays easy to
> visualise, four dimensional arrays not? The answer is completely
> obvious to anyone who thinks about it for even a moment.

You're trying to visualise arrays in 3D space, but that is not always
meaningful.

Start with a string, itself a 1D array of characters, representing a
line of text. A array of lines is a page, and an array of pages is a book.

So far that's 3 dimensions. But we could have had words, paragraphs and
chapters within those 3. And we can have shelves, bookcases and
libraries of books.

That's far more than 3 dimensions, and it's quite easy to visual.