| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 24 06:49PM -0400 On 10/24/20 4:08 PM, Bart wrote: > I turned off AV and this time it stayed on-screen. But it didn't much. > The keyboard controls all worked except '3'. This version is not on a frame per second governor. It runs as fast as your video card and CPU can render it. As I say, on my dev machine it's about 3 fps due to a 2007 video card limitation. > Does it update each time there's a new frame? If so there should be an > indication such as a frame counter, if the difference is too subtle to > notice. If your video card's a bottleneck, it won't show much variation between 32-bit and 64-bit. I used my cell phone's stop watch app to time them. Just under 29 seconds for 64-bit, and just under 45 seconds for 32-bit. > Whatever it is that's making it slow, I don't think it's OpenGL. It does a lot of 64-bit FPU computing. Every vertex is recomputed for planetary rotation, plus axial tilt, plus the position / track along the assembly line. > I also tried it with glut32.dll (also a free download from somewhere), > renamed to freeglut.dll, and that was OK. freeglut.dll was designed to be a drop-in replacement for glut32.dll. They should work interchangeably. > (One technical note about glew.dll (is that yours?); it exports over > 3000 names, but only 7 of those are functions. The rest are variables. glew.dll is part of the GLU toolkit. It enables some shortcuts for the complexities of programming OpenGL. I use gluLookAt(), for example, which gives me an eye position, a camera position, and which directions are considered up, and it computes the rest of the projection in OpenGL terms. I'm not very good with OpenGL. I have only hacked at it and gotten things to work. I still don't compute normals correctly, and my rendering is based on quads, triangles, and lines, rather than strips. It could have much greater performance. But, it works, and on a fast GPU it's quite speedy (especially in 64-bit mode). > I suspect a lot of variables either don't have 'static', or are shared > across modules of this library, but are not intended as exports from the > DLL.) I don't know. For me it was a black box that did what I needed. I'd like to switch over to pure OpenGL but I'd need a video tutorial and probably someone to help me translate a teaching into the way I learn. -- Rick C. Hodgin |
| Bart <bc@freeuk.com>: Oct 25 12:21AM +0100 On 24/10/2020 23:49, Rick C. Hodgin wrote: > 32-bit and 64-bit. I used my cell phone's stop watch app to time them. > Just under 29 seconds for 64-bit, and just under 45 seconds for 32-bit. >> Whatever it is that's making it slow, I don't think it's OpenGL. I tried once more, and stared at it for several minutes looking for a 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. Then it took 75 seconds on my 64-bit machine to go through the whole cycle. |
| olcott <NoOne@NoWhere.com>: Oct 24 05:08PM -0500 On 10/24/2020 3:57 PM, Mike Terry wrote: > Again, returning true to H is supposed to say it detected non-halting > behaviour, but the calculation it is examining actually halts. > There, I said it again! :) (last time, really...) Apparently this whole inner invocation of H_Hat() and outer invocation of H_Hat() is against your religion. None-the-less an actual execution trace would show that the outer invocation does abort the inner invocation thus allowing the outer invocation to terminate normally. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 05:20PM -0500 On 10/24/2020 4:41 PM, Alan Mackenzie wrote: >> Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == true >> means that the input has infinite execution. > Or for which a halting program would say "doesn't halt". No, not at all. Not in the least little bit. Was forced to halt is not the same thing at all as does not ever halt. >> Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) == false >> means that the input DOES NOT HAVE infinite execution. > Or for which a halting program would say "does halt". Yes there is it the same. > counterexample to Goldbach's conjecture. Your redefined halt decider > would likely be unable to say if the brute force search would ever > terminate. That is merely undecided which it not at all the same thing as undecidable. The way that the technical nature of what is called undecidable works is that someone asks a (yes or no) question that has no (yes or no) answer and no one notices that the problem is the this question itself is incorrect. The The logical law of polar questions copyright PL olcott 2015 https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ >> (a) Has infinite execution. >> (b) DOES NOT HAVE infinite execution. > and (c) it is unknown whether there's infinite execution. It is no longer possible to derive a counter-example that proves that the halting problem is undecidable. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 05:35PM -0500 On 10/24/2020 5:14 PM, Andy Walker wrote: > you mean and express it clearly, it's small wonder that the rest of us > can't do it for you, and that you seem not to understand what we are > trying to tell you. Most computer programming languages support recursion by allowing a function to call itself from within its own code. https://en.wikipedia.org/wiki/Recursion_(computer_science) When a software function calls itself this is recursive invocation. When When a software function calls another function that calls itself this indirect recursive invocation. When H_Hat() calls Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) unless the above function aborts its execution trace of H_Hat() it will continue to execute forever, UTMs do not have any stack depth limit. The only reason that H_Hat(H_Hat) ever terminates is that Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat) aborted it execution. > As you have been told many times, there are many other ways > to show that there is no general algorithm to decide this; which is > different from any given problem being undecidable. You have been Undecided is not at all the same thing as undecidable. > between TMs and descriptions thereof. That you don't is either a > cause of your confusions or a deliberate choice that you don't want > to express yourself clearly. Your decision. All of the C code that I have provided is ultimately anchored in the x86 machine language that is generated with the Microsoft C compiler. This is the byte for byte exact Turing machine Description language of my machines. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 05:45PM -0500 On 10/24/2020 5:16 PM, Malcolm McLean wrote: > The outer invocation H_Hat is the function we are interested in. If it > terminates normally, that's another way of saying it halts. So H() must > return "not aborted". The outer invocation of H_Hat() is an entirely different process having much more data than the inner invocation. > have you been following my posts? Yes I read all of the ones replying to me and all but one of the others. > The way round this problem is to > say the H aborts itself. i.e. it smashes the machine (abortion is equivalent > to taking a sledgehammed to the machine). Now H_Hat doesn't halt. In the invocation of H_Hat(H_Hat) the inner process tree including an inner Aborted_Because_Non_Halting_Behavior_Detected(M, N) process are aborted before any of them can complete. So even though both instances of H_Hat() have identical source code because they do not have identical data they can have different execution traces. Because the inner H_Hat() is forced to terminate before it gets any return value from its instance of Aborted_Because_Non_Halting_Behavior_Detected(M, N) the outer instance of H_Hat() can have a different execution trace and terminate normally. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 24 06:00PM -0500 On 10/24/2020 5:17 PM, Richard Damon wrote: > Now, we run H_Hat(H_Hat), and it will also get the same true answer, and > it will then immediately Halt. Thus it is clear that H gave the wrong > answer, No the outer H_Hat() is an entirely different process and has much more 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. > construction does NOT have infinite execution, and H_Hat, at least if H > returned non-Halting, adds a very small finite amount of execution to > it, so it is also finite in execution. 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. > If there IS a problem of infinite execution, then that problem is in H, > which is what YOU provided, so if there is a problem, it is yours. No H() and H_Hat() are merely the conventional functions used in every standard halting problem proof. > Aborted_Because_Non_Halting_Behavior_Detected returns false, then H will > say that H_Hat does terminate, but when you run H_Hat is will never > halt, so again you get the wrong answer. Yes you can break my solution to make it not work. That is not any sort of actual rebuttal what-so-ever. -- Copyright 2020 Pete Olcott |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 24 03:09PM -0700 The MS-Windows executable file is a PE file that contains a 'DOS stub' at the beginning of it. This stub is a 16-Bit DOS program that typically prints "This program cannot be run in DOS mode". If I replace the stub with a 16-Bit version of the sha256 program, then the fat binary will also run on MS-DOS 6.22. |
| 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