HN user
It shouldn't, under the assumptions they are opening up with. Inverse square law twice is appropriate for an approximation that the reflection is entirely diffuse because you assume that the diffuse reflection is uniform in all directions away from the illuminated surface. A single inverse square law is appropriate (with both distances added to each other before squaring) under the approximation that the reflection is specular.
Some day we'll get CREATE TABLE ... ( ... STORAGE ORDER COLUMN MAJOR) to have our transactional cake on the tables that need it and eat our analytics cake on the tables that need that.
But until then, separate tools for separate purposes isn't a bad place to be when those tools are both fantastic.
The vast majority of POI churn information comes from streetview + machine learning object detection + automatic change detection + human verification. There are many clever algorithms in play through the entire pipeline. As moats go, its probably bigger than search.
they (might) have a float, and are using the `==` operator, they're doing something wrong.
Storage, retrieval, transmission, and serialization/deserialization systems should be able to transmit and round-trip floats without losing any bits at all.
Repeating the exercise with something that is exactly representable in floating point like 1/8 instead of 1/10 highlights the difference.
They are very similar to the pros and cons of having a monorepo. It encourages information sharing and cross-linkage between related teams. This is simultaneously its biggest pro and its biggest con.
You can't even express static rounding in C. You can't even express them in the LLVM language-independent IR. Any attempt to use the static rounding modes will necessarily involve intrinsics and/or assembly.
Nothing major, just some oddball decisions here and there.
Fused compare-and-branch only extends to the base integer instructions. Anything else needs to generate a value that feeds into a compare-and-branch. Since all branches are compare-and-branch, they all need two register operands, which impairs their reach to a mere +/- 4 kB.
The reach for position-independent code instructions (AUIPC + any load or store) is not quite +/- 2 GB. There is a hole on either end of the reach that is a consequence of using a sign-extended 12-bit offset for loads and stores, and a sign-extended high 20-bit offset for AIUPC. ARM's adrp (address of page) + unsigned offsets is more uniform.
RV32 isn't a proper subset of RV64, which isn't a proper subset of RV128. If they were proper subsets, then RV64 programs could run unmodified on RV128 hardware. Not that its going to ever happen, but if it did, the processor would have to mode-switch, not unlike the x86-64 transition of yore.
Floating point arithmetic spends three bits in the instruction encoding to support static rounding modes. I can count on zero hands the number of times I've needed that.
The integer ISA design goes to great lengths to avoid any instructions with three source operands, in order to simplify the datapaths on tiny machines. But... the floating point extension correctly includes fused multiply-add. So big chunks of any high-end processor will need three-operand datapaths anyway.
The base ISA is entirely too basic, and a classic failure of 90% design. Just because most code doesn't need all those other instructions doesn't mean that most systems don't. RISC-V is gathering extensions like a Katamari to fill in all those holes (B, Zfa, etc).
None of those things make it bad, I just don't think its nearly as shiny as the hype. ARM64+SVE and x86-64+AVX512 are just better.
Any argument that is filled with this much ragebait should be dismissed out of hand.
ISPC suffers from poor scatter and gather support in hardware. The direct result is that it is hard to make programs that scale in complexity without resorting to shenanigans.
An ideal scatter-read or gather-store instruction should take time proportional to the number of cache lines that it touches. If all of the lane accesses are sequential and cache line aligned it should take the same amount of time as an aligned vector load or store. If the accesses have high cache locality such that only two cache lines are touched, it should cost exactly the same as loading those two cache lines and shuffling the results into place. That isn't what we have on x86-AVX512. They are microcoded with inefficient lane-at-a-time implementations. If you know that there is good locality of reference in the access, then it can be faster to hand-code your own cache line-at-a-time load/shuffle/masked-merge loop than to rely on the hardware. This makes me sad.
ISPC's varying variables have no way to declare that they are sequential among all lanes. Therefore, without extensive inlining to expose the caller's access pattern, it issues scatters and gathers at the drop of a hat. You might like to write your program with a naive x[y] (x a uniform pointer, y a varying index) in a subroutine, but ISPC's language cannot infer that y is sequential along lanes. So, you have to carefully re-code it to say that y is actually a uniform offset into the array, and write x[y + programIndex]. Error-prone, yet utterly essential for decent performance. I resorted to munging my naming conventions for such indexes, not unlike the Hungarian notation of yesteryear.
Rewriting critical data structures in SoA format instead of AoS format is non-trivial, and a prerequisite to get decent performance from ISPC. You cannot "just" replace some subroutines with ISPC routines, you need to make major refactorings that touch the rest of the program as well. This is neutral in an ISPC-versus-intrinsics (or even ISPC-versus-GPU) shootout, but it is worth mentioning only to point out that ISPC is also not a silver bullet in this regards, either.
Non-minor nit: The ISPC math library gives up far too much precision by default in the name of speed. Fortunately, Sleef is not terribly difficult to integrate and use for the 1-ulp max rounding error that I've come to expect from a competent libm.
Another: The ISPC calling convention adheres rather strictly to the C calling convention... which doesn't provide any callee-saved vector registers, not even for the execution mask. So if you like to decompose your program across multiple compilation units, you will also notice much more register save and restore traffic than you would like or expect.
I want to like it, I can get some work done in it, and I did get significant performance improvements over scalar code when using it. But the resulting source code and object code are not great. They are merely acceptable.
Shout-out to the NOAA GFS team, who publish the GFS analysis directly to AWS S3.
And I suppose you could write a validator to make sure that this worked.
Like this one!
https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argu...
introduced by PWM dimming, but why would that be a low enough frequency to bother people?
The human fovea has a much lower effective refresh rate than your peripheral vision. So you might notice the flickering of tail lights (and daytime running lights) seen out of the corner of your eye even though you can't notice when looking directly at them.
clang-format and clang-tidy are both excellent for C and C++ (and protobuf, if your group uses it). Since they are based on the clang front-end, they naturally have full support for both languages and all of their complexity.
LUTs are commonly used in geodesy applications on or near the Earth's surface. The full multipole model is used for orbital applications to account for the way that local lumpiness in Earth's mass distribution is smoothed out with increasing distance from the surface. It might be reasonable to build a 3D LUT for use at Starlink scale or higher, but certainly not for individual satellites.
Exactly what order and degree were you using to evaluate the model? Variations in drag and solar pressure are more significant than the uncertainty in the gravity field for objects in LEO somewhere much less than 127th order (40 microseconds on my machine, your smileage may vary), so you can safely truncate the model for simulations. GRACE worked by making many passes such that they could average out those perturbations to make their measurement. But for practical applications, those tiny terms are irrelevant.
IERS Technical Note 36 section 6.1 gives recommendations for model truncation if you are looking for justification. https://iers-conventions.obspm.fr/content/tn36.pdf
"^integer" which is better than "int"
I agree that it reads a little better. But as a small-handed person, it is unfortunately much more uncomfortable to type.
isn’t a standard in that protobuf doesn’t care
Shove protobuf into Something Else that does packet delimitation for you. I'm fond of SQLite for offline cases as a richer alternative to sstable.
Shout-out to Firefox Multi-Account Containers, which Just Works (TM) for exactly this use case.
This comment is a fantastic example of the meta-battle which the tech industry has been waging. They have worked very hard to change the very questions in the privacy debate. In their terms, collection of the data itself is never under debate; all debates are framed in terms of how they are allowed to use data. In this case, the failure isn't the law or the company's compliance with it. It was the collection and retention of the data in the first place.
Running multiple test builds in parallel isn't all that difficult, though. One with ubsan, one with asan, and one (opt-in on a test-by-test basis) with tsan.
There aren't connections in SQLite like there are for network-connected DBs (eg MySQL)
The handle named `db` in your example is as expensive to create as a connection in the relative sense and should be optimized the same way in your application. It may be less expensive than a network database connection, but its still very expensive relative to any subsequent queries. The database file is opened, its first page is read, its schema is parsed from text (!), some memory is pre-allocated and so on every time you make that call.
The sqlite3_exec call invokes the parser and query optimizer every time it is called. A better benchmark would be to compile a valid statement (sqlite3_prepare). The unit under test should just be sqlite_bind() for relevant parameters followed by sqlite_step(), and maybe (but not necessarily) sqlite_reset().
Its even optional in ARMv7-A and Cortex-A9 doesn't have it.
Big family house in the suburbs with aggressive demand scheduling (ie, we let the temp float a fair amount when nobody is home) versus high-efficiency car.
For my case, it was worse. When normalized to dollars, I spent nearly 2x more in HVAC expenses compared to driving's fuel costs, and that's with a modest commute (20 miles). Its much less energy intensive to air condition one large medium-density building than many smaller low-density buildings.
Not surprising, though. The issues surrounding if/how a system provides libraries of any kind (static or shared) are completely implementation-defined. The Standard doesn't have anything to say about them at all except for the program-wide symbol scope rules.
Hear, hear!
Galileo and BeiDou behave similarly to GPS in this respect. Oddly enough, all three time bases have an origin that is specified in UTC, but model elapsed seconds since that epoch. So GPS time does include the 9 leap seconds which occurred prior to its epoch. Galileo time's epoch is aligned to the GPS week, so it shares a leap second offset with GPS, but its still specified in terms of UTC (1999-08-21T23:47). BeiDou's epoch is specified as 2006-01-01T00:00 UTC, so it includes another 14 leap seconds with respect to GPS. So the three systems do not quite model the platonic ideal, but fortunately the offsets are all constants and its trivial for the receiver to use such an ideal in practice.
GLONASS time is UTC + three hours (ie, Moscow civil time) and does have leap seconds. To figure out the leap second offset between GLONASS time and GPS time the GLONASS ICD actually tells you to get that info from the GPS broadcast messages, although they do have an alert system for upcoming leap second updates. One more reason to dislike working with GLONASS.
Almost all of the ionosphere's total thickness is below 550km, so the lower altitude doesn't matter. Starlink sees less impact from the ionosphere because the carrier frequencies are higher, and dispersion is proportional to 1/f^2.
Regular GPS precision due to ionosphere changes is too low.
... for single-frequency receivers. Military receivers have been dual-frequency for a long time. GPS L2C's rollout is pretty slow (and L5 is even farther behind), but Galileo and BeiDou are both fully operational with dual-frequency civil signals right now. All dual-frequency receivers can naturally cancel out the effect of the ionosphere. That's part of why some smartphone baseband chips are coming out with L5 capability: GPS L5, Galileo E5A, and BeiDou B2A all operate in the same spectrum.
It depends strongly on how the phased array is being steered. If the components prior to phasing and summation are saturated by the interference then phased array beamforming will not reject the interference.