Hacker News new | past | comments | ask | show | jobs | submit | Conscat's comments login

OpenMP was pivotal to my last workplace, but because some customers required MSVC, we barely had support for OpenMP 2.0.

It is a bit better now, but OpenMP is yet another standard born in UNIX HPC clusters, so I am even surprised that Microsoft bothered at all, it seems to be something to fill a check box.

For what it's worth, a lawyer _did_ ask the presiding Judge Christopher Lopez to tell Alex Jones he definitely can't do that and solidify this in writing the terms of bankruptcy, and the judge simply refused to even try on the basis that everyone involved is an adult and ought to know better.

It’s standard practice to let somebody else own your things when you are in a position that don’t allow you to have something. It’s not provable easily and if it’s justice to charge him 1.4B for talking some shit it’s also justice to use the loopholes of the system.

Appointing outwardly biased Supreme Court justices who prejudiced USA law against women and many minorities.

Arguably this stacking of the Supreme Court could have been prevented if Justices had retired when the Democrats still had control of appointing their replacements

No, nothing would have changed if that happened. Republicans have no qualms about overtly breaking the law and abandoning their duty and decorum. If they did then Garland would be a sitting SCJ and Gorsuch wouldn't.

If RBG had retired while Obama was still president, it would have been a Democrat appointment, no?

Am I missing something?


yes. Scalia died in Feb 2016 (while Obama was president) and the senate refused to hold confirmation hearings on a successor until Trump took office in 2021.

I recently implemented a runtime for `__builtin_cpu_init()`, `__builtin_cpu_supports()`, and `__builtin_cpu_is()` for x86-64. Using these compiler intrinsics, or a higher level feature such as `[[gnu::cpu_dispatch]]`, you can write functions that behave differently on different CPUs. Fortunately the implementation isn't terribly complex. On x86, it's based around a neat `cpuid` instruction, and other ISAs have similar features.

https://github.com/Cons-Cat/libCat/blob/main/src%2Flibraries...


I'm confused why you insinuate that "flag waving" in June has anything to do with this topic. You frame it as though that is something developers tolerate because they are paid to, in contrast to how developers behave in volunteer work (demonstrably untrue).


I wasn't talking about you personally.

I was talking about the type of human who is shown in this commercial: https://www.youtube.com/watch?v=X55JPbAMc9g

We need to be very clear that they are human, and not a reptile wearing human skin and using human words to get to eat human babies.


That is a completely intended way to use std::hash, along with a few other functions like std::tuple_size and std::tuple_element.


Clang supports C11 - 23 in C++, as well as some future C features like fixed-point integers. The main pain points with Clang are just the fundamental differences like void* and char, which don't typically matter much at an interoperability layer.


There's a lot of subtle differences between 'proper' C and the C subset of C++, since C++ uses C++ semantics everywhere, even for its C subset.

Many C++ coders are oblivious to those differences (myself included before I switched from 'mainly C++' to 'mainly C') because they think that the C subset of C++ is compatible with 'proper' C, but any C code that compiles both in a C++ and C compiler is actually also a (heavily outdated) subset of the C language (so for a C coder it takes extra effort to write C++ compatible C code, and it's not great because it's a throwback to the mid-90s, C++ compatible C is potentially less safe and harder to maintain).

For instance in C++ it's illegal to take the address of an 'adhoc-constructed' function argument, like:

    sum(&(bla_t){ .a = 1, .b = 2, .c = 3, .d = 4 });
