OPM Hack
-
Thirty days is not likely enough time to correct a decade-plus of neglect of antiquated systems, poor leadership, and spotty attempts at modernization.
Somebody at Ars deserves a Masterful Command of Understatement
.
-
The Halting Problem is strongly unsolvable; merely assuming that it is solvable — plus some trivially true stuff that you could code up in a minute or two — leads to a nonsensical conclusion such as a program that halts exactly when it doesn't halt. Which is completely mad, and proof that the assumption must not hold.
-
-
@ben_lubar said:
I don't think old COBOL is irreplaceable
That is because you ...think of Go as a viable option ...
... Archive format conversion is likely to be the one that falls out of scope first,....
How does Go feel about Zoned-packed decimal?
-
The most you can do is determine if halting conditions are reachable.
But in order to determine if it halts on an input, it invariably relies on executing the code, or a simplification of the code.
And since you can't say, it hasn't halted as of 1 million years later, and so it won't halt, because the program could be designed to halt 2 million years later, you can't say it won't halt.
Say there is a program that halts if its call to create a random float value ends up producing exactly 4.6821. Can you determine, without executing it, that it will one day produce that value given any seed.
-
I couldn't find anything on zoned-packed, but here's a decoder for zoned decimals and packed decimals. No error checking, but what do you expect from 10 minutes of research and 3 minutes of work?
-
How does Go feel about Zoned-packed decimal?
Done it in Python to deal with some Visa thing (IIRC) -- once you figure out the pattern, it's just a matter of a bit of lookup table work. Mildly annoying if you ask me, but easy enough to encapsulate into a library of some flavor.
-
...here's a decoder for zoned decimals and packed decimals. No error checking, ....
@ijij said:
How does Go feel about Zoned-packed decimal?
Done it in Python to deal with some Visa thing (IIRC) --
Well OK then. Now I'm perfectly comfortable
with all financial institutions migrating away from COBOLburying my wealth as copper coins in the back yard.TIL
-
See also: viable energy generation from terrestrial nuclear fusion.
Well, one could argue that we had the Manhattan Project for fission.
We don't have a project of similar scope for fusion.
-
-
We do, we just pay them in peanuts and defective hohlraums.
-
The most you can do is determine if halting conditions are reachable.
If a program has a provably finite state space, i.e., it's mappable to a finite state automaton, you can determine exactly if it will terminate. It might take a lot of work (in fact, it probably does, and the analysis system will probably require a lot of storage in the process) but it's quite possible.
Once you have non-bounded state, that technique doesn't work. There are tricks to compact a non-bounded state into a bounded one (e.g., computing the Galois connection) but they lose information and can easily lead to an answer of “I can't tell” even where they theoretically ought to be able to.
-
I thought the halting problem was generating a way to solve any program given any input.
The wikipedia goes into detail that if you know the program, you can generate a way to determine if that one program halts.
I'm hypothesizing that you can create a program that always determines if halting conditions are reachable, and that's about it.
And you're saying you can generate a way to determine if any mappable program halts.
-
I'm hypothesizing that you can create a program that always determines if halting conditions are reachable, and that's about it.
You're hypothesising you can use a computer to solve a problem that has been proven to be uncomputable?
-
Reachable halting condition, and does or does not halt, is not the same problem.
For one, reachable halting condition is independent of input to the program.
Does or does not halt, is determined by the inputs of the program and the input to the program.IsHaltingConditionReachable(program)
DoesHalt(program, inputToProgram)
-
The wikipedia goes into detail that if you know the program, you can generate a way to determine if that one program halts.
Not really, or not in general with less effort than just running the program. It's possible to create a program that searches for a proof of some currently unproven mathematical conjecture such that a proof of termination is a proof of the conjecture. (Or it's converse. Whatever.) For example, imagine using an arbitrary precision arithmetic library to conduct a search for a contradiction of Goldbach's Conjecture; you'll be searching a long time, yet it'll be trivial to show that if the conjecture is false then it does terminate (it's not complicated programming).
Termination proofs can get evil even without resorting to the vicious nastiness of the Halting Problem.
-
It's much easier to just run the program.
Of course, there are programs that are meant to not halt, unless a bad condition occurs. So there's that.
But other than those, a program that doesn't halt in sufficient time, is not all that useful.
But it gets worse when you consider that some programs can alter their code in memory.
-
Of course, there are programs that are meant to not halt, unless a bad condition occurs. So there's that.
With those, you prove that they return infinitely often to a particular state, e.g., “accept another incoming message”. They can often be divided into the communicate part (nasty external-world stuff, but not algorithmically complex) and the computational part (which you want to terminate in the standard way so that yuo can send the response and go back to waiting). I can't remember the formal name for this type of system right now, but it's a trivial extension of the basic challenge.
Unless you're doing something evil. Then you need the big proof guns.
Halting problem - Wikipedia
Go Playground - The Go Programming Language
