Its always amazing to realize how big 2^64 really is. 2^32 Flicks is about 6 seconds (which can be enough, but still not that useful), but 2^64 is over 800 years, which should be quite enough for anything needing this sort of precision. It would be actually pretty nifty to have this in eg. `struct timespec` and overall base rtc around Flicks
Flicks – A unit of time defined in C++
21–30 of 55 posts
Re: Flicks – A unit of time defined in C++
#22I'm not sure I understand this: "The NTSC variations (~29.97, etc) are actually defined as 24 * 1000/1001 and 30 * 1000/1001, which are impossible to represent exactly in a way where 1 second is exact, so we don't bother - they'll be inexact in any circumstance." The NTSC color subcarrier is exactly 315/88 MHz, so one could make the flick something like 1/528th of this period. The frame is related to the subcarrier b…
The problem is that NTSC isn't 30Hz, it's 29.97Hz (or exactly 30/1.001Hz). This was due to some technical issues when introducing colour transmission, see https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate
Re: Flicks – A unit of time defined in C++
#23Earlier quoted context omitted.
You can if you want to try and plaster your name all over VR as a facet of soft lock-in and to arbitrarily insert yourself into every potential aspect of a fledgling industry. Next they'll invent the 'Ocu-ternion', which is the same as a normal Quaternion but each scalar value is divided by a constant because...VR? Facebook? Who cares, the point is they own it.
> Who cares, the point is they own it. The header file they provided is BSD licensed. You can use it freely, forever, for anything you want.
Which is fair, but I still have a problem with the sheer temerity of licensing a unit of measurement.
Re: Flicks – A unit of time defined in C++
#24Can you "invent" a definition?
Most freshman undergraduate mathematicians have had their fair share debating whether you "invent" or "discover" definitions and proofs. The general consensus is that you "discover" things that are very natural, and you "invent" things for which different mathematicians would have perhaps come up different ideas. But only one thing is shared between both sides of the debate: the distinction really doesn't matter and is definitely bikeshedding.
Re: Flicks – A unit of time defined in C++
#25I'm not sure I understand this: "The NTSC variations (~29.97, etc) are actually defined as 24 * 1000/1001 and 30 * 1000/1001, which are impossible to represent exactly in a way where 1 second is exact, so we don't bother - they'll be inexact in any circumstance." The NTSC color subcarrier is exactly 315/88 MHz, so one could make the flick something like 1/528th of this period. The frame is related to the subcarrier b…
The problem is that NTSC isn't 30Hz, it's 29.97Hz (or exactly 30/1.001Hz). This was due to some technical issues when introducing colour transmission, see https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate
I don't think you understand the comment you are replying to.
Re: Flicks – A unit of time defined in C++
#26I'm not sure I understand this: "The NTSC variations (~29.97, etc) are actually defined as 24 * 1000/1001 and 30 * 1000/1001, which are impossible to represent exactly in a way where 1 second is exact, so we don't bother - they'll be inexact in any circumstance." The NTSC color subcarrier is exactly 315/88 MHz, so one could make the flick something like 1/528th of this period. The frame is related to the subcarrier b…
I agree with your line of thinking, but since they give 1/30 fps frame as 23520000 flicks, I get 1 NTSC frame = 23520000 * (1001 / 1000) flicks = 23543520 flicks.
I was all set to file a doc PR but noticed you have to file a CLA. newp.
Re: Flicks – A unit of time defined in C++
#27I'm not sure I understand this: "The NTSC variations (~29.97, etc) are actually defined as 24 * 1000/1001 and 30 * 1000/1001, which are impossible to represent exactly in a way where 1 second is exact, so we don't bother - they'll be inexact in any circumstance." The NTSC color subcarrier is exactly 315/88 MHz, so one could make the flick something like 1/528th of this period. The frame is related to the subcarrier b…
I agree with your line of thinking, but since they give 1/30 fps frame as 23520000 flicks, I get 1 NTSC frame = 23520000 * (1001 / 1000) flicks = 23543520 flicks. I was all set to file a doc PR but noticed you have to file a CLA. newp.
CLA?
Re: Flicks – A unit of time defined in C++
#28Earlier quoted context omitted.
I agree with your line of thinking, but since they give 1/30 fps frame as 23520000 flicks, I get 1 NTSC frame = 23520000 * (1001 / 1000) flicks = 23543520 flicks. I was all set to file a doc PR but noticed you have to file a CLA. newp.
CLA?
Usually: contributor license agreement.
Re: Flicks – A unit of time defined in C++
#29Its always amazing to realize how big 2^64 really is. 2^32 Flicks is about 6 seconds (which can be enough, but still not that useful), but 2^64 is over 800 years, which should be quite enough for anything needing this sort of precision. It would be actually pretty nifty to have this in eg. `struct timespec` and overall base rtc around Flicks
Why would it be nifty to base the underlying format exposed by the OS time APIs and real-time clocks be based on a unit that happens to be a integer divisor of a bunch of common audio and video formats in 2018?
Sure, flicks seems like a useful tool for people working in those fields, but what about the rest of us?
Seems a bit short sighted, or at least extremely unusual for the average person who doesn't care how audio or video is encoded but still deals with high precision time.
If I'm interested in CPU performance, should I suggest that time be denominated in units that are compatible with common CPU frequencies?
Re: Flicks – A unit of time defined in C++
#30I'm not sure I understand this: "The NTSC variations (~29.97, etc) are actually defined as 24 * 1000/1001 and 30 * 1000/1001, which are impossible to represent exactly in a way where 1 second is exact, so we don't bother - they'll be inexact in any circumstance." The NTSC color subcarrier is exactly 315/88 MHz, so one could make the flick something like 1/528th of this period. The frame is related to the subcarrier b…
I agree with your line of thinking, but since they give 1/30 fps frame as 23520000 flicks, I get 1 NTSC frame = 23520000 * (1001 / 1000) flicks = 23543520 flicks. I was all set to file a doc PR but noticed you have to file a CLA. newp.
It is worth noting that while you can represent single NTSC frame time exactly in Flicks, it still does not fulfill their goal of representing "also 1/1000 divisions of each" for NTSC. To get there you'd need 1 Flick to be 25 times smaller, i.e. 1/17640000000 seconds. Although this would go below 1 ns, which was also one of their constraints, but I'm not exactly sure what importance that really has.