I'm thinking your hypothesis is false, but I just have a thought, and that's far from a proof. A rational number can be written as x/y. By allowing negative a1 etc., you get the 1/y part. But what about a number x/y where you need the same number p1, p2, or p3 to make both x and y?
I'd think the rule below the extracted games rule actually prohibits wii vc games:
Play games that are emulated well
Emulation of several platforms such as Nintendo 64, DOS, Arcades is still far from perfect, and some games work worse than others. This may be grey area on such systems, but we generally aim to publish videos that look like they could be played back on the original video game system. Movies of games that are not emulated well (have graphical or functional glitches that do not exist on the real console) should not be submitted.
To call a wii vc emulated game the "original video game system" is a hard sell, in my opinion.
The run is a bit repetitive to me. If it was only the last half hour, it would be a blast for sure. It's still a very pretty and cute game, but this is a 'meh' for me.
Certainly did not see that coming, as the previous 100% tas was done, except for the final bosses I think (and commentary if you want to count that)? It clocked in at 22 hours or something, so I'm not all that giddy to watch everything again, but I am interested in what the differences are between the old and the new. At hte very least I see that 99 of every possible item is not a goal anymore.
For 2n=8 it becomes somewhat difficult to keep track of the possibilities with pen and paper, and I haven't yet felt up to programming something up to crunch through the possibilities.
I tried to write something down with pen and paper for 8, and it becomes quite a monstrosity. There's a lot of branches, and except one the few I tried all died. It's just very hard to see whether a suggested branch will die off rounds later without trying. In the end, I would not be surprised to see that there are 3 unique ways, and that for every step you increase n, the answer is the nth number in the fibonacci sequence (with n = (1,2,3) the #ways are (1,1,2) after all). But that is a wild guess.
Edit: obviously, thanks to r57shell, I was all wrong. I tried to find the specific ways voor 6, and that worked out, but that was already quite difficult to keep organised.
As I understand it, a countable set of infinite numbers has a method that eventually, given infinite time, maps the set to the sequence 1 to infinity. Cantor's diagonal argument (applied to the set of Real numbers at the very least) is a method that proves that whatever your method of indexing R, there is always a number not on your list.
Your example is different. You give the set N in binary but inverted, but that is obviously still a set of numbers mappable to N: it is a countable set. The diagonal argument does indeed not apply in this case, but then again, it never was supposed to.
Would it be helpful to have a tiered system? Like, one strict tier where the input as is (so including any changes necessary to get the input file suited to the NES/GB(C) shenanigans, but excluding lag frames etc.) is console verified, and one looser tier where a certain amount of lag frame edits are allowed. This looser tier would prove that gameplay-wise it is the game being abused and not the emulator used. The stricter tier would also prove any hardware tricks are absolutely legit.
This doesn't say anything about non-deterministic problems, but it might be a start. In any case, I think the rules for console verification should spring from the reasons why you would want to console verify at all, and the only reason I can think to do that is because you distrust the emulator is completely correct.
I have the Logitech M500 as well, and it really is a very nice mouse. As for the wheel, it requires enough force that you'd never press it accidentily, is a bit tougher than the left/right click, but is still a very casual click.
Chanoyu, looks like you ignoring that 10 heads may appear as subsequence. Your calculations holds when you do: 10 toss. Is all heads or tails? no! Make fresh new 10 tosses. But what if it was 1 tail and 10 heads 9 tails? Your calculation assume those two as two fails in the row.
This is certainly true of my solution where you do not decide heads or tails first, but I don't think it applies for the solution where you do decide that before the first cointoss. I'll try whether I can understand it a bit better with some simulations myself.
Edit: I ran the simulations. I discovered my estimate of 2036 was wrong, by 10, because what I said ("'10 (the succesful sequence) -> 1*10 = 10 "') is untrue: the sequence can of course still fail on the 10th cointoss. If it doesn't, only then the succesful sequence is reached of 10 additional cointosses. My program does not disagree (in running it three times I got 2045, 2024 and 2057; for lower numbers of consecutive heads it agreed closer). So either I'm right in this case, or my code is wrong also.
If I apply the same correction to my 'don't care about heads or tails' solution, I get 1023 average tries. My code does not disagree, in multiple tries it hovers about that number as well. It really may have been that simple.
This is my python code, with commented what is only for both heads and tails instead of only heads:
import random
consecutive = 10
coin = ('h', 't')
totaltosscount = 100000000
tosscount = 0
tossesneeded = []
sequence = ''
heads = ''
#tails = ''
for i in range(consecutive):
heads += 'h'
# tails += 't'
for i in range(totaltosscount):
tosscount += 1
sequence += random.choice(coin)
if len(sequence) == consecutive:
if sequence == heads #or sequence == tails:
tossesneeded.append(tosscount)
tosscount = 0
sequence = ''
else:
sequence = sequence[1:]
print(sum(tossesneeded)/len(tossesneeded))
The chances of 10 consecutive 50% chances is 0.5^10=0.0009765625. If you want the average amount of tries to get this chance, it's 1/0.0009765625=1024. This means you have to try 1024 times on avarage to get 10 consecutive cointosses heads. If you want either heads or tails, this gets halved to 512.
The next question is, how many cointosses does it take on avarage to get to the avarage 1024 tries to get 10 consecutive heads? Of course, not every try takes only one cointoss (if you care not whether you get 10 heads or 10 tails, every try takes at least two cointosses). If you care only for heads, these are the numbers:
1 cointoss until failure (=tails) -> 50% chance, so .5*1024=512 tries of one cointoss.
2 cointosses until failure -> 25% chance, so .25*1024=256 tries of two cointosses means 512 cointosses.
3 cointosses until failure -> 12.5% chance, so 128 tries of three means 384 cointosses.
4 -> 64 tries of 4 means 256 cointosses.
5 -> 32*5=160
6 -> 16*6=96
7 -> 8*7=56
8 -> 4*8=32
9 -> 2*9=18
10 (the succesful sequence) -> 1*10 = 10
adding all these up together gets us the avarage number of cointosses to get 10 consecutive heads. It is 2036.
You could do the same thing if you don't care about heads or tails. Since that is the same as flipping a coin to decide whether you want 9 consecutive heads or tails, we can use the method above to get to the answer. 512 tries to get to 9 consecutives, 1*.5^1*512+2*.5^2*512+etc up to 9*.5^9*512=1013 cointosses, plus the one cointoss to decide heads or tails, means the avarage number of cointosses to get 10 consecutive of either heads or tails and you don't care which is 1014.
If you want to know how many 10-consecutives you get on avarage in a million cointosses, it's 1000000/2036=~491 or 1000000/1014=~986
I think for a typical long division, your divisor is way smaller than your dividend, and usually two digits or so. Then the method cuts up the big division in smaller parts. For your example it doesn't do much, though it still works.
And, in long division you do not need to compute the greatest multiple. You can choose to just subtract the divisor of the dividend one by one, it's just more effective to subtract the most you can. This, at least, is how I first learned it at school. Subtracting the greatest multiple at once was an advanced technique, since it requires you to compute more in your head.
Reading comprehension is hard, apparently.
How I got to it, is that the fastest route is a straight line form start to finish. If that's impossible, then you want the straightest line, and that requires a jump parallel to the straight line.
Though I do not think the movie very entertaining in itself, it does have a high entertainment per second value. As with all ACE glitches, and maybe even as all glitches, the entertainment of them lies in, I think, in these aspects: 1) speed; 2) surprise; 3) absurdity.
Bypassing the Door of Time in OoT, going out of bounds in Metroid Prime, abusing hitboxes, but also this DPCM glitch, I think they all have either nothing to do with gameplay, or they are all a part of gameplay. They all have that air of cheating associated with them, because you bypass the rules of the game as a normal player would see them. But they do not bypass the rules of the game as programmed.
Getting a missile underflow or w/e in Super Metroid for unlimited missiles and the beating the last bosses quickly is fun in its own way. But it's a different kind of fun from the killing Materia keeping by combining the mechanics of poison and lucky 7777. In the case of SMB3, whether the game-ending glitch takes place at the title screen, or in a level in world 7, the one is as unrelated to gameplay as the other. The one just takes more normal (superhuman) play to get where the fun begins, or ends. In both cases slowing the movie down does nothing, there is nothing to understand when viewing without the submission notes, they are both, if entertaining, entertaining through their speed, surprise and absurdity. I cannot see the difference.
Thanks feos. It's a fate I wouldn't wish on Super Metroid either, but I think it's important to keep in mind that forgoing major skip glitches in favour of entertainment is not that different from forgoing certain less major skip glitches in favour of entertainment.
With a 100% movie that uses glitches corrupting graphics, we can't also have a 100% branch that doesn't. They would be too similar in too many ways. But as I said, nothing prevents avoiding those glitches in unvaultable branches. So everyone can have something that pleases them the most. Unfortunately, it's impossible to constantly remain entertaining for everyone if the knowledge base on a game is quickly evolving.
On this subject, wouldn't the vaultable 100% run of SM probably use space-time beam or some other major skip glitch not used here?
I see what you mean. If a=b=c, then they need to be > l/2cos(30°) (about 0,577l). If you choose a = 0, then b and c have to be at least l.
So if a, b, c > 0,577l, then it's possible for sure, but if one of them is less, the others have to compensate.
With a = b = c, that's the simplest case, as I understand it, seeing as the three sides of the pyramid will be identical. The top vertex would be above the dead center (centroid it's called?) of the base.
At least, if you take a triangular pyramid to mean a pyramid made out of four triangles (http://mathworld.wolfram.com/TriangularPyramid.html). How do you understand it Bruno?
Some quick constructionwork with paper and scissors suggests it will work.
The bounds for choosing a, b, c, and l are literally that the triangles abl, bcl, and acl exist. Obviously, triangle lll exists also.
1) So, we choose lll as base.
2) We place abl at one of the three sides (angle to be determined).
3) Then, we place acl so that its edge a borders edge a of abl (the angles are locked now). This is always possible, but what the angles are between the base and the sides is dependent on the lengths chosen.
4) We now have a triangular pyramid with one side open. This triangle is defined by three edges, l at the bottom, and b and c at the sides. This triangle lbc exists, since that was a requirement in choosing a, b, c, and l.
The point of the pyramid may not be above the base though, so if filled with a homogenous substance it may fall over.
I watched the main differences with the previous submission. An improvement in time, and in entertainment, as more bosses are fought without slots. I always liked the music after the Gi Cave though. Overall, same as last time, the run is impressive, but not so very entertaining. Great work all the same.
I watched the fixed graphics encode, and that was amazing and fun to watch, so thanks for the great movie. Even so, I struggle with the non-fixed graphics encode, where it's all just so hard to follow, that I have no choice but to tune out.
Best moments were the elevator rides.