- 64-bit vs 32-bit app performance, heavy in 64-bit FP - 7 Updates
- The x86utm operating system shows how the halting problem can be made decidable - 10 Updates
- The key aspects of x86utm are now finally complete [ HP proof refutation has been provided ] - 5 Updates
- My first ever YT coding vlog! (Creating a C++ logging framework from scratch) - 2 Updates
- T const - 1 Update
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 25 12:20AM -0400 On 10/24/20 7:21 PM, Bart wrote: > change. > Then I discovered that I had to press Space to start it. I hadn't tried > that before because you said if pauses it, which is not quite right. It pauses and un-pauses it. I apologize if that wasn't clear. LOL. I can actually see how it might not be. On the website it had the pause and un-pause reference. > Then it took 75 seconds on my 64-bit machine to go through the whole cycle. I'm not sure how long it takes on mine. Will test it tomorrow. It's quite a while. Build in debug mode and it almost doubles the slowness. -- Rick C. Hodgin |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 24 09:38PM -0700 On 10/24/2020 9:20 PM, Rick C. Hodgin wrote: > and un-pause reference. >> Then it took 75 seconds on my 64-bit machine to go through the whole >> cycle. Why not try to move the calculations to the GPU? |
| Paul <nospam@needed.invalid>: Oct 25 01:15AM -0400 Chris M. Thomasson wrote: >>> Then it took 75 seconds on my 64-bit machine to go through the whole >>> cycle. > Why not try to move the calculations to the GPU? Maybe using a profiler would tell you where the time is being spent. Paul |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 25 11:08AM +0100 > The 64-bit version is 16 seconds faster per frame, or about 33%. Maybe because of SSE has twice the number of registers in 64 bit mode. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 25 12:11PM -0400 On 10/25/20 12:38 AM, Chris M. Thomasson wrote: > Why not try to move the calculations to the GPU? Because I don't know how to do that. :-) I've reported on things like OpenCL before, but I've never programmed with any of those GPU libraries. It would lend itself well to parallel processing as I have hundreds of vertices that all need to have the same operations performed. I need to use atan2() to get the angle theta, and another atan2() to get rho, and then rotate them, recompute sin() and cos() on both to reposition for rotation and axial tilt. That's the bulk of the transformations. -- Rick C. Hodgin |
| Bart <bc@freeuk.com>: Oct 25 04:27PM On 25/10/2020 16:11, Rick C. Hodgin wrote: > then rotate them, recompute sin() and cos() on both to reposition for > rotation and axial tilt. > That's the bulk of the transformations. If rotating by the same angle lots of times, presumably you set up a transformation matrix first? If not, you presumably don't recalculate sin/cos with the same angle? A transformation matrix can combine several operations (multiple rotations, shearing, moving) into one matrix. OpenGL I think has facilies to apply such a matrix. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 25 01:02PM -0400 On 10/25/20 12:27 PM, Bart wrote: > If rotating by the same angle lots of times, presumably you set up a > transformation matrix first? If not, you presumably don't recalculate > sin/cos with the same angle? Each planet rotates by its rotational rate in the simulation. If you look near the top of the earth_solar_system.cpp file in the main() function you'll see where the multiple iBuildSphere() functions are called. They have rotation rate. Each vertex is rotated by that amount. You can search for the iRotateZ() and iRotateY() functions to find them. This performs arbitrary rotation on the Z or Y axes. > A transformation matrix can combine several operations (multiple > rotations, shearing, moving) into one matrix. OpenGL I think has > facilies to apply such a matrix. I've never understood how those kinds of matrices work. I've tried reading through some tutorials a handful of times over my life, but it's always been confusing to me. It would be better to see the example, and then see the assembly instructions it would generate on a CPU, while I also recognize that in a GPU it performs them as a single operation. I understand quite well trigonometry and the unit circle (and unit sphere). So, I've been able to operate within those boundaries just fine to date, but it is slower. And, as I say, on our gaming laptop with a high-end Nvidia graphics card, I am able to get a 29 second cycle, which is actually too fast. We had to slow it down a little for the videos. I'll put a fps setting on there, but just don't have it yet. I'm also not working on that repository for my active development. That's just a snapshot taken at a given time for public consumption. The work I'm doing now is in creating a triangle map of the land area of the Earth, and then flattening it out so rather than being curved around the sphere / globe, it's as though you took something like a shape in the shape of Australia and then laid it on a flat surface. It changes its geometry a little. Then, I'm taking it and placing it somewhere arbitrarily on the surface of the sphere and having it wrap back around the curve of the sphere's surface. By doing this, I'm able to move continents about to other places on the globe. Baby steps. -- Rick C. Hodgin |
| Elijah Stone <elronnd@elronnd.net>: Oct 25 01:03AM -0700 > What happens if it detects no "non-halting behaviour" (loops or infinite > recursion, or whatever) but its PUT does not terminate either? On real hardware with a finite amount of memory, there are a finite number of total states. So at some point either 1) An explicit halt will occur 2) A state will be repeated The halting problem is decidable on a machine with finite memory within 1+2^n cycles (where n is the number of bits of memory), because the number of states inducible by the program will necessarily be exhausted by 2^n cycles. (Granted, on modern hardware, n is so large as to render 2^n effectively infinite.) -E |
| olcott <NoOne@NoWhere.com>: Oct 25 09:21AM -0500 On 10/25/2020 8:29 AM, Alan Mackenzie wrote: >> behavior of its (PUT) or its (PUT) terminates on its own. > This doesn't work for PUTs which neither terminate nor exhibit > "non-halting behavior", whatever that might mean. My fully elaborated halt decider will detect many kinds of infinite loops and many kinds of infinite recursion, thus two kinds of non-halting behavior. > There is no essential difference between a random halt decider (which > cannot exist) and your A_B_N_H_B_D (which _might_ exist, but won't work). > Halt deciders do not exist and cannot exist. Your dogma is contradicted by my code. I wish people would do more than form what superficially appears to be a rebuttal to the very gullible. > have something to show. Please let us know what the current anticipated > release date is. And then leave all these newsgroups in peace until the > anticipated release becomes an actual release. Since you already disagreed with my current proof without pointing out any error you would likely simply disagree with fully operational code. Any disagreement that does not point out any actual error or what is mistakenly believed to be an error is mere vacuous rhetoric. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 25 09:40AM -0500 On 10/25/2020 3:03 AM, Elijah Stone wrote: > cycles. > (Granted, on modern hardware, n is so large as to render 2^n effectively infinite.) > -E It looks like a 8 GB machine that runs at 2 Ghz takes a minimum of 34 seconds to repeat a prior state. This is only if the code was intentionally designed to as quickly as possible get into every one of its possible states. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 25 02:47PM On 24/10/2020 22:58, olcott wrote: > decider that is omniscient (all knowing). > The scope is to show the conventional proofs do not prove that the > halting problem is undecidable. More specifically, your scope is to exhibit an H, H^ pair, such that H(H^,H^) makes the correct decision for whether H^ (actually) halts. (Not whether H(H^,H^) /would/ halt if something else did or didn't happen, whatever that means. Actually, I've had an insight into what you might mean by that, but I'll probably post that in a new thread...) So, lets stick to your specific (yet to be fully delivered) H, H_Hat pair, and I'll ask the same question: What happens if H fails to detect non-halting behavior for its corresponding H^(H^) calculation, and also that calculation does not terminate? I suggest the answer is that H itself will never terminate, and so fail in its role of halt decider in this crucial case. (But maybe you believe this scenario is impossible.) >> non-halting behaviour for a calculation you agree actually halts. > H_Hat(H_Hat) never ever halts unless and until it is aborted at some > level of inner to outer invocation. "aborted at some level of inner to outer invocation"? How do you come up with such phrases? (More importantly, what does it mean exactly?) What I think you mean is that H_Hat(H_Hat) halts precisely when its call to Aborted_Because_Non_Halting_Behavior_Detected() returns YES, and this in turn happens precisely when tha call has decided it's found "non-halting behaviour" in the program it was emulating (and so decided to cease emulating and return). |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 25 05:04PM +0200 25.10.2020 16:40 olcott kirjutas: > seconds to repeat a prior state. This is only if the code was > intentionally designed to as quickly as possible get into every one of > its possible states. Whoa, an error of ca 10^2,000,000,000 times! This must be a new record, so far I have only seen newspaper articles getting numbers 1 billion times wrong, which is only meager 10^9. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 25 03:16PM On 25/10/2020 14:21, olcott wrote: >> This doesn't work for PUTs which neither terminate nor exhibit >> "non-halting behavior", whatever that might mean. > My fully elaborated halt decider will detect many kinds of infinite loops and many kinds of infinite recursion, thus two kinds of non-halting behavior. "Many kinds"? "Many" isn't good enough, mate. Unless it can detect ALL kinds of non-halting behaviour for ALL arbitrary UTMs then you haven't refuted Turing's proof, dear. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 25 10:30AM -0500 On 10/25/2020 9:47 AM, Mike Terry wrote: > What happens if H fails to detect non-halting behavior for its > corresponding H^(H^) calculation, and also that calculation does not > terminate? H is (and I will repeat for the fifth time) not all knowing. > I suggest the answer is that H itself will never terminate, and so fail > in its role of halt decider in this crucial case. Your assertion is merely that it is possible for programs that are not all knowing to have bugs. You did not notice that by making this assertion that you simply dodged the whole point. The task at hand is not to speculate that a implementation of a halt decider that is not all knowing may get some answers incorrectly only because it is not all knowing. The task at hand is to provide a a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) When I am correct and people realize that I am correct and still want to form a rebuttal they use all kinds of underhanded deceptive tactics to try to win the argument. With persuasive enough rhetoric they sneak in ad hominem attacks disguised as personal insults they succeed in convincing the very gullible that I am probably incorrect. I am not saying that you are using these dishonest tactics. I am merely trying to get you to directly focus on the key point at hand. The task at hand is to provide a a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) >> level of inner to outer invocation. > "aborted at some level of inner to outer invocation"? How do you come > up with such phrases? (More importantly, what does it mean exactly?) Maybe this is incomprehensible without actually seeing the working code. I can understand it only because I focused on this key detail for hundreds of hours and have a fully operational operating system that implements the details of this. > in turn happens precisely when tha call has decided it's found > "non-halting behaviour" in the program it was emulating (and so decided > to cease emulating and return). Yes. H_Hat() is naturally infinitely recursive. https://groups.google.com/g/comp.theory/c/NcFS02hKs1U/m/PlBF-1LRBAAJ This same thing applies to all of the conventional self-referential halting problem proof counter-examples. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 25 10:58AM -0500 On 10/25/2020 10:04 AM, Paavo Helde wrote: > Whoa, an error of ca 10^2,000,000,000 times! This must be a new record, > so far I have only seen newspaper articles getting numbers 1 billion > times wrong, which is only meager 10^9. 8 GB is 68,719,476,736 bits 2 Ghz is 2,147,483,648 operations per second 68,719,476,736 bits / 2,147,483,648 OPS = 32 seconds. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 25 11:07AM -0500 On 10/25/2020 9:55 AM, Alan Mackenzie wrote: > "non-halting behaviour" and will fail with an arbitrary input program. > This is consistent with the theorem saying a halting decider isn't > possible. The task at hand is not to speculate that a implementation of a halt decider that is not all knowing may get some answers incorrectly only because it is not all knowing. The task at hand is to provide a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > superficial about it. And, as yet, I've seen no evidence you have any > code whatsoever. But, for the record, I believe you have something > resembling what you claim in the opening post of this thread. The task at hand is to provide a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > what you have is not a "proof". Abusing the word "proof" is a strong > sign of a crank. What more is necessary? Others have pointed out > detailed flaws, but you won't accept these. The task at hand is to provide a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > And no, I wouldn't disagree with fully operational code. But I know such > is not possible. If you want to prove me wrong, produce this code. If that was true then you could meet this challenge: The task at hand is to provide a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > No. Enough people have pointed out errors for it to be unnecessary for > me to waste time on it. And the burden of proof is on your side, not > ours. The task at hand is to provide a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > You didn't answer the question: when's your software going to be ready? Quite soon. I got totally burned out working all-the-time for months and months. I may reduce the time spent on it to as little as 40 hours per week. I am still aiming for the 2020-12-13 7:00 PM deadline of my two year anniversary of refuting the conclusion the conventional self-referential halting problem proof counter-examples. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 25 11:12AM -0500 On 10/25/2020 10:16 AM, Mr Flibble wrote: > kinds of non-halting behaviour for ALL arbitrary UTMs then you haven't > refuted Turing's proof, dear. > /Flibble The task at hand is not to speculate that a implementation of a halt decider that is not all knowing may get some answers incorrectly only because it is not all knowing. This would be required ONLY if my claim is that I have solved the halting problem. What I have already done is refute all of the conventional self-referential halting problem proof counter-examples. Any correct rebuttal of this must meet this burden of proof: Provide a specific input to this function that can be shown to be impossible to decide correctly: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) -- Copyright 2020 Pete Olcott |
| Richard Damon <Richard@Damon-Family.org>: Oct 24 07:48PM -0400 On 10/24/20 7:00 PM, olcott wrote: > data than the inner H_Hat(). Because the same code has entirely > different data one instance can have a completely different execution > trace than the other. Both the outer H and outer H_Hat invoke the function in identical manners, if they don't you have translated them right. Thus they invoke the detection function the same way. The inner H_Hat is supposed to be a faithful representation of the outer H_Hat, if not, you haven't encoded it properly. Both are calculating the value of H_Hat(H_Hat), one as the actual program and one as your emulated program. Yes, because you are emulating the inner H_Hat, your emulator can do what it wants to that inner one, but the whole purpose of this to let H decide what the running of H_Hat is going to do. Making the emulated one act differently just isn't going to help you figure out what the real machine is going to do. > Different instances of H_Hat() having entirely different data must be > against your religion, none-the-less fully operational code will totally > prove my point. There is nothing wrong with running H_Hat with some other data, but it is meaningless to the Linz proof. Linz everywhere is using H_Hat(H_Hat) and H(H_Hat, H_Hat). |
| olcott <NoOne@NoWhere.com>: Oct 24 07:29PM -0500 On 10/24/2020 6:48 PM, Richard Damon wrote: > the detection function the same way. > The inner H_Hat is supposed to be a faithful representation of the outer > H_Hat, if not, you haven't encoded it properly. The inner H_Hat has the exact same machine code as the outer H_Hat yet the outer DebugTrace() has seen many more steps of the inner H_Hat() than this inner H_Hat()'s DebugTrace() have seen of its own inner inner H_Hat(). > but the whole purpose of this to let H decide what the running of H_Hat > is going to do. Making the emulated one act differently just isn't going > to help you figure out what the real machine is going to do. Actually you are missing a key detail. The only function in the whole system that decides halting is Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) > There is nothing wrong with running H_Hat with some other data, but it > is meaningless to the Linz proof. Linz everywhere is using H_Hat(H_Hat) > and H(H_Hat, H_Hat). No one seems to be getting the idea that there are three different H_Hats() specified by the execution of this code: void H_Hat(u32 M) { if (Aborted_Because_Non_Halting_Behavior_Detected(M, M)) MOV_EAX_0 // Execution of M(N) has been aborted else { MOV_EAX_1 // M(N) has halted HERE: goto HERE; } HALT } int main() { u32 M = (u32)H_Hat; H_Hat(M); // MOV_EAX_0 HALT; } The H_Hat() called by main() is the outermost H_Hat(). Aborted_Because_Non_Halting_Behavior_Detected(M, M) creates a whole brand new process context to execute its own H_Hat() instance which in turn executes a whole other instance of Aborted_Because_Non_Halting_Behavior_Detected(M, M) in the process instance of the inner H_Hat() which which in turn creates yet another whole process instance to execute an inner inner H_Hat(). The two instances of the actual halt deciders: Aborted_Because_Non_Halting_Behavior_Detected(M, M) have different amounts of data. The outer instance decides to abort the whole process tree. This aborts both inner and inner H_Hats() and it also aborts the inner instance of Aborted_Because_Non_Halting_Behavior_Detected(M, M) before it ever returns a value. Apparently this stuff is simply too difficult to understand without seeing working code that proves that the execution trace has been described accurately. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 25 09:35AM -0500 On 10/25/2020 2:45 AM, Malcolm McLean wrote: > The mistake you are making is that if H aborts, you can somehow capture that > and suppress or invert it. Then its not an abort. > To make that obvious, I say abort means "smash the machine". We could say that the computer is smashed so that H_Hat() cannot do the opposite of what the halt decider decided. We also could say that the process containing H_Hat() has been aborted and its memory has been released so that H_Hat() cannot do the opposite of what the halt decider decided. And we can finally say that the Universal Turing Machine (UTM) halt decider that was executing the H_Hat() UTM simply stops executing it so that H_Hat() cannot do the opposite of what the halt decider decided. In each of these three cases H_Hat() cannot possibly do the opposite of whatever the halt decider decides as it always does in each of the conventional self-referential halting problem proof counter-examples. When the halt decider makes its {true,false} halting decision: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) The program under test is no longer executing. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 25 10:07AM -0500 On 10/25/2020 3:07 AM, Malcolm McLean wrote: > That's another way of solving the problem. Pass hidden data to > Aborted_Because_Non_Halting_Behavior_Detected(M, M). It's the > route I thought you would take. There is nothing hidden. The x86utm operating system is a master UTM. As is common knowledge a UTM can see everything that its subordinate TM does. The x86utm master UTM provides an operating system function that allows a subordinate TM to execute its own subordinate TMs in DebugStep() mode. >> Aborted_Because_Non_Halting_Behavior_Detected(M, M) before it ever >> returns a value. > You mean "both outer and inner H_Hats?". This is crucial. If you abort H_Hat(H_Hat) has one outer H_Hat() and two inner H_Hat()s. When the outer H_Hat()'s Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) traces the execution of its first param it detects infinite recursion. The first inner H_Hat invokes its own Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) in its own process context. The outer Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) aborts the first inner H_Hat() before the inner H_Hat()s The outer Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) has returned its value. It can do this because it has already seen more DebugStep() processing steps than the inner process has seen. > H_Hat, it can't halt, and so Linz is side-stepped. (Linz only applies to halt > detectors that are Turing machines, and by giving the machine an "abort" > state you've stopped it from being a strict Turing machine. Linz wasn't So you are saying that it is impossible for a UTM to decide to stop executing its TM. Why do you believe this? -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 25 10:33AM -0500 On 10/25/2020 9:39 AM, Malcolm McLean wrote: >> Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) >> The program under test is no longer executing. > And H is no longer executing either. That's the crucial step. When the halt decider has already terminated the execution of its program under test, then this PUT cannot possibly implement the conventional trick of doing the opposite of whatever the halt decider decides. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 25 01:30PM My first ever YT coding vlog! The new microphone seems to work. :D https://www.youtube.com/watch?v=JTK8MbvLq84 /Flibble -- ¬ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 25 03:06PM On 25/10/2020 13:30, Mr Flibble wrote: > My first ever YT coding vlog! The new microphone seems to work. :D https://www.youtube.com/watch?v=JTK8MbvLq84 > /Flibble New video URL: https://www.youtube.com/watch?v=8c2nfQrPb6g -- ¬ |
| Brian Wood <woodbrian77@gmail.com>: Oct 24 05:16PM -0700 On Tuesday, June 19, 2018 at 10:30:09 AM UTC-5, Scott Lurndal wrote: > >Here's a script to help people switch to east const: > Why on earth would someone want to do something so silly? Talk > about churn for the sake of churn. A new name has appeared on the petition: http://slashslash.info/petition/ in the last few months. I encourage you to join us. Brian https://webEbenezer.net |
| 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