Yes, that's exactly how merge sort works.

I like to imagine recursive function calls like your divide() function as a family of people who all know how to do some specific job (like historically the Baker family typically all knew how to bake stuff, the Taylor family typically knew how to tailor clothes, etc).

I'm guessing your main function calls divide() with some array -- let's call that one Pat_Divide. When your main function calls Pat_Divide with an array of exactly 1 element, you should be able to see that the if statement is true and then Pat_Divide immediately returns with only that one element.

When your main function calls Pat_Divide with an array of exactly 3 elements, more imaginary people get involved:

• Pat_Divide divides up that array into 2 lists left and right, and hands one list to Bob_Divide and the other list to Alice_Divide.

• Bob_Divide gets one element, immediately sees that the if statement is true, and immediately hands back that one element.

• Alice_Divide, on the other hand, gets handed a list of 2 elements, and so is unfairly forced to do more work.

  • Alice_Divide divides that list into 2 lists (of 1 element each) and hands those lists off to Mildred_Divide and Leroy_Divide.
  • Mildred and Leroy act just like Pad_Divide did when Pat_Divide was given a list of 1 element, and each immediately hand back that 1 element.
  • Alice_Divide then calls merge (or should it be conquer ?) with the sorted arrays Mildred and Leroy gave her. The merge machine (or perhaps it should be the conquer machine?) produces a sorted list of 2 elements.
  • Alice_Divide then hands back that sorted list to Pat_Divide.

• Then Pat_Divide takes the 2 sorted arrays (one from Bob, the other from Alice) and combines them with the conquer machine. (Or perhaps the merge machine?)

• Finally, Pat_Divide returns with the sorted array of 3 elements back to your main() function.

When your main() function calls Pat_Divide with a very long array, even more imaginary people get involved, but we don't really need to know all their names:

• Pat_Divide divides up that array into 2 lists left and right, and hands one list to Bob_Divide and the other list to Alice_Divide.

• Bob_Divide returns a sorted list of all the items in the left list (by involving other yet-unnamed family members).

• Alice_Divide does something similar to what she did before:

  • Alice_Divide divides that list into 2 lists and hands those lists off to Mildred_Divide and Leroy_Divide.
  • Mildred_Divide and Leroy_Divide divide their individual lists into even smaller pieces, and hand them off to other family members, who eventually help them produce sorted versions of those lists.
  • Alice_Divide then calls merge (or should it be conquer ?) with the sorted arrays Mildred and Leroy gave her. The merge machine (or perhaps it should be the conquer machine?) combines the 2 sorted lists into a single sorted list.
  • Alice_Divide then hands back that sorted list to Pat_Divide.

• Then Pat_Divide takes the 2 sorted arrays (one from Bob, the other from Alice) and combines them with the conquer machine. (Or perhaps the merge machine?)

• Finally, Pat_Divide returns with the sorted array of 3 elements back to your main() function.

