Overunity.com Archives is Temporarily on Read Mode Only!



Free Energy will change the World - Free Energy will stop Climate Change - Free Energy will give us hope
and we will not surrender until free energy will be enabled all over the world, to power planes, cars, ships and trains.
Free energy will help the poor to become independent of needing expensive fuels.
So all in all Free energy will bring far more peace to the world than any other invention has already brought to the world.
Those beautiful words were written by Stefan Hartmann/Owner/Admin at overunity.com
Unfortunately now, Stefan Hartmann is very ill and He needs our help
Stefan wanted that I have all these massive data to get it back online
even being as ill as Stefan is, he transferred all databases and folders
that without his help, this Forum Archives would have never been published here
so, please, as the Webmaster and Creator of these Archives, I am asking that you help him
by making a donation on the Paypal Button above.
You can visit us or register at my main site at:
Overunity Machines Forum



quentron.com

Started by Philip Hardcastle, April 04, 2012, 05:00:30 AM

Previous topic - Next topic

0 Members and 40 Guests are viewing this topic.

sarkeizen

Quote from: Bruce_TPU on January 27, 2013, 10:03:51 PM
Does anyone else out there feel like every page of this thread reads like the page before?
Awww...Bruce_TPU needs a hug.  Sorry for neglecting you Bruce_TPU you are an important part of the OU community.  Where else would people go for vapid chatter?  I get that for you, this is like sitting through algebra again or having to sit at the grownup's table during thanksgiving.   That can be tough. :(

I admit I was hoping the My Little Pony Reference might help keep your interest.  I kind of figured you for a closet Brony.

That said, between lumen's foot-dragging, boasting, refusing to answer questions and now it turns out he didn't bother to read a number of posts.  I can totally understand how this might seem tedious.

Thanks for understanding and being patient with him.

(I will try to put more cartoon references to entertain you - like Science Ninja Team Gatchaman!!!!)


lumen

Quote from: sarkeizen on January 27, 2013, 08:46:45 PM
Well first thanks for admitting what I've said for about six posts now.   You don't have a single half of a clue as to what I'm talking about.  Interesting that really didn't seem to get in the way of you being so utterly arrogant that you couldn't believe that you had got it wrong.  Post after post after post after post of you going on and on and on about a "solution".  When in fact, you didn't even read enough of my posts to even see the problem.  Really, if there's someone here with an ego which is enormous to the point of being crippling it's you and this should be a wake-up call....but it probably won't be.

Well moving on...if you had read the posts I made after that I built upon the concept of using WillThisEnd() by creating a new function WillThisEndOnSelf() which takes a single argument which is a pointer to a program. i.e.

function WillThisEndOnSelf(program) {
     if ( WillThisEnd(program,program) == 'true' )
        while (1);
     else
        return;
}

All this is, is a function which is run on the CPU - which happens to call WillThisEnd (which is your interpreter).  If WillThisEnd returns 'true' then WillThisEndOnSelf goes into an infinite loop.  However if WillThisEnd returns 'false' then it terminates normally.

Again if you had actually followed along with the posts and read the words in them you would have seen that my question was.  What happens when you run:

WillThisEndOnSelf(WillThisEndOnSelf);

Using your software as "WillThisEnd()"I haven't written any assembler here so that's kind of an empty criticism.  C is a useful tool because the syntax is largely settled (unlike say Python), it doesn't differ significantly from architecture to architecture, it allows a fair amount of low level access and it can create pretty complex code with limited library support (as opposed to Java).

The fact that you can't write it, even to the point of realizing that you need to pass as many arguments as your function is defined with is kind of telling.  Look at the evidence!  You haven't shown very much code of any kind.  You don't appear to understand rudimentary computer science.  I get that some people are self-taught and primarily "practical" coders and I also get that others are formally taught and generally "theoretical" coders.  You seem to suck at both.

Granted I'm looking at a limited sample of what you can do but that's pretty much your own fault as you have worked very hard to avoid showing any code.If you had even taken a high-school course in programming you would have known that some of the syntax you used was AMBIGUOUS so while I'm not concerned if something is letter-perfect. If you write utter crap like:

lumenFunction(lumenFunction) = 4;

Then of course there's a problem. See, "=" is an ASSIGNMENT operator in so many programming languages it's not even funny.   So what this line is actually attempting to do is unclear, if it in fact does anything at all.  Even this might be tolerable if you would actually ANSWER QUESTIONS about your code but you don't.

So you have provided me with good reason to think you're the biggest fucking loser that has ever sat down at a computer.  Capiche?That would be good advice if you also applied it to yourself.   This thread is pages and pages and pages of you crooning about how solving the halting problem is so easy....WHEN YOU DIDN'T EVEN UNDERSTAND IT!   Sorry the only person not questioning themselves here is you. 

Also if questioning things is good how come your belief that I didn't question Turing's proof isn't being questioned? My marital status was, according to you unquestionable.  I could go on an on how many ridiculous moronic and overly broad things you've asserted without any doubt at all.

  The only thing *I've* maintained is that there exists a mathematical PROOF restricting the kinds of programs which can be written.  Unlike you, who immediately assumed (and did not question themselves) that whatever the problem is it can't possibly something that can't be done.  Unlike you I actually read Turing's paper.  I did the proof.  What I'm giving you here is an "easy to understand" version and still you're still so stupid that you don't understand it.

