Live data from Hacker News

In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

mux.com

11–20 of 66 posts

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#11
post #7
post #4

The article's leap year rules seem wrong. Pretty sure year 2000 did have a leap day, but 1900 didn't.

Yep. The algorithm is: there is a leap day for every year divisible by 4, unless the year is also divisible by 100. But if the year is divisible by 400, then there is a still leap day.

Oh shit, it’s FizzBuzz!

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#12
The reason you don't see flicks used all that much is because media encoding is incredibly proprietary in the space where it matters most, live broadcast. Selling into the broadcast space, every broadcaster has petabytes of video in their own chosen format. You have to support EVERY format to sell broadly, and they're not going to let you transcode everything into your format. Using flicks gives you the ability to support as many combinations as possible with the least effort.

It matters very little when users are trained to tolerate slow transitions between videos, formats, etc...

It also doesn't matter a whole lot when doing offline transcoding either, as you can afford to do the more expensive calculation.

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#14
> That is 367.5 times more audio samples than video frames.

Okay, but an audio sample is not comparable to a frame of video, which by itself means something to the viewer. (But, on the other hand which probably doesn't differ much from the previous or next one, especially at 120 Hz).

An audio sample is sort of more comparable to a pixel.

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#15
> The number result is 0.008333333333 with the 3 repeating forever. For a computer to store a number that repeats forever would require an infinite amount of memory

This is very much not true, as I'm sure other HN readers will notice. The number is rational (it's equivalent to 1/120). Now, it is true that a floating point number may not be able to represent it exactly, but by no means does this number require "infinite memory." In fact I have represented the number exactly in this comment, which does not take up infinite space.

For irrational numbers, sure, they cannot be exactly represented. But there are no irrationals involved in this article.

I got hung up at this point in the article, so I haven't finished it yet, but it looks like the author goes on to argue that because numbers like the above cannot be represented in computer memory at all, errors will always accumulate in representations of audio/video. This makes me question whether the author understands the problem they are writing about.

Edit: the author does in fact state that rational numbers can be represented by a numerator and a denominator. The article is actually about errors the accumulate during floating point operations. It ends up making a decent argument despite false claims about representing numbers in memory.

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#16
post #15

> The number result is 0.008333333333 with the 3 repeating forever. For a computer to store a number that repeats forever would require an infinite amount of memory This is very much not true, as I'm sure other HN readers will notice. The number is rational (it's equivalent to 1/120). Now, it is true that a floating point number may not be able to represent it exactly, but by no means does this number require "infini…

Thanks for the comment. For the record, I am very aware of iee 754, And I am aware that some numbers that have infinite repetition in decimal can have an exact representation. I actually thought about pointing that out. However I decided that it didn't add much to the post. It was written for more of a general audience and diving into those details, while would make the post more technically correct, would not actually add any value for the average reader.

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#17

> That is 367.5 times more audio samples than video frames. Okay, but an audio sample is not comparable to a frame of video, which by itself means something to the viewer. (But, on the other hand which probably doesn't differ much from the previous or next one, especially at 120 Hz). An audio sample is sort of more comparable to a pixel.

Its comparing 1 dimensional space to 2 demential space. So, any comparison is gong to be a little hand wavy. But temporally, I believe the comparison is apt.

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#18
post #15

> The number result is 0.008333333333 with the 3 repeating forever. For a computer to store a number that repeats forever would require an infinite amount of memory This is very much not true, as I'm sure other HN readers will notice. The number is rational (it's equivalent to 1/120). Now, it is true that a floating point number may not be able to represent it exactly, but by no means does this number require "infini…

Thanks for the comment. For the record, I am very aware of iee 754, And I am aware that some numbers that have infinite repetition in decimal can have an exact representation. I actually thought about pointing that out. However I decided that it didn't add much to the post. It was written for more of a general audience and diving into those details, while would make the post more technically correct, would not actual…

The issues of "repeating decimal" and exact representation as a floating point number are orthogonal. Because the mantissa in a floating point number (which is fixed width) is in base 2, only fractions with denominators that are powers of two can be exactly represented. This means that simple base-10 decimals like 0.1 cannot be exactly represented by a float. For this reason it's at least a bit misleading to talk about how some numbers cannot be represented with finite memory, and then go straight into a demonstration of how they can in fact be represented in finite memory (as a fraction).

As for the comment about a general audience, if (some of) your target audience is HN readers, I think it's reasonable to expect many readers to be familiar with computer science.

If this were my article, I would replace the paragraph in question with a discussion of the error introduced in floating point calculation — consider perhaps that many programming languages will tell you 0.1 + 0.2 = 0.30000000000000004 [0].

[0]: https://0.30000000000000004.com/

Re: In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

#20
post #15

> The number result is 0.008333333333 with the 3 repeating forever. For a computer to store a number that repeats forever would require an infinite amount of memory This is very much not true, as I'm sure other HN readers will notice. The number is rational (it's equivalent to 1/120). Now, it is true that a floating point number may not be able to represent it exactly, but by no means does this number require "infini…

Thanks for the comment. For the record, I am very aware of iee 754, And I am aware that some numbers that have infinite repetition in decimal can have an exact representation. I actually thought about pointing that out. However I decided that it didn't add much to the post. It was written for more of a general audience and diving into those details, while would make the post more technically correct, would not actual…

I don't want to come off as combative, but I would argue that a correction would add quite a bit to the post. What you have is straight-up incorrect and wouldn't even take that much effort to fix. "For a computer to store the decimal representation a number that repeats forever would require an infinite amount of memory, so the number is approximated" would be correct and it's just a couple words more.
Post reply on HN