ambrop7

The issue is not motion, the vestibular system cannot measure velocity, only linear acceleration and rotation. The only issue is while you are accelerating in a horizontal direction in VR, but you are not actually acccelerating (remember acceleration is absolute not relative). But I don't expect this will be much of an issue. We don't have a problem speeding up or slowing down on a treadmill.

Do you maybe know, when frames rendered by GPU 1 (e.g. fast GPU) need to be sent to GPU 2 (e.g. slow GPU doing the compositing and outputting to the monitor), how does the data actually get transferred? I can imagine the following possibilities:

1) GPU 1 writes to CPU RAM, GPU 2 reads from CPU RAM

2) GPU 1 writes to GPU 2 RAM via PCI Express (DMA between devices)

3) GPU 2 reads from GPU 1 RAM via PCI Express (DMA between devices)

This is quite unclear to me. Is DMA-BUF so generic that the memory it refers to can be in different types of RAM, including GPU RAM and CPU RAM?

The mention of DMA-BUF makes me suspect that it involves rendered video being copied from the GPU to the main RAM and back to the GPU, which wastes energy. Does someone have details about how the integration works?

In any case, if the program forks in order to exec, it shouldn't be using fork at all, but posix_spawn. Fork gets more expensive as the virtual memory of the process grows, since it needs to copy page tables. For very large process forking can be prohibitively expensive due to this. And posix_spawn does not have this problem.

Suppose the the period of lights is equal to the time expected to move from one light to the next, and each light is red/green for the same amount of time. You have a green wave if you pass the first light green and drive at the expected speed. But if you drive twice as fast, you reach the second light red instead of green. Now it would work if the period of lights was half the time expected to get from one light to the next, but why would that generally be the case?

Actually I think the opposite will usually hold: you will still have a green wave if you drive at the expected speed divided by an integer.

Programming languages aren't able to express arbitrary real numbers, so to "determine whether a given real number is representable as an int or not" is mostly meaningless in a programming language as opposed to a computer algebra system.

What you can do is:

- determine if a float is an integer (trunc(x) == x),

- convert a float to a certain integer type with some kind of rounding, or get an error if it's out of range (see my comment with double_to_uint64),

- convert a float to a certain integer type exactly, or get an error if it's not representable (e.g. by doing both of the above).

The basic reason that so many people fail to use floats correctly is that they act like operations on floats are equivalent to operations on the real numbers they represent, when in fact they are usually defined as the operation on real numbers rounded to a representable value.

Each floating point value that is not a NaN represents a certain real number, -inf or +inf (this can be expressed in terms of the sign bit, exponent and mantissa). Knowing that, a == b when neither operand is a NaN is defined as equality of what they represent, in purely mathematical terms. Similar can be said for inequality operators.

Be aware that +0.0 and -0.0 are different floating point values but represent the same real number, so +0.0 == -0.0 follows.

People who say == means nothing for floating point and you always need epsilon checks are wrong, plain and simple. == is very well defined. Don't confuse the definition of floating point operations with common practices for using them effectively.

You can iterate through all non-NaN values and check that successive ones are indeed not equal:

    #include <math.h>
    #include <stdint.h>
    #include <assert.h>
    #include <stdio.h>
    #include <inttypes.h>

    int main()
    {
        float x = (float)-INFINITY;
        uint64_t count = 1;
        while (x != (float)INFINITY) {
            float y = nextafterf(x, (float)INFINITY);
            assert(y != x);
            x = y;
            ++count;
        }
        printf("Found %" PRIu64 " floats.\n", count);
        return 0;
    }
    
    $ gcc -std=c99 -O3 a.c -lm -o a
    $ ./a
    Found 4278190081 floats.

Interestingly, this only finds one zero (-0.0), hence the assert doesn't actually fail around zero.

One benefit would be to protect yourself from security issues in the main torrent code. Anyway it was just an idea, not a serious proposal.

You don't always need epsilon. I've written lots of floating point code that works well without epsilon checks. See my comment in this thread (double_to_uint64) how what the OP needs can be done correctly without an epsilon check.

This is not right. The current rounding mode is not guaranteed to apply to integer to floating point conversions. Quoting C99, section 6.3.1.4, paragraph 2:

"When a value of integer type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined."

See it says implementation-defined manner, not according to the current rounding mode.

