It's not clear how you'd do that with current technology.
What is the oldest unmaintained working man-made mechanism? I have no idea, but I'd hazard that it's closer to 100 years old than 1000. Things that do keep working do so because they're regularly maintained by people. I'm thinking of stuff like multi hundred year old mechanical clocks.
Assuming you mean some kind of electronics made with transistors, you would have to deal with unsolved problems including
* how you build a billion-year power source
* how you deal with transistor aging on the billion year timescale
* how you deal with medium & large scale events over a billion years (example: weather if on a planet, micrometeorite impacts if in space)
Heck even the clock of the long now <https://en.wikipedia.org/wiki/Clock_of_the_Long_Now>, a clock that works on a scale of 10k years, is a major engineering challenge that will most likely be unsuccessful (my opinion)
All human thought processes appear to require some irreversible physical processes in order to occur. (not some fancy quantum process that might turn out to proceed in a way that avoids the energy limit of computation)
Together with Bremermann's Limit, this means that we can put a limit (albeit a very large one!) on the amount of thought that can ever happen. You'd get a smaller limit considering the earth or solar system vs the entire universe, but it'd still be finite.
So if you just start with the infinite thoughts "There is a natural number 0", "There is a natural number 1", and so on, there must be a unique smallest (finite!) natural number X for which the statement "There is a natural number X+1" will never be thought.
so you could just write the much clearer and more distinctive ⹗derive<serde::Serialize>⹘ and so on for the other new multi-punctuation sequences.
Yes, by the time C++37 comes around it might be necessary to petition Unicode to add additional code points. This wouldn't be a problem, for two reasons:
First, Unicode is accustomed to adding new code points and might even be willing to pre-allocate some entire pages to the C++ committee.
Second, the existing ways to modify emoji could apply to designated mathematical modifiers as well. For instance, ∅ would denote a distinct future C++ operator symbol from ∅ or ∅ (sadly, as of 2024, hacker news can't render "pale woman "A-type" empty set" or the other empty set symbol variations I lovingly entered in this paragraph).
These sequences are highly preferable to ASCII sequences like [: because the ZWJs allow supporting editors to correctly render them as a single glyph occupying a single terminal cell and without using font ligature hacks.
Lean (and iirc Mathematica) use backslash escapes: you type \symbolname and the symbol is inserted by your editor.
You can also imbue the backslash escape sequence with the same meaning as the unicode, so that in the event that the editor didn’t make this replacement it would still mean the same thing.
julia also. Mathematica uses literal “escape” sequences, ie you start a symbol by pressing the esc key and finish with another esc (aside from a bunch of bindings for commonly used things).
One of the fun things about the Unicode bidi algorithm is that it flips brackets. You always use ( as an open round bracket, but if your script is rtl it appears like ). In order to support this feature, Unicode has a list of all known kinds of reversible paired brackets.
* PEP 696: Type parameters (typing.TypeVar, typing.ParamSpec, and typing.TypeVarTuple) now support defaults.
* PEP 702: The new warnings.deprecated() decorator adds support
for marking deprecations in the type system and at runtime.
* PEP 705: typing.ReadOnly can be used to mark an item of a typing.TypedDict as read-only for type checkers.
* PEP 742: typing.TypeIs provides more intuitive type narrowing behavior, as an alternative to typing.TypeGuard.
Personally the ability for the type checker to note calls to deprecated functions in a signature-dependent way looks useful. I'm sure the others will be useful too.
With only 2kB RAM, the tetris demo implements what seems to be a 18 or 36-line screen with 21 characters per line. The bitmap for the next line is generated after blasting the bits out for the previous line.
Like some classic game consoles, this leaves most of the "vertical blanking period" for running your main game-or-whatever logic.
What's great about this board is the built in connectors & software to use it. And the fact you can build it yourself if you know how to wield a soldering iron. And it's a 32-bit microcontroller. On the other hand, its capabilities are limited by the small flash & SRAM: it has less RAM than an Apple I did! (but more flash than the Apple I had ROM, and RISC-V code density probably trumps 6502 code)
You're right that the hilbert curve only visits certain points in the unit square, and never a (non-rational,non-rational) point. While the Wikipedia article doesn't seem to mention it, other sources like [1] mention that the definition of a space-filling curve is one that comes arbitrarily close to any point within its space. I think you would be able to see that the iteration of the hilbert curve does get arbitrarily close to (say) the point (sqrt(2)/2, sqrt(2)/2).
The Hilbert curve does contain every point in the unit square. It is a limit of curves, and so can contain points even not in the intermediate constructions. This is similar to how the limit of 1/x as x -> infinity can be 0, even though 1/x never equals 0.
Also, a curve which gets arbitrarily close to every point in the unit square actually touches every point in the unit square. This is because (by definition) a curve is a continuous map from a compact space (the unit interval) to a Hausdorff space (R^2), and so its image is compact, and thus closed. A closed set contains every point that it is arbitrarily close to.
If I travel one half of the distance from where I am to the finishing line an infinite number of times, I reach the finishing line but still never finish the race.
With a Hilbert curve the entire plane becomes a limit.
This doesn't seem to fly with the inductive fact that 1/2 of a power of two is always one over a power of two no matter how many times you perform the iteration.
There are a countably infinite number of rationals between any two rationals, you can even keep splitting up those rational infinitesimal gaps into countably many rationals that are infinitesimal even relative to the earlier infinitesimals.
And you still only end up with a countably infinite set of expressible locations and not the real continuum.
Either x, y, or both are guaranteed to be a number of that form for all values on the curve.
this was my first thought as well. Authors just acknowledge it and move on; it's not like shopify and google care whether there's another way to successfully track users online.
10. Privacy Considerations
Since dictionaries are advertised in future requests using the hash
of the content of the dictionary, it is possible to abuse the
dictionary to turn it into a tracking cookie.
Which is why they are treated as if they are cookies and are cleared any time the cache or cookies are cleared so that they can not provide an additional tracking vector beyond what cookies can do (and when 3rd party cookies are partitioned by site/frame, they are also partitioned the same).
There are LOTS of privacy teams within the respective companies, W3C and IETF that have looked it over to make sure that it does not open any new abuse vectors. It's worth noting that Google, Mozilla and Apple are all supportive of the spec and have all been involved over the last year.
Sorry, I should provide more context. The language in the IETF draft is a bit generic because it is a HTTP spec intended to be used more broadly than just web content in browsers and each should evaluate the risks for their use case.
For browsers specifically, the fetch spec changes will be explicit about the cache clearing and partitioning (partitioned by both top-level document site and frame origin). You can see Chrome's implementation here: https://source.chromium.org/chromium/chromium/src/+/main:net...
The fetch spec changes are in progress (just documenting, the discussions have already happened). You can follow along here if you'd like: https://github.com/whatwg/fetch/issues/1739
Any meaningful change here since [2017]? I know letsencrypt recently announced intent to cease OCSP (https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls....) and it sounds like that will be done industry wide based on CA/Browser forum balloting.
fine-structure constant: less than 10^−17 per year
gravitational constant: less than 10^−10 per year
proton-electron mass ratio: less than 10^−16 per year
Fringe science here. APEC is "Alternative Propulsion Engineering Conference" so these are the EM drive people, etc. The probability that "this is anything" is low.
Now, I have no idea what the explanation is for the observation in this presentation & the videos. But, it would be important to exclude known effects, and I see no effort to do that.
There are at least two obvious "not new physics" things that could be changing the measured weight in the load cell experiment: interaction with Earth's magnetic field causing a net force on the coils, and thermal expansion having an unanticipated effect.
For instance, current through a conductor creates a field; per https://physics.stackexchange.com/questions/338069/why-doesn... "if you have a meter of wire carrying one ampere of current from east to west, it'll feel a magnetic force of 0.5×10−4N [...] That force corresponds to the weight mg of an object with mass m=5mg"
6A in 5m of wire would approximate the 0.15g figure shown in "GEM effect data" on slide 34, and neither 6A nor 5m seem improbable values for a commercial 3 phase motor. Did you take care to control for the expected force imparted in this way? no.
What about heat production? The way the 3-phase experiment is mounted is, charitably, hard to make out from the photos. Suppose any wire undergoes thermal expansion; this could take up some of the weight that is otherwise on the load cell. Some kind of temperature expansion effect would also explain the asymmetry of the weight vs time graph: Heating would occur quickly (several amps through a wire) and cooling would occur slowly (heat removal only via convection). Any analysis of thermal effects? no.
Coincidentally (along with measurement error), thermal effects & electromagnetic interactions are two of the sources of erroneous thrust measurements in the "EM drive" acknowledged in Yang's work at NWPU. So, like, this isn't something people aren't aware of.
What is the oldest unmaintained working man-made mechanism? I have no idea, but I'd hazard that it's closer to 100 years old than 1000. Things that do keep working do so because they're regularly maintained by people. I'm thinking of stuff like multi hundred year old mechanical clocks.
Assuming you mean some kind of electronics made with transistors, you would have to deal with unsolved problems including
* how you build a billion-year power source
* how you deal with transistor aging on the billion year timescale
* how you deal with medium & large scale events over a billion years (example: weather if on a planet, micrometeorite impacts if in space)
Heck even the clock of the long now <https://en.wikipedia.org/wiki/Clock_of_the_Long_Now>, a clock that works on a scale of 10k years, is a major engineering challenge that will most likely be unsuccessful (my opinion)