Entropy • Hacker News Board

Re: Entropy

#11

Post by bmh100 » Sun, Aug 17, 2014, 8:08 PM UTC

laluser wrote: post #3

I 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

The situation you are suggesting might require dumps of as much state as can be measured and a method for recreating the state of the application from that dump. That might be a very large set of data if every variable can be altered. Even execution paths and past variable values would need to be measured over time.

Re: Entropy

#12

Post by logician76 » Sun, Aug 17, 2014, 8:47 PM UTC

bmh100 wrote: post #4

What 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.

Computers are inherently imprecise? Floating point is imprecise, yeah lets generalize that to the entire computer..

Re: Entropy

#13

Post by 0x0 » Sun, Aug 17, 2014, 8:51 PM UTC

ingenter wrote: post #2

It 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.

Until the bits flip in your code instead of your data :)

Re: Entropy

#14

Post by cm127 » Sun, Aug 17, 2014, 8:53 PM UTC

Seems like a Monte Carlo simulation for adding noise to any Javascript variable. It'd be cool if you could apply filters to the noises.

Re: Entropy

#15

Post by bodski » Sun, Aug 17, 2014, 9:19 PM UTC

Wow, this is really appropriate for the day I've had today. Repeatedly failing to get a brand new install of Bitcoin Core to index and sync with the blockchain. I finally dusted off my Memtest86 and voila, bad RAM stick!

I suppose crypto would fare pretty badly inside this language, or has anyone thought about this kind of thing?

Re: Entropy

#16

Post by ams6110 » Sun, Aug 17, 2014, 9:25 PM UTC

michael_nielsen wrote: post #5

Reminds 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.

AFAIK Chaos Monkey inserts random but non-permanent failures into the system, not really entropy. Entropy would be the gradual loss of their movie data, something I'm sure they work quite hard to prevent.

Re: Entropy

#17

Post by mbq » Sun, Aug 17, 2014, 9:26 PM UTC

logician76 wrote: post #12

bmh100 wrote: post #4

What 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.

Computers are inherently imprecise? Floating point is imprecise, yeah lets generalize that to the entire computer..

Float operations are actually precise, the catch is that floats are not real real numbers.

Re: Entropy

#18

Post by jfoutz » Sun, Aug 17, 2014, 9:27 PM UTC

maikklein wrote: post #7

I 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.

Back in the day, AutoCAD did that with point coordinates. No dongle, each save got progressively worse.

Re: Entropy

#19

Post by rossng » Sun, Aug 17, 2014, 10:33 PM UTC

maikklein wrote: post #7

I 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.

The original Operation Flashpoint game did almost exactly that: https://en.m.wikipedia.org/wiki/FADE

Re: Entropy

#20

Post by moyix » Mon, Aug 18, 2014, 12:29 AM UTC

bodski wrote: post #15

Wow, this is really appropriate for the day I've had today. Repeatedly failing to get a brand new install of Bitcoin Core to index and sync with the blockchain. I finally dusted off my Memtest86 and voila, bad RAM stick! I suppose crypto would fare pretty badly inside this language, or has anyone thought about this kind of thing?

Well, Shannon & Moore showed [1] that you can make arbitrarily reliable circuits out of unreliable relays, so I expect you could find a redundant enough encoding for any program that would allow it to operate at high precision, even in this language. It would almost certainly be larger and slower than a more accurate equivalent though!

[1] http://mriedel.ece.umn.edu/wiki/images/3/30/Moore_Shannon_Re...