Hacker Newsnew | past | comments | ask | show | jobs | submit | tromp's commentslogin

The linked-to page mentions:

> Infinite length Mazes: It's possible to create an infinitely long Maze (a finite number of columns by as many rows as you like) by only keeping part of the Maze in memory at a time and "scrolling" from one end to the other, discarding earlier rows while creating later rows.

> An easier way to make an infinite Maze is with Eller's or the Sidewinder algorithms, as they already make Mazes one row at time, so simply keep letting them add rows to the Maze forever.

My tiny obfuscated maze program at https://tromp.github.io/pearls.html#maze will print an infinitely long maze if you enter a negative height.


Great idea. However it is infinite in one direction. Could be made infinite in two directions (I guess) by extending along a diagonal line that get long with each step. Probably could also make it infinite in all directions with a square that gets extended with each step. However, that would mean that if one walks away from the origin, the maze has to be generated in all directions. For practical applications it would be nice to only generate the part of the maze that is 'visible' from a certain point of view (either from the top or while walking inside the maze up to a certain distance).

The notation used seems rather confusing, not even showing the list of arguments. For example, the argument swapping combinator C which is normally defined as

    C f x y = f y x
is shown on this page as as y F x, which I can only make sense of by assuming that F is an infix function. In Haskell you could use infix notation to define

    C f x y = y `f` x
but you can't use capitalize function arguments.

I think that "having no known quantum attack" is a reasonable interpretation of "quantum resistant". If there were no possible "quantum attack" (under appropriate complexity assumptions, such as EC-DLP not being in P), then we could call it "quantum proof" instead of quantum resistant.

I understand what you mean, but I think such a concept or definition would be highly misleading: "having no known quantum attack" means every novel encryption method would be automatically "quantum resistant" for having had 0 adversarial attempts to find quantum or even classical weaknesses!

There should be some measure of competence-level-adjusted man-hours of cryptographers and mathematicians trying to swing their favorite hammers at the problem; in order to estimate this "quantum resilience".


In minutes, on a single computer, for example, is the lowest bar.

* https://mathematical-research-institute.sydney.edu.au/quantu...

* https://magma.maths.usyd.edu.au/magma/

Props to John Cannon, George Havas, Charles Leedham-Green, et al.


> let webWorkerURL = `${options.basePrefix}/.within.website/x/cmd/anubis/static/js/worker/sha256-${workerMethod}.mjs?cacheBuster=${options.version}`;

It looks like it's computing sha256 hashes. Such an ASIC friendly PoW has the downside that someone with ASICs would be able to either overwhelm the site or drive up the difficulty so high that CPUs can never get through.



Make that almost nobody.

I wrote a non-trivial lambda program [1] which enumerates proofs in the Calculus of Constructions to demonstrate [2] that BBλ(1850) > Loader's Number.

[1] https://github.com/tromp/AIT/blob/master/fast_growing_and_co...

[2] https://codegolf.stackexchange.com/questions/176966/golf-a-n...




Thanks, great read. Fills in quite a few holes in my own understanding of events.

Doesn't exactly leave one optimistic for a favorable final outcome, given how much U235 they supposedly already enriched to 60%. As I understand it, they could build twice as many bombs if they took the time to enrich to 90%, but they could build at least some now if they felt they had a reason to hurry.

I wouldn't be surprised if they felt they had a reason to hurry.


As nicely illustrated in this Young Sheldon episode fragment: https://www.youtube.com/shorts/Nd90rFPYVnc


I would have gone with South Park's murder porn episode in which the kids accidentally got the parents interested in Minecraft.


Are you aware that every YT Short can also be viewed with the normal player? If you do, do you prefer the Shorts interface and thus posted that URL rather then https://www.youtube.com/watch?v=Nd90rFPYVnc ?


Or a C implementation at https://tromp.github.io/pearls.html#sieve which runs in well under 10s.


I'd be interested in seeing an explanation of the code, since it looks pretty incomprehensible to me. Per the arbitrary rules I set for myself, I'm not allowed to precompute/hardcode the wheel (looks like this implementation uses a hardcoded wheel of size 2x3x5=30). I wonder if/by how much the performance would suffer by computing and storing the coprime remainders in memory instead of handing them directly to the compiler.


I wrote this in a semi obfuscated style to make it fit on one screen. It's indeed a hardcoded 2x3x5 wheel; but I suspect computing all those constants would have made the program significantly longer.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: