jepler
23:55 start scanning
23:59:59 message added
00:00:01 perform timestamp check
You also mentioned a directory being created 5 minutes early: what if some system has a clock skewed the opposite way, and puts a message in a directory 5 minutes late instead?
I use the Python decimal package to calculate 17^(1/7) to 4000 decimal places. I show the first 12 characters of the ASCII representation ("1.4989198720"), then take the first 1000 characters after the decimal place. I show the first and last 10 characters of this string ("4989198720...6163659068") so that you can verify it against the string you are testing.
Then I use a list comprehension to check each 3-digit string (e.g., 001, 002, 003, ..., 999) to find out whether it is a substring of the concatenation of `s` with itself, and list the ones that don't appear. I manually abbreviated the list, but I'm saying that in my string, 000, 002, 004, 005, 009, [and some other numbers], 993, 994, 995, 998, and 999 did not appear. (The concatenation `s+s` is checked so that the subsequences that occur at the wraparound---here,684 and 849---are found)
Because some of these length-3 sequences are missing, to my understanding this does not constitute a de Bruijn sequence of order 3 on a size-10 alphabet. However, I'm also not entirely sure whether this is what you were claiming.
Python 3.11.2 (main, Sep 14 2024, 03:00:30) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 4000
>>> d = 17 ** (1 / Decimal(7))
>>> sd = str(d)
>>> sd[:12]
'1.4989198720'
>>> s[:10], s[-10:]
('4989198720', '6163659068')
>>> s = sd[2:][:1000]
>>> [i for i in range(1000) if "%03d" % i not in s+s]
[0, 2, 4, 5, 9, [...], 993, 994, 995, 998, 999]
>>> len(_)
361there was some discussion on at least two github issues: https://github.com/python/cpython/issues/127307 and https://github.com/python/pythondotorg/issues/2663
The papers claim some interesting but not game-changing results on factorization of tiny primes and attacking toy, reduced round cryptosystems that resemble AES in a particular way.
If any intermediate sum overflows, you get an infinity. Further arithmetic can never return you to the realm of finite numbers (though you can also get into the world of "not a number" NaNs by calculating -inf + inf for instance), so you can use a standard function like (C99 <math.h>) isfinite() to check if any intermediate step of summing FP numbers overflowed the representation.
(Apparently that's 9x10^5 INR, or in the neighborhood of 10,000€ or $10,000. If you're curious about this system of naming and writing numbers used in India and other countries in the region, https://en.wikipedia.org/wiki/Lakh and https://en.wikipedia.org/wiki/Indian_numbering_system#Use_of... will get you started)
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.
Unicode has at least 50 sets of pairing punctuation just waiting for use...
\N{MEDIUM LEFT-POINTING ANGLE BRACKET ORNAMENT} U+276c
\N{HEAVY LEFT-POINTING ANGLE BRACKET ORNAMENT} U+2770
\N{LIGHT LEFT TORTOISE SHELL BRACKET ORNAMENT} U+2772
\N{MEDIUM LEFT CURLY BRACKET ORNAMENT} U+2774
⊥ \N{UP TACK} U+22a5 ⊥
⊦ \N{ASSERTION} U+22a6 ⊦
⊧ \N{MODELS} U+22a7 ⊧
⊨ \N{TRUE} U+22a8 ⊨
⊩ \N{FORCES} U+22a9 ⊩
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.
https://docs.python.org/3.13/whatsnew/3.13.html
New typing features:
* 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)
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. 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 yearNow, 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.
This was long enough ago that it was in the Python 2 days, so I don't know if the method survived the product's transition to Python 3. I do know the method would probably not have survived a dedicated reverse engineer who wanted to figure out how to recover the unencrypted bytecode.
if (write_offset == INT64_MAX) {
/* writes are not possible */
error = EFBIG;
goto error_out;
}Here's one hand-wavy proof of why the cardinality of the real interval P=[0,1] is the same as the cardinality of the real interval Q=[0, infinity]: The function f(x) = 1/x-1 is a bijective function that maps the P interval onto the Q interval, which also proves the cardinality of the two sets is equal. (https://en.wikipedia.org/wiki/Bijection#Cardinality).
If you're not comfortable with 1/0 = infinity as a general matter, then simply replace the f(x) I gave with an explicit piecewise function f(x) = { 0 if x = ∞, else (1/x-1) } and the proof still works.
these days, since I am doing bare metal embedded, I barely use valgrind; but it is game changing in the situations where it's useful.
gmp contains not only the basic operations on arbitrary precision integers, it also contains a highly efficient implementation of the fibonacci sequence.
It uses a recurrence relation other than the ones mentioned, that can generate F(2k-1) and F(2k+1) quickly from F(k) and F(k-1): https://gmplib.org/manual/Fibonacci-Numbers-Algorithm
(so in a way it's similar to the repeated squaring matrix algorithm, you find your way up to the desired number in log2(n) uses of the recurrence relation)
My particular computer (AMD Ryzen 7 3700X) can compute fibonacci(21'500'000) (21 and a half million) as a 149,262,011 bit number in right around 1s. The wrapper program is not very interesting, it's literally just calling `mpz_class::fibonacci`...: https://gist.github.com/jepler/9908e9ee4a7b0becc11edbedf8b76...
(I commented out the line finding the decimal length of the resulting number, but this was not actually a very big part of the runtime and could probably still have stayed under 1s.)
On the same machine, OP's bin/field_ext.O3.out program takes a hair over 1 second to compute F(4 million) so it seems this algorithm, plus the probably better-optimized gmp, are well faster.
However, gmp gives out soon after: It only supports numbers up to (I think; it's been a while since I figured this out) CHAR_BIT * sizeof(int) * (1<<31) bits long so it literally can't find F(256 million):
gmp: overflow in mpz type
Command terminated by signal 6