In defense of 'flicks' (or how I learned to stop worrying and love 705600000)
mux.com
mux.com
using flicks = std::chrono::duration<std::chrono::nanoseconds::rep, std::ratio<1, 705600000>>;1 flick = 1/705600000 second
This unit of time is the smallest time unit which is LARGER than a nanosecond, and can in integer quantities exactly represent a single frame duration for 24 Hz, 25 Hz, 30 Hz, 48 Hz, 50 Hz, 60 Hz, 90 Hz, 100 Hz, 120 Hz, and also 1/1000 divisions of each, as well as a single sample duration for 8 kHz, 16 kHz, 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, and 192kHz, as well as the NTSC frame durations for 24 (1000/1001) Hz, 30 * (1000/1001) Hz, 60 * (1000/1001) Hz, and 120 * (1000/1001) Hz.*
That above was one hell of a run-on sentence, but it's strictly and completely correct in its description of the unit.
This makes flicks suitable for use via std::chrono::duration and std::ratio for doing timing work against the system high resolution clock, which is in nanoseconds, but doesn't get slightly out of sync when doing common frame rates."
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.
It's also necessary for clip switching. If you want frame accurate clip switching (i.e. show->ad->ad->show) you need consistent and precise pointers into your files.
"Audio recorded at 44100khz" should be 44.100 kHz or 44100 Hz.
"there was no leap day in the year 2000" - false. 2000 is divisible by both 400 and 100, so it was a leap year.
OK
> and 100
We'd be in real trouble if not!
Tell that to the management over at Microsoft. [1]
[1] https://docs.microsoft.com/en-us/office/troubleshoot/excel/w...
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.
Although I love the coinage "2 demential space", I think you mean "comparing one-dimensional space [audio] to three-dimensional space [video]". A two-dimensional signal might be a still image or a temporal sequence of samples from a one-dimensional array of sensors, such as those in a single slice of a CT machine or a linear MIMO antenna array. A video signal is three-dimensional, not two-dimensional, and probably not "2 demential" either.
The article has it backwards. Years divisible by 400 get leap days, others divisible by 100 do not.
I wrote a friendlier abstraction over top Boost DateTime in C++ at a previous employer. Adding things like cross platform support of using the Olson database for historical timezone info, a friendlier interface (more akin to Python's datetime lib, which is probably the friendliest datetime lib Ive used across any language) and cross platform strptime. So, didn't do the heavy lifting myself, but rather supplied the timezone info.
There were so many subtle details. Like, what does it mean to add 1 day to a timestamp? Do you increment year/month/day as needed to be the next day? Or do you add 24 hours? This matters because if you increment the date only, you can end up with an invalid or ambiguous time. I also appreciate the author mentioning how many hours are there in a day. 23, 24 and 25 are most common for jurisdictions observing daylight saving time, but arbitrary shifts are possible. It depends on the jurisdiction. Take the US for example. It depends not just on the state, but sometimes even the county within a state. Some states dont observe DST (Arizona and Hawaii, maybe others). Parts of Indiana do, some don't (maybe this has changed).
Compound this with changes to when DST starts/ends. Its entirely political and can change on a whim. I know there are clocks that are still wrong 12 years later for 6 weeks of the year because of the 2007 US DST change, because of embedded rules for when to change.
Sorry for the rant. Spent over 18 months on that project, and I know there are bugs in there nobody bothered to fix after I left that company (fractional seconds handling in strptime I ported from NetBSD, I'm looking at you).
Someone should make a date/time "meta library" which iterates through all possible system time values while calling each extant language's date/time method at each iteration.
Then report the system time values for which there are discrepancies in the output.
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.
The point about using infinite memory to store an irrational number is just a rhetorical device / presentation style to keep the novice reader engaged, and following along. And then you say, "Next we will explain how to solve this impossibility...," and such.
It's a good technique for writing, and presenting, but doesn't work if your audience already knows where you're going and gets impatient with you!
The author does not present this conflict as "it may seem impossible…" but rather as "is is impossible." That's an inaccuracy, not a writing technique.
I did so with mine and I concluded it did not. Perhaps you will conclude differently. Perhaps the same. In either case, I think you will find it worthwhile.
Also, the 'decimal' part of your comment is not needed, number base is irrelevant here.
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].
You can represent pi:
4*atan(1)
log(1)
I think you meant exp(1).
Talk about splitting hairs.
This is clearly a literary technique to create interest. Like saying something like "I told you a billion times not to exaggerate". It should be clear to most readers that this is not an attempted mathematically precise comment.