I like to think that despite being  acerbic I've been pretty patient with your nonsense.  Considering that the proof in question has held up to scrutiny for over seventy years.  I've let you talk about how easy something is.  I've put up with your foot-dragging when answering the most simple and trivial of questions.  The only thing I wanted was for you to make your case in a clear an unambiguous manner but when you finally agree to the presuppositions involved with this you didn't even bother to read the post demonstrating the problem and went on to argue something COMPLETELY IRRELEVANT.

Really?  You think I need to question myself more.  That's really what's going through your head?

One coherent thought.
Well the big interface problem here is the C programming. I don't do much programming in C so it takes me a bit to understand it.
I program machine control software and need the easy string control and math so I mainly use Power basic, which lets me incorporate assembly and C into the program and compile to very tight code similar to C.
I understand that when I stated "WillThisEnd(WillThisEnd) = true"  It would have been better to say "Returns True" and not that the functon was set to a ture condition if possible.
I figured you would understand the concept as the function returns true when run on itself which was a problem for two reasons, one of which you didn't know about. Regardless, I corrected that problem.

So now, I understand that your function:
function WillThisEndOnSelf(program) {
     if ( WillThisEnd(program,program) == 'true' )
        while (1);
     else
        return;
}
Is simply designed to never end as long as "WillThisEnd(program,program)" returns true.

So then running:

WillThisEndOnSelf(WillThisEndOnSelf);

Will force a false because it's true the program never ends, and in turn the false will end the program. Which is all very clever but does not change the fact that the original function "WillThisEnd(program) returned the correct results.
Though a false is returned, the program will still end, and is your point. However, the false that was returned was correct because the program never ended. Only the results terminated the program which are conditions after the fact and outside the scope of WillThisEnd(program).
Did the program correctly determine if the program would end?  If it had not, the program would not end.

 





sarkeizen

Quote from: lumen on January 27, 2013, 11:02:38 PM
Will force a false because it's true the program never ends, and in turn the false will end the program.
Again terribly vague statements. "force a false" a false what?  We don't really know what your code will return because, after all it hasn't been written.
Quote
Which is all very clever but does not change the fact that the original function "WillThisEnd(program) returned the correct results.
Not in this case it doesn't. You should pay more attention.  WillThisEnd() was defined to produce 'true' ONLY WHEN THE PROGRAM IT IS FED TERMINATES and 'false' ONLY WHEN THE PROGRAM IT IS FED DOES NOT.

In this case if WillThisEnd says WillThisEndOnSelf terminates.  WillThisEndOnSelf does not terminate.  If WillThisEnd says WillThisEndOnSelf does not terminate, then WillThisEndOnSelf terminates.  Hence WillThisEndOnSelf(WillThisEndOnSelf) can never get a correct answer when it calls WillThisEnd(WillThisEndOnSelf,WillThisEndOnSelf).  Thus, if even one case will cause any implementation of WillThisEnd to fail then no program can be written to cover all cases.  QED.

Concede yet?

(GaiKing added for Bruce_TPU)

lumen

Quote from: sarkeizen on January 27, 2013, 11:27:56 PM
Again terribly vague statements. "force a false" a false what?  We don't really know what your code will return because, after all it hasn't been written.Not in this case it doesn't. You should pay more attention.  WillThisEnd() was defined to produce 'true' ONLY WHEN THE PROGRAM IT IS FED TERMINATES and 'false' ONLY WHEN THE PROGRAM IT IS FED DOES NOT.

In this case if WillThisEnd says WillThisEndOnSelf terminates.  WillThisEndOnSelf does not terminate.  If WillThisEnd says WillThisEndOnSelf does not terminate, then WillThisEndOnSelf terminates.  Hence WillThisEndOnSelf(WillThisEndOnSelf) can never get a correct answer when it calls WillThisEnd(WillThisEndOnSelf,WillThisEndOnSelf).  Thus, if even once case will cause any implementation of WillThisEnd to fail then no program can be written to cover all cases.  QED.

Concede yet?

But again, it's based on what WillThisEnd returns. This is not any different than simply changing the the results of WillThisEnd.

If not (WillThisEnd(program) == true);

This game is to silly, I give up due to WOT.
You can now claim your WOT victory.

sarkeizen

Quote from: lumen on January 27, 2013, 11:53:35 PM
But again, it's based on what WillThisEnd returns.

And in one case WillThisEnd is always, always, always, always wrong.  Must be hard on the ego to see something no engineer or even all engineers or even all engineers past and future can ever fix.
Quote
This is not any different than simply changing the the results of WillThisEnd.

If not (WillThisEnd(program) == true);
You should provide the context for that because it doesn't make any sense just sitting out on it's own.

In any case WillThisEndOnSelf is accepting exactly the output that WillThisEnd sends it.  However WillThisEnd just happens to always be wrong in this case.

(Huckleberry hound is for Bruce_TPU)