Test case:

    #pragma STDC FENV_ACCESS ON
    #include <stdio.h>
    #include <stdint.h>
    #include <fenv.h>

    int main()
    {
        fesetround(FE_DOWNWARD);
        printf("%f\n", (double)UINT64_MAX);
        fesetround(FE_UPWARD);
        printf("%f\n", (double)UINT64_MAX);
        return 0;
    }

    $ gcc -std=c99 -frounding-math x.c -lm
    $ ./a.out 
    18446744073709551616.000000
    18446744073709551616.000000

Here's a reliable/portable solution:

    bool double_to_uint64 (double x, uint64_t *out)
    {
        double y = trunc(x);
        if (y >= 0.0 && y < ldexp(1.0, 64)) {
            *out = y;
            return true;
        } else {
            return false;
        }
    }

Explanation:

- we first round the value to an integer (but still a floating point value),

- we then check that this integer is in the valid range of the target integer type by comparing it with exact integer values (0 and 2^N),

- if the check passes, then converting this integer to the target integer type is safe, and if the check fails, then conversion is not possible.

Of course if you literally need to convert to "long" you have a problem because the width of "long" is not known, but that is a rather different concern. I argue types with unknown width like "long" should almost never be used anyway.

(based on my answer here: https://stackoverflow.com/questions/8905246/how-to-check-if-...)

It could be done with a local TCP / UDP <=> WebSocket gateway, especially if it's written in a safe language like Rust.

See my sibling comment, that should make it much better.

Two more about.config:

- gfx.webrender.all = true (important on Linux, fixes jerky scrolling)

- general.smoothScroll.mouseWheel.durationMaxMS = 200 (makes mouse scroll animation faster)

Plasma/KDE is mostly great, but a major thing that GNOME and Xfce still do better is GVFS and GVFS-FUSE. That means I can browse to smb://something or sftp://something, double click a file and it just works whatever the application is (e.g. play in VLC, edit in VS Code). This has never worked in KDE where only KDE apps can open remote files (and even that has bad performance).

Or at least the basic double-slit experiment with snakes. WILL the snakes form an interference pattern?

Also, more SW programmers should be getting into this field, as by working in SW first you realize all the things that need improvement in the FPGA world (which the FPGA people didn't recognize, not knowing how SW is done in the modern world, or got used to).

-march=native and -mtune=broadwell tell the compiler to optimize for your architecture. One would think given the compiler documentation that march implies mtune, but this is apparently not the case.

That sounds like a bug to me which should be reported.

I only use my alarm clock in addition to my phone when I must not miss something really important.

GCC has had this since forever:

cc: internal compiler error: Segmentation fault (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See <URL> for instructions.

(the URL may be customized by the distro)

Paid 13200 USD (they don't publish the price on their web page any more, but I suppose it didn't change much). Supposedly their price is one of the lowest (and you get the best care).

Hope you're better. I had a similarly horrifying experience myself. More and more pain pretty much everywhere, tiredness, headaches, GERD - almost every "vague" symptom you could think of, slowly getting worse over months and years, and no answers from multiple specialists. Luckily it wasn't Lyme (which I got tested for). After getting a large panel of lab tests assembled after weeks of online research, I found high calcium levels, and with follow-up tests diagnosed myself with Primary Hyperparathyroidism (at 28 years old, which is rare). Flew to the USA a month later for surgery (the place where they do it best, the Norman Parathyroid Center, is essentially incomparable to everyone else) and now several months later I am much better.

I could argue that even people who genuinely feel emotions have, unconsciously, learned to feel them through their interactions with other people. Who can prove to me that emotions are something fundamental to humans and not acquired through culture? In a sense, everyone may as well be faking it.

It's equally clear that most of what we associate with consciousness, such as thinking, awareness of the body and the moment and time and decision making and ... doesn't exist either. Because time and time again studies prove that when a decision is made (this is well studied in traffic for instance) there are no conscious reasons. Reasons only happen afterwards.

Since a person can tell what they experience and what they do not, the distinction between conscious experience and unconscious processing must have a base in physical reality (brain activity). With sufficiently advanced technology, one could analyze the brain processes and see which processes are associated with the reported conscious experience.

The fact that not all brain activity is associated with conscious experience in no way implies that conscious experience does not exist.

If a brain performs the same sensory and decision-making functions, it is also going to claim that it feels emotions and experiences colors in particular ways. For all practical purpose, such a brain is conscious.

Wondering what's genetic about this experiment.

It also does away with rounding errors

What? Surely it does not have infinite precision with a finite number of bits, and also doesn't seem to be a rational number representation.

It appears that one person is working on it and the project is in a prototype phase: https://gitlab.freedesktop.org/emersion/waypipe

Nitpick: modern bone density scans use X-rays, and don't typically fall under nuclear medicine.