Live data from Hacker News

Ask HN: What's your favorite elegant/beautiful algorithm?

news.ycombinator.com

251–260 of 507 posts

Re: Ask HN: What's your favorite elegant/beautiful algorithm?

#251

Duff's device. Because you will first look at it in disgust, but then you realize how clever it really is. See: https://en.wikipedia.org/wiki/Duff%27s_device

Quite a few EA Sports games have Duff's Device in locations of computational bottlenecks. I know because I put them there. Wonderful little mechanism.

Is there ever a case nowadays where the compiler doesn't do this for you automatically?

Re: Ask HN: What's your favorite elegant/beautiful algorithm?

#252

Duff's device. Because you will first look at it in disgust, but then you realize how clever it really is. See: https://en.wikipedia.org/wiki/Duff%27s_device

The first time I saw that thing I just thought "That just can't be valid C syntax". It's quite an amazing hack that seems ugly at first but seems more and more elegant the more you think about it.

These days compilers usually do loop unrolling on their own, so the device has mostly lost its purpose, but it can apparently also be used to implement something similar to coroutines in C, which is nice.

Re: Ask HN: What's your favorite elegant/beautiful algorithm?

#253
You may also find the YouTube channel PapersWeLove interesting [0]. I particularly recommend Casey Muratori's episode, where he talks about marching cubes, quaternions, and a fast way of computing the distance between complex objects in 3D [1].

[0]https://www.youtube.com/user/PapersWeLove/videos

[1]https://youtu.be/SDS5gLSiLg0

Re: Ask HN: What's your favorite elegant/beautiful algorithm?

#255
Two phase commit, for example to guarantee once and only once message delivery in MQTT. I like how far you can get with such a simple protocol:

    A to B: send message (repeat  until ack)
    B to A: ack (resend if a repeat of message is received)
    A to B: commit message (repeat until commit ack)
    B to A: commit ack (resend if a repeat is received, but commit only once)

Re: Ask HN: What's your favorite elegant/beautiful algorithm?

#258
Priority encoder based on bit-twiddling: A&(-A) isolates least significant set bit of A. Allows you to make fast round-robin arbiters in FPGAs by taking advantage of the dedicated carry chain.

Also the compress and extract algorithms from Hacker's Delight.

Re: Ask HN: What's your favorite elegant/beautiful algorithm?

#259
post #37

Not exactly an algorithm, but I like recursion as a pattern to be just insane to even think about. You can build an entire working structure from base operations, exit conditions and logic that scale to higher states of the operations. Extending the same, TCO is another very elegant concept in CS.

Same feeling here about recursion. I find it really cool that some algorithms can be described quite concisely and often simply, using recursion, sometimes more so than iterative or non-recursive algorithms for the same problem.

The same goes for some data structures, a simple example being a list, as often defined in functional programming languages. E.g.:

A list is either:

- empty, i.e. []

- a head (an element) followed by a tail (which is also a list), i.e. h | t

Lists of any size fit that definition because of the recursive definition.

Similar for binary tree, being either just a node, or a node with left and right child, each of which is a binary tree.

Re: Ask HN: What's your favorite elegant/beautiful algorithm?

#260
post #241

Earlier quoted context omitted.

Without looking much further into it, I can't imagine it going very wrong. My intuition says that the density function will be bounded, since you're working with a finite number of points, therefore you'll always be able to climb to a local maximum.

The problem I see is the word "near" in "climb to nearest peak" . To quote the curse of dimensionality wiki page: > The common theme of these problems is that when the dimensionality increases, the volume of the space increases so fast that the available data become sparse. This sparsity is problematic for any method that requires statistical significance. https://en.wikipedia.org/wiki/Curse_of_dimensionality

Are you concerned that in a very high dimensional space you'd need an absurd number of points in order to produce a meaninful KDE, since otherwise the points will be too sparse? If so I think I'm with you... you'll probably just end up with a very large number of small, weak clusters.

Although I wonder if you can't account for that by simply increasing the kernel bandwidth. Perhaps not. Perhaps this is why mean-shift seems to be mostly used for computer vision and image processing, where (I guess?) the number of dimensions is low.

Post reply on HN