(godbolt: https://www.godbolt.org/z/r7r5rPc6K)

Interestingly, Objective-C leaves its C subset alone, so it is always automatically compatible with the latest C features without requiring a new 'ObjC standard'.


Because Objective-C initial proposal is that everything that isn't touched by Smalltalk like code, clearly in brackets or @annotarions, is plain C.

The pre-processor original compiler, before the GCC fork, would leave everything else alone, blindly copying into the generated C file.


The first thing that comes to mind when I think "flux" is none of the above too . There's an extremely cool alternative iterator library for C++20 by Tristan Brindle named flux.


/me glances across my desk to see my soldering station...


Does anyone have examples of calculations that need quadruple precision? My last work place seemed fine using double precision for simulating satellites in orbit, and I have the imprecision double precision makes black holes and quantum physics simulation work correctly, so I have no intuition for this.


I see it in statistics. It's not uncommon in a lot of statistical algorithms to need to take the product (or sum) of a lot of very small numbers and then divide by that product when computing likelihoods of a bunch of independent measurements. There are some algebra tricks you can use to get around loss of precision like working in the log domain or some tedious scaling tricks, but working in quad precision can help when those aren't enough.

The article also gives an example from quantum physics. Some chaotic or highly numerically unstable problems just need quad precision to not blow up; primarily problems/algorithms (can be the problem itself or the algorithm to solve it that causes the issues) that tend to catastrophically amplify small errors. Matrix inversion is another example, to the point that most algorithms try to do almost anything to avoid explicitly inverting a matrix. But sometimes you just have to.


To put some specifics on "a lot of very small numbers", it's around a million numbers with part-per-billion precision, or a billion numbers with part-per-million precision, where you approach the limits of naive summation in double precision.


For sums, yes, but products and division by small numbers are the real killer and those come up a lot in stats. Hence why you try to avoid them by working with log-probabilities (where products become sums), but sometimes you can't. Quad precision is a bit of a bandaid that just pushes the issue off when you don't have a better algorithm, but it works sometimes.


How so? All primitive operations are backward stable, and unlike addition and subtraction, division and multiplication are well-conditioned.


It's more about resolution. Products of small numbers get small a lot faster than sums. Likewise for dividing two small numbers. The smallest possible quad precision number is a lot smaller than the smallest possible double precision one.


But the main feature of floating point is that you keep the same relative precision at all sizes. As long as you're not hitting infinity or denormals, multiplying doesn't lose information like adding a big number to a small number does.

Do stats often deal with distict probabilities below 10^-300? And do they need to store them all over, or just in a couple variables that could do something clever?


> Do stats often deal with distict probabilities below 10^-300?

Yes and with very wide dynamic range, though you really try to avoid it using other tricks. A lot of methods involve something resembling optimization of a likelihood function, which is often [naively] in the form of a product of a lot of probabilities (potentially hundreds or more) or might also involve the ratio of two very small numbers. Starting out far away from the optimum those probabilities are often very small, and even close to the optimum they can still be unreasonably small while still having extremely wide dynamic range. Usually when you really can't avoid it there's only a few operations where increased precision helps, but again even then it's usually a bandaid in lieu of a better algorithm or trick to avoid explicitly computing such small values. Still, I've had a few cases where it helped a bit.


Matrix inversion precision can be fixed iteratively (at a CPU cost, of course). Nearly singular matrices should probably be factored in any case.


Probably, that falls into "doing almost anything to avoid inverting a matrix explicitly", but direct inversion is the classic example here.


For numerical PDE solvers, you never do the actual inversion, but the discretization of the system (denoted A) can have significant sensitivity to numerical precision. Look up Condition Number and Preconditioning. In fact, resolving the problems with numerical precision for some A takes as much time as actually solving the system, and it's worth it.


Oh I'm very aware, I'm lumping those all into "tricks used to avoid/work around the numerical issues associated with matrix inversion" for simplicity, because explicit computation of a matrix inverse is one of the classic examples of a numerically unstable task. Hence why a large subfield of applied math can be summarized as "coming up with ways to avoid matrix inversion." PDE solvers like you mention are one of the main applications for that.

Tricks like clever factorization (which a lot of factorization algorithms have their own severe numerical issues e.g. some of the ways to compute QR or SVD), preconditioners, sparse and/or iterative algorithms like GMRES, randomized algorithms (my favorite) etc are all workarounds you wouldn't need if there was a fast and stable way to exactly invert any arbitrary non-singular matrix. Well, you would have less need for, there are other benefits to those methods but improving numerical stability by avoiding inverses is one of the main ones.


One situation that already uses two doubles, which you may already be familiar with, is the International Astronomical Union's Standards of Fundamental Astronomy library. It uses two doubles for the date in order to be able to be able to have pico/nano second precision over thousands of years. Of course the algorithms aren't precise to that level over thousands of years, but you still need the ability to specify it to that level during the time periods they are that accurate for.


Interesting. I would have thought that fixed-point would make more sense for a time quantity. If you use a 64-bit integer to represent picoseconds, it gives you a time range of about 18 million years.


You calculated something wrong. 2^64 picoseconds is only half a year.

Once you decide you need to go over 64 bits, the exact data type is largely a matter of convenience, and I can easily see two doubles being more convenient than either a quad or a 128-bit integer. You have more than 100 bits of precision in such a scheme, and it runs pretty fast.


Ah good catch, my bad! 18 million seconds, not 18 million years. Oops =)


It's a very quick and easy / lazy way to measure the floating-point error in your existing double-precision algorithms; run the computation at quadruple precision and check for differences in the output. If there's any significant difference then you take a closer look.


You can easily get catastrophic cancellation in physical simulations, people are just not very aware of it.

If for e.g. you see bare summation rather than some sort of sorting by magnitude then expect bad results as numbers get bigger.


It is a bit weird though, because people also get very, very clever about designing their physical simulations so that they don’t have to care too much about their working precision.


Yeah, GPUs actually helped with this a lot when they first came out because suddenly to get the great performance you had to drop to single precision, at least until 2018 or so (can’t remember exactly now, but it used to be the case that the older cards were 2x as slow at DP)


I don’t really do GPU stuff, but I expect double to be at least 1/2 as slow as single, even on good hardware. I mean it is twice as many bits. (Maybe you think in bits/second, though, which is totally fair).

I looked up my consumer card on a whim (playing with sprinkling some GPGPU into my code—cupy is actually really easy to use and ergonomic!), and apparently doubles are 1/32 as fast as singles. Yikes!


Any long running calculation where the new state depends on the old state and there isn't much of a correction factor. Anything with "sensitive dependance on initial conditions", any dynamical systems.

For example: simulating the three body problem (three celestial bodies of equalish size orbiting eachother). Very small differences get amplified, and any difference at all in how the math is implemented on different systems will result in divergent solutions.


I use it for generating music through physical models. If the model requires a very numeric-sensitive algorithm like a differential equation solver, it's nice to have the extra precision, and usually performance doesn't matter too much in these sort of things (because ultimately, I just click "render" and wait anyway). To be very honest, I don't even know if I need 128bits, maybe a 32bit float would do... I never ran a comparative analysis. It just gives me more room for error, so that I can focus on the music/sound and not too much on the numerical analysis/programming. Working on hobby music+programming projects is the ultimate freedom.


I'm glad you're having fun but if you never compared it to double and single then you're not giving a valid example. Especially if you would have picked even higher if it was available.


Basically guaranteed that you don't need quad for this.


Of course, you also need to use solid gold audio cables, or you're just throwing away the extra precision via poor signal fidelity.


Flexible PCBs are convenient to embed in fabric.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: