| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 08:29AM -0400 I've written a simulation for my Solar System Assembly Line theory in Open GL. You can download the EXEs here. And please report any errors in getting it to run. 32-bit: http://www.3alive.org/ssal/earth_solar_system_open_gl__32_bit.zip 64-bit: http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip You might need to install the Microsoft Visual C Runtime distribution files if your machine doesn't already have them installed: Microsoft DLLs (x86: vc_redist.x86.exe, x64: vc_redist.x64.exe): https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads And you can also view the latest simulation videos here if you don't want to download and run the EXE: Orthographic: https://www.youtube.com/watch?v=deQAjOvcmwI Perspective: https://www.youtube.com/watch?v=Ahoi9OVFoos ----- On our local gaming laptop test machine, the 32-bit and 64-bit versions offer vastly different performance and frame rates: 32-bit: 45 seconds per cycle* 64-bit: 29 seconds per cycle* * A cycle is the time it takes for the simulation to see the full 7,000 year cycle + PE transfer + reduction (as the PE enters PE-3 Saturn). The 64-bit version is 16 seconds faster per frame, or about 33%. The EXE versions published above are compiled in Visual Studio 2019 and are written in mostly C with a few C++ extensions and relaxations used (for function overloading, relaxed syntax constraints, tighter type checking, anonymous unions, and line comments). The simulation relies heavily on 64-bit floating point math. Even though the 32-bit version is compiled to use SSE2 / vectors where possible, I was still quite surprised at the benefits of seen in the 64-bit code. I am developing this product on an older desktop machine using Visual Studio 2008. Its Open GL 3D graphics card is by far the greatest constraint as I only get about 3 fps without anti-aliasing on either 32-bit or 64-bit compile. But on our production machine where we generate the videos, it's a huge difference in performance. We've been running the VS 2008 32-bit and 64-bit versions and they offer similar performance to the VS 2019 versions. I was wondering if anyone else has seen such a huge difference in any apps comparing 32-bit to 64-bit compiles? Up until now, I have never seen more than a 5% or maybe 10% variation on rare occasion, but most of my C/C++ apps until now have been business apps using databases, networking, and basic business logic. I have done some gaming development, but never with a high-end graphics card, so I've never seen the performance constraints revealed to such a degree. My son and I both had our jaws drop when we ran the 64-bit version and visibly saw the speedup. Quite a thing. -- Rick C. Hodgin |
| Bart <bc@freeuk.com>: Oct 24 03:54PM +0100 On 24/10/2020 13:29, Rick C. Hodgin wrote: > http://www.3alive.org/ssal/earth_solar_system_open_gl__32_bit.zip > 64-bit: > http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip I tried the 64-bit version. It started, and I got a picture that looked like the first frame of your video, but it didn't do anything. After a few seconds it disappeared. If I tried to start it again, it said Access Denied (and there were no orphaned processes that I could see still running. But I was able to delete the binary. When I reinstalled it, it did the same thing. This is on Windows 7. > card, so I've never seen the performance constraints revealed to such a > degree. My son and I both had our jaws drop when we ran the 64-bit > version and visibly saw the speedup. Quite a thing. When I want from 16 bits to true 32 bits (not just 32-bit ops in 16-bit mode), my main application was 50% faster. I no longer any means of producing both 32 and 64-bit binaries with the same compiler, so can't compare any more. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 24 03:57PM +0100 On 24/10/2020 13:29, Rick C. Hodgin wrote: > I am developing this product on an older desktop machine using Visual Studio 2008. Its Open GL 3D graphics card is by far the greatest constraint as I only get about 3 fps without anti-aliasing on either 32-bit or 64-bit compile. But on our production machine where we generate the videos, it's a huge difference in performance. We've been running the VS 2008 32-bit and 64-bit versions and they offer similar performance to the VS 2019 versions. > I was wondering if anyone else has seen such a huge difference in any apps comparing 32-bit to 64-bit compiles? Up until now, I have never seen more than a 5% or maybe 10% variation on rare occasion, but most of my C/C++ apps until now have been business apps using databases, networking, and basic business logic. > I have done some gaming development, but never with a high-end graphics card, so I've never seen the performance constraints revealed to such a degree. My son and I both had our jaws drop when we ran the 64-bit version and visibly saw the speedup. Quite a thing. Dis-liked and commented. /Flibble -- ¬ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 24 04:05PM +0100 On 24/10/2020 13:29, Rick C. Hodgin wrote: > I am developing this product on an older desktop machine using Visual Studio 2008. Its Open GL 3D graphics card is by far the greatest constraint as I only get about 3 fps without anti-aliasing on either 32-bit or 64-bit compile. But on our production machine where we generate the videos, it's a huge difference in performance. We've been running the VS 2008 32-bit and 64-bit versions and they offer similar performance to the VS 2019 versions. > I was wondering if anyone else has seen such a huge difference in any apps comparing 32-bit to 64-bit compiles? Up until now, I have never seen more than a 5% or maybe 10% variation on rare occasion, but most of my C/C++ apps until now have been business apps using databases, networking, and basic business logic. > I have done some gaming development, but never with a high-end graphics card, so I've never seen the performance constraints revealed to such a degree. My son and I both had our jaws drop when we ran the 64-bit version and visibly saw the speedup. Quite a thing. Couldn't run it locally as my anti-virus doesn't like it, or your god, mate. Filename: earth_solar_system_opengl.exe Threat name: WS.Reputation.1Full Path: C:\Users\leigh\Downloads\earth_solar_system_open_gl__64_bit\earth_solar_system_opengl.exe ____________________________ ____________________________ On computers as of 24/10/2020 at 16:01:05 Last Used 24/10/2020 at 16:03:06 Startup Item No Launched No Threat type: Insight Network Threat. There are many indications that this file is untrustworthy and therefore not safe ____________________________ earth_solar_system_opengl.exe Threat name: WS.Reputation.1 Locate Very Few Users Fewer than 5 users in the Norton Community have used this file. Very New This file was released less than 1 week ago. Medium This file risk is medium. ____________________________ http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip Downloaded File from 3alive.org Source: External Media earth_solar_system_opengl.exe ____________________________ File Actions File: C:\Users\leigh\Downloads\earth_solar_system_open_gl__64_bit\ earth_solar_system_opengl.exe Removed ____________________________ File Thumbprint - SHA: 9bc820ca5349f68bad2e7f0490a2d5d5076d78028d80813eb7629d2b004f8a87 File Thumbprint - MD5: 004d14ac233ed9985eab297d417c6bb0 /Flibble -- ¬ |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 24 05:42PM +0200 https://www.virustotal.com/gui/file/9bc820ca5349f68bad2e7f0490a2d5d5076d78028d80813eb7629d2b004f8a87/detection |
| Juha Nieminen <nospam@thanks.invalid>: Oct 24 03:48PM > I've written a simulation for my Solar System Assembly Line theory in > Open GL. Amazing how much work you put into absolute insanity. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 11:56AM -0400 On 10/24/20 10:54 AM, Bart wrote: >> http://www.3alive.org/ssal/earth_solar_system_open_gl__64_bit.zip > I tried the 64-bit version. It started, and I got a picture that looked > like the first frame of your video, but it didn't do anything. It has controls. Spacebar pauses, -+ to make it wider/narrower, */ make it taller/shorter, 1,2,3 for perspective, ortho, and motion. It sounds like anti-virus killed it. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 12:04PM -0400 On 10/24/20 11:48 AM, Juha Nieminen wrote: >> I've written a simulation for my Solar System Assembly Line theory in >> Open GL. > Amazing how much work you put into absolute insanity. I'm prepared to accept it's not a valid theory, but not based on opinion or beliefs. I'm looking for hard scientific data which disproves it, or overt Biblical passages / doctrine which categorically refutes it. I've studied this theory for 10 years now, and I am not aware of any. I am asking for other people to help me break the theory and disprove it. I would like to be free from it, as it's a burden that follows me around in my life. -- Rick C. Hodgin |
| Richard Harnden <richard.nospam@gmail.com>: Oct 24 05:23PM +0100 On 24/10/2020 17:04, Rick C. Hodgin wrote: > I'm prepared to accept it's not a valid theory, but not based on opinion > or beliefs. I'm looking for hard scientific data which disproves it, or > overt Biblical passages / doctrine which categorically refutes it. Occam's razor? > am asking for other people to help me break the theory and disprove it. > I would like to be free from it, as it's a burden that follows me around > in my life. You have wasted ten years, then, sorry. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 12:25PM -0400 On 10/24/20 10:54 AM, Bart wrote: > said Access Denied (and there were no orphaned processes that I could > see still running. But I was able to delete the binary. When I > reinstalled it, it did the same thing. This is on Windows 7. I don't think you use Visual Studio, but I'll post the source code so people can compile it for themselves. I develop it in VS2008 in a specific folder, and have some paths hard-coded for that development. It's part of my LibSF software project, so it goes here: \libsf\source\earth_solar_system\c++\earth_solar_system_opengl\ And it copies its output to: \libsf\source\earth_solar_system\c++\test_opengl\ \libsf\source\earth_solar_system\c++\test_opengl\x64\ And in those two folders I have the DLLs it needs for 32-bit and 64-bit access. Those are the folders I ZIP'd up today after building with VS2019. I'll put it on a GitHub page so people can download it and test it. I don't have GitHub presently, so I'll have to get it all setup. I'll also remove the hard dependencies and make them relative so it can be immediately loaded, compiled, and ran. To my knowledge, there's nothing malicious in anything I've published. If there is something, it might be from the DLLs I use as those were taken from the web several years ago (Free GLUT). I haven't had any issues with them and my own AV does not flag them (in Windows 7 or Windows 10). My son's computer initially flagged them when running an app this 3D engine I've created is based on. It was a test of a Mario World like side-scroller. He added an exception for that executable, and hasn't had any issues since. He gets an update on the Earth Solar System Open GL exe on an almost daily basis, and his AV has not complained since. If you're daring, add an exception. If not, wait for the source code and compile it in Visual Studio 2008 or later from the solution, or probably almost any version of Visual Studio 2003 or later otherwise. -- Rick C. Hodgin |
| Lew Pitcher <lew.pitcher@digitalfreehold.ca>: Oct 24 04:29PM On Sat, 24 Oct 2020 17:23:40 +0100, Richard Harnden wrote: >> disproves it, or overt Biblical passages / doctrine which categorically >> refutes it. > Occam's razor? Russell's teapot: the philosophic burden of proof lies upon a person making unfalsifiable claims. [snip] -- Lew Pitcher "In Skills, We Trust" |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 12:43PM -0400 On 10/24/20 12:29 PM, Lew Pitcher wrote: > Russell's teapot: the philosophic burden of proof lies upon a person > making unfalsifiable claims. I have laid everything before people, and am finalizing a book that will be published for free which holds the entire concept in a 300 page package. Are you able to prove something true? Newton's theories of motion are correct, but they are incomplete. It took Einstein coming along to extend Newton to different velocities and gravitational environments. This theory I have takes what we have been given and puts it together into a package which aligns Biblical teaching with real-world observation through our probes and landings and gazing through telescopes. It answers questions which cannot be answered today. It puts philosophical meaning behind our existence. It does a lot to address the needs of science and religion. But how do you prove it's true? I'm only looking for something in science or in the Bible which will disprove it. That should be doable if it's wrong. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 24 05:45PM +0100 On 24/10/2020 17:25, Rick C. Hodgin wrote: > To my knowledge, there's nothing malicious in anything I've published. If there is something, it might be from the DLLs I use as those were taken from the web several years ago (Free GLUT). I haven't had any issues with them and my own AV does not flag them (in Windows 7 or Windows 10). My son's computer initially flagged them when running an app this 3D engine I've created is based on. It was a test of a Mario World like side-scroller. He added an exception for that executable, and hasn't had any issues since. He gets an update on the Earth Solar System Open GL exe on an almost daily basis, and his AV has not complained since. > If you're daring, add an exception. If not, wait for the source code and compile it in Visual Studio 2008 or later from the solution, or probably almost any version of Visual Studio 2003 or later otherwise. If I ever add an exception to my AV so I can run any of your fucktarded software, mate, then someone needs to shoot me as I have obviously completely lost it. /Flibble -- ¬ |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 12:47PM -0400 On 10/24/20 12:45 PM, Mr Flibble wrote: > If I ever add an exception to my AV so I can run any of your .. > software, mate, then someone needs to shoot me as I have obviously > completely lost it. I would expect no less from you, Leigh. You do not seek the truth. I do not expect you to be a part of this project, but only to sit on the outside screaming at the top of your lungs against it, posting negative comments, spewing hate, fomenting discord ... all the things one compromised by sin in this world would do. It won't get you anywhere, and it will cost you everything in the end. Good luck. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 12:48PM -0400 On 10/24/20 12:25 PM, Rick C. Hodgin wrote: > don't have GitHub presently, so I'll have to get it all setup. I'll > also remove the hard dependencies and make them relative so it can be > immediately loaded, compiled, and ran. This will be the GitHub page: https://github.com/RickCHodgin/Earth_Solar_System_OpenGL I haven't pushed the source code yet. But, it will be up there sometime soon (Lord willing, James 4:15). :-) -- Rick C. Hodgin |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 24 08:04AM -0600 On 2020-10-24 00:03, olcott wrote: > it is aborted and it halts we have the wrong answer. > It must mean: Aborted_Because_Non_Halting_Behavior_Detected. > This is the exact same cases, except now we have the right answer. I'm starting to think your confusion about Linz proof is even deeper than I'd originally thought. From the above you seem to think that there is a contradiction if you claim a program doesn't halt when it has to be aborted inside DebugTrace() because aborting it causes it to halt. That isn't a contradiction, because presumably if you ran the program on its own it would not halt. And that's the only behaviour that H is concerned with. And if you are under the impression that *that* is the contradiction inherent in the Linz Proof, then you have completely misunderstood the proof (not that there was any doubt of that). The question which H is designed to answer is 'does the input TM halt'? It isn't asking about what happens when run inside your DebugTrace() routine. It's asking about what happens when the machine is run on its own. There's nothing in the definition of H which requires H to run the input program at all. Merely to determine if it would halt, which is one reason, among many, why you need to stop talking about UTMs. A UTM is a TM which executes another arbitrary TM. Neither H nor Ĥ do that. They answer a *question* regarding another TM. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 24 10:36AM -0500 On 10/24/2020 9:38 AM, Mike Terry wrote: > Maybe, and that would be the right thing to do if your solution is > wrong. In any case, if you can't refute the Linz proof without changing > the meaning of "Halt Decider", then your solution is wrong. I am refuting that the Linz proof proves that the halting problem is undecidable by finding another way to define the halt decider that cannot be contradicted. > and there is no contradiction anymore, so I've refuted the Linz proof. > [The Linz proof said there could be no such H, but I've delivered one, > and I can supply the traces to prove it!] Right? A halt decider is a program that always halts and cannot be shown to ever get the wrong halting answer. > conditions for a Halt Decider specified in Linz [with the exception that > it only has to correctly decide one input program, viz H^, in order to > refute Linz]. As long as it cannot be shown to ever get the wrong answer when it divides its input into halting and not halting and the halt decider itself always halts then all of the other details are moot. If it calls its halting decision: "three blind mice see how they run" and this means Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false If it calls its not halting decision: "Baa, baa, black sheep, Have you any wool?" and this means Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true Then it is still a halt decider that has refuted the proof that he halting problem is undecidable. If it is forced to report HALTS or DOES_NOT_HALT then in those cases where it must abort the execution trace of its input it is forced to get the wrong answer. It could report would_not_otherwise_halt_unless_aborted (the actual situation) that does not fit into either a HALTS or DOES_NOT_HALT category. > If it doesn't, you are not talking about the Linz proof, so no way can > you be refuting it. This is much more basic than any of the other stuff > you talk about in your refutation. I am refuting the conclusion of the Linz proof that the halting problem is undecidable. > code, but you still need to get *the right answer for H*. H must > somehow translate the Was_Its_Execution_Aborted() return code into its > HALT/NOT_HALT decision. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. > OK I've said that before, so I won't be looping and saying it in any > further posts. I have answered it before and you either did not get to that post yet or you ignored my answer. The most common form a dialogue with me in these forums is to ignore what I say and dogmatically assert that I must be incorrect. >> decidable we must ask a question that cannot be thwarted. > You can ask such a question internally, but H has to answer the Linz > question. The only reason that the Linz proof succeeds it that it is based on a definition of a halt decider that can be made subject to pathologcal self-reference. None of the conventional self-referential halting problem proof counter-examples actually show that the halting problem has no solution they merely found one way NOT to solve the halting problem. It is like Edison trying to invent the light bulb. He tries to make a light build out of a brick. It does not work, so Edison concludes that light bulbs are impossible. > turns it into its HALT/NOT_HALT decision, we /can/ contradict that. (And > no, you're not allowed to change the definition of what H decides - > that's specified in Linz proof.) So yes as all the proofs show there is at least one way that you can define a halt decider that can be fooled. > old questions are equivalent in computing terms, and it doesn't matter > whether you say "I emulated input and terminated it because I correctly > decided it would never halt" or "input never halts [if run natively]". In this case running it natively includes that it is aborted because H_Hat() still invokes Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I); >> This function cannot be contradicted. > But H has to translate the rc from Was_Its_Execution_Aborted() into a > HALT/NOT_HALT decision. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I); Can be interpreted as exactly what it means by a human yet does not precisely fit into either category of HALTS / DOES_NOT_HALT. > "literal naming" convention, perhaps its preferable to call > DeciderLogic() "WouldItHaltIfCalledNatively()", because that is the > actual question H has to answer according to Linz spec. That is an incorrect way of saying it because H_Hat() natively invokes: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I); > Was_Its_Execution_Aborted() and then somehow turns the answer to that > question into its own answer [which it can't do correctly, as the > standard Linz proof shows]. bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I); does refute the conclusion of all of the conventional self referential halting problem proofs. > must answer the Linz question, because it is the Linz proof that you are > claiming to refute. [Basic and obvious fact.] > Mike. bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true cannot be precisely placed into either category of HALTS / DOES_NOT_HALT Yet does divide all of its inputs into halting and looping. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 10:41AM -0500 On 10/24/2020 4:37 AM, Malcolm McLean wrote: > anyway, ignoring this little difficulty. H(H_Hat,H_Hat) reports "this program > terminated abormally". H_Hat(H_Hat) terminates abormally. > So everything is consistent. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true Does not precisely fit into either category of HALTS / DOES_NOT_HALT, yet always indicates that the input program would never halt unless it was aborted. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 04:58PM +0100 On 24/10/2020 05:02, olcott wrote: >> Was_Its_Execution_Aborted emulates H_Hat(H_Hat) >> Was_Its_Execution_Aborted decides the emulation is looping!!! > Infinitely recursive. What do you mean by that? Are you agreeing or disagreeing with the line? How should the line be corrected? Does Was_Its_Execution_Aborted() decide the emulated H_Hat(H_Hat) is exhibiting infinite recursion)? That is a form of "not halting", so we could make the line 100% correct by rewording it I think maybe you just mean that Was_Its_Execution_Aborted() identifies the onset of infinited recursion in the program its emulating, and so decides it is going to abort the emulation - so your remark is just a comment. Or at least we can get rid of this comment if I change my wording to Was_Its_Execution_Aborted decides the emulated program .. .. will never terminate if not aborted I.e. the problem(?) is just my use of the word "loop" rather than the more general "never terminate". >> H_Hat does the opposite of HALT/NOT_HALT > No this step is incorrect as you can see by the following code. > In this case ABORTED = true causing the outermost H_Hat() to halt. Ok, this is all down to me copy-and-pasting from my earlier post which included my DeciderLogic() intermediate routine. I tried to remove references to that after the copying, but the HALT/NOT_HALT is a carry over. (DeciderLogic() translated ABORTED into the HALT/NOT_HALT decision that H makes.) So this is easily corrected - we just have to know how ABORTED is to be translated into H's HALT/NOT_HALT decision. (I.e. whether H sets EAX to 0 or 1 when ABORTED is true...) > } > HALT > } Given this implementation it's clear Was_Its_Execution_Aborted() returning ABORTED results in H_Hat halting. Which is what you said, so good. So we can correct my trace by amending my line from >> H_Hat does the opposite of HALT/NOT_HALT to >> H_Hat halts > It seems really really weird that H_Hat() decides that its input of > H_Hat() will not halt and then it goes ahead and halts itself. Not really, H_Hat is not a decider. It is only you who sees weirdness, because you /tried/ to design H/H^ to work in a particular way, and in the end they do not. :) > information than the inner halt decider (more traced steps) so we are > not getting two different results from the same function for the same > input. The inputs are different. I am only interested (for this machine trace) in whether H_Hat(H_Hat) halts or does not halt for the specific case of your final code delivery (which you've yet to make). You can give your own explanations for /why/ your code does what it does, but I don't need to understand that. (Also, the trace is only for the outer level process, and you are trying to explain something about the inner levels, which is OK but not relevant to this level of trace.) > it is best that it terminates its input as soon as it definitely decides > that its input must be terminated. This keeps things simple. >> So... which of these lines are correct/incorrect? Thanks for responding above. So... Based on your comments, here is a corrected version of my H_Hat machine trace!: H_Hat starts (main() calls H_Hat(H_Hat)) H_Hat calls Was_Its_Execution_Aborted(H_Hat,H_Hat) Was_Its_Execution_Aborted emulates H_Hat(H_Hat) Was_Its_Execution_Aborted decides the emulated program .. .. will never terminate if not aborted Was_Its_Execution_Aborted stops emulating and returns ABORTED H_Hat halts Great! >> ..from Was_Its_Execution_Aborted() >> While we're at it you might as well say which of these lines are >> correct/incorrect too. :) And also, based on your comments, here is a corrected version of my H machine trace!: H starts (main() calls H(H_Hat,H_Hat)) H calls Was_Its_Execution_Aborted(H_Hat,H_Hat) Was_Its_Execution_Aborted emulates H_Hat(H_Hat) Was_Its_Execution_Aborted decides the emulated program .. .. will never terminate if not aborted Was_Its_Execution_Aborted stops emulating and returns ABORTED H halts, with EAX=0 [= NOT_HALT decision] Great! Except that now the H_Hat and H machine traces are in conflict for the expected reason. You may explain /why/ your code has behaved like this by talking about outer levels of code having more information than inner levels, and why you believe there is nothing contradictory about this, but in the end that simply doesn't matter. The fact is that FOR YOUR FINAL DELIVERY OF H, H_Hat, it is the case that: 1) H_Hat run with input (H_Hat) halts 2) H run with input (H_Hat, H_Hat) transitions to the NOT_HALT state. This is exactly what Linz says. Your refutation has failed. Mike. |
| olcott <NoOne@NoWhere.com>: Oct 24 11:04AM -0500 On 10/24/2020 9:00 AM, Richard Damon wrote: >> this time it does it in a way that it cannot be fooled. > Does it? Does Was_Input_Aborted ALWAYS return the correct answer. Will > it say 'Aborted' only if the program being analyzed WILL loop infinitely? The redefined halt decider eliminates the undecidability of the halting problem. It cannot be shown that the redefined halt decider ever necessarily gets the wrong answer. > program likely runs forever, but maybe it stops? > If the latter, then you are basically admitting that your answer isn't > always correct. It cannot be shown that the answer is ever necessarily incorrect. The redefined halt decider eliminates the undecidability of the halting problem. > In particular, it seems that you are accepting that H(H_Hat, H_Hat) will > say that the machine H_Hat(H_Hat) needed to be aborted, even though when > you actually run H_Hat(H_Hat) it properly halts in finite time. This is the tricky part. Now that I have a full x86utm operating system to back me up I can make claims that can be empirically proved. I will use Mike Terry's new name because it is more clear: The outermost x86utm process that invokes this function Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) has a longer execution trace than its inner invocation in the H_Hat() process. This means that the outer invocation has more data than the inner invocation. Because it has more data the rule that the same function with the same data must produce the same result is not violated when the outer x86utm process: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) decides to abort the whole H_Hat() process tree. It doesn't matter if H() or H_Hat() invokes Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) in the x86utm process because they are both invoking the same function with the same data thus decuding the same result: Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) == true. It turns out that all of the conventional self-referential halting problem proof counter-examples specify infinite recursion that never reaches the undecidable states. Because of this none of them would ever halt unless their execution is aborted. If we simply wait and see what H_Hat() does and do not decide to abort it, then H_Hat()'s infinite recursion causes it to have infinite execution. > So yes, your 'Halting Decider' can be built as long as it is allowed to > be WRONG some of the time. This redefined halt decider cannot be shown to ever necessarily decide incorrectly. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 11:14AM -0500 On 10/24/2020 8:50 AM, Richard Damon wrote: > correctly its halting state. > To find fault in that machine, you just need to somehow provide a > machine that can give the answer for that particular construction. Yes that is correct. The other aspect of this issue is that the halt decider must be redefined so that it is not subject to pathological self-reference: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. > of H_Hat outside of that machine are fully defined. The candidate > machine H is not allowed to loop forever, as then it doesn't met the > requirements of a decider. All of the conventional halting problem proof counter-examples merely found one way to define a halt decider that does not work. The above redefined halt decider cannot be shown to ever get the wrong asswer. > all input to refute Linz, but you do need to come up (somehow) with one > that correctly works for his H_Hat(H_Hat) that is allowed to use your > definition of H. I have done the most difficult part of this task. I created the x86utm operating system. Once you understand: (1) The effect of the redefinition of a halt decider eliminates the undecidability of the halting problem. (2) The fact that every conventional self-referential halting problem proof counter-example is infinitely recursive and never reaches the undecidable states. Then correctly deciding _H_Hat() is only a matter of detecting its infinite recursion and reporting: Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 11:25AM -0500 On 10/24/2020 9:04 AM, André G. Isaak wrote: > DebugTrace() because aborting it causes it to halt. That isn't a > contradiction, because presumably if you ran the program on its own it > would not halt. And that's the only behaviour that H is concerned with. H_Hat(H_Hat) calls Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) which aborts the inner H_Hat() and returns true to the outer H_Hat() which then terminates normally. > inherent in the Linz Proof, then you have completely misunderstood the > proof (not that there was any doubt of that). > The question which H is designed to answer is 'does the input TM halt'? Yes and this question can be phrased such that it is subject to pathological self-reference and it can be phrased such that is is not subject to patholegical self-reference. > It isn't asking about what happens when run inside your DebugTrace() > routine. It's asking about what happens when the machine is run on its own. Previously when I talking about inner H_Hat() and outer _H_Hat() people flatly denied that there could be any such thing. Now I have a complete x86utm operating system to empirically prove my point. People were saying the every instance of a halt decider having the same input must always return that same result without realizing that the outer instance of a halt decider has a longer execution trace than the inner instance of this halt decider sop the input is not the same. > TM which executes another arbitrary TM. Neither H nor Ĥ do that. They > answer a *question* regarding another TM. > André The simplest and most direct way to define any halt decider is to simply execute its program under test (PUT) one (step / state transition) at a time and examine its actual behavior. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 24 05:37PM +0100 On 24/10/2020 16:36, olcott wrote: > I am refuting that the Linz proof proves that the halting problem is > undecidable by finding another way to define the halt decider that > cannot be contradicted. The Linz halt decider corresponds to the correct (HP) definition of a halt decider. If you change this definition you are not discussing HP. >> I've delivered one, and I can supply the traces to prove it!] Right? > A halt decider is a program that always halts and cannot be shown to > ever get the wrong halting answer. A halt decider is what the HP says a halt decider is. There is nothing in that definition about "cannot be shown to...". You've made that up. > As long as it cannot be shown to ever get the wrong answer when it > divides its input into halting and not halting and the halt decider > itself always halts then all of the other details are moot. The point of the Linz proof is that it /does/ show that any halt decider will always give a wrong answer for at least one input (the (H^,H^) input). If you aim to refute this, then for you must show that your H, H^ have the correct relationship and yet the Linz conclusion is incorrect for your H,H^. (So far you've demonstrated that it IS correct as shown in the two stack traces for their execution.) > Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true > Then it is still a halt decider that has refuted the proof that he > halting problem is undecidable. Nonsense. > If it is forced to report HALTS or DOES_NOT_HALT then in those cases > where it must abort the execution trace of its input it is forced to get > the wrong answer. Exactly, so it is not in fact a halt decider after all. > It could report would_not_otherwise_halt_unless_aborted (the actual > situation) that does not fit into either a HALTS or DOES_NOT_HALT category. No, a halt decider by definition reports HALT/NOT_HALT. You can obviously change the labels to whatever you like, but the /meaning/ behind the labels cannot be changed: - HALT decision indicates the TM identified by the tape input when run with the data identifed by the tape input halts - NOT_HALT decision indicates the TM identified by the tape input when run with the data identifed by the tape input does not halt ok, now our dialog has just come to repeating the same stuff, so I'm stopping. Mike. |
| olcott <NoOne@NoWhere.com>: Oct 24 11:40AM -0500 On 10/24/2020 7:07 AM, Ben Bacarisse wrote: >> H(H_Hat, H_Hat) and H_Hat(H_Hat) because its input is identical. > And hence, as I (and others) showed you, H(H_Hat, H_Hat) gives the wrong > result. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true means that the input has infinite execution. Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false means that the input DOES NOT HAVE infinite execution. This redefined notion of a halt decider cannot be shown to ever get the wrong answer. > gets its return value (or what you call it) does not stop H(H_Hat, > H_Hat) being wrong, but a people seem to have got sucked into your > vortex! When executed from the outermost execution context of x86utm H(H_Hat, H_Hat) and H_Hat(H_Hat) both call Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) and each one receives a return value of true. Also in each case the inner invocation of Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) that was executed in the process context of the inner H_Hat() is aborted when the whole process tree of the inner H_Hat() is aborted. This prevents the inner Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) from ever returning a value to the inner H_Hat(). > Notice that you are wrong in several equally problematic ways. You have > redefines the notion of a halt decider so as to give yourself permission > to get some cares wrong (that was the 2004 tactic), but you also haven't If you foolishly ignore what I say and merely dogmatically state that I am incorrect this is no rebuttal what-so-ever. Merely dogmatically stating that I am incorrect without actually pointing out any error only becomes dishonest when you claim to have pointed out an error and indeed did not point out any error. It is not dishonest if you point something out that you wrongly believe is an error and indeed is not actually an error. In this case it is merely an honest mistake. -- Copyright 2020 Pete Olcott |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 24 06:19AM -0700 This is a follow-up to "Making a Fat Binary for Linux and Mac" which I multi-posted two days ago to three newsgroups: comp.lang.c, comp.lang.c++, comp.unix.programmer I got the most responses on 'comp.lang.c', which you can see here: https://groups.google.com/forum/#!topic/comp.lang.c/Qev_btMilNI I have now made a fat binary that contains 5 executable programs: * Linux arm32 * Linux arm64 * Linux x86_32 * Linux x86_64 * MS-Windows x86_32 For the Microsoft Windows executable file, I went with a 32-Bit executable because it will run on both 32-Bit and 64-Bit versions of MS-Windows. So here's how my 'combined Linux and MS-Windows' script looks now. Note that each line begins with four spaces. This script will run as an 'sh' shell script on Linux, and will run as a batch file on MS-Windows. [BEGIN SCRIPT] :; if [ -z 0 ]; then # @echo off goto :MICROSOFT fi # Linux shell script starts here # x86 32-Bit = i386, i686 # x86 64-bit = x86_64 # arm 32-Bit = arm # arm 64-Bit = aarch64 aarch64_be armv8b armv8l arch=`uname -m` case ${arch} in i386|i686) skip=000000018788 count=000000005464 ;; x86_64) skip=000000024252 count=000000010216 ;; arm|armv7l) skip=000000034468 count=000000005528 ;; aarch64|aarch64_be|armv8b|armv8l) skip=000000039996 count=000000010080 ;; *) exit 1 ;; esac tmpfile=$(mktemp /tmp/fatbinary_${arch}.XXXXXXXXXX) dd if="$0" of=${tmpfile} bs=1 skip=${skip} count=${count} > /dev/null 2>&1 chmod +x ${tmpfile} ${tmpfile} "$@" retval=$? rm -rf "$tmpfile" exit ${retval} # Microsoft batch file starts here :MICROSOFT REM The next 6 lines are just for making a temporary file :loop set /a y$$=%random%+100000 set y$$=temp%y$$:~1,2%.%y$$:~-3% if exist "%temp%\%y$$%.exe" goto loop set "y$$=%temp%\%y$$%" set "tempfile=%y$$%.exe" findstr /v /c:" " "%~f0" > %tempfile% %tempfile% %* set "finalerrorcode=%ERRORLEVEL%" del /f /q %tempfile% exit /b %finalerrorcode% [END SCRIPT] The Linux part of the above script has "\n" line endings, whereas the Microsoft part of the above script has "\r\n" line endings. See the first link at the end of this post to get the original file. As for the program for which I chose to make a fat binary, I went with a sha256 digest calculator, using code by Alain Mosnier from repository: https://github.com/amosnier/sha-2 I have turned Mosnier's code into a single-source-file C program that calculates the sha256 digest of its first command line argument. For the C code, see the second link at the end of this post. I compiled this C program 5 times and got the 5 following binaries: -rwxr-xr-x 1 root root 17422 Oct 24 11:10 prog_mswin_x86_32.exe -rwxr-xr-x 1 root root 5464 Oct 24 13:50 prog_x86_32 -rwxr-xr-x 1 root root 10216 Oct 24 13:50 prog_x86_64 -rwxr-xr-x 1 root root 5528 Oct 24 13:50 prog_arm32 -rwxr-xr-x 1 root root 10080 Oct 24 13:50 prog_arm64 (See download links 3-7 at the end of this post) I concatenated my script with these 5 binaries as follows: cat script.txt prog_mswin_x86_32.exe prog_x86_32 prog_x86_64 prog_arm32 prog_arm64 > fatsha256.bat The result is my fat binary with size 50 kilobytes: -rwxr-xr-x 1 root root 50076 Oct 24 13:51 fatsha256.bat (See download link 8 at the end of this post) This file can be executed at the command line on both Linux and MS-Windows: fatsha256.bat "This is my message" And it prints the digest: 3311b7c0bd91b6c73a38212de8ade31c51910f17480ad212ed2b9798a35b7747 I have verified it works on: * Linux arm32 * Linux arm64 * Linux x86_64 * MS-Windows x86_32 It should also work on Linux x86 32-Bit, let me know if someone tries it. Links: 1: http://virjacode.com/experimental2/script.txt 2: http://virjacode.com/experimental2/sha256.c 3: http://virjacode.com/experimental2/prog_arm32 4: http://virjacode.com/experimental2/prog_arm64 5: http://virjacode.com/experimental2/prog_x86_32 6: http://virjacode.com/experimental2/prog_x86_64 7: http://virjacode.com/experimental2/prog_mswin_x86_32.exe 8: http://virjacode.com/experimental2/fatsha256.bat |
| 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