double values[nnz];
- a single array of ints with the corresponding column index: int columns[nnz];
- a single array of ints, of length (m+1), with the start of each row in the two other arrays (the (m+1)th element stores nnz, which will be useful later): int start[m + 1];
So to print a whole matrix, you do this: for (int i = 0; i < m; i++) {
index = start[i]; // where
count = start[i + 1] - start[i]; // number of nonzeros in row i
for (int t = 0; t < count; t++) {
j = columns[index + t];
v = values[index + t];
printf("element (%d, %d) has value %g\n", i, j, v);
}
To a modern programmer, this may look very old-fashioned (Fortran-ish), but I have tried many alternatives (like grouping columns and values together in a struct, or using pointers), and in my numerical codes, nothing gets even close in terms of performance. It must be said that CSR and CSC (its transpose) are very compact in memory, which is often a bottleneck. Also, since so many sparse numerical codes in benchmarks have used this representation for decades, it could be that CPU designers make sure that it works well. CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
Similar to CLOCK_MONOTONIC, but provides access to
a raw hardware-based time that is not subject to
NTP adjustments or the incremental adjustments per‐
formed by adjtime(3). This clock does not count
time that the system is suspended.
There is also CLOCK_BOOTTIME to keep counting time while suspended: CLOCK_BOOTTIME (since Linux 2.6.39; Linux-specific)
A nonsettable system-wide clock that is identical
to CLOCK_MONOTONIC, except that it also includes
any time that the system is suspended. This allows
applications to get a suspend-aware monotonic clock
without having to deal with the complications of
CLOCK_REALTIME, which may have discontinuities if
the time is changed using settimeofday(2) or simi‐
lar. double x = a + b
results in x := fp64(a + b)
Furthermore, the C code double y = a + b * c
results in y := fp64(a + fp64(b * c))
These restrictive definitions have the huge advantage of allowing portability and determinism of floating-point operations: regardless of the platform, architecture, or compiler, the values of x and y are mandated down to the bit representation. Also, this most often does not come at any performance cost, since most architectures have IEEE-754-compliant instructions. y := fp64(a + fp80(b * c))
where fp80() uses the internal 80-bit x87 FPU registers. This is "excess precision" (80 instead of 64 bits), and this would generally be faster than the standard-compliant code. A more recent example, since Haswell, Intel CPUs have builtin fused multiply-add (FMA) instructions, allowing one to eschew the inner rounding altogether: y := fp64(a + b * c)
This is a case of "contraction" in GCC parlance, and it is also generally slightly faster that the standard-compliant code. -fexcess-precision=standard is not implemented for languages other than C.
The commit linked in the bug report adds the options for C++.* -ffp-contract=style
-ffp-contract=off disables floating-point expression
contraction. -ffp-contract=fast enables floating-point
expression contraction such as forming of fused multiply-
add operations if the target has native support for them.
-ffp-contract=on enables floating-point expression
contraction if allowed by the language standard. This is
currently not implemented and treated equal to
-ffp-contract=off.
The default is -ffp-contract=fast.
[2] https://godbolt.org/z/GKb7G4nW9
Then in January 2022, the NYT bought Wordle, and started tweaking both lists, first shrinking the secret word list to 2309 entries, but leaving the logic otherwise intact. Fast forward to today, I looked up the current code [1], and it seems that there are now 14855 allowed words. The first 12546 are ordered alphabetically (0: "aahed", 12545: "zymic"), and the next 2309 are not. This may suggest that the latter are the secret words, but the logic for picking them has changed: I found no obvious sequence, when compared to the last few days' secret words. So it's either a more complex sequence, or the secret word is picked server-side.
In any case, I guess they decided to re-shuffle the list now at day 1689 / 2309 in order to avoid giving particularly assiduous player an additional bit of information: they can exclude all previous secret words. (To be accurate, I think this would be 1.897 bits, but my information theory is rusty.)
[1] https://www.nytimes.com/games-assets/v2/9003.896ec900f2a1ce8...