Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #154536 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@nospicedham.gmail.com> |
|---|---|
| First post | 2020-09-04 20:33 -0400 |
| Last post | 2020-09-09 10:53 +0200 |
| Articles | 20 on this page of 76 — 19 participants |
Back to article view | Back to comp.lang.c
Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@nospicedham.gmail.com> - 2020-09-04 20:33 -0400
Re: Bit Swizzling Bart <bc@freeuk.com> - 2020-09-05 12:36 +0100
Re: Bit Swizzling Bart <bc@freeuk.com> - 2020-09-05 15:30 +0100
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-05 11:29 -0400
Re: Bit Swizzling Bart <bc@freeuk.com> - 2020-09-05 20:28 +0100
Re: Bit Swizzling kegs@provalid.com (Kent Dickey) - 2020-09-05 11:35 -0500
Re: Bit Swizzling Bart <bc@nospicedham.freeuk.com> - 2020-09-05 12:33 +0100
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-05 20:55 +0200
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-05 15:18 -0400
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-06 10:17 +0200
Re: Bit Swizzling Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-07 07:06 +0000
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-07 10:35 +0200
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-07 11:01 -0400
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-07 20:07 +0200
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-07 14:19 -0400
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-07 20:39 +0200
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-07 15:13 -0400
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 12:21 +0200
Re: Bit Swizzling Bart <bc@freeuk.com> - 2020-09-08 12:51 +0100
Re: Bit Swizzling Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-09-08 05:18 -0700
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 15:20 +0200
Re: Bit Swizzling Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-08 15:56 +0000
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-08 12:17 -0400
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 19:31 +0200
Re: Bit Swizzling olcott <NoOne@NoWhere.com> - 2020-09-08 12:46 -0500
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 19:53 +0200
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-08 15:13 -0400
Re: Bit Swizzling (c++ versus c) olcott <NoOne@NoWhere.com> - 2020-09-08 14:59 -0500
Re: Bit Swizzling (c++ versus c) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-08 21:45 -0400
Re: Bit Swizzling (c++ versus c) olcott <NoOne@NoWhere.com> - 2020-09-08 20:56 -0500
Re: Bit Swizzling (c++ versus c) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-08 19:49 -0700
Re: Bit Swizzling (c++ versus c) Juha Nieminen <nospam@thanks.invalid> - 2020-09-09 06:27 +0000
Re: Bit Swizzling (c++ versus c) Melzzzzz <Melzzzzz@zzzzz.com> - 2020-09-09 06:38 +0000
Re: Bit Swizzling (c++ versus c) David Brown <david.brown@hesbynett.no> - 2020-09-09 11:54 +0200
Re: Bit Swizzling (c++ versus c) olcott <NoOne@NoWhere.com> - 2020-09-09 09:21 -0500
Re: Bit Swizzling Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-08 16:31 +0000
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 19:35 +0200
Re: Bit Swizzling olcott <NoOne@NoWhere.com> - 2020-09-08 12:50 -0500
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 19:53 +0200
Re: Bit Swizzling olcott <NoOne@NoWhere.com> - 2020-09-08 13:09 -0500
Re: Bit Swizzling Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-08 18:48 +0000
Re: Bit Swizzling + [HP] olcott <NoOne@NoWhere.com> - 2020-09-08 14:09 -0500
Re: Bit Swizzling + [HP] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-09-08 12:37 -0700
Re: Bit Swizzling + [x86utm] olcott <NoOne@NoWhere.com> - 2020-09-08 16:59 -0500
Re: Bit Swizzling + [HP] olcott <NoOne@NoWhere.com> - 2020-09-08 18:13 -0500
Re: Bit Swizzling + [HP] olcott <NoOne@NoWhere.com> - 2020-09-08 20:07 -0500
Re: Bit Swizzling + (HP refutation criteria) olcott <NoOne@NoWhere.com> - 2020-09-09 20:10 -0500
Re: Bit Swizzling + [HP] olcott <NoOne@NoWhere.com> - 2020-09-09 21:07 -0500
Re: Bit Swizzling + [HP refutation criteria] olcott <NoOne@NoWhere.com> - 2020-09-09 21:30 -0500
Re: Bit Swizzling + [HP refutation criteria] olcott <NoOne@NoWhere.com> - 2020-09-09 21:39 -0500
Re: Bit Swizzling + [HP] olcott <NoOne@NoWhere.com> - 2020-09-10 22:48 -0500
Re: Bit Swizzling Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-08 13:06 -0700
Re: Bit Swizzling Bart <bc@freeuk.com> - 2020-09-08 19:37 +0100
Re: Bit Swizzling David Brown <david.brown@hesbynett.no> - 2020-09-09 12:04 +0200
Re: Bit Swizzling Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-08 18:39 +0000
Re: Bit Swizzling Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-09-08 12:27 -0700
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-07 15:47 -0400
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 12:23 +0200
Re: Bit Swizzling Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-08 00:07 +0000
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 12:26 +0200
Re: Bit Swizzling scott@slp53.sl.home (Scott Lurndal) - 2020-09-08 15:50 +0000
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 19:06 +0200
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2020-09-08 13:13 -0400
Re: Bit Swizzling olcott <NoOne@NoWhere.com> - 2020-09-08 12:18 -0500
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 19:28 +0200
Re: Bit Swizzling Bart <bc@freeuk.com> - 2020-09-08 18:51 +0100
Re: Bit Swizzling olcott <NoOne@NoWhere.com> - 2020-09-08 13:02 -0500
Re: Bit Swizzling Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 20:45 +0200
Re: Bit Swizzling Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-08 15:55 +0000
Re: Bit Swizzling olcott <NoOne@nospicedham.NoWhere.com> - 2020-09-08 11:25 -0500
Re: Bit Swizzling olcott <NoOne@nospicedham.NoWhere.com> - 2020-09-08 11:50 -0500
Re: Bit Swizzling Kaz Kylheku <793-849-0957@nospicedham.kylheku.com> - 2020-09-08 17:47 +0000
Re: Bit Swizzling "R.Wieser" <address@nospicedham.not.available> - 2020-09-08 20:26 +0200
Re: Bit Swizzling David Brown <david.brown@nospicedham.hesbynett.no> - 2020-09-08 22:00 +0200
Re: Bit Swizzling "Rick C. Hodgin" <rick.c.hodgin@nospicedham.gmail.com> - 2020-09-08 21:51 -0400
Re: Bit Swizzling "R.Wieser" <address@nospicedham.not.available> - 2020-09-09 10:53 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Kaz Kylheku <793-849-0957@kylheku.com> |
|---|---|
| Date | 2020-09-08 18:48 +0000 |
| Message-ID | <20200908114117.208@kylheku.com> |
| In reply to | #154728 |
On 2020-09-08, olcott <NoOne@NoWhere.com> wrote: > On 9/8/2020 12:53 PM, Bonita Montero wrote: >>> Parenthesis makes code more readable because precidence is explicitly >>> stated rather than implied. Complex expressions should be broken down >>> into their constituent parts. >> >> Parentheses make the code less readable if you know the operator >> precedence. >> > > If complex expressions are encoded as a hierarchy of appropriately named > compile time macros parenthetical expression nesting is greatly reduced. See, if you just avoid topics of Turing and Halting, you start to make sense. You should do that more often. You could teach children computing principles or something. > I have found that it is best to make code directly say what you mean and > not have to separately remember language details that can possibly vary > across languages. That's a great point; I was also thinking of the same thing. Suppose you're a busy developer working on tasks in four different languages in the same day. You can get tripped up; your wires can get crossed. By and large, languages broadly agree on only the "BEDMAS" precedence rules everyone learns in elementary school. For other operators that language designers have invented, there is a large variance in precedences and other details. (Not all languages, have BEDMAS, either. Smalltalk is an example of a language in which operators are reduced left to right, because they are just method application, or something like that: x + y * z means (x + y) * x).
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-08 14:09 -0500 |
| Subject | Re: Bit Swizzling + [HP] |
| Message-ID | <UNedndc9ZNJgS8rCnZ2dnUU7-fXNnZ2d@giganews.com> |
| In reply to | #154733 |
On 9/8/2020 1:48 PM, Kaz Kylheku wrote: > On 2020-09-08, olcott <NoOne@NoWhere.com> wrote: >> On 9/8/2020 12:53 PM, Bonita Montero wrote: >>>> Parenthesis makes code more readable because precidence is explicitly >>>> stated rather than implied. Complex expressions should be broken down >>>> into their constituent parts. >>> >>> Parentheses make the code less readable if you know the operator >>> precedence. >>> >> >> If complex expressions are encoded as a hierarchy of appropriately named >> compile time macros parenthetical expression nesting is greatly reduced. > > See, if you just avoid topics of Turing and Halting, you start to make sense. > I would make sense on Turing and halting too if people did not begin examining what I say on the basis of the immutable foundational assumption that I must be wrong. > You should do that more often. > > You could teach children computing principles or something. > >> I have found that it is best to make code directly say what you mean and >> not have to separately remember language details that can possibly vary >> across languages. > > That's a great point; I was also thinking of the same thing. Suppose > you're a busy developer working on tasks in four different languages in > the same day. You can get tripped up; your wires can get crossed. > My knowledge of computer science most fundamentally comes from my knowledge of software engineering. You can create all the diagonalizations and theorems that you want yet once you directly see an actual computer program actually correctly deciding the HP cases that were "known" to be impossible then you directly see the big [whoops we goofed] aspect of the halting problem proofs. > By and large, languages broadly agree on only the "BEDMAS" precedence > rules everyone learns in elementary school. For other operators that > language designers have invented, there is a large variance in > precedences and other details. > > (Not all languages, have BEDMAS, either. Smalltalk is an example of a > language in which operators are reduced left to right, because they are > just method application, or something like that: x + y * z means (x + > y) * x). > -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-09-08 12:37 -0700 |
| Subject | Re: Bit Swizzling + [HP] |
| Message-ID | <50d83cab-be73-4046-bdd5-4afdd18fcb41n@googlegroups.com> |
| In reply to | #154734 |
On Tuesday, 8 September 2020 at 20:10:09 UTC+1, olcott wrote: > On 9/8/2020 1:48 PM, Kaz Kylheku wrote: > > On 2020-09-08, olcott <No...@NoWhere.com> wrote: > > > >> If complex expressions are encoded as a hierarchy of appropriately named > >> compile time macros parenthetical expression nesting is greatly reduced. > > > > See, if you just avoid topics of Turing and Halting, you start to make sense. > > > I would make sense on Turing and halting too if people did not begin > examining what I say on the basis of the immutable foundational > assumption that I must be wrong. > Inevitably. The various proofs that halt deciders are impossible are generally accepted to be sound. They are also fairly succinct. If you don't have a succint refutation, you don't have an institutional affiliation with an organisation with a high reputation in computer science, you don't have a track record of producing interesting results in computer science, and the result you claim to overturn is a famous one familiar to many people with only a cursory knowledge of the field, then you'll meet with scepticism. If you genuinely have a contribution, even if it falls short of an actual refutation, e.g. a subtle cheat no-one has ever thought of before, then you will eventually break this down.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-08 16:59 -0500 |
| Subject | Re: Bit Swizzling + [x86utm] |
| Message-ID | <N-udnVuUnu5SY8rCnZ2dnUU7-S_NnZ2d@giganews.com> |
| In reply to | #154738 |
On 9/8/2020 2:37 PM, Malcolm McLean wrote: > On Tuesday, 8 September 2020 at 20:10:09 UTC+1, olcott wrote: >> On 9/8/2020 1:48 PM, Kaz Kylheku wrote: >>> On 2020-09-08, olcott <No...@NoWhere.com> wrote: >>> >>>> If complex expressions are encoded as a hierarchy of appropriately named >>>> compile time macros parenthetical expression nesting is greatly reduced. >>> >>> See, if you just avoid topics of Turing and Halting, you start to make sense. >>> >> I would make sense on Turing and halting too if people did not begin >> examining what I say on the basis of the immutable foundational >> assumption that I must be wrong. >> > Inevitably. The various proofs that halt deciders are impossible are generally > accepted to be sound. They are also fairly succinct. If you don't have a succint > refutation, I do have this. I have an x86 partial halt decider sufficiently equivalent to the Linz H correctly deciding halting on the Linz Ĥ thus proving the H/Ĥ template does not prevent a correct halting decision. > you don't have an institutional affiliation with an organisation with > a high reputation in computer science, you don't have a track record of > producing interesting results in computer science, and the result you claim > to overturn is a famous one familiar to many people with only a cursory > knowledge of the field, then you'll meet with scepticism. > > If you genuinely have a contribution, even if it falls short of an actual refutation, > e.g. a subtle cheat no-one has ever thought of before, then you will eventually > break this down. > Coding the refutation of the standard conventional halting problem counter-examples on the basis of an [every single detail is complete] design is quite trivial compared to creating the operating system infrastructure to actually execute this code. These are the only operating system functions that x86utm provides. I can't begin to implement my halt decider until they are complete. // Saves the state of the current virtual-machine void SaveState(u32* s); // Loads the state of a saved virtual-machine void LoadState(u32* s); // Allocates memory from the heap u32* Allocate(u32 size); // The master machine executes the slave machine void DebugStep(u32* master_state, u32* slave_state); The most difficult one is DebugStep() that enables any x86 code to execute other x86 code in debug-step mode to an arbitrary recursive depth. Time slicing between processes was very easy, I have done this many times before. I am nearly certain that I have re-entrancy correctly. I have done this many times before too. I had to be very careful exactly where I drew the line on atomic execution. The above OS functions are atomic and each x86 instruction is atomic. There are several other x86utm OS functions that are implemented as ordinary user code because they do not currently seem to require atomicity. Conservatively I expect x86utm to be completed this month. While implementing all of the enhancements I did introduce a bug that took me two days to fix. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-08 18:13 -0500 |
| Subject | Re: Bit Swizzling + [HP] |
| Message-ID | <x8SdnXqhHIVjksXCnZ2dnUU7-bnNnZ2d@giganews.com> |
| In reply to | #154734 |
On 9/8/2020 5:38 PM, Keith Thompson wrote: > olcott <NoOne@NoWhere.com> writes: >> On 9/8/2020 3:49 PM, Keith Thompson wrote: >>> [dropping comp.lang.c] >>> olcott <NoOne@NoWhere.com> writes: >>> [...] >>>> I would make sense on Turing and halting too if people did not begin >>>> examining what I say on the basis of the immutable foundational >>>> assumption that I must be wrong. >>> >>> There's likely some of that going on, but for the most part I don't >>> think people *assume* you're always wrong. >>> >>> You make claims that contradict widely accepted proofs of theorems >>> that have stood up to strutiny for decades, and you decline to >>> support your claims with enough detail for anyone with expertise >>> in the field to verify them. *Of course* people conclude that >>> you're wrong. >> >> They have to form a conclusion before all the facts are in? > > They don't have to, but in this case it's entirely reasonable to form a > *tentative* conclusion. > A tentative conclusion is OK. Dead certainty that I must be a fool and a continual disparaging tone indicates bias thus a disregard for truth. > I once had a conversation with a seemingly sincere flat-Earther. > Long before I heard everything he had to say on the topic, I had > reached the reasonable conclusion that he was wrong -- because I > was already aware of a multitude of facts supporting the idea that > the Earth is not flat. On the other hand it is logically possible that every single empirical fact is pure bullshit. It might be the actual case that no Earth what-so-ever actually exists everything is a computer simulation. > It was logically possible (though extremely > unlikely) that he could have presented evidence that I had not > encountered before, evidence strong enough to induce me to change > my mind. Forming a conclusion doesn't have to imply a refusal to > consider new evidence -- but that new evidence has to be presented. > I had a personal friend that had a verifiably 143 IQ that really sincerely believed in flat Earth. I found actual empirical proof that the Earth is spherical as a YouTube video experiment. They sited a pair of lights on a tower about a mile away. The key thing that made the calculations turn out (curved Earth) as expected was the refractive index of the moisture in the air. We never got to finish our analysis of this because he became too perturbed about the way that I disagreed with him and quit being my friend. > Admittedly there are more independent pieces of evidence that > the Earth is not flat than that the halting problem is not solvable. > But there is at least one seemingly rigorous and valid mathematical > proof that the halting problem is not solvable. That crucially depends upon what turns out to be false assumption. > My conclusion, > based on the evidence I've seen so far, is that it's far more likely > that a proof that's been examined by experts for decades is valid > than that you've found a flaw in it that nobody else had noticed. Sure that would certainly be the most plausible scenario. > The fact that you have not provided the necessary details strongly > reinforces that conclusion. > Unless you accept that the basis that I stated for not providing those details yet an actual legitimate basis. I really must complete my x86utm. It is almost done. > One point of clarification: Are you claiming that the halting > problem is solvable (and that you have solved it), or merely that > the existing proofs of its insolubility are flawed? (It would be The second one. The first one requires me to provide an omniscient computer program. > logically possible for the existing proofs to be invalid but for > their conclusion nevertheless to be correct.) > I prove that their conclusion ultimately depends on a false assumption. >> They could more logically say that since I have not yet provided a >> sufficient basis to determine that I am correct they will have to >> simply wait-and-see. > > Sure, we'll wait and see. But I see no reason to doubt the validity of > the existing proofs while we're waiting. No but you can make sure that my stated criterion measure of success is sufficient: I have an x86 partial halt decider sufficiently equivalent to the Linz H correctly deciding halting on the Linz Ĥ thus proving the H/Ĥ template does not prevent a correct halting decision. > >>> Even if we assume you're right, you have to expect people to react >>> to your ideas as they would to flat-Earth or moon hoax theories -- >>> until and unless you prove your ideas to the satisfaction of experts >>> in the field. There is nothing dishonest about any of this. >> >> That I provided the one plausible basis where I could be correct >> (a key detail that no one every noticed before) should provide a >> suffucient basis for a wait-and-see rather than caustic denigration >> attitude. > > Not really, no. Anybody could make such a claim. Yet that single assertion moves what I am claiming from analytically impossible to the realm of possibility. If I said the reason that my proof is correct is that: There really are snakes on the plane! ** this break from reality would be sufficient to disregard my claim. ** Good movie. > > If I told you that I had a key detail that no one ever noticed before > that established that the Earth is flat, but didn't tell you what that > key detail is, would you "wait-and-see", or would you (quite reasonably) > assume that I'm wrong until and unless I provide real evidence? > My brother in-law told me that he was sure that he is Satan and the Pope in Rome (while he was there in Rome)** held a parade for him. **He really did go to Rome my sister bought him the ticket. At the time I thought that this was very implausible yet not impossible. >>> You want people to believe you're right? Prove that you're right. >>> Telling us that you're *just about* to do so carries no weight >>> at all. > The key thing that reviewers in these forums can do in the short time before I complete my work is help me most accurately state the criteria of my success: I (will soon) have an x86 partial halt decider sufficiently equivalent to the Linz H correctly deciding halting on the Linz Ĥ thus proving the H/Ĥ template does not prevent a correct halting decision. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-08 20:07 -0500 |
| Subject | Re: Bit Swizzling + [HP] |
| Message-ID | <45idncqNx8Mnt8XCnZ2dnUU7-f3NnZ2d@giganews.com> |
| In reply to | #154745 |
On 9/8/2020 7:41 PM, Kaz Kylheku wrote: > On 2020-09-09, olcott <NoOne@NoWhere.com> wrote: >> On 9/8/2020 6:44 PM, Keith Thompson wrote: >>>> A tentative conclusion is OK. Dead certainty that I must be a fool and >>>> a continual disparaging tone indicates bias thus a disregard for >>>> truth. >>> >>> No, it indicates a sincere belief that you are a fool. >> >> None-the-less this is a bias thus a divergence from truth. > > A bias is some unfair predisposition. > > If you say foolish things, then someone who believes you are a fool is > doing so based on evidence. > > It's difficult to demonstrate the presence of a bias. > > It requires statistical techniques, which require a decent quantity > of data. > > For instance, if we have data indicating that someone is nice to most > crackpots, except for a certain one, then that could perhaps indicate > some sort of personal bias. > >> It is about 100,000 fold easier for me to refute the halting problem >> proofs by simply providing a fully operational computer program that >> actually performs the computation that was deemed impossible. > > Problem is, you're only showing that it's 100,000 fold easier to keep > writing Usenet articles about the idea of providing the program. Since I am getting so close to being able to provide the actual program I need to make sure that it will be evaluated accurately by mutually agreeing on the precise criterion measure of its success: This is the current rough sketch: I (will soon) have an x86 partial halt decider sufficiently equivalent to the Linz H correctly deciding halting on the Linz Ĥ thus proving the H/Ĥ template does not prevent a correct halting decision. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-09 20:10 -0500 |
| Subject | Re: Bit Swizzling + (HP refutation criteria) |
| Message-ID | <mMidnQ0ocI5j4cTCnZ2dnUU7-avNnZ2d@giganews.com> |
| In reply to | #154745 |
On 9/9/2020 7:40 PM, Mike Terry wrote: > On 10/09/2020 00:10, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> I just wanted to make sure that my x86 halt decider actually applies >>> to the halting problem. >> >> That's not necessary. Any program P that gives the correct answer to >> the case you highlight (P(<[P^], [P^]>) is equally impossible. You can >> publish in Basic, C or Snobol and the world will react in the same way. >> > > Provided P doesn't cheat in some way. P needs to be written in such a > way that the diagonal argument applies for it. > > There are languages where the processing performed within a function > procedure is fixed by the parameters passed to it (and there are no side > effects, just a return value?). I expect there is a word describing > such languages and you would know it... I think there would be a case > for claiming that any P in such a language would be subject to the > diagonal argument, and so if this P did what PO claimed it would refute > that version of the halting proof. > > So does this apply for PO and his emulator environment for running his > COFF file? Who knows? > > What we need from PO is a guarantee that there are no "hidden inputs" to > his "TM"s M and M_Hat - specifically anything that would enable the copy > of M within M_Hat to follow a different execution path to the original M > when calculating P(<[P^], [P^]>). Any such deviation would by > definition be the result of some (hidden) input, which would invalidate > the correspondence between Linz H/H_Hat and P/P_Hat. > > Possible hidden inputs might be: > - global variable usage > - direct comparison by the program of values which vary between > the runs purely due to his emulator internal operation: > - addresses values of returned storage?? > - instruction addresses?? > - something more direct from his emulator showing that > M is running "embedded" or directly?? (Don't know enough > to know whether this is plausible.) > > I'd say it's possible that a program /could/ be written avoiding such > cheating, and for such a program I'd agree with you: if it did what PO > claims it would refute the diagonal argument. But I wouldn't want to > specify an iron-tight list of conditions that would guarantee that. I > think any such cheating would be fairly obvious, so I'll just wait and > see. [Hmm, I know iron-tight isn't right, but my minds gone blank for > what it should be!] > > > Regards, > Mike. > This is the current rough sketch: I (will soon) have an x86 partial halt decider sufficiently equivalent to the Linz H correctly deciding halting on the Linz Ĥ thus proving the H/Ĥ template does not prevent a correct halting decision. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-09 21:07 -0500 |
| Subject | Re: Bit Swizzling + [HP] |
| Message-ID | <_oudncpY6d7yF8TCnZ2dnUU7-KfNnZ2d@giganews.com> |
| In reply to | #154745 |
On 9/9/2020 8:26 PM, Mike Terry wrote: > On 10/09/2020 01:58, olcott wrote: >> On 9/9/2020 7:40 PM, Mike Terry wrote: >>> On 10/09/2020 00:10, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> I just wanted to make sure that my x86 halt decider actually applies >>>>> to the halting problem. >>>> >>>> That's not necessary. Any program P that gives the correct answer to >>>> the case you highlight (P(<[P^], [P^]>) is equally impossible. You can >>>> publish in Basic, C or Snobol and the world will react in the same way. >>>> >>> >>> Provided P doesn't cheat in some way. P needs to be written in such a >>> way that the diagonal argument applies for it. >>> >>> There are languages where the processing performed within a function >>> procedure is fixed by the parameters passed to it (and there are no >>> side effects, just a return value?). I expect there is a word >>> describing such languages and you would know it... I think there >>> would be a case for claiming that any P in such a language would be >>> subject to the diagonal argument, and so if this P did what PO claimed >>> it would refute that version of the halting proof. >>> >>> So does this apply for PO and his emulator environment for running his >>> COFF file? Who knows? >>> >>> What we need from PO is a guarantee that there are no "hidden inputs" >>> to his "TM"s M and M_Hat - specifically anything that would enable the >>> copy of M within M_Hat to follow a different execution path to the >>> original M when calculating P(<[P^], [P^]>). Any such deviation would >>> by definition be the result of some (hidden) input, which would >>> invalidate the correspondence between Linz H/H_Hat and P/P_Hat. >>> >> >> My H and H_Hat invoke the same halt deciding function. >> > > That's good. Also, can you confirm that the processing path within the > halt deciding function is identical in both invocations? > > Mike. > Instead of focusing on the details of what I have or I don't have lets focus on the specification: I (will soon) have an x86 partial halt decider sufficiently equivalent to the Linz H correctly deciding halting on the Linz Ĥ thus proving the H/Ĥ template does not prevent a correct halting decision. That should do it right? -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-09 21:30 -0500 |
| Subject | Re: Bit Swizzling + [HP refutation criteria] |
| Message-ID | <TMydnVXr_a9XEsTCnZ2dnUU7-TPNnZ2d@giganews.com> |
| In reply to | #154745 |
On 9/9/2020 8:53 PM, Ben Bacarisse wrote: > Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: > >> On 10/09/2020 00:10, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> I just wanted to make sure that my x86 halt decider actually applies >>>> to the halting problem. >>> >>> That's not necessary. Any program P that gives the correct answer to >>> the case you highlight (P(<[P^], [P^]>) is equally impossible. You can >>> publish in Basic, C or Snobol and the world will react in the same way. >>> >> >> Provided P doesn't cheat in some way. P needs to be written in such a >> way that the diagonal argument applies for it. > > That's covered by P^ being definable from P. If PO has some genuine > reason to think he has what he says, I would put money on it being > because he has either misunderstood, or deliberately mangled, this P to > P^ transformation. That's why the original claim of an actual Turing > machine was so obviously wrong. The P to P^ mapping in Linz is > unambiguous when you have a Turing machine. > >> There are languages where the processing performed within a function >> procedure is fixed by the parameters passed to it (and there are no >> side effects, just a return value?). I expect there is a word >> describing such languages and you would know it... > > Most functional languages have pretty much this sort of pattern. The > functions can have values from outer scopes, but the value is baked-in > when the function is defined because there is no assignment. > > This would be much easier to get watertight in Haskell. > >> I think there would be a case for claiming that any P in such a >> language would be subject to the diagonal argument, and so if this P >> did what PO claimed it would refute that version of the halting proof. >> >> So does this apply for PO and his emulator environment for running his >> COFF file? Who knows? > > The source is in C so it should be obvious if there is some sort of > cheating going on. I wouldn't look at the COFF file at all. > >> What we need from PO is a guarantee that there are no "hidden inputs" >> to his "TM"s M and M_Hat - specifically anything that would enable the >> copy of M within M_Hat to follow a different execution path to the >> original M when calculating P(<[P^], [P^]>). Any such deviation would >> by definition be the result of some (hidden) input, which would >> invalidate the correspondence between Linz H/H_Hat and P/P_Hat. > > I am increasingly sure that, unless this is all a giant hoax, some > cheating is going on. That's why I suggested he send me P and send him > back P^. That way I can't complain about his messing it up on purpose. > I notice he ignored that post. (Unless something went wrong and it did > not appear.) > >> Possible hidden inputs might be: >> - global variable usage > > Global variables aren't a problem, as far as I can see. Unless, of > course, he's cheating in a massive way by not encoding the input. If > you try to have "P^ go on and behave like P" using function pointers > you've broken the rules. Globals variables in P should start with known > initial values, and P^ is presented as [P^] not as a function pointer. > [P^] is either source code or some other encoding, so the initial values > of the globals are embedded in it too. Nothing P does can change how > the P "embedded" in [P^] works or it's not P! > > Is there some other sort of cheat you have in mind? > >> - direct comparison by the program of values which vary between >> the runs purely due to his emulator internal operation: >> - addresses values of returned storage?? >> - instruction addresses?? >> - something more direct from his emulator showing that >> M is running "embedded" or directly?? (Don't know enough >> to know whether this is plausible.) > > Self-modifying code? > >> I'd say it's possible that a program /could/ be written avoiding such >> cheating, and for such a program I'd agree with you: if it did what PO >> claims it would refute the diagonal argument. But I wouldn't want to >> specify an iron-tight list of conditions that would guarantee that. I >> think any such cheating would be fairly obvious, so I'll just wait and >> see. [Hmm, I know iron-tight isn't right, but my minds gone blank for >> what it should be!] > > Iron-clad. > > My simpler solution is to deal only with the high-level code. PO > publishes P, and I (or you or whoever) creates P^. PO specifies (if > it's not already obvious) how programs and computations are encoded as > data, and then everyone can tell what P(<[P^], [P^]>) and P^([P^]) do. > In fact, if it's portable C, and not too resource hungry, everyone can > run them. > > As I've said elsewhere, I'm not sure if all the x86 emulation stuff is > just about delaying. It may also be about finding somewhere to hide the > cheat. Not easy in C, easier in a pile of x86 run on an emulator. > > Part of me hopes it is not a hoax, because I'd like to see the cheat! > The emulator stuff is about being handed all of the control flow of the whole system on the silver platter of a fully specified directed graph of machine language. Every line of code has the unique label of its machine address. All of the control flow transitions to these machine addresses. -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-09 21:39 -0500 |
| Subject | Re: Bit Swizzling + [HP refutation criteria] |
| Message-ID | <GM-dnSbykZ18DMTCnZ2dnUU7-YPNnZ2d@giganews.com> |
| In reply to | #154745 |
On 9/9/2020 9:07 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> On 9/9/2020 6:10 PM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> I just wanted to make sure that my x86 halt decider actually applies >>>> to the halting problem. >>> >>> That's not necessary. Any program P that gives the correct answer to >>> the case you highlight (P(<[P^], [P^]>) is equally impossible. You can >>> publish in Basic, C or Snobol and the world will react in the same way. >> >> That is great for the longest time it seemed that you were saying the >> opposite. > > I once said halting for C programs is effectively decidable. Is that > what made you think I was saying the opposite? If so, I am /still/ > saying that, and it does /not/ conflict with what I said above. If you > are puzzled by that, ask some questions. > > But one way or another it's good to be on the same page. When will you > send me your C program P, so I can send you back P^? > I have to complete x86utm first. It is almost done. I ran into a bug with my patching the relocatable addresses. The last and most difficult x86utm operating system function to implement is: // The master machine executes the slave machine void DebugStep(u32* master_state, u32* slave_state); -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2020-09-10 22:48 -0500 |
| Subject | Re: Bit Swizzling + [HP] |
| Message-ID | <eMSdncgS5qIZbsfCnZ2dnUU7-UvNnZ2d@giganews.com> |
| In reply to | #154745 |
On 9/10/2020 10:33 PM, Mike Terry wrote: > On 10/09/2020 02:53, Ben Bacarisse wrote: >> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >> >>> On 10/09/2020 00:10, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> I just wanted to make sure that my x86 halt decider actually applies >>>>> to the halting problem. >>>> >>>> That's not necessary. Any program P that gives the correct answer to >>>> the case you highlight (P(<[P^], [P^]>) is equally impossible. You can >>>> publish in Basic, C or Snobol and the world will react in the same way. >>>> >>> >>> Provided P doesn't cheat in some way. P needs to be written in such a >>> way that the diagonal argument applies for it. >> >> That's covered by P^ being definable from P. If PO has some genuine >> reason to think he has what he says, I would put money on it being >> because he has either misunderstood, or deliberately mangled, this P to >> P^ transformation. That's why the original claim of an actual Turing >> machine was so obviously wrong. The P to P^ mapping in Linz is >> unambiguous when you have a Turing machine. >> >>> There are languages where the processing performed within a function >>> procedure is fixed by the parameters passed to it (and there are no >>> side effects, just a return value?). I expect there is a word >>> describing such languages and you would know it... >> >> Most functional languages have pretty much this sort of pattern. The >> functions can have values from outer scopes, but the value is baked-in >> when the function is defined because there is no assignment. >> >> This would be much easier to get watertight in Haskell. >> >>> I think there would be a case for claiming that any P in such a >>> language would be subject to the diagonal argument, and so if this P >>> did what PO claimed it would refute that version of the halting proof. >>> >>> So does this apply for PO and his emulator environment for running his >>> COFF file? Who knows? >> >> The source is in C so it should be obvious if there is some sort of >> cheating going on. I wouldn't look at the COFF file at all. >> >>> What we need from PO is a guarantee that there are no "hidden inputs" >>> to his "TM"s M and M_Hat - specifically anything that would enable the >>> copy of M within M_Hat to follow a different execution path to the >>> original M when calculating P(<[P^], [P^]>). Any such deviation would >>> by definition be the result of some (hidden) input, which would >>> invalidate the correspondence between Linz H/H_Hat and P/P_Hat. >> >> I am increasingly sure that, unless this is all a giant hoax, some >> cheating is going on. That's why I suggested he send me P and send him >> back P^. That way I can't complain about his messing it up on purpose. >> I notice he ignored that post. (Unless something went wrong and it did >> not appear.) >> >>> Possible hidden inputs might be: >>> - global variable usage >> >> Global variables aren't a problem, as far as I can see. Unless, of >> course, he's cheating in a massive way by not encoding the input. If >> you try to have "P^ go on and behave like P" using function pointers >> you've broken the rules. Globals variables in P should start with known >> initial values, and P^ is presented as [P^] not as a function pointer. >> [P^] is either source code or some other encoding, so the initial values >> of the globals are embedded in it too. Nothing P does can change how >> the P "embedded" in [P^] works or it's not P! >> >> Is there some other sort of cheat you have in mind? > > I was thinking of P and P^ both accessing the /same/ global flag g. g > could be initialised to ORIGINAL in P, but P^ might initialise g to > EMBEDDED before calling (embedded) P with the correct parms. Yes, > that's outrageous cheating, and PO has said he has found a way to > actively prevent the use of globals, so I don't think he is thinking of > this blatent cheat. > > But... I note that PO totally avoided my request that he confirm that > (embedded within P^)P calculation path is identical to (original)P > calculation path, as it would be if there is /no/ hidden input. > No actually I answered this too many times. People ask me a question I answer it, then after I answer it they ask me again, and again... > Let's face it - if the paths /are/ identical then his P,P^ are obviously > going to fail, so either he does not realise this yet, or he is planning > for the calculation paths to differ /somehow/ (if not through a simple > global variable cheat). > > OK I've thought up another variation: a C program can take and inspect > function addresses, right? So if P takes its own address and compares > it to something it could branch differently in the two execution > scenarios. That's sort of like using a global... and totally easy to > spot on code inspection, so a bit pointless. (Also now I'm thinking it > that while compilers allow it, it may not be language-legal to compare > function addresses in this way.) > >> >>> - direct comparison by the program of values which vary between >>> the runs purely due to his emulator internal operation: >>> - addresses values of returned storage?? >>> - instruction addresses?? >>> - something more direct from his emulator showing that >>> M is running "embedded" or directly?? (Don't know enough >>> to know whether this is plausible.) >> >> Self-modifying code? > > I don't know. Provided (embedded within P^)P calculation path is > identical to (original)P calculation path, it shouldn't really make any > difference whether the code modifies itself. It's the hidden input idea > that would make the cheat work. > > Then again, if we had a TM model where the TM could inspect itself, it > would be quite easy to make the execution paths diverge - e.g. P could > count its states and diverge if this is above some hard-coded threshold. > (P embedded within P^ would count more states, but this is just > another example of hidden input, invalidating the Linz correspondence.) > None of this is to suggest that such a TM could be a halt decider, or > that it could refute the Linz proof. > >> >>> I'd say it's possible that a program /could/ be written avoiding such >>> cheating, and for such a program I'd agree with you: if it did what PO >>> claims it would refute the diagonal argument. But I wouldn't want to >>> specify an iron-tight list of conditions that would guarantee that. I >>> think any such cheating would be fairly obvious, so I'll just wait and >>> see. [Hmm, I know iron-tight isn't right, but my minds gone blank for >>> what it should be!] >> >> Iron-clad. > > Lol, right. Think I was mixing it with water-tight :) Perhaps cast > iron is better, but I don't think that was anywhere in my mind. > >> >> My simpler solution is to deal only with the high-level code. PO >> publishes P, and I (or you or whoever) creates P^. PO specifies (if >> it's not already obvious) how programs and computations are encoded as >> data, and then everyone can tell what P(<[P^], [P^]>) and P^([P^]) do. >> In fact, if it's portable C, and not too resource hungry, everyone can >> run them. > > I'm sure his code will contain what he calls "OS" calls into his > emulator, making this difficult. I don't have any idea how any of the I will echo the assembly language instructions that it executes. These four virtual machine instructions must be executed as a single atomic unit or the system could crash. > "nested emulation" stuff is supposed to behave. I certainly haven't seen > any guarantee that calls from (embedded within P^)P calculation must > always give the same results as calls within (original)P. > > > Mike. > >> >> As I've said elsewhere, I'm not sure if all the x86 emulation stuff is >> just about delaying. It may also be about finding somewhere to hide the >> cheat. Not easy in C, easier in a pile of x86 run on an emulator. >> >> Part of me hopes it is not a hoax, because I'd like to see the cheat! >> > What if it is neither a hoax nor a cheat and is verifiably correct? -- Copyright 2020 Pete Olcott
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-09-08 13:06 -0700 |
| Message-ID | <87y2lkjaol.fsf@nosuchdomain.example.com> |
| In reply to | #154733 |
Kaz Kylheku <793-849-0957@kylheku.com> writes:
[...]
> By and large, languages broadly agree on only the "BEDMAS" precedence
> rules everyone learns in elementary school. For other operators that
> language designers have invented, there is a large variance in
> precedences and other details.
>
> (Not all languages, have BEDMAS, either. Smalltalk is an example of a
> language in which operators are reduced left to right, because they are
> just method application, or something like that: x + y * z means (x +
> y) * x).
And I think APL groups right-to-left (though that's probably an
oversimplification).
Note that BEDMAS doesn't entirely cover even the obvious set of
precedence rules in C. The "E" is exponentiation, and C doesn't have
an exponentation operator. It also omits assignment (C's treatment
of assignment as an operator can be surprising to newcomers).
The parentheses in
x = (y + z);
are definitely superfluous.
It might be interesting to collect a list of *which* of C's operator
precedence rules are obvious enough that parentheses don't add clarity.
But it would be impossible to reach universal agreement on any such
list, and clarity depends on context. For example, sometimes I might
consider
a || b && c
to be clear enough, but I'd *probably* add parentheses.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-09-08 19:37 +0100 |
| Message-ID | <qbQ5H.1048452$Ij4.1025298@fx29.am4> |
| In reply to | #154726 |
On 08/09/2020 18:53, Bonita Montero wrote: >> Parenthesis makes code more readable because precidence is explicitly >> stated rather than implied. Complex expressions should be broken down >> into their constituent parts. > > Parentheses make the code less readable if you know the operator > precedence. > What does this code mean: A << B + C Hint: I haven't said what language it is. Or it might be pseudocode.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-09-09 12:04 +0200 |
| Message-ID | <rja9bt$lr0$1@dont-email.me> |
| In reply to | #154730 |
On 08/09/2020 20:37, Bart wrote: > On 08/09/2020 18:53, Bonita Montero wrote: >>> Parenthesis makes code more readable because precidence is explicitly >>> stated rather than implied. Complex expressions should be broken down >>> into their constituent parts. >> >> Parentheses make the code less readable if you know the operator >> precedence. >> > > What does this code mean: > > A << B + C > > Hint: I haven't said what language it is. Or it might be pseudocode. > Obviously there is no answer to the question without knowing the language. (Or if you prefer, the answer is "it's meaningless without context".) How it might be parenthesised would often depend on the context too - even when the operator parsing is the same. For example, in C++ I would generally use parenthesis for calculations such as : x = (1u << n) + y; But for an stream output, I would not: cout << x + 1; It's all about what makes code clearest to understand from the context, for whoever is likely to be reading it (sometimes that is only highly experienced programmers, sometimes it is people who barely know the basics of the language), and what makes it least likely for a mistake to be made when writing the code or changing it later. (Again, the level of abilities here can vary hugely.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <793-849-0957@kylheku.com> |
|---|---|
| Date | 2020-09-08 18:39 +0000 |
| Message-ID | <20200908112159.582@kylheku.com> |
| In reply to | #154721 |
On 2020-09-08, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> 2. people who believe that production programs should be lexically >> minimized (such as by eliminating all parentheses that are not >> strictly necessary) almost never make it as far as the interview >> stage, so someone who claims to have interviewed one must be >> making it up. > > I don't say that they should be "lexically minimized", but in some > aspects yet. A lot of parentheses make the code less readable to me. That may be so, but they don't hide the meaning or make the intent less clear. > This presumes you're familiar with the operator-precedences. Even though I'm familiar with operator precedence, I also know that people make precedence-related mistakes. So when I'm reading code, I have to read expressions in multiple ways: of course, I have to read what is actually written, under the assumption that it correctly reflects the coder's intent. That's always our "null hypothesis". At the same time, I also have to take the skeptical view: that the coder may have made a precedence mistake, and interpret it that way. In other words play a game of "what if the writer was actually thinking that the precedence is such and such, and intended this other calculation?" When parentheses are present, I don't have to do that, for that part of the expression. That reduces my cognitive load. That has nothing to do with whether or not I have internalized the precedence rules.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-09-08 12:27 -0700 |
| Message-ID | <037bc1c6-4af6-435d-b737-2681f279a366n@googlegroups.com> |
| In reply to | #154721 |
On Tuesday, 8 September 2020 at 18:35:25 UTC+1, Bonita Montero wrote: > > 1. nobody in their right mind would say such a thing in an interview, > > because they know that it runs contrary to the predominant > > common-sense view in the industry. > Nobody in an interview would ask something like this because the > attitudes are very homogenous in that. > > 2. people who believe that production programs should be lexically > > minimized (such as by eliminating all parentheses that are not > > strictly necessary) almost never make it as far as the interview > > stage, so someone who claims to have interviewed one must be > > making it up. > I don't say that they should be "lexically minimized", but in some > aspects yet. A lot of parentheses make the code less readable to me. > This presumes you're familiar with the operator-precedences. > I use the rule of three. Three levels of parentheseses can be parsed by a human reader. More than that and you need help, like indentiation. So just adding parentheses everywhere isn't the answer. On the other hand, rejecting them in expressions which otherwise wouldn't have any parentheses at all isn't the answer either.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2020-09-07 15:47 -0400 |
| Message-ID | <rj62o1$4gu$1@dont-email.me> |
| In reply to | #154682 |
On 9/7/20 2:39 PM, Bonita Montero wrote:
>>> It's better to have a solid knowledge of the language.
>
>> It's better to have a solid understanding of people and their needs.
>
> Sorry, kowing the operator precedence of C++ is essential literacy.
> You can't say that you would have to put everything in baces, even
> "||" vs "&&" or "*" / "/" vs. "+" / "-". A certain skill-level has
> to be assumed for a decent developer.
Something else to consider in such a case is it's easier to prevent
a mistake, and better to convey to the next developer, that your
actual intention was this:
o |= ((v >> s) & 1) << d;
And not this:
o |= (v >> (s & 1)) << d;
Which isn't completely clear given only this:
o |= (v >> s & 1) << d;
It could've been a mistake to leave the three operators like that
in a row relying on operator precedence.
It's better to convey your intended meaning and remove all doubt.
The developer conveys information beyond logic required for the
compiler in their source code. Comments are one way, but coding
style can also be another way. Adding these extra parentheses
does provide information to the next developer, or even to you
later on when the details of the algorithm have left your mind.
It's important for maintenance and documentation IMO.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-09-08 12:23 +0200 |
| Message-ID | <rj7m2j$9e6$2@dont-email.me> |
| In reply to | #154685 |
> Which isn't completely clear given only this: > o |= (v >> s & 1) << d; For me it's completely clear what this means. You're just assuming a developer like a poem that doesn't know the order of the letters in the ABC.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <793-849-0957@kylheku.com> |
|---|---|
| Date | 2020-09-08 00:07 +0000 |
| Message-ID | <20200907170236.433@kylheku.com> |
| In reply to | #154653 |
On 2020-09-07, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> I normally use as less braces as possible to train the kowledge >>> of operator precedence. > >> Of course, not your own knowledge (that being in competitive shape >> at all times) but the knowledge of anyone who might read your code. > > I think it's always good to train that knowledge. > That's programming-literacy everyone should know. Suppose I'm reading your code, and also happen to know precedence very well. That doesn't settle everything. I have to trust that *you* know precedence well: that the expression you wrote matches your intent. A few parentheses go a long way toward making your intent clear, independently of precedence. A modicum of encoding redundancy is good; it provides a "parity check". -- TXR Programming Lanuage: http://nongnu.org/txr Music DIY Mailing List: http://www.kylheku.com/diy ADA MP-1 Mailing List: http://www.kylheku.com/mp1
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-09-08 12:26 +0200 |
| Message-ID | <rj7m8a$cer$1@dont-email.me> |
| In reply to | #154690 |
> Suppose I'm reading your code, and also happen to know precedence very > well. > That doesn't settle everything. > I have to trust that *you* know precedence well: that > the expression you wrote matches your intent. As I know the operator-precedence my code is more readable for me than a bunch of encapulated parentheses. For me additional parentheses are just as less necessary here as for you in a statement where "/" / "*" vs. "+" / "-" are used; I'll bet my right hand that you don't use parentheses there.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web