There are infinitely many prime k-tuples for every admissible tuple.

Generalization of the Twin prime conjecture.

As of 2023, there was no specific admissible tuple for which it had been proven that there infinite of, only bounds of type:But these do not specify which specific tuple, e.g. Yitang Zhang's theorem.

There are infinitely many primes with a neighbor not further apart than 70 million. This was the first such finite bound to be proven, and therefore a major breakthrough.

This implies that for at least one value (or more) below 70 million there are infinitely many repetitions, but we don't know which e.g. we could have infinitely many:or infinitely many:or infinitely many:or infinitely many:but we don't know which of those.

The Prime k-tuple conjecture conjectures that it is all of them.

Also, if 70 million could be reduced down to 2, we would have a proof of the Twin prime conjecture, but this method would only work for (k, k + 2).

When Ciro Santilli was studying electronics at the University of São Paulo, the courses, which were heavily inspired from the USA 50's were obsessed by this one! Thinking about it, it is kind of a cool thing though.

That Wikipedia page is the epitome of Wikipedia failure to explain things in a way that is of any interest to any learner. Video 1. "Tutorial on LC resonant circuits by w2aew (2012)" is the opposite.

Let's show them how it's done with primes + awk. Edit. They have a -d option which also shows gaps!!! Too strong:gives us the list of all twin primes up to 100:Tested on Ubuntu 22.10.

Both are harmonic oscillators.

In the LC circuit:

You can kickstart motion in either of those systems in two ways:

This is a general principle of software/hardware design that Ciro feels holds wide applicability.

The most extreme case of this is of course the integrated circuit itself, in which it is essentially impossible (?) to observe the specific value of some indidual wire at some point.

Somewhat on the other extreme, we have high level programming languages running on top of an operating system: at this point, you can just GDB step debug your program, print the value of any variable/memory location, and fully understand anything that you want. Provided that you manage to easily reach that point of interest.

And for anything in between we have various intermediate levels of complication. The most notable perhaps being developing the operating system itself. At this level, you can't so easily step debug (although techniques do exist). For early boot or bootloaders for example, you might want to use JTAG for example on real hardware.

In parallel to this, there is also another very important pair of closely linked tradeoffs:

Emulation also has another potential downside: unless you are very careful at implementing things correctly, your model might not be representative of the real thing. Also, there may be important tradeoffs between how much the model looks like the real thing, and how fast it runs. For example, QEMU's use of binary translation allows it to run orders of magnitude faster than gem5. However, you are unable to make any predictions about system performance with QEMU, since you are not modelling key elements like the cache or CPU pipeline.

Instrumentation is another technique that has can be considered to achieve greater observability.

They come up a lot in many contexts, e.g.:

Unsurprisingly the term "computer" became a synonym for this from the 1960s onwards!

Bibliography: