jepler

My mind just balks at the idea of having so much source that a 2020s computer could take hours to index it. ctags is nothing special (both in terms of optimization but also the level of detail it gets to: just global function identifiers) and looks like it runs at about 400MB/s on a single core of an i5-1235U. But still it looks ctags could process about 100TB in 4 hours across 16 threads on a workstation class CPU...

According to http://comopt.ifi.uni-heidelberg.de/software/TSPLIB95/STSP.h... the optimal solution for eil51 is 426 (the linked page has a tour of 428.87) and the optimal solution for st70 is 675 (the linked page has a tour of 677.11).

I wonder whether you still have a bug. It depends how "scanning" is implemented.

    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 don't know Haskell, so I can imagine if you didn't know Python it'd be "greek to you" (unintelligible). I'll try explaining in prose what I did. [note: I also edited the grandparent comment because when I simplified the session I showed, the assignment of "s" ended up out of order]

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.

assuming you mean the decimal expansion and a length-3 de bruijn sequence on 10 symbols, I am not seeing it. There seem to be many sub-sequences which do not appear. (assuming that python's Decimal library at a precision of 4000 digits is actually giving the first 1000 digits correctly; though I have no reason to doubt this I don't know for sure the maximum ULP error of exponent)

    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 = sd[2:][:1000]
    >>> s[:10], s[-10:]
    ('4989198720', '6163659068')
    >>> [i for i in range(1000) if "%03d" % i not in s+s]
    [0, 2, 4, 5, 9, [...], 993, 994, 995, 998, 999]
    >>> len(_)
    361

and it's back now. No incidents reported on status.python.org.

there was some discussion on at least two github issues: https://github.com/python/cpython/issues/127307 and https://github.com/python/pythondotorg/issues/2663

No downtime noted yet at https://status.python.org/ but confirmed from here

Too tired to find the actual debunking of these claims but no, d-wave is not effective for cryptanalysis of RSA or AES as deployed.

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.

Anil is a given first name, maybe just not in your culture.

You don't need machine code these days to find overflow in IEEE floating point arithmetic.

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.

If you're writing for an audience outside of India you might want to explain what ₹9 lakh equates to, as both the value of ₹1 and the magnitude of the lakh are probably unfamiliar.

(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)

https://www.flightconnections.com/flights-from-iah-to-hav there are direct flights from USA to Cuba these days

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)

I'd take recourse to https://en.wikipedia.org/wiki/Bremermann%27s_limit

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.

A modest proposal: stop adopting new digraphs like [:, ^^, [[.

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.

since this is a 'walled site, you can just have a read of the official release notes and then the related PEPs ...

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.

I was curious how this thing did video. As you might expect, it's done by bit-banging the VGA RGB output pin from an IRQ. A time honored tradition. Here's the code in the Tetris demo: https://github.com/OLIMEX/RVPC/blob/main/SOFTWARE/Demo-Tetri...

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).

[1] https://people.csail.mit.edu/jaffer/Geometry/PSFC

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.

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.

wikipedia has a high level review of current constraints: https://en.wikipedia.org/wiki/Time-variation_of_fundamental_...

    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.

I had no idea the BF16 format was actually named "brain float". TIL.

This is quite possible, and I'm sure someone's doing it. At $OLD_DAY_JOB I developed a way to byte compile and then encrypt Python byte code for plug-ins, to meet a requirement from some third party partner.

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.

bsd/vfs/vfs_vnops.c:

        if (write_offset == INT64_MAX) {
                /* writes are not possible */
                error = EFBIG;
                goto error_out;
        }

That may feel like an intuitive declaration, but that's not how it works in standard mathematics. In standard set theory, the cardinality of the reals is equal to the cardinality of any non-degenerate interval of reals. Wikipedia quotes this fact without proof (https://en.wikipedia.org/wiki/Cardinality_of_the_continuum#S...).

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.

at $OLD_JOB I literally joked that we used a fork of valgrind just to fix the pronunciation. of course, our fork was also years behind the official version.

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.

Weird

You Can't Solve These Super Mario Bros. Levels: Undecidable Mario Games https://arxiv.org/abs/2405.10546

First off .. let me say I liked the video, it was a good overview and packed a lot of knowledge.

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