Re: "A diagram of C23 basic types"

On 4/15/2025 12:22 PM, David Brown wrote:

On 15/04/2025 07:40, BGB wrote:

On 4/14/2025 11:15 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 19:43:04 -0500, BGB wrote:
>

On 4/14/2025 5:33 PM, Lawrence D'Oliveiro wrote:

>
I figured that it would be hard to find an epoch less arbitrary than
the Big Bang ...

>
But, we don't really need it.
>
If so, could probably extend to 128 bits, maybe go to nanoseconds or
picoseconds.

>
The reason why I chose the Planck interval as the time unit is that
quantum physics says that’s the smallest possible time interval that makes
any physical sense. So there shouldn’t be any need to measure time more
accurately than that.

 Quantum mechanics, the current theory, is not complete.  Physicists are aware of many limitations.  So while Plank time is the smallest meaningful time interval as far as we currently know, and we know of no reason to suspect that smaller times would be meaningful, it would be presumptuous to assume that we will never know of smaller time intervals.
 

>
Practically, picoseconds are likely the smallest unit of time that people could practically measure or hope to make much use of.

 The fastest laser pulses so far are timed at 12 attosecond accuracies - 100,000 as accurate as a picosecond.  Some subatomic particle lifetimes are measured in rontoseconds - 10 ^ -27 seconds.  Picoseconds are certainly fast enough for most people, but certainly not remotely fast enough for high-speed or high-energy physics.
 

>
While femtoseconds exist, given in that unit of time light can only travel a very short distance, and likely no practical clock could be built (for similar reasons), not worth bothering with (*).
>

Physicists have measured times a thousand millionth of a femtosecond. It is not easy, of course, but not impossible.
 

I am not saying that the smaller times don't exist, but that there is no point in wasting bits encoding times more accurate than can be used by a computer running at a few GHz, with clock speeds that will likely never exceed a few GHz.
This sets the practical limit mostly in nanosecond territory.
But, for many uses, even nanosecond is overkill. Like, even if a clock-cycle is less than 1ns, random things like L1 cache misses, etc, will throw in enough noise to make the lower end of the nanosecond range effectively unusable.
And, things like context switches are more in the area of around a microsecond or so. So, the only way one is going to have controlled delays smaller than this is using delay-loops or NOP slides.
But, also not much point in having clock times much smaller than what the CPU could effectively act on. And, program logic decisions are unlikely to be able to be much more accurate than around 100ns or so (say, several hundred clock cycles).
...
You could express time as a 64-bit value in nanoseconds, and, it would roll over in a few centuries.
Meanwhile, a microsecond is big enough for computers to effectively operate based on them, small enough to be accurate for most real-world tasks.
Granted, one could have a "double" value holding the time in seconds, but this is its own thing (and, outside of 3D games or similar, more common to represent time values as integers, *).
*: And, we don't use "float", as this isn't even sufficient even really for games (if you are much over an hour or so from the epoch, then you no longer even have millisecond accuracy...).
...