Live data from Hacker News

MIT develops new tool that can interrupt infinite loops

bostinnovation.com

51–60 of 72 posts

Re: MIT develops new tool that can interrupt infinite loops

#54

Aren't event loops infinite loops where memory might be unchanged for a long time?

Presumably the user would not activate Jolt in that case. And technically, unless the loop uses polling, it's not an infinite loop because the program isn't even running.

Even an event-driven loop needs to cycle now and then to service timers.

Re: MIT develops new tool that can interrupt infinite loops

#55
my experience from debugging is that breaking out of a loop in this way is very hit and miss - coupling that with my experience of common office software failures being hard crashes rather than hangs and i can't imagine this tool being /that/ useful. I'd much rather have a tool that does autosaving at a very regular interval - I've written many throwaway tools for that in the past mostly when dealing with old versions of excel being abused to solve database/code problems... still this is better than nothing i guess

as for the nature of the halting problem meaning this can't work??? that only displays a lack of understanding...

all in all this article and the comments reinforce my view that academia diverges too far from the practical realities of software development. sure we need academic research and education, i won't deny it, but the noise making should be reserved for after practical success has actually occurred.

Re: MIT develops new tool that can interrupt infinite loops

#56
post #18

Earlier quoted context omitted.

The halting problem: Given a program and an input, determine whether that program, given that input, will ever halt, or if it will loop infinitely. One of the fundamentals of academic computer science is learning that it is mathematically impossible to solve the halting problem - which is why the grandparent comment simply notes "the halting problem" with no further explanation; it's a famous problem. (Don't feel bad…

Thanks for the explanation! No shame here (I didn't study CS in undergrad) but I find it intuitive that a program can't detect an input that would loop indefinitely.

If that's intuitive for you already (great!) consider one step further: Rice's Theorem. Rice's Theorem in layman's term is "all nontrivial properties of a program are undecidable in the general case". "Undecidable" is the difficulty class of the halting problem (there are actually harder problems!).

A couple accessible examples:

1. Constant Propagation - we know that we'll never detect all compile-time constants because of Rice.

2. Exception frequency - I can write a function that has "raise new FooException()" in the code, but the function never raises, and you won't be able to prove it never raises.

Re: MIT develops new tool that can interrupt infinite loops

#57
post #47

Earlier quoted context omitted.

def is_collatz(n): s = set() while n not in (1, 2, 4): if n % 2: n = 3 * n + 1 else: n /= 2 if n in s: # Non-Collatz loop return False s.add(n) return True This is theoretically bounded far below modern memory limits. Feel free to tell me the first natural number for which it returns False. :3

Why would that be bounded far below modern memory limits? Why would that be bounded at all ? Secondly, you're making the logic error A => B implies not A => not B. If state spaces as large as modern memory limits allow are too large, that doesn't imply that state spaces far below modern memory limits are small enough to handle. Thirdly, your program trivially terminates doing nothing.

Troll-feeding time!

Pretend that an OOM condition is the same as a False answer. :3

Here's a program, building on the previous one, which either terminates or doesn't.

  from itertools import count
  for i in count(1):
   if not is_collatz(i):
    break

Re: MIT develops new tool that can interrupt infinite loops

#59

Earlier quoted context omitted.

Noob question time: what's the halting problem?

The halting problem is an profound bit of theoretical CS well-explained on this thread. However, the actual halting problem is moot in most of the references I see to it, as the halting problem is usually misused by the half-educated to make claims that 'nothing useful can ever be inferred about the behavior of any program, ever'. For example, we built a tool to either estimate a reasonable ceiling on the stack usage…

My undergraduate thesis tackled static analysis in Ruby. One of the problems I attacked was "does a given method yield to its block?" I broke methods into a few classes, two of which are "Block-Required" and "Block-Optional."

I had to write software which proved a method optionally yielded, which isn't just undecidable, but unrecognizable. For non-CS folks, that means it's actually harder than the halting problem. Yet my software works on nearly all Ruby code I throw at it - it only really has difficulty on complex delegation patterns. Unsurprisingly, the code people write to create Block-Optional methods is highly structured.

Re: MIT develops new tool that can interrupt infinite loops

#60
post #35

OP looks like a spammer for bostinnovation.com: http://news.ycombinator.org/submitted?id=pgatzke

There's a fuzzy line between spammer & contributor.

I made the comment because Reddit has some bostinnovation.com spammers: http://www.reddit.com/user/joeymullette & http://www.reddit.com/user/chezral

I'm guessing they have employees who just post to social news sites.

Post reply on HN