planede

C23:

> The unary * operator denotes indirection. If the operand points to a function, the result is a function designator; if it points to an object, the result is an lvalue designating the object. If the operand has type "pointer to type", the result has type "type". If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.

below in a note (emphasis mine):

> Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime.

Now the note is not normative, but I assume there are normative wording for defining what the "invalid" pointer values are, scattered around in the standard.

C++:

https://eel.is/c++draft/expr.unary.op#1.sentence-4

C++ is very particular in what it means for a pointer to point to an object, and this is also UB there.

How does arithmetic work with NonZeroI16 and remain efficient? What's the codegen of adding/subtracting two NonZeroI16 values?

Like one that is free'd or point to a stack object that is no longer in scope. Or one that points one past the last element of an array.

More like:

  switch (e) {
    case A:
      foo(); break;
    case B:
      bar(); break;
  }
  std::unreachable();

instead of:

  switch (e) {
    case A:
      foo(); break;
    case B:
      bar(); break;
    default:
      std::unreachable();
  }

The former is more likely to produce a warning if there is an enumeration C that you forgot to handle, or you added an enumeration C and missed a switch-case to update.

edit:

duh, it's supposed to be returns here instead of breaks.

On libstdc++ std::unreachable() also reliably crashes if you define either _GLIBCXX_DEBUG or _GLIBCXX_ASSERTIONS. libc++ should have a similar macro. I expect MS STL to also reliably crash on debug builds here, as it's quite heavy on debug assertions in the standard library anyway by default (and debug and release builds are explicitly not ABI compatible there).

I recommend omitting the default case and putting std::unreachable() outside the switch and omitting the default label for the sole reason that compilers are more likely to warn for a missed case label this way (-Wswitch vs -Wswitch-enum in gcc/clang, the former is included in -Wall, the latter isn't included even in -Wextra).

This also allows expressing intent: no default label means that I meant to handle all cases, and having a default means that I opted into a fallback, please don't warn. That's probably why -Wswitch-enum isn't enabled by default, too many false positives without a convenient way to suppress the warning.

However matmat is done, row-major vs column-major for both matrices shouldn't make a difference (for square matrices at least).

I don't know if tiling is done for matvec. I don't think it makes sense there, but I didn't think about it too hard.

C code conforming to the ISO C standard generally requires a (very small) runtime.

Even if the RGB components correspond to sRGB, to linearize you apply the same non-linear function to each component value, independently. So even if you do the interpolation in a linear colorspace, the order of the sRGB components does not matter.

Your reasoning starts out nicely with y=Ax, but you get the wrong conclusion. The layout of x and y are not affected at all by row or column order, they are just consecutive numbers in either case. So you have to look at the layout of A.

For the row-major layout the multiplication Ax ends up being more cache-efficient than for the column major layout, as for calculating each component of y you need to scan x and a row of A.

Technically still better than not offering deletion at all, but of course in reality it's in many ways worse.

The images might have ~10cm resolution, but that doesn't necessarily mean that there can't be larger scale systematic offsets and other distortions for larger tiles.

I recently learned that satellite images are often corrected to match known maps.

https://www.youtube.com/watch?v=PVemGumEEgo

Hmm, this opens the possibility to also commit these files as directory structures. I wonder how this would affect merges and conflicts.

If you asked a person to give you a random number between 1 and 6, would you accept if they just said a number they just came up with or would you rather they rolled a die for it?

> I'd prefer a messy history but have a way to just see MRs into master/main as the main sequence of changes.

git log --first-parent gets you there.

> Then be able to zoom in futher if necessary to see how an MR was arrived at.

Yeah, an interactive UI would be nice for this, maybe there are some, but I really only use the CLI.

Switzerland has a lot in my experience. At least the few cities that I visited. They are also very well mapped on openstreetmap, so it was easy to search for a nearby one with osmand whenever I was thirsty.

problem statement: git history, as normally presented, is hard to follow and contains too much noise.

article's proposed solution: simplify the git history by destroying information that are irrelevant. That's what rebase is.

The problem is what is or isn't relevant depends on context. I think the right way to go about it is to simplify the presentation and otherwise improve tooling to get information out of the git history. git already has some ways to filter the history, but it lacks very feature rich query language, like mercurial. git guis should also step their game up.

Because that's not the framework where N and NP applies. There is no notion of black boxes outside of the algorithm.

A bag of bytes is a bag of bytes. Any encoding should be either assumed by the protocol being used or otherwise specified.

I would think that the majority of immigrants that are not white are also not from the EU, but I don't know that statistics.

The "printf" hiding is probably too crude and tailored to bash. But I don't see why the so file couldn't just modify the environment once it's loaded.

Merges of course should have changes, but IMO they shouldn't have changes that are not resolving conflicts (either actual conflicts marked by git, or conflicts that manifest in failing tests, etc...). An entirely unrelated change stuffed into a merge commit is inappropriate.

Interesting. From what I can find the pixel format is 4 polarization directions per pixel, 45 degrees apart. Even though there are 4 channels this doesn't allow to deduce the V Stokes parameter (this camera can't capture circular polarization). Technically one channel is redundant here, but I guess it can be useful for reducing error.

I wonder if an alternative pixel format, with 3 polarization directions 60 degrees apart and a circular polarization channel would be desirable for some applications.

> like 256 orientations per pixel per image

You only need 4 parameters to describe the polarization at a single wavelength[1]. Naively this could be 4 parameters per color channel, so 12 channels overall. I think you could potentially need more color channels though to capture the full spectrum. But 12 channels at least looks feasible for a camera.

[1] https://en.wikipedia.org/wiki/Stokes_parameters

edit:

On second thought for dealing with reflections you might get away not capturing the "V" Stokes parameter, as you might not care about circular polarization.

edit2:

The I,Q and U parameters can be captured fully by a single polarization filter at three different rotations. This could be feasible with existing cameras with a tripod and a static subject. I wonder if this has been done before.

For me that means having multiple keys in `authorized_keys` for the same user and never transferring private keys between devices. From what I gathered from the discussion here, this is not a given.

I would say if it still runs other unmodified xbox games natively then it's an xbox (and possibly more).

I think this tool must share a lot techniques and use cases with rr. I wonder how it compares in various aspects.

https://rr-project.org/

rr "sells" as a "reversible debugger", but it obviously needs the determinism for its record and replay to work, and AFAIK it employs similar techniques regarding system call interception and serializing on a single CPU. The reversible debugger aspect is built on periodic snapshotting on top of it and replaying from those snapshots, AFAIK. They package it in a gdb compatible interface.

Hermit also lists record/replay as a motivation, although it doesn't list reversible debugging in general.

There were proposals for optimizing this kind of stuff for C++ in particular for error handling, like:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p07...

> Throwing such values behaves as-if the function returned union{R;E;}+bool where on success the function returns the normal return value R and on error the function returns the error value type E, both in the same return channel including using the same registers. The discriminant can use an unused CPU flag or a register

I don't think a fresh boot is the best benchmark for this. I do use plasma and in my experience memory usage tends to go quite a bit higher with use, even if you close everything. I don't think they have leaks and it's probably just memory some data structures and the allocator hold onto for various reasons.

> Scotopic vision occurs at luminance levels of 10−3[5] to 10−6[citation needed] cd/m2

They should have more than enough brightness to be clearly visible in those light conditions on almost any visible wavelength they chose for the laser, so it's weird if they optimize for this instead of the outdoor performance.