Entropy
andrew-hoyer.com
Entropy
1–10 of 32 posts
Re: Entropy
#2It would be interesting to write a program that is going to work properly by using only such "decaying" variables.
There are actually applications for such programs - software replacement for ECC memory.
Re: Entropy
#3I love this idea, it's quite interesting. On the flip side, I made a change in some software at my work the other day to replace the use of a random in a unit test. The use of random was being used to populate some data. This language would make matters incredibly difficult to recreate bugs and even test software
Re: Entropy
#4What is interesting about this is how it forces one to deal with a lack of precision. Computers are inherently imprecise in many situations, leading to non-commutative multiplication. I wonder if a language like this would be helpful for programming with approximate processors. They are supposed to be much faster at a cost of precision.
Re: Entropy
#5Reminds me of Netflix's "Chaos Monkey". Both Entropy and the Chaos Monkey force you to deal with failure as an eventual certainty, not something to ignore and hope it doesn't happen.
Re: Entropy
#6[deleted]
Re: Entropy
#7I see an evil DRM for games, you buy a game and textures will decay over time until you buy the game again to reset the decay.
Re: Entropy
#8[deleted]
Re: Entropy
#9What is interesting about this is how it forces one to deal with a lack of precision. Computers are inherently imprecise in many situations, leading to non-commutative multiplication. I wonder if a language like this would be helpful for programming with approximate processors. They are supposed to be much faster at a cost of precision.
Pedantic aside: I guess you mean non-associative multiplication? That is, ax(bxc) versus (axb)xc. Since rounding happens at different times, they can give different results. Floating point multiplication is indeed non-commutative as well, but that has to do with NaN handling, not imprecision.
Re: Entropy
#10What is interesting about this is how it forces one to deal with a lack of precision. Computers are inherently imprecise in many situations, leading to non-commutative multiplication. I wonder if a language like this would be helpful for programming with approximate processors. They are supposed to be much faster at a cost of precision.
Pedantic aside: I guess you mean non-associative multiplication? That is, ax(bxc) versus (axb)xc. Since rounding happens at different times, they can give different results. Floating point multiplication is indeed non-commutative as well, but that has to do with NaN handling, not imprecision.
Yes, good catch! I did indeed mean non-associative multiplication based on the timing of the rounding.