Re:Hard work and specialising early is not always a recipe f...
by eric234223 on Sunday March 15, 2020 @05:27AM
(#22582367)
The example problem is unclear. Could you please describe more on it. Which DSP algorithm falls under the Halting Problem and is there any database or general programming related problem that falls under "Halting Problem" ?
Re:Hard work and specialising early is not always a recipe f...
by pyentropy on Sunday March 15, 2020 @07:36AM
(#22582867)
Suppose your company is developing a framework for creating mobile apps. You work on optimizing the GUI renderer and you are assigned a task to make a module which finds computationally equivalent render functions (or a company making a programming assignment plagiarism system, or a duplicate config file detector when the config language is accidentally Turing-Complete).
You may try removing whitespace, finding invariants, ordering the variables by type, converting for loops to while, tail call optimization, but your collegue always has a trick to make equivalent functions undetectable by your module. You were solving the halting problem. Instead, you should use CS knowledge and tell them it's impossible but they can have a non-optimal search. Perhaps, the fastest way to complete the task would be to score similarities between the functions' machine code or AST.
> In what context?
The problem is that they don't recognize it as the "Halting Problem". It will be something like "Well, we can scan this thing to see if it does X or Y." No, actually you can't because "Doesn't terminate" is also an option. Oops. That's the Halting Problem.
In digital design, non-causal logic is a similar pitfall. Offline DSP algorithms can look backward and forward in time. If, however, you try to apply such a forward looking algorithm to a real-time system that needs an answer on the same time as the current sample, you wind up accidentally creating non-causal logic and wondering why your algorithm isn't working.