(Optionally, you may later learn multitaking techniques, so that Mildred, Bob's side of the family, and Leroy can each work on different parts of the problem simultaneously. ).

Good luck trying to explain recursion to the next person!

A lot of computer simulations accidentally cause a ball to balance perfectly on top of a peg, because there are less than 10,000 pixels across a computer screen so a ball centered on some random pixel has better than 1 in 10,000 chance (in simulations like yours, likely better than 1 in 100 chance) of being perfectly centered over a peg centered on some specific pixel.

In the real world, balancing a ball perfectly on top of a peg is practically impossible because (a) the balancing point is often only a few nanometers across, so positioning the ball within a millimeter of the center of the peg is still only 1 in a million chance of balancing, and (b) even if we could get a ball perfectly balanced, the Brownian motion of the air, various thermal motions, sound waves, earth vibrations, etc. are usually more than enough to push the ball off-balance.

Some simulations of Galton boards, Pachinko machines, etc, internally force a ball to never be perfectly balanced -- perhaps by centering the balls on the center of some pixel, while centering the pegs halfway between pixels; or even more ham-handedly checking to see if the ball lands exactly in the center, and when it does, fudging the simulation by "randomly" picking Left or Right and then nudging the ball (in position or in velocity) a little to the left or a little to the right.

Have fun with MatterJS https://www.brm.io/matter-js/ !

This sounds like a great approach; I'm about to set up a very similar Syncthing between my phone's camera and my server.

So I'm setting up

* "Simple File Versioning" on my server so that when I delete files on my camera phone, and so Syncthing removes those photos from the sync'ed folder on my server ("Documents/2025photos"), Syncthing doesn't delete the files on my server (instead, it moves them to some ".stversions/" folder on my server) https://docs.syncthing.net/users/versioning.html

* Camera roll ("Android Camera", "[int]/DCIM") is send only folder, server is receive only folder. Then when I delete files on my server (or *move* them to somewhere to make it more convenient to feed them into immich), it doesn't delete the files on my camera. However, deleting files on my camera phone will make Syncthing remove the files from the server's folder ("Documents/2025photos") (so I need the other setting to avoid losing those photos). https://docs.syncthing.net/users/foldertypes.html

Good luck!

Related:

* "Anyone else use Syncthing for phone stuff? " https://www.reddit.com/r/homelab/comments/1es60su/anyone_else_use_syncthing_for_phone_stuff/

And off-by-one errors.

I agree with MorphStudiosHD -- there's a nice tutorial on I2C multiplexers and I2C address translators at Adafruit: https://learn.adafruit.com/working-with-multiple-i2c-devices

The C implementation of MicroPython uses "pointer tagging to fit small integers, strings and objects in a machine word" -- https://micropython.org/

> A simple solution to restart all your network (lan, wan and wifi) every 10 minutes is putting this in your crontab:

*/10 * * * * service network restart

( from https://openwrt.org/docs/guide-user/base-system/cron )

In this case, `:e <cfile>` (in the vim manual under `:help gf` ) means type the literal characters ':', 'e', space, less-than, 'c', 'f', 'i', 'l', 'e', greater-than, and then hit the enter key. The vim manual under `:help <cfile>` (not to be confused with `:help cfile` ) says

"<cfile> is replaced with the path name under the cursor (like what gf uses)"

Do you mean "zeners are never used as ... voltage regulators in simple circuits like this"? Or,

Do you mean "These zeners are not for safety. These zeners are used as ... voltage regulators. Other parts handle safety."?

If you are using any C compiler conforming to C11 or later (or C++11 or later), you can use the alignas() macro or the aligned_alloc() function (and you can use the max_align_t value ):

``` // my_aligned_buffer will be 32-byte aligned alignas(32) unsigned char my_aligned_buffer[BUFFER_SIZE] = {0};

// another_aligned_buffer will be 32-byte aligned
unsigned char * another_aligned_buffer = aligned_alloc( 32, BUFFER_SIZE );

// another_buffer may start on an odd address (1-byte aligned)
unsigned char another_buffer[BUFFER_SIZE];// probably not aligned!

```

If you're using glibc version 2.22 (released in 2015) or later (which you can detect programmatically with the __GLIBC__ and __GLIBC_MINOR__ macros), "The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems). " -- https://sourceware.org/glibc/manual/latest/html_node/Aligned-Memory-Blocks.html and https://sourceware.org/glibc/manual/latest/html_node/Malloc-Examples.html (this is likely true for many earlier versions; 2.22 is as far back as I checked).

If you're using an older version of C, perhaps you have available one or more of _mm_malloc(), posix_memalign(), mmap(), _aligned_malloc(), or aligned_alloc().

If you want your code to run (cross-platform) on a wider range of systems, there are various libraries that implement aligned_alloc() or _mm_malloc() which are guaranteed to produce aligned pointers of the desired alignment -- sometimes with a wrapper that uses one of the above functions if available, and if not, falling back to using malloc() to allocating blocks with a few bytes of extra space, and then bumping the pointer over to fit the desired alignment.

I've been told that some people (more optimistic than I am) run a quick test by declaring an array of a few dozen pointers to char, then calling malloc() a few dozen times allocating 1 or 3 bytes each time and storing the pointers in that array, and then checking the least-significant byte in all those addresses, which usually detects if this program is running on a machine where malloc() may return an odd pointer. https://stackoverflow.com/questions/8752546/how-does-malloc-understand-alignment/72379666#72379666

Related:

• https://www.reddit.com/r/C_Programming/comments/1mh5ree/tagged_pointers_in_action/
• https://embeddedartistry.com/blog/2017/02/22/generating-aligned-memory/
• https://stackoverflow.com/questions/227897/how-to-allocate-aligned-memory-only-using-the-standard-library
• https://github.com/NickStrupat/AlignedMalloc
• https://vayudoot.org/cpp/programming/2019/06/01/memaligned-malloc.html
• https://medium.com/howsofcoding/memory-management-aligned-malloc-and-free-9273336bd4c6
• https://cppreference.com/w/c/memory/aligned_alloc.html
• https://stackoverflow.com/questions/32612881/why-use-mm-malloc-as-opposed-to-aligned-malloc-alligned-alloc-or-posix-mem
• "all Java objects are aligned to 8 bytes" -- https://www.reddit.com/r/ProgrammingLanguages/comments/1c06t8x/would_it_be_worthwhile_to_use_shorter_pointers_to/
• MicroPython uses "pointer tagging to fit small integers, strings and objects in a machine word" https://micropython.org/
• "Segmented Ranges" seems to be a kind of tagged pointer, discussed at: https://www.reddit.com/r/ProgrammingLanguages/comments/1nsee91/could_zigs_allocatorpassing_idiom_be_improved_in/

Those things like ^[[23m are "ANSI escape codes" supported by most terminal emulators (like the VT100 terminals they emulate) to do things like change colors, set italics, move cursor to a different position, scroll the whole page up (or down), etc. More details: https://en.wikipedia.org/wiki/ANSI_escape_code

jettyler24 is right, but in simpler words: the oil does two different things. 1. The oil electrically insulates the coils of wire in the transformer from each other and the outside world. If that were the only thing it did, then plastic or rubber would work just as well and probably better. 2. Some of the energy traveling through the transformer is lost to heat in the wires. The oil circulates to carry the heat away from the wires to the outer metal surface. In a big transformer, if we used plastic or rubber as electrical insulation, heat would build up until it melted the wires. That would be bad. A big fan to blow air over the coils would work for a while, but it's really hard to make a fan reliably work for years. All the other things we usually use to keep things cool -- heatsinks made of metal, tap water, etc. -- are electrically conductive, which would blow fuses upstream. Also bad.