Nobody in any RTA speedrunning community would question the legitimacy of tricks in a run that plays back on the Game Boy Player as it's the standard for most GB/GBC RTA speedrunning, and in actuality Donkey Kong '94's console verification helped prove some prior tricks to be the result of emulation inaccuracy.
The RTA speedrunning community, especially at speedrun.com, sometimes have rather incomprehensibly lax rules when it comes to what can be run where.
Perhaps the most prominent example that I'm very familiar with is Ocarina of Time: At speedrun.com, as long as it has been an officially released version of the game for an officially supported platform, it's A-ok. Moreover, it doesn't matter which version of the game you are running on which platform, they are all competing on the exact same leaderboard.
This has a quite long history. Many years ago, perhaps a bit controversially, running OoT on the iQue console was considered completely valid, and categorized on the exact same leaderboard as the N64 runs. The issue? The iQue is a bit faster than the N64 which means there are less lag frames (or something to that effect), which allowed a bit faster runs. Thus OoT speedrunners who only owned a N64 had to compete against those who had purchased an iQue (which is not as easily available as the N64, because the iQue was only released in China). In other words, there was a bit of a pay-to-win situation here.
A bit more recently, and a lot more prominently, the OoT running on the Wii Virtual Console was also not only accepted, but accepted on the exact same leaderboard as the original N64 runs. This is, IMO, even more controversial because Virtual Console does not emulate the N64 absolutely perfectly, allowing for glitches that aren't possible on the latter (most prominently the item delay glitch, which saves like 2 or so minutes on the (current) "Defeat Ganon" category, which was for many years the main "any%" category, only works on the Wii Virtual Console, and doesn't work on the N64.)
Here at tasvideos even if the Wii Virtual Console version were to be accepted, it would be considered a completely separate version from the N64 version, especially because of the emulation inaccuracies. Not so at speedrun.com, for reasons that I cannot really comprehend.
While -W(-1) is one solution (I'm not going to talk more about this; go see blackpenredpen if you're interested), this reasoning doesn't explain why there aren't any other solutions, since any z such that e^(e^z) = z (not necessarily e^z=z) could be a candidate solution for e^z = ln(z).
Does there being only one solution mean that the two surfaces formed on the complex plane by ez and ln(z) only touch at one single point?
If that's so, is this coincidental, or is there a mathematical reason for this?
I think a good definition would be "a timesave that's unexpectedly large, given the history of the game so far".
I wonder if it could also apply if, for example, the new TAS uses a very different route than the previous one, even if the timesave it gives isn't extraordinary. The "notability" in this case would be that it's very different as a viewing experience compared to the previous one, because of the different route.
Except in the case where there is a logic difference between emulator and console (like a glitch that cannot be done on console that's exploited in the TAS), I'd consider the easier ability to reproduce, distribute and introspect a TAS in an emulator to be more useful of a quality than the modified version that plays back on console but not yet on any emulator, since far more people have the ability to interact with the former than the latter (though we should of course still make both available). Yes, the console verified file is more accurate but less accessible.
Given that, as far as I know, it's impossible to create a TAS without an emulator, I find the scenario quite unlikely that there would be a console-only TAS with no emulator version.
Would this be the proper place to, perhaps, rekindle a bit the discussion I started in another thread (that was less relevant to this particular topic) about the fact that, apparently, we consider the emulator the sort of "highest authority" on what is considered a valid legit TAS, rather than the actual console it's emulating. In other words, as long as the TAS syncs and works with the emulator, it's considered valid and legit even if the same TAS fails to sync on the actual console hardware.
This feels a bit contradictory with the sentiments that TASes should at least theoretically be replicable, as is, in the actual console and that, for example, TASes that rely on emulator bugs or faulty emulation are not considered valid.
In the cases where a TAS does not sync in the actual hardware because the emulator does not emulate the hardware 100% correctly, and it's these tiny differences that are the problem, shouldn't this be considered the TAS relying to faulty emulation to work correctly, and thus technically speaking not fully valid?
(Of course there are consoles where it's essentially impossible to make a prerecorded TAS work correctly eg. because of non-deterministic reading times of disc-based mass media, but these consoles could be considered separately from those that are completely deterministic.)
I'm not saying that TASes that have not been console-verified at all should be considered somehow "invalid" or "dubious". They could be considered provisionally legit, unless proven otherwise. However, in the cases where the TAS does not sync in the console without modification, shouldn't this modified version be considered the official valid version of the TAS (with the version that syncs on the console being just a side version for those who want to replay it on the emulator)?
It's a bit counter-intuitive that even in the clear-cut cases where a TAS needs to be slightly modified to sync on the console because of lacking emulation accuracy, it's still the emulator version of the TAS that's considered the official legit version, rather than the console version.
While it might not be a 100% unambiguous universally agreed set-in-stone definition, there is a relatively widely accepted definition of what constitutes a "closed-form expression". The set of operations and functions to be included in "closed-form expressions" may be somewhat arbitrary, but there exists a somewhat consistent consensus on this list.
For example the basic trigonometric functions are usually included in the list, but more exotic functions (like the gamma function or the bessel functions) are not.
I don't think it's very useful to start nitpicking about the exact definition, and just go with, for example, what's listed at the wikipedia article.
It's also not very useful to engage in trickery like "we define the function smartass(a, b) to be the exact perimeter of an ellipse with radiuses a and b. Therefore the closed-form expression for the perimeter is smartass(a, b)." This would just be a useless circular (hah!) definition.
One interesting point: the realtime speedrunning community considers this a legitimate completion of the game, but what it's actually doing is warping to a point in the middle of the credits.
Is there a flag or some other way of recording game completion that exists within the game? If so, does the run set it?
I think this TAS would be worth accepting anyway, but it may need a category designed explicitly to make it clear what goal it's going for, something like "credits warp".
The "credit warp" category has always spawned the discussion of what exactly constitutes "completing the game" and what doesn't. Ultimately, when we go to the very core of the issue, there is no 100% accurate technical definition of what constitutes "completing the game", and it all boils down to an argument from popularity: Whatever the majority of the speedrunning community decides is a valid completion will be considered a valid completion. It doesn't really need a more technical definition than that.
In this particular case (ie. in the case of OoT), it has been decided that if the game shows anything from the end credits (starting from anywhere in the end credits sequence) will be considered a "valid completion". I suppose that technically means that if there would be a way to jump from the file select screen to the final ending credits screen (the one that's a b&w freeze frame with a "the end" text in the middle), that's enough. The completion time could be like 0.1s, but that's fine.
At speedrun.com, perhaps partially not to throw away a decade of previous speedruns, partially to still keep a category that has a sense of "actually" completing the game (ie. delivering the final blow to Ganon) as fast as possible, there's a "defeat Ganon" category.
I'm of the strong opinion that "defeat Ganon" should also be considered a valid category for TASing as well.
Matt Parker in his latest video points out how, perhaps a bit surprisingly, there is no closed-form expression for the perimeter of an ellipse (at least not for the general case).
That got me thinking: Are there ellipses (other than the circle) where the major radius, the minor radius and the perimeter are all expressible with closed-form expressions?
(In this context "closed-form expression" excludes integrals.)
Here is 128 by 64 division for aarch64. highest bit of b should be set! This is what I mean by aligned. This is essential of long division. If it's not set then shift both operands until it's set.
I notice that if the inputs are shifted to the left until the highest bit of b is set, then the returned remainder also needs to be shifted to the right by that same amount.
I must admit that without understanding the math behind it, the code is almost incomprehensible to me. Even after reading it for like an hour I cannot understand what it's doing.
(It's also rather appalling how astonishingly complicated multiprecision division is, compared to all the other arithmetic operations. Or even short division, if a double-sized-register-divided-by-register operation is not available. Understanding even something like the Karatsuba multiplication algorithm is peanuts compared to this. It's inscrutable.)
I might settle for a short division with a limit of 32 bits for the divisor. At least that's trivial to implement.
I'm interpreting your task as: we can do N bits by N division / addition / subtraction / multiplication. Also multiplication of N bits by N gives N bits.
If it helps, it is possible to get the full 128-bit result of a 64-bit multiplication in this case. (The architecture in question is aarch64.)
(otherwise why you can't divide 2N bits by N?)
The aarch64 instruction set has a way to get the full 128-bit result of a multiplication, but does not have support for dividing a 128-bit value by a 64-bit one.
First, as I said: split N bits into N/2 bits and do long division, because you can now divide (N/2)*2 by (N/2) which is required for long division.
I wish I knew how to implement long division, but I don't. (The grade school "long division" algorithm is pretty useless because it's hilariously circular and completely unhelpful. It essentially says "to calculate A/B, find the largest C for which B*C<=A"... which is the very definition of A/B. In other words, it's just saying "to calculate A/B, calculate A/B". Gee, thanks.)
Other way is to use binary search to implement 2N by N division, and use basic short division algorithm.
One would think that when a fast N by N division is available, one wouldn't have to resort to a complicated 64-step binary search in order to calculate a 2N by N division. There has to be a way to take advantage of that N/N operation to make it faster.
Problem is, if we halve the size of the digits (eg. consider the operands to consist of 32-bit values instead of 64-bit values) now it's not a short division anymore, because it would be dividing a multi-digit value by a 2-digit value (because now the divisor is being interpreted as having the size of two 32-bit values).
While now we do have a 64-bit/32-bit division operation available, I'm not sure this becomes any easier, because the divisor is not single-digit anymore.
Or is there an easy "short division" algorithm that works for a two-digit divisor?
I'm trying to figure out a way to do short division (ie. dividing a multi-digit value with a single-digit value) when all you have available is single-digit arithmetic (and bitwise) operations.
Short division is quite simple if you could divide (and get a remainder of) a 2-digit value by a 1-digit value, but it's not as trivial if all you have is single-digit division.
Essentially, one would need a way to divide a 2-digit value by a single digit value, using only single-digit arithmetic. For short division in particular the constraint can be safely assumed that the most-significant digit of the dividend is always smaller than the divisor (and therefore the quotient and remainder are both always single-digit).
Preferably the solution would not involve looping and searching (because in this case we are not talking about digits in the range 0, 9, but digits in the range 0, 264-1. Even a 64-iteration binary-search loop would be a bit too much.)
Yes, "parabolaness" is preserved under all (bijective) affine transformations; a parabola remains a parabola when you apply uneven x/y scaling or any isometry (rotation, reflection, translation), and since those operations generate the affine transformations, a parabola remains a parabola under any affine transformation.
If applying an affine transformation (which may include uneven scaling) to a parabola gives another parabola, and given that all parabolas are similar (something that can be proven with a bit of elementary algebra), that ought to mean that any affine transformation done to a parabola can be replaced with a similarity transformation that gives the exact same resulting parabola. Is that so?
Is there a formula or algorithm to deduce the equivalent similarity transformation from a given affine transformation?
I recently go the idea: Suppose you needed to represent a particular permutation of all the integers between 1 and 100 in a binary data file for example. What is the smallest space you can squeeze this data into (regardless of what permutation it is, ie. we are looking at the worst case scenario here, ie. no permutation will ever take more than this much space.)
Obviously you could just store one byte per value, which would take 100 bytes. Also likewise obviously this is very wasteful because there's a lot of unused numeric representation being wasted here.
The next idea is to store it, essentially, as a "base-100" number. In other words, we store them as values in the range 0-99 (inclusive), we take the first number, multiply it by 100, add the second number, multiply the entire thing by 100, add the third number, and so on until the last number has been added. This takes ceil(log2(100^100)) = 665 bits (ie. a bit less than 84 bytes).
But this isn't the best we can do either. After all, once we have listed 99 numbers we don't need to list the final one because there's only one possibility. We need only 658 bits for this (which fit in 83 bytes).
But wait, there's still more. We still have too much unused space. After all, once the first number has been given, there are only 99 other numbers that can come next. Since this is a permutation, the same number cannot come again. Thus we can reduce the range by one after each number. (So, for example, if the first number given was 60, the next one will be taken as-is if it was less than 60, and incremented by one if it's 60 or larger. Then the next number would be incremented by 0, 1 or 2 depending on which range it's in, and so on.)
In other words, we take the first number, multiply it by 99, then the second number, adjust it as necessary and add it, then we multiply the result by 98, take the third number, adjust it as needed and add it, and so on and so forth.
How many bits does the list take now?
Is there a way to still make it smaller?
All parabolas are similar. This means that you can take any parabola and by simply rotating it, flipping it, translating it and scaling it equally in all directions, you can map it exactly on any other parabola.
I was wondering if there's a name for those allowed transformations. (They are not affine transformations because those allow uneven scaling.)
Dark Boshy, as it is considered the most fun way to play, mostly because of his large bullets.
So by fun, you mean effectively the easiest character to play as? Seems odd for a TAS, since you can just land precise shots anyways.
Related to this I have been meaning to ask: Does "avg-mode" mean "not the hardest mode"? Because I remember there being a rule that TASes should always play on the hardest mode unless there's a good reason not to.
Actually when I thought about it afterwards, the answer is much, much simpler than I thought. I'm in fact a bit embarrassed of not realizing it pretty much immediately, as it's pretty trivial.
The reason why 0.12345678901234... is not in the list is because it simply cannot be added to the list due to the constraint of the diagonal. There is no place in the list where you could add it without it breaking the rule imposed on the diagonal.
After all, the constraint is "the first digit (after the decimal point) must be 0, or the second digit must be 1, or the third digit must be 2, ..., or the 10th digit must be 9, or the 11th digit must be 0, or the 12th digit must be 1, ..." and so on and so forth, and that number doesn't fulfill that constraint anywhere. (And it's rather easy to prove that there are infinitely many rational numbers that don't fulfill that constraint.)
On the other hand, this leads to the semi-interesting fact that it's impossible to list the rational numbers in a manner that the diagonal of their decimal representation would be a rational number. Or, in other words, no matter how you reorder the list of rationals, the diagonal will always form an irrational number.
If I write that last idea of mine a bit more semi-formally, I suppose it would be something like:
Let's assume that we can list all rational numbers between 0 and 1 in such an order that the diagonal of their decimal expansion has the infinitely-repeating pattern 0123456789. In other words:
0.0xxxxx...
0.x1xxxx...
0.xx2xxx...
0.xxx3xx...
and so on. We can now construct a new number that consists of all those digits in the diagonal, incremented by 1 (the digit 9 would "wrap around" to 0), ie:
0.123456789012345...
However, since this new number is different from any of the numbers in the list, and this new number is a rational number (all numbers whose decimal expansion is repeating is a rational number), we have a contradiction: The list was supposed to be complete (ie. contain all the rational numbers between 0 and 1) but we created one that was not in the list.
The only possible conclusion is that the assumption that we can list all the rational numbers in such an order is impossible.
But it's not immediately obvious nor intuitive why that's so. I suppose my question would be if there is an intuitive explanation of why they cannot be listed in such an order.
(Or, maybe there's another explanation for this?)
I'm not so certain that the vaccine is irrelevant.
Remember that the Spanish Flu pandemic lasted for a whopping 3 years before dying out, with several waves of it sweeping over the world. While this pandemic is not nearly as bad in terms of deaths, it's not out of the realm of possibility that it may likewise last for several years.
Most people don't get infected during a wave, and thus they are fertile ground for the virus during the next wave. There's only so much that preventive measures do.
A vaccine, if it gives immunity for several years, is the most effective way of actually stopping the pandemic a lot quicker and in a much safer way.
As a side note, I noticed that the diagonal argument also proves (I think) that you cannot list all the rational numbers in such an order that eg. their decimal expansions all have the same digit on the diagonal, or in such a way that the diagonal contains a repeating pattern (eg. 0123456789012345... etc)
If you could list all the rational numbers in that way, the diagonalization would just produce a rational number.
I think it's relatively obvious to see why the diagonal cannot contain only one repeated digit (because not all rational numbers contain that digit anywhere). It's less obvious why it can't contain a repeating pattern.
