I sent one of my Prius fobs through the laundry a few years back and, ever after, the electronics just didn't work.

Recently I bought a replacement fob from Amazon, and I'm pleased to report it worked brilliantly... after I completed the chicken dance, which I'm copying from here, for posterity.

Some Prius keys have SKS. Your key has this ability if you can drive the car with the fob in your purse or pocket, not in the dash slot.

Procedure A: Programming the fob to start/stop the engine from the key port

All new fobs should be programmed for this. This will program the fob to start/stop engine while it is inserted into the key port.

1. Get into the car.
2. Close and unlock all doors.
3. Ensure the car is off.
4. Insert and remove your old fob (the one that currently works) into the fob slot 4 times in a row fairly quickly.
5. Insert it a fifth and final time and leave it there.
6. Open and close driver door 6 times fairly quickly.
7. Remove old fob from slot.

The car should be in programming mode now. This will be indicated by the red car-shaped dash light staying on and not blinking.

If the red car-shaped dash light is not on solid, you have failed. Go back to step one and try again. Maybe you need to go faster or slower.

If the red car-shaped dash light is on solid, proceed.

8. Insert your new fob and leave it in the slot. The red anti-theft light on the dashboard should begin blinking.
9. When the light stops blinking and goes dark, your new fob is programmed. This may take up to a full minute.
10. Remove the new fob.

You're now done with the START/STOP portion of the programming.

If you have SKS, proceed to PROCEDURE B don't have SKS, proceed to PROCEDURE C).

Procedure B: Locking/unlocking doors + smart key functionality, if you have SKS

This procedure is for chrome logo key fobs and vehicles with SKS functionality.

1. Open the driver door and leave it open with no fob in slot (ensure the driver door is unlocked). Other doors can be locked or unlocked, it doesn't matter.
   Complete step 2 within 5 seconds of Step 1.

2. Insert the old fob into the key slot and remove it twice.
   Complete steps 3 and 4 within 40 seconds of completing step 2.

3. Close and open driver door twice.

4. Insert and remove old fob once.
   Complete steps 5, 6, 7, and 8 within 40 seconds of completing step 4.

5. Close and open driver door twice again.

6. Insert old fob in slot and close door.

7. Without pressing the brake, press power button, wait a second, press it again, wait a second, press it a third time to turn car back off.

8. Remove old fob from slot. You'll be in "add mode" at this point. Within 3 seconds, the car should lock and unlock doors to verify it is in add mode (the precise number of times the car locks/unlocks the door is model specific, but it should do it at least once). If it does not cycle the locks, return to step 1; otherwise, proceed to step 9.
   Steps 9a and 9b should be started within 40 seconds of completing step 8.

9. Adding a new key

   a. Press and hold the Lock and Unlock key (simultaneously) on the OLD/MASTER fob. A couple of seconds should pass and the locks will cycle once. If you do not get this cycle, it is likely due to a weak CR 2032 battery in your fob. Replace the battery in your old fob and try again.

   b. Press both the Lock and Unlock key (simultaneously) on the NEW fob. Hold for about 1.5 seconds then immediately, within 3 seconds...

   c. Press the lock key on the NEW fob. If successful the lock/unlock will cycle once indicating success. It may take a while for the lock/unlock cycle. I've seen it happen just as I was ready to say, "well, it didn't work". If you wait for a long time (a long time being more than a minute) and get no cycle at all, complete step 10 and test to see if the SKS functions of your new fob work. Remember to put old fob outside the car or else the test of whether the new smart key can start the car without being in a slot in the dash would be meaningless.

   Several users have reported it being necessary to execute 9b step twice before doing 9c, but most do not find this to be true. If your first go-around does not succeed , try it again and execute step 9b twice then 9c. You may be able to just do it over from 9a onward if your car is still in "add" mode, rather than going all the way back to Step B1.

   d. If you need or want to program another "new" fob, repeat steps 9a, 9b, and 9c for the next new fob.

   If done programming fobs, proceed to step 10.

10. To end this programming, open then close the driver's door.

To test whether you have successfully programmed SKS mode, put the old fob outside the car and close the door, then try to start the car without putting the new fob in the slot.

