| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: May 09 08:01PM +0100 On 09/05/2021 19:27, olcott wrote: > The latest version of my paper as an attachment. > I have never done attachments to USENET messages before. > I am doing this primarily for archival backup purposes. Until you address the issue of program state and branching logic predicated on that state your "paper" is worthless and your "refutation" is vacuous. /Flibble -- π |
| olcott <NoOne@NoWhere.com>: May 09 02:11PM -0500 On 5/9/2021 2:01 PM, Mr Flibble wrote: > predicated on that state your "paper" is worthless and your "refutation" > is vacuous. > /Flibble That you believe that there is such an issue is an error on your part. Others will understand that you are mistaken when you elaborate the details of your position. If the execution trace of function Y() shows: (1) function X() is called twice in sequence from the same machine address of Y() (2) with the same parameters to X() (3) with no conditional branch or indexed jump instructions in Y() (4) with no function call returns from X() then the function call from Y() to X() is infinitely recursive. The above criteria does correctly recognize the subset of infinite recursion / infinitely nested simulation such that Halts() does correctly decide not halting on the x86 machine language trace of H_Hat(). void H_Hat(u32 P) { u32 Input_Halts = Halts(P, P); if (Input_Halts) HERE: goto HERE; } int main() { u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat); Output("Input_Would_Halt = ", Input_Would_Halt); } http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: May 09 09:03PM +0100 On 09/05/2021 20:11, olcott wrote: > Output("Input_Would_Halt = ", Input_Would_Halt); > } > http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf You repeat yourself over and over without adding anything new. I can do the same: Until you address the issue of program state and branching logic predicated on that state your "paper" is worthless and your "refutation" is vacuous. /Flibble -- π |
| olcott <NoOne@NoWhere.com>: May 09 03:11PM -0500 On 5/9/2021 3:03 PM, Mr Flibble wrote: > You repeat yourself over and over without adding anything new. I can do > the same: > Until you address the issue of program state and branching logic Until you explain what you mean about "branching logic" people will not be able to tell which mistake you are making. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: May 09 09:33PM +0100 On 09/05/2021 21:11, olcott wrote: >> Until you address the issue of program state and branching logic > Until you explain what you mean about "branching logic" people will not be able > to tell which mistake you are making. Turing machines execute algorithms and algorithms, in the general case, include branching logic (conditional expressions). Unless you address the general case rather than the brain-dead specific case of an algorithm that doesn't do any useful work you are not adding anything of value to the discourse. It is really fucking simple, dear. /Flibble -- π |
| olcott <NoOne@NoWhere.com>: May 09 03:39PM -0500 On 5/9/2021 3:33 PM, Mr Flibble wrote: > algorithm that doesn't do any useful work you are not adding anything of > value to the discourse. It is really fucking simple, dear. > /Flibble Now everyone can see your error: You are saying that correctly refuting the halting proofs is of no value at all until after I actually solve the halting problem. Everyone here will be able to see that this understanding is woefully incorrect. By correctly refuting the halting problem proofs others will be able to begin working on solving the halting problem now that I have proved that solving the halting problem is not proved to be impossible. I changed the follow up to comp.theory -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Siri Cruise <chine.bleu@yahoo.com>: May 09 01:45PM -0700 In article <WjWlI.555068$BHVc.471766@fx32.ams4>, > on > that state your "paper" is worthless and your "refutation" is vacuous. > /Flibble Some number theory conjectures can be expressed as turing machines that either halt on disproved or do not halt if proven. Let a halting problem decider work on these, and then I'll take this crap seriouslike. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \ I am an Andrea Doria sockpuppet. insults Islam. Mohammed |
| olcott <NoOne@NoWhere.com>: May 09 03:54PM -0500 On 5/9/2021 3:45 PM, Siri Cruise wrote: > machines that either halt on disproved or do not halt if proven. > Let a halting problem decider work on these, and then I'll take > this crap seriouslike. When we base halting on answering questions that currently have no known answers this does not derive the conventional notion of halting undecidability. It is not the case that the correct answer is impossible to provide, we just don't know what that answer is right now. In any case this does not refute my claim to have refuted the conventional halting problem proofs. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: May 09 09:56PM +0100 On 09/05/2021 21:54, olcott wrote: > know what that answer is right now. > In any case this does not refute my claim to have refuted the conventional > halting problem proofs. You repeat yourself over and over without adding anything new. I can do the same: Until you address the issue of program state and branching logic predicated on that state your "paper" is worthless and your "refutation" is vacuous. /Flibble -- π |
| Siri Cruise <chine.bleu@yahoo.com>: May 09 02:00PM -0700 In article <0vednVI61bCe0QX9nZ2dnUU7-U3NnZ2d@giganews.com>, > answers this does not derive the conventional notion of halting > undecidability. It is not the case that the correct answer is impossible > to provide, we just don't know what that answer is right now. In other words you can solve whether a specific TM will halt after someone else proves whether it will halt. That's a really impressive skill. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ Discordia: not just a religion but also a parody. This post / \ I am an Andrea Doria sockpuppet. insults Islam. Mohammed |
| olcott <NoOne@NoWhere.com>: May 09 04:00PM -0500 On 5/9/2021 3:56 PM, Mr Flibble wrote: > predicated on that state your "paper" is worthless and your "refutation" > is vacuous. > /Flibble What you mean is that correctly refuting the conventional halting problem proofs is worthless until I actually solve the halting problem. Everyone that sufficiently understands the halting problem proofs would disagree. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: May 09 04:04PM -0500 On 5/9/2021 4:00 PM, Siri Cruise wrote: > In other words you can solve whether a specific TM will halt > after someone else proves whether it will halt. That's a really > impressive skill. I have correctly refuted the conventional halting problem proofs. If you are saying that is of no consequence people sufficiently understanding these proofs would disagree. http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| wij <wyniijj@gmail.com>: May 08 07:21PM -0700 On Sunday, 9 May 2021 at 06:45:48 UTC+8, olcott wrote: > Copyright 2021 Pete Olcott > "Great spirits have always encountered violent opposition from mediocre > minds." Einstein Please provide a valid C++ code and CONSISTENT, HONEST, descriptions. Your statements are confusing, not showing desire for Honest Dialogue |
| olcott <NoOne@NoWhere.com>: May 08 09:35PM -0500 On 5/8/2021 9:21 PM, wij wrote: >> minds." Einstein > Please provide a valid C++ code and CONSISTENT, HONEST, descriptions. > Your statements are confusing, not showing desire for Honest Dialogue The above paper has much more details. This posting is the essence of my results. u32 Halts(u32 P, u32 I); The key C code is provided above. Halts() is actually quite complex depending on many hundreds of pages of x86 emulator code also written in C. The only thing that needs to be known about this otherwise enormously complex code is that Halts() simulates the code @ machine address P with data at machine address I until this simulation matches the non-halting criteria of (1)(2)(3)(4) shown above. Putting all this together and the key halting problem instance is shown to be decidable as non-halting. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| wij <wyniijj@gmail.com>: May 08 08:02PM -0700 > Copyright 2021 Pete Olcott > "Great spirits have always encountered violent opposition from mediocre > minds." Einstein The non-halting criteria of (1)(2)(3)(4) mentions X(),Y(), while the examples use u32 Halts(u32,u32), and H_Hat(u32). I am baffled what is really said. (consistency) |
| olcott <NoOne@NoWhere.com>: May 08 10:11PM -0500 On 5/8/2021 10:02 PM, wij wrote: > The non-halting criteria of (1)(2)(3)(4) mentions X(),Y(), while the examples > use u32 Halts(u32,u32), and H_Hat(u32). I am baffled what is really said. > (consistency) The X() and Y() function names specify the generic [infinite-recursion] behavior pattern. This behavior pattern equally applies to the [infinitely nested simulation] behavior of H_Hat() relative to Halts(). I cut-and-pasted this stuff from my five page paper. The above is explained on page one of my paper. http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| wij <wyniijj@gmail.com>: May 08 08:55PM -0700 > explained on page one of my paper. > http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf > -- How is the result of your paper helpful in practice (or in theory)? |
| olcott <NoOne@NoWhere.com>: May 08 11:07PM -0500 On 5/8/2021 10:55 PM, wij wrote: >> http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf >> -- > How is the result of your paper helpful in practice (or in theory)? The conventional halting problem proofs cease to prove that the halting problem cannot be solved. This provides the basis for the solution to the halting problem. https://en.wikipedia.org/wiki/Halting_problem The fundmental limits of algorithmic computation that were previously demonstrated by the halting problem proofs cease to exist. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: May 09 07:18PM +0100 On 09/05/2021 05:07, olcott wrote: > problem. https://en.wikipedia.org/wiki/Halting_problem > The fundmental limits of algorithmic computation that were previously > demonstrated by the halting problem proofs cease to exist. You haven't refuted anything until you address the issue of program state and branching logic predicated on that state. /Flibble -- π |
| wij <wyniijj@gmail.com>: May 09 12:15PM -0700 On Sunday, 9 May 2021 at 12:08:27 UTC+8, olcott wrote: > Copyright 2021 Pete Olcott > "Great spirits have always encountered violent opposition from mediocre > minds." Einstein I feel the contents would not be appropriate in this place, moved to comp.theory https://groups.google.com/g/comp.theory/c/cGaCqjMYHvs |
| "ΓΓΆ Tiib" <ootiib@hot.ee>: May 09 09:56AM -0700 On Saturday, 8 May 2021 at 23:27:38 UTC+3, Juha Nieminen wrote: > Good programming practices, and common sense in programming, would dictate > to avoid deliberate obfuscation and "fancy syntactic tricks" (when much > more readable and understandable 100% equivalent alternatives exist). Yes. Correct. My whole point was that it is often not worth even to consider how 100% it is. > just because they like them, find them fancy and cool, but a good programmer > is distinguished by being able to write clear readable code that's still > reasonably simple and reasonably efficient. Indeed reasonably efficient. > Anyway, rather obviously there are benefits to the trinary comparison > result in many situations. Yes and in many situations like with IEEE 754 types we may benefit from quaternary comparison results. But if it brings any performance benefits is unclear until shown by profiler. The discussions about spaceship operators I've had so far have been clearly that it most likely is less performant than binary operators. > of time which the trinary comparison operator solves: It directly tells you > if that last element that was compared was larger or equal to the searched > element, so you just need to check the integer value to know. It solves that only when the trinary comparison is of equal cost with binary comparison. > need to perform the binary search yourself. But the trinary comparison > result will help you in this case to avoid the double comparison of the > same element at the end of the search.) And if we are in benefit or loss with it only profiler can tell. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment