jkafjanvnfaf

How accurate is this two-pass approach in general? From my outsider's perspective, it always looked like most of the difficulty in implementing Lanczos was reorthogonalization, which will be hard to do with the two-pass algorithm.

Or is this mostly a problem when you actually want to calculate the eigenvectors themselves, and not just matrix functions?

"Esports" is not a league. That would be like saying "sports" is a league.

There are leagues around some games (like the ones mentioned in the article). There are also events with "league" in the name that are not really leagues (like ESL Pro League). In any case, none of them are financially successful in the US.

It's new because it makes no sense.

There already is an implicit "branch" on every array access in C, it's called an access violation.

Do they test for a segfault on every single array access in the code base? No? Then they don't really have 100% branch coverage, do they?

The only series that release "every 12-18 months" are sports games and Call of Duty, and I can assure you that the overlap between that audience and the Persona one (which has five main-series entries of which barely anyone has played the first two) is extremely small.

Have you considered that you may just be very out of touch?

Nice writeup and algorithm. My first instinct would have been to take the lazy way out and just use a table with 365 entries (or 366, or both depending on the implementation), but this is a lot more elegant.

First of all, you are correct that nonlinear optics usually requires high field strengths. But...

>Photons are bosons and therefore are very reluctant to interact, essentially requiring nonlinearities.

Please don't throw out random sciency terms. First of all, interaction is pretty much by definition nonlinear. Second, photons are not reluctant to interact. Photon-photon scattering is negligible (which has nothing to do with them being bosons, as gluons and mesons readily demonstrate), but nonlinear optics doesn't rely on photon-photon scattering.

For completeness, there are languages that do not require stacks to implement (nor any workarounds that in practice emulate a stack). If you do not support explicit recursion, you don't need one. All variables can be statically allocated and only a single return address needs to be stored for each function, so you do not need a stack for return addresses either.

The most famous example is FORTRAN, until 1990 when they added RECURSIVE directive.

The usual technique is to keep a 4-element array of sums (so sum[j] is the sum of all terms of the form a[4*i + j] * b[4*i + j]), and then take the total at the very end. This allows for the use of vectorization even with strict IEEE-compliance.

Generally, I would recommend against -ffast-math mostly because it enables -ffinite-math-only and that one can really blow up in your face. Most other flags (like -funsafe-math-operations) aren't that bad from an accuracy standpoint. Obviously you should not turn them on for code that you have actually tuned to minimize error, but in other cases they barely ever degrade the results.

That is true. Still, we are kind of trading one unintuitive postulate (an invariant speed) for a different one: Why would we ever think that the time interval between two events can depend on the reference frame?

Sadly, I feel like SR can only really be "understood" as a complete theory. All the individual phenomena (time dilation, length contraction, relativity of simultaneity, constant speed of light etc.) are very hard to understand, because you cannot just take one of them and add it to classical relativity without immediately running into paradoxes. Only once the whole picture is known you see that all the pieces beautifully imply each other. This problem applies to every approach to the subject I've seen.

The mathematics are sound, but the reasoning around is unclear to me. The derivation shows that Lorentz transformations and Galilean transformations are the only ones that allow for the equivalence of all inertial frames, which is a nice result. But it clearly does require the additional assumption of an invariant speed to conclude that Lorentz transformations are anything more than a mathematical curiosity.

So what have we really gained? Since we still need the extra assumption that an invariant speed actually exists, we could've just gone the other way and done the light clock calculation to get the Lorentz transformation instead.

MATLAB had its first commercial releases in the mid-80s and had indexing syntax that looks pretty much the same. Since it got popular very quickly, I assume that it is the most immediate source of Fortran 90's indexing style.

ALGOL 68 had some form of array slicing as well, but I'm not sure how influential it really was in this department.

After thinking about the problem a bit, I've come up with a completely different approach. I'm sure this is known, but I can't find anything so I'd appreciate if someone can point me to a citation.

Generate two independent doubles a and b the "usual way", meaning from [0, 1) with equal spacings of 2^-53. Then calculate 2^-53*b + a. Assuming for simplicity that the rounding mode is towards zero, this gives a new random double in [0, 1). I've only done the math in my head so I'm not 100% sure on all the numbers, but I believe it scores pretty well at the criteria in the blog post; tentative results are

Probability of zero: 2^-106

Smallest nonzero: 2^-106

Largest non-seeable: approx. 2^-54

Distinct values: 2^58.7

The usual rounding mode (round to nearest, ties to even) will generate numbers in [0, 1] with very slight biases that need closer analysis. One could also go further and do e.g. 2^-106*c + 2^-53*b + a, but something like that should only be needed for for single-precision floats.

The obvious downside is that you always need two random integers and not just in the slow path. However, SIMD becomes easier because you don't need AVX512 for lzcnt.

This does look quite nice. I always felt that the operator precedence / association rules in other stack languages were by far the most difficult thing to get used to, not the nonstandard symbols. This appears more inviting in that regard.

I do have to question the choice of right-to-left (array language) evaluation order. I've personally always preferred left-to-right (stack language) evaluation. I feel like right-to-left requires you to think to the end of a line before you start typing anything at all, as the first thing you type is the last thing that's evaluated. Left-to-right would also allow re-evaluating and visualizing the stack as you write each operator.

Hello and thank you for the neat article. I have not finished it yet (I'm still partway through the ML bit), so ignore me if this is explained somewhere, but as far as I can see you only considered "generate and test for solvability" approaches. But isn't there a direct way to generate puzzles by solving the board "backwards"? Start with a single white piece on the board. Then, pick a random predecessor of that state; either the piece moved there normally or it was a capture. In the first case just move the white piece back, in the second replace it with a matching black piece and place a new white piece in a spot that could have captured it. Do this a few times until you are satisfied with the number of black pieces.

The biggest issue I can see right now is matching up the starting piece with the previous puzzle's ending piece, but I feel that should be manageable with some heuristics and brute force. And one would have to test whether the puzzles generated like this are actually "random-looking" enough.