Procedure C: For black logo key fobs without SKS functionality

1. Open the driver door with no fob in slot and the doors unlocked.
2. Insert old fob into slot and remove it twice within 5 seconds.
3. Close and open driver door twice.
4. Insert and remove old fob once.
5. Close and open driver door twice again.
6. Insert old fob in slot and close door.
7. Without pressing the brake, press power button, wait a second, press it again, wait a second, press it a third time to turn car back off.
8. Remove old fob from slot. You'll be in "add mode" at this point.
9. Car should lock and unlock doors twice to verify it is in add mode.
10. Press and hold both buttons on new fob simultaneously for a second and a half.
11. Within 3 seconds, press just the lock button on new fob.
12. Car should respond with one quick lock/unlock to verify that the new fob is all set. If the car responds with two lock/unlocks, that means it didn't work. Either try again, your fob is bad or, you have too many fobs assigned to the car.
13. To end this programming, open then close the driver's door or put fob in the slot.

An answer to this question on Stack Overflow.

Question

PyTorch contains these macros which use __builtin_expect:

#define C10_LIKELY(expr) (__builtin_expect(static_cast<bool>(expr), 1))
#define C10_UNLIKELY(expr) (__builtin_expect(static_cast<bool>(expr), 0))

Apart from the fact that __builtin_expect is compiler specific, what is the difference between these and C++20's [[likely]] and [[unlikely]] attributes?

Answer

Quick Answer: Expressivity

The difference is in the degree of expressivity. With __builtin_expect we can write:

