Get a Life | Hacker News Reader

Get a Life

crypto.stanford.edu

176 pointsakkartik21 comments

Oh, excellent timing! I've got a question for Ben Lynn, who will hopefully show up here to answer questions.

I'm in the early stages of porting my decade old Flash Wireworld player ( http://rezmason.net/wireworld ) to HTML5 ( http://rezmason.github.io/wireworld-player ), and I was planning on finally tackling a HashLife based implementation down the road.

May I use or adapt your Wireworld HashLife implementation for my project? Also, can I brainstorm with you the likely characteristics of other types of optimizations?

Here's one by me at exactly the opposite end of the performance spectrum:

https://latedev.wordpress.com/2011/06/25/a-poker-chip-comput...

The lambda calculus section of this site helped me so much in my Language Theory course last semester. I highly recommend a look through if you're interested in the basic of computation and types.

https://crypto.stanford.edu/~blynn/lambda/

A more descriptive title would help

The title is part of the charm here, no?

Charm, yes. But it's very non-functional.

We're all here to get news and discuss them. A title gives an indication about whether reading the article is of interest to me so that I can decide whether to read it. Some clever word play may be funny but it goes totally against its purpose.

Imagine all titles at Hacker News being like that. We could just replace them with "Article 1", "Article 2" etc. which would be terrible but would not lose any further information.

Agreed. At first I thought it was about work-life balance (!).

This is true. I still haven’t clicked on it nor do I know what it’s about based on the comments. Would alt-text descriptions of submissions be useful to add?

Yeah I guess that’s what subtitles are for after all.

Article is a Haskell implementation of Gosper's Hashlife algorithm for computing the nth iteration of Conway's Game of Life in O(log(n)) time.

Have you discussed this with Bill Gosper?

this reminds me of the drama around when Bitcoin forked into BTC and BCH - I recall there was some optimization that allowed miners to land at digests equivalent to some huge hash rate without actually computing that many hashes and since it was baked into ASICs that would be rendered useless after the optimization was nullified they had no choice but hard fork.

I think you're talking about ASICBOOST, more importantly the "Covert ASICBOOST" drama, which was almost entirely fabricated as a political ploy to turn the /r/bitcoin community against the mining community. It was used to justify the soft fork inclusion of SegWit (Segregated Witness) but in reality had zero impact on the actual ASICBOOST capability, which was an overly complicated and incredibly mild hashing optimization which no one really actually used. The risk of orphaning blocks was likely higher than and potential profits from the extra advantage.

oh nice I couldn't find any details earlier but googling "asicboost" turned up the whole scandal - I had no idea it was all disinformation campaign!

This doesn’t seem to solve in linear time.

This doesn’t seem to be linear time for exponential changes. It’s much slower.

Reply on news.ycombinator.com