Recent submissions

Comment · 9 years ago
You say "we need to protect minorities and women from the white male oppressors" is not an accurate representation of their viewpoint.

Then you proceed to say that minorities and women are discriminated against, and we need to do something about that. Who is doing this discrimination, then? You point out that white-skinned people tend to hold power in (traditionally white) Western nations. I would say that my description is accurate.

Comment · 9 years ago
You do realize that is exactly why alt-righters believe there is bias against white people?

"We need to protect minorities and women from the white male oppressors" is basically the slogan of the identity politics wing of the left.

Comment · 9 years ago
Comment · 9 years ago
In section 3.1 they say it is a performance issue.
Comment · 9 years ago
Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.
Comment · 9 years ago
16 Psyche is far to big to move anywhere.

16 Psyche's mass is 2.27·10^19 kg and its orbital speed is 17.34 km/s.

Earth's orbital speed is 29.78 km/s.

So a perfect orbital transfer (not even possible) to get 16 Psyche into Earth's orbit would take an impulse of at least (29780.0 m/s - 17340.0 m/s) · 2.27·10^19 kg = 2.82388·10^23 kg·m/s.

A Saturn V rocket produces 3.51·10^7 N of thrust.

So it would take one Saturn V rocket 8.0452·10^15 seconds to move 16 Psyche, or 2.5511·10^08 years.

If we had 1 million Saturn V rockets, it would take just over 255 years.

Comment · 9 years ago
Comment · 9 years ago
Though for the purposes of comparisons, -0 and +0 are the same in IEEE 754.

So the expression "x >= 0.0f && x <= 1.0f" is true for x = -0.

Comment · 9 years ago
SSE1 is single-precision only. SSE2 added double precision.

So the bug will still appear for 'double' using just SSE1.

Comment · 9 years ago
The solution is to compile with SSE2 on x86. (flags: -mfpmath=sse -msse -msse2)

On x86-64, the compiler should default to SSE2.

SSE2 is ~16 years old so compatibility shouldn't be an issue.

Comment · 9 years ago
It works for 32-bit unsigned integers and double precision floats.

For n < 19, "(double)n * (1.0 / 19.0)" evaluates to a double between 0.0 and 1.0, then it is truncated to 0 when it is implicitly converted to unsigned int.

Since there are only 2^32 values for 32-bit integers, it is possible to test all values in under a minute:

    #include <stdio.h>
    #include <stdint.h>

    int main() {
        uint32_t n = 0;
        do {
            uint32_t a = n / 19;
            uint32_t b = (double)n * (1.0 / 19.0);
            if (a != b) {
                printf("Not equal for n = %u\n", n);
            }
            ++n;
        } while (n != 0);
    }
Comment · 9 years ago
It does work, though not as well as using an integer multiply.

The approximate latencies for Skylake are:

    div --> 26 cycles
    cvtsi2sd + mulsd + cvttsd2siq --> 6 + 4 + 6 = 16 cycles
I did a quick (and imperfect) microbenchmark, got these results:

    Real integer division (-Os) --> 1.392s
    FPU Multiply (-Os)          --> 0.243s
    FPU Multiply (-O2)          --> 0.197s
    Integer Multiply (-O2)      --> 0.164s
The code:

    #include <stdio.h>

    int main() {
        volatile unsigned x;
        for (unsigned n = 0; n < 100000000; ++n) {
    #if 1 /* Change to 0 to use FPU. */
            /*
            Compile with -Os to get GCC to emit div instruction.
            -O2 to emit integer multiply.
            Clang emits integer multiply, even with -Os.
            */
            x = n / 19;
    #else
            /* Use the FPU. */
            x = (double)n * (1.0 / 19.0);
    #endif
        }
    }
Comment · 9 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton