Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
I was looking into continued fractions, and I found this OEIS wiki page on the subject.
It lists the basic continued fraction [0, 1, 2, 3, 4, 5]... as I_1(2)/I_0(2) where I_n is the modified Bessel Function of the 1st kind.
This is the last place I expected to see the Bessel function crop up. Any insight on why this is? I have been unable to find a proof.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
I was able to find a French paper that provides this formula as: "The slowest and heaviest formula imaginable to access pi, developed to verify a hypothesis on the volume of the sphere"
I don't know how slowly it converges. It might be sub-logarithmic.
A formula the converges approximately as quickly as Leibniz formula is the Wallis Product formula. This formula also has logarithmic convergence.
2/1 * 2/3 * 4/3 * 4/5 * 6/5 ...
Hope this helps.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
Well, x^(1/x) = e^(log(x)/x) in the domain of interest.
Using a similar approach, this satisfies the differential equation y' = x^-2(1 - log(x))y
The form of this is not so nice. But the x^-2 bit shouldn't affect the roots, even under repeated differentiation (it will however ensure that there will always be a log and a constant, so there will always be exactly one root from each term).
So... that's the outline of a proof, but the only problem, is I can't seem to figure out a way to prove that roots will never repeat.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
(d^n x^(1/x))/(dx^n) = x^(-n + 1/x) (1 - n + 1/x)_n for (n element Z and n>=0 and x!=1/x)
Where (x)_n is the Pochhammer symbol and represents (x)(x+1)(x+2)...(x+n-1)
This formula is polynomial of 1/x of degree n which can be easily shown to have positive zeroes (when 1/x = 1-n+m), multiplied by a term which is zero at no point while x > 0. However, one of the zeroes is at 1/x = 0. I'd look into this more to figure out where the final zero is coming from, but I have to drive.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
SPACKlick wrote:
GIM crashes on N64 but not on Virtual Console. I don't know if there's a way of testing runs on VC or not.
I'm highlighting this because it implies that the run might not be accepted even if it were submitted due to GIM.
I'm honestly rather happy it didn't get submitted because that would be a solid MONTH of drama.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
ruadath wrote:
So after extensive discussion on IRC, and some testing with a physical console, it turns out that even putting aside RAM initialization issues, the game is not being emulated correctly. There are apparently some issues (among other things) with the sound effects in this game that bsnes cannot emulate properly
I wasn't aware of this. Do you have a reference?
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
ruadath wrote:
There was some discussion on the irc today about certain SNES JRPGs (like Tales of Phantasia) having different initial RNG configurations based on whether BizHawk or lsnes was used. After doing some digging, it turned out that the source of the discrepancy was that the game seeds its initial RNG state with values of the RAM prior to initialization. lsnes sets its uninitialized RAM to all 0x55s, while BizHawk apparently uses some fixed pseudorandomly generated RAM state.
This brings up the question of what counts as a "proper," "valid," or "acceptable" initial WRAM configuration. I could not find any documentation on this topic so I thought that I would make a thread for people to discuss their philosophy with regard to this issue and perhaps even some actual data (if anyone has it)!
After some contemplation, I justified the "legitimacy" of my BizHawk run to myself by arguing that since the random number generation only depends on two bytes, the entropy is low enough (65536 states) that it is possible for a snes to power on with the RNG seed that BizHawk generates for it.
But that begs the question, why is it the case that adjusting the initial RAM values is not allowed by site rules? Why is the particular set of random values generated by BizHawk (which more likely than not do not correspond in any way to the values that a physical console would produce) preferred over some customized starting configuration?
Just wondering what people's thoughts are on this matter.
Some bits are correlated, some are anti-correlated. This might be true of groups as well. We don't know enough to demonstrate which power on states are valid and which are not.
In order to get sufficient statistical power, as much as a few hundred or few thousands cold power-ons can be be required.
Once this work is complete, the plausibility and possibility of various power on states can be evaluated. Until then, taking the conservative route is prudent.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
r57shell,
You've agreed that there is a velocity along the radius. If there is a velocity along the radius then the radius must change. Because the velocity is monotonic constant and in the negative direction it must constantly decrease. But in order to arrive at the next corner, it must attain the original radius. So therefore it cannot.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
eternaljwh wrote:
A program for dumping ROM through PCM already exists: TapeDump.
A modifier to make it RAM instead would not be all that hard, though I'm not sure if he's released source.
I suggest running your cart-variables that aren't in registers through on-cart RAM.
Don't forget: no interrupts nor subroutine calls until you've dumped stackpage.
Sweet! Thanks for the resource.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
dwangoAC wrote:
The only reasonable case to reject this run is that it does not use pure controller input but I think this limitation is unwise in this case as the expansion port is a valid port exposed to the end user. Therefore, this gets a Yes vote from me.
Disclaimer: I don't necessarily disagree, but I would like to play Devil's Advocate for a short period of time, because I think this is worth fleshing out.
The major difference between the two types of ports is that controllers are designed to be used by a human, whereas the expansion port is designed to be used by a piece of hardware.
From the perspective of the SNES, user input is user input, and there's very little distinction. But from the perspective of a human player, one is an input they can use, and the other requires specialized hardware.
While we are not ruled by the standards set by the speedrunning community, there is significant overlap between the communities of authors and viewers, and we do take cues back and forth. Most speed records disallow the usage of custom hardware. This rule was adopted to prevent usage of autofire and other controller features, but custom hardware to insert a ACE payload would be similar if not more egregious.
Personally, I like to think of a TAS as sort of an ideal. If I were infinitely good at a video game, and I sat down, how fast could I play it? Movies like this challenge this idea, because no matter how good I am, I don't have a method of interacting normally with the expansion port. Again, I'm fence sitting, and I don't have a strong opinion either way. But this, at least for me, brings up the questions of what a TAS is, and what a TAS should be, and I think that these questions should at least be explored.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
TheBirdOfPrey wrote:
Your suggestion of having the devs push a patch to the game is not so simple, they would have to deal with publishers, verifying the build stability, there is many more steps and bureaucracy to that process than is immediately obvious.
...
Thank you for that lesson on the complexities of indie development and publishing of which I was entirely unaware.
I'm not suggesting that they're going to drop everything and do it, but it's entirely possible to get them to roll it into a maintenance patch, presuming they're still touching the game, or at the very least sign off on it as being closer to the ideal of the game than they published, which will make it an easier sell to the site staff.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
BrotherMojo wrote:
...that said, I understand that's not exactly a decision made in the interest of "being faithful to the original release." The mod is developed for Dustforce players as a whole, it has quite a few great features for TASing but some of the decisions have also been made with the RTA player-base in mind. In that case, the decision was made so that determinism would be preserved on an individual-level basis, so if you miss a critical attack on a group of enemies, that means you positioned yourself incorrectly, or mistimed it, or some other mistake on your part as a player, rather than having gotten bad RNG.
Well, the good news is that if msg555 has the source code from the dustforce team, and they actually intended there to be no RNG, it shouldn't be difficult to convince them to pull your patch and release it in the base game assuming it was done cleanly.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
TheBirdOfPrey wrote:
My previous comment still stands, I believe we need to talk with a Site Admin and/or Senior Judge in order to verify that our submission would be within the guidelines of the site.
I'm neither, but I can tell you that the method you describe is not be within the guidelines of the site, unless you can demonstrate that if you fed the keystrokes into an unmodified version of the game it would function in the same way (and then only maybe, it will be slightly contentious).
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
Nach wrote:
Probability of each bit is the wrong question.
You need to know the relationship of each bit. Some may be mutually exclusive at the power on state.
Interesting. I'll also look for interbit correlation as well then. The fact that it's more interesting than a simple heatmap means it's more likely that I can convince my advisor that it's a worthwhile problem.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
creaothceann wrote:
https://wiki.nesdev.com/w/index.php/CPU_ALL#Power_up_state
byuu did read out the SNES WRAM content iirc. There are some patterns that can be observed, but nothing definite. It varies with SNES model, temperature, if the SNES was turned on before (and how long ago) etc.
Right, but the point isn't to get a pattern. It's to get a frequency probability for each bit, from a sample of a few thousand power-ons across several systems, so we can determine the probability of a specific power on state. And also allow emulators to generate a weighted random power-on state (or a single, most probable state) that more accurately represents a typical power on state than straight random fill with a seed, or a pattern fill.
It'd take a lot of boring, time-consuming work, but I have a Computer Engineering senior design project coming up soon, and this might be something that's applicable to that.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Experienced Forum User, Published Author, Player
(37)
Joined: 9/11/2004
Posts: 2633
A thought occurred to me, and I wanted to know how feasible it would be.
Because an NES cart is mapped to memory directly, loading a ROM does not take any RAM necessarily.
Is is possible for a very small program, to read the uninitialized RAM and then stream it to the sound channel PCM (with ECC data), which then can be read in through a microphone in and analyzed?
If several different consoles are tested several times, it would be possible to create a heat map to give the appropriate probabilities that a specific byte would be set or unset. This data would allow a realistic initial RAM condition to be generated randomly, and would allow a given initial RAM condition to be evaluated to see if it's possible or likely.
This would probably work for the NES and SNES and would allow movies such as the FF6 rejected movie to be evaluated in a more "fair" manner.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
I don't know how slowly it converges. It might be sub-logarithmic.
A formula the converges approximately as quickly as Leibniz formula is the Wallis Product formula. This formula also has logarithmic convergence.
2/1 * 2/3 * 4/3 * 4/5 * 6/5 ...
Hope this helps.