if (LIKELY(x()) && UNLIKELY(y())) {

while with [[likely]] we can only write

if (x && y) [[likely]] {

Does it matter?

Yes.

Let's construct two programs to explore the difference.

Using builtin

// builtin.cpp
// Method A: per-operand hints via __builtin_expect.
// Opaque predicates + sinks so nothing is folded away and both
// short-circuit branches must be emitted as real branches.
extern bool x();
extern bool y();
extern void body();
extern void keep_going();
#define LIKELY(expr)   (__builtin_expect(static_cast<bool>(expr), 1))
#define UNLIKELY(expr) (__builtin_expect(static_cast<bool>(expr), 0))
// "x almost always true, y almost always false"
void hint() {
#ifdef LIKELY_FIRST // For exploring orderings
    if (LIKELY(x()) && UNLIKELY(y())) {
#else
    if (UNLIKELY(x()) && LIKELY(y())) {
#endif
        body();
    }
    keep_going();
}
// Control: single condition.
void single() {
    if (LIKELY(x())) { body(); }
    keep_going();
}

Using [[likely]]

// likely.cpp
// Method B: statement-level hint via the standard [[likely]]/[[unlikely]] attribute.
// Opaque predicates + sinks so nothing is folded away and both
// short-circuit branches must be emitted as real branches.
extern bool x();
extern bool y();
extern void body();
extern void keep_going();
// only says "the taken branch (body) is unlikely"
void hint() {
    if (x() && y()) [[unlikely]] {
        body();
    }
    keep_going();
}
// Control: single condition.
void single() {
    if (x()) [[likely]] { body(); }
    keep_going();
}

Compiling and comparing

We can compile to assembly

clang++ -O2 -std=c++20 -S -o builtin_likely_first.s builtin.cpp -DLIKELY_FI
RST
clang++ -O2 -std=c++20 -S -o builtin_unlikely_first.s builtin.cpp
clang++ -O2 -std=c++20 -S -o likely.s likely.cpp

when we compare

diff builtin_likely_first.s likely.s

There's not a meaningful difference.

However, when we compare builtin_unlikely_first, we find the following:

# diff -y --width=80 --expand-tabs builtin_unlikely_first.s likely.s
# LEFT = UNLIKELY(x()) && LIKELY(y())     RIGHT = x() && y() [[unlikely]]
# gutter:  | changed    < left only    > right only   (blank = same)
        .file   "builtin.cpp"          |          .file   "likely.cpp"
        .text                                     .text
        .globl  _Z4hintv                          .globl  _Z4hintv              
        .p2align        4                         .p2align        4
        .type   _Z4hintv,@function                .type   _Z4hintv,@function
_Z4hintv:                                 _Z4hintv:                             
        .cfi_startproc                            .cfi_startproc
# %bb.0:                                  # %bb.0:
        pushq   %rax                              pushq   %rax
        .cfi_def_cfa_offset 16                    .cfi_def_cfa_offset 16
        callq   _Z1xv                             callq   _Z1xv
        testb   %al, %al                          testb   %al, %al
        jne     .LBB0_1                |          je      .LBB0_3
                                       >  # %bb.1:
                                       >          callq   _Z1yv
                                       >          testb   %al, %al
                                       >          jne     .LBB0_2
.LBB0_3:                                  .LBB0_3:
        popq    %rax                              popq    %rax
        .cfi_def_cfa_offset 8                     .cfi_def_cfa_offset 8
        jmp     _Z10keep_goingv                   jmp     _Z10keep_goingv       
.LBB0_1:                               |  .LBB0_2:
        .cfi_def_cfa_offset 16                    .cfi_def_cfa_offset 16
        callq   _Z1yv                  <
        testb   %al, %al               <
        je      .LBB0_3                <
# %bb.2:                               <
        callq   _Z4bodyv                          callq   _Z4bodyv
        popq    %rax                              popq    %rax
        .cfi_def_cfa_offset 8                     .cfi_def_cfa_offset 8
        jmp     _Z10keep_goingv                   jmp     _Z10keep_goingv       
.Lfunc_end0:                              .Lfunc_end0:
        .size   _Z4hintv, .Lfunc_end0-            .size   _Z4hintv, .Lfunc_end0-
        .cfi_endproc                              .cfi_endproc
                                                                                
        .globl  _Z6singlev                        .globl  _Z6singlev            
        .p2align        4                         .p2align        4
        .type   _Z6singlev,@function              .type   _Z6singlev,@function
_Z6singlev:                               _Z6singlev:                           
        .cfi_startproc                            .cfi_startproc
# %bb.0:                                  # %bb.0:
        pushq   %rax                              pushq   %rax
        .cfi_def_cfa_offset 16                    .cfi_def_cfa_offset 16
        callq   _Z1xv                             callq   _Z1xv
        testb   %al, %al                          testb   %al, %al
        je      .LBB1_2                           je      .LBB1_2
# %bb.1:                                  # %bb.1:
        callq   _Z4bodyv                          callq   _Z4bodyv
.LBB1_2:                                  .LBB1_2:
        popq    %rax                              popq    %rax
        .cfi_def_cfa_offset 8                     .cfi_def_cfa_offset 8
        jmp     _Z10keep_goingv                   jmp     _Z10keep_goingv       
.Lfunc_end1:                              .Lfunc_end1:
        .size   _Z6singlev, .Lfunc_end            .size   _Z6singlev, .Lfunc_end
        .cfi_endproc                              .cfi_endproc
                                                                                
        .ident  "clang version 21.1.8             .ident  "clang version 21.1.8 
        .section        ".note.GNU-sta            .section        ".note.GNU-sta
        .addrsig                                  .addrsig

Let's focus on the key changes. This section

testb   %al, %al                          testb   %al, %al
        jne     .LBB0_1                |          je      .LBB0_3
                                       >  # %bb.1:
                                       >          callq   _Z1yv
                                       >          testb   %al, %al
                                       >          jne     .LBB0_2

shows that after testing x(), the two versions part ways.

On the left (UNLIKELY(x()) first), the whole fast path is the single instruction jne .LBB0_1. Since x is expected to be false, "x is false" just falls straight through toward keep_going(), and the code only jumps away, to a separate block, in the rare case that x is true. y() isn't here at all (it's been moved farther down).

On the right ([[unlikely]]), after testing x, y() is also called and tested (callq _Z1yv -> testb), so y() stays on the path.

The next section is

.LBB0_1:                               |  .LBB0_2:
        .cfi_def_cfa_offset 16                    .cfi_def_cfa_offset 16
        callq   _Z1yv                  <
        testb   %al, %al               <
        je      .LBB0_3                <
# %bb.2:                               <

On the left we have the section the previous left-side section jumped to. y() is compared here in the rare case that's necessary (callq _Z1yv -> testb.

On the right the matching block has none of those lines because y() was already evaluated further up.

What difference does it make?

Modern CPUs don't just execute instructions one at a time. They have many layers of complexity to improve code performance and these layers interact with how we write code.

The instruction cache and the front-end. The CPU fetches instructions in contiguous chunks (cache lines, ~64 bytes). Instructions that sit next to each other in memory get fetched together "for free." Placing the unlikely y() and body() in a separate block way at the end of the function means that the most likely path of execution is pulled into cache and then used. In contrast, if unlikely y() follows likely x() directly then cold code evicts the useful hot code. Rearranging code so this doesn't happen is called hot/cold splitting and means fewer cache lines are touched on the hot path and better use is made of the instruction cache.

Branch prediction and fall-through. The CPU attempts to predict whether a branch will be taken or not (so it can prefetch and do speculative execution). If the CPU predicts wrong this work is wasted and a full pipeline flush may be necessary.

Compilers arrange code so the expected path is the fall-through (no jump) and the unexpected path is the one that jumps away. Note that putting UNLIKELY above meant that the hot path has one fewer branch prediction then the when we used [[unlikely]]. That gives the CPU a better shot at getting things right, in addition to the instruction cache benefits.

As a caveat, a person can really overthink this. You'd only notice the difference between these in a really hot path. If this is something you actually worry about it would be better to use profile-guided optimization (PGO): the compiler can measure actual branch frequencies and reorganize code accordingly, ignoring hints. This is much better than using hints. So hints matter most in situations where we can't profile and suspect a hot path.

Branch-hint layout matrix (clang 21, -O2)

We can explore this for all orderings and logical operators by evaluating

void f() {
    if ( <cond over x() and y()> ) { body(); }
    keep_going();
}

And we find that && and || will short-circuit. In contrast, ^ never short-ciruits (both x() and y()) always run, so per-operand hints can't steer it.

Legend: "body usually runs taken?" = is the body the common case? "cold tail" = pushed to an out-of-line block. "inline" = on the straight-line fast path. "always" = the body() call is emitted unconditionally (no short-circuit).

An answer to this question on Stack Overflow.

Question

I am not sure Stack Overflow is the right place for this question but I'm shooting my shot.

I have a 2D field sampled on a global longitude-latitude structured curvilinear grid and I would like to compute how much of the field's variance/energy is associated with different spatial scales.

The data is stored as a NumPy array of shape (nt, nx, ny). For each grid point I also have its longitude and latitude coordinates as 2D arrays.

The grid is regular in longitude and latitude, for example a constant angular spacing of 0.25°, but it is not regular in physical distance. Due to meridian convergence, two neighboring points separated by 0.25° longitude are much closer together near the poles than near the equator. I also have the physical area of each grid cell and local scale factors relating angular distances to physical distances.

My initial approach was to compute a 2D FFT and derive a power spectrum. However, a standard FFT assumes uniform sampling, which is not true in physical space for a longitude-latitude grid. I then tried interpolating the data onto a more uniform grid before applying the FFT, but the interpolation noticeably smooths small-scale features and changes the resulting spectrum.

So my question is, what is the standard way to perform a scale decomposition in this situation?

Can I apply a standard FFT directly in index space if the goal is to compare multiple fields defined on the same grid? Should I look into non-uniform FFTs applicable when the sampling locations are known through longitude and latitude coordinates? Should I look at an alternative approach altogether?

Answer

Perhaps convert the points to 3D (x,y,z) or use a spatial binning (eg, https://github.com/r-barnes/dggridr/).

An answer to this question on Stack Overflow.

Question

I'm not a specialist, but as far as I know, a bit of information in a QR-code is coded more than once, and it is defined as the redundancy level

How can I estimate a QR-code redundancy level ? Is where an mobile app or a website where I can test my QR-code redundancy level easily ? If not, is it an easy algorithm that I can implement ?

Redundancy is sorted in different categories according to this website, but I'd like to have the direct percentage value if possible

Answer

QR codes contain a couple of bits which indicate the error correction level, as depicted below (source):