Prepare a script that deletes one character randomly:
Hmm, but can it also deal with general bit flips? Because that's usually what radiation does not delete characters. The only case it would delete a character with a bit flip on the data would be causing the DEL char 0x7F i think, which 7 ASCII chars have a 1 in 8 chance of mutating into (because we have 8 actual bits but only 7 are used for ASCII): ~}{wo_?
There are 96 ASCII characters that might be used in source code naively assuming equal character probability that's 7/96 * 1/8 = 0.9% chance of a bit flip deleting a character by mutating into 0x7F. There's also a chance of a character mutating into a non-printable character (0-31), only the 2nd and 3rd column of ASCII can mutate into this by ending up with both high bits off, so there are 64/96 chars with a 1/8 chance that's an 8.3% chance of mutating into a non-printable control char etc (i'm ignoring LF because it displaces DEL). If the 8th bit flips into a one on any char then we get extended ASCII I think, that's 96/96 * 1/8 = 12.5% chance. That leaves 78.3% chance of mutating into another regular printable ASCII character. Apologies for any bad math.
There are a lot of possible affects on the interpreter when it sees any of those characters, the control chars could be particularly troublesome.
Possible -- depends on the rules of the specific challenge. Most of the time it's edits, deletes, or some combination. Sometimes the score depends on how many edits your code can withstand.
Ah, I wasn't aware it was the name of a common code golf challenge, I do code golfing myself but apparently not enough :)
I guess it makes sense people would frame the game that way, arbitrary bit flips seems way too hard, I'm not even sure it's possible for a program to cope on it's own.
Physics guy here. Isn't the solution to simply duplicate the code and compare it before execution? Do it 3 times and use the majority. This could be the preamble to any quine. (I realize though that, like most physics people, I enjoy waltzing into a specialized domain that I know nothing about and reduce it to first principles. But hey, it's who I am.)
Yes, triple redundancy is nice, but then the problem becomes how to make the code that checks the code also tipple redundant and checked without creating another layer to deal with.
Most software that does this simply tries to make the test code as small and reliable as possible. But it's an interesting challenge to make the test code somehow self checking with the same properties.
Well, physically, you really need three independent machines. Which means three copies of the file, three processes, three verifications, and so on, and a way for those processes to communicate with each other and "vote". Then you run into the problem of definition - is a cluster a quine? Note that most of the "primordial bit flip" problems go away if you make N >> 3 and design each machine to "fail fast".
Isn't the solution to simply duplicate the code and compare it before execution? Do it 3 times and use the majority
Yes, voting is a common way to deal with radiation or critical software. There are of course also complications about the voting software itself needing to also be redundant. Some can be done with hardware, or you can just radiation harden parts of the system (reducing overall cost).
This is definitely one of those problems where at a quick glance it seems like there's a few simple solutions that can resolve 90% of issues but when you dig into the weeds you find out that 20% dictates most of the outcomes and there's at most a 10% overlap with your quick/obvious solutions.
Hardware radiation hardening techniques have existed for a long time, and are applied commonly in space, satellites, nuclear power, military.
Roughly speaking it breaks down into a couple categories including the manufacturing of electronics and chips themselves, including everything from substrate differences to using entirely different types of RAM and block storage [0], to the higher level strategies employed by many generations of space probes where a variety of total system redundancy is employed, e.g the Voyager probes used discrete component level redundancy, and most modern probes use almost full system redundancy where they run 3 complete computers in lock step, the idea being that triple redundancy is the minimum needed to detect which computer is wrong.
Another potential strategy not so commonly applied for this purpose is software resilience, such as the techniques applied by the Minix3 microkernel, the idea being to minimise the critical kernel code to be so small that it's unlikely to have bugs or be affected by hardware level affects, then everything else underneath can be kept alive by the kernel, even block device drivers, by employing triple redundancy and a "resurrection server". This was intended to protect against bugs in critical software like device drivers and hardware/firmware bugs rather than radiation, but it could be similarly effective especially as a layered strategy.
Comments
Hmm, but can it also deal with general bit flips? Because that's usually what radiation does not delete characters. The only case it would delete a character with a bit flip on the data would be causing the DEL char 0x7F i think, which 7 ASCII chars have a 1 in 8 chance of mutating into (because we have 8 actual bits but only 7 are used for ASCII): ~}{wo_?
There are 96 ASCII characters that might be used in source code naively assuming equal character probability that's 7/96 * 1/8 = 0.9% chance of a bit flip deleting a character by mutating into 0x7F. There's also a chance of a character mutating into a non-printable character (0-31), only the 2nd and 3rd column of ASCII can mutate into this by ending up with both high bits off, so there are 64/96 chars with a 1/8 chance that's an 8.3% chance of mutating into a non-printable control char etc (i'm ignoring LF because it displaces DEL). If the 8th bit flips into a one on any char then we get extended ASCII I think, that's 96/96 * 1/8 = 12.5% chance. That leaves 78.3% chance of mutating into another regular printable ASCII character. Apologies for any bad math.
There are a lot of possible affects on the interpreter when it sees any of those characters, the control chars could be particularly troublesome.
Either way this is still a very cool quine :P
What you're describing just isn't what this game called "radiation hardening" is. It would be a different, also interesting game.
But "radiation hardening" challenges are common in code golf, and always (from challenges I've seen) framed in terms of character mutation.
Also I suspect some unconscious bias based on your username :P
So by "character mutation" you mean the deletion of characters? Because to my ears that term still sounds like bit flips, i.e. changing characters.
https://codegolf.stackexchange.com/questions/tagged/radiatio...
What if my random edit is to add a character?
Possible -- depends on the rules of the specific challenge. Most of the time it's edits, deletes, or some combination. Sometimes the score depends on how many edits your code can withstand.
Ah, I wasn't aware it was the name of a common code golf challenge, I do code golfing myself but apparently not enough :)
I guess it makes sense people would frame the game that way, arbitrary bit flips seems way too hard, I'm not even sure it's possible for a program to cope on it's own.
To be fair, "radiation" suggests only bit flips.
Physics guy here. Isn't the solution to simply duplicate the code and compare it before execution? Do it 3 times and use the majority. This could be the preamble to any quine. (I realize though that, like most physics people, I enjoy waltzing into a specialized domain that I know nothing about and reduce it to first principles. But hey, it's who I am.)
Someone said similar elsewhere, but the problem is the "meta code" that does the comparison needs to be hardened as well.
Yes, triple redundancy is nice, but then the problem becomes how to make the code that checks the code also tipple redundant and checked without creating another layer to deal with.
Most software that does this simply tries to make the test code as small and reliable as possible. But it's an interesting challenge to make the test code somehow self checking with the same properties.
Well, physically, you really need three independent machines. Which means three copies of the file, three processes, three verifications, and so on, and a way for those processes to communicate with each other and "vote". Then you run into the problem of definition - is a cluster a quine? Note that most of the "primordial bit flip" problems go away if you make N >> 3 and design each machine to "fail fast".
Yes, voting is a common way to deal with radiation or critical software. There are of course also complications about the voting software itself needing to also be redundant. Some can be done with hardware, or you can just radiation harden parts of the system (reducing overall cost).
This is definitely one of those problems where at a quick glance it seems like there's a few simple solutions that can resolve 90% of issues but when you dig into the weeds you find out that 20% dictates most of the outcomes and there's at most a 10% overlap with your quick/obvious solutions.
It adds weight but why not put all the computing hardware in one spot and build a lead or water shield around it?
Hardware radiation hardening techniques have existed for a long time, and are applied commonly in space, satellites, nuclear power, military.
Roughly speaking it breaks down into a couple categories including the manufacturing of electronics and chips themselves, including everything from substrate differences to using entirely different types of RAM and block storage [0], to the higher level strategies employed by many generations of space probes where a variety of total system redundancy is employed, e.g the Voyager probes used discrete component level redundancy, and most modern probes use almost full system redundancy where they run 3 complete computers in lock step, the idea being that triple redundancy is the minimum needed to detect which computer is wrong.
Another potential strategy not so commonly applied for this purpose is software resilience, such as the techniques applied by the Minix3 microkernel, the idea being to minimise the critical kernel code to be so small that it's unlikely to have bugs or be affected by hardware level affects, then everything else underneath can be kept alive by the kernel, even block device drivers, by employing triple redundancy and a "resurrection server". This was intended to protect against bugs in critical software like device drivers and hardware/firmware bugs rather than radiation, but it could be similarly effective especially as a layered strategy.
[0] https://en.wikipedia.org/wiki/Radiation_hardening#Radiation-...
That's part of the strategy for Europa Clipper.
https://europa.nasa.gov/resources/210/complete-europa-clippe... https://europa.nasa.gov/resources/342/electronics-vault/
Try doing that in space
Doing what?