AirAKose

Just put up a rambley, conceited blog post on my site about a topic I'm way too invested in for no good reason.

When peeps are talking about the Monty Hall problem, they always discuss the theory but never show practical results outside of certain circles. This has lead many to denying the conclusion the math community reached.

For the uninitiated, the Monty Hall problem is usually described as:

You're on a game show, and they present you with three doors. Behind one door is a Brand New Car, and the other two doors have a goat each. If you pick the car, you get to keep it.

You make a choice, but before they reveal what you picked, they open one of the Other two doors to reveal a goat. They ask if you want to change your pick.

Should you change?

Our common perception of the problem is that we still have the same chance of winning if we change or not, 1/3, but that's not true!

You actually have better odds if you do change. 1/3 chance to win without changing vs a 2/3 chance if you do. It's counter-intuitive, and more statistics-minded peeps have gone into great detail about why that is.

But instead of theory, I present to you a practical proof:

I made a program to run through the Monty Hall scenario some large number of times (Half a million in this case). It does this twice - once without swapping its initial choice, and again with swapping its initial choice after having the goat revealed. Each iteration it totally re-randomizes the state, and the choices / reveals are randomized.

Here are the results:

This is a boring console app, but here you can see that it prints out the Win to Total runs ratios followed by the calculated win% (as a fractional number)

Without swapping its choice, it won approximately 1/3 of the time (0.33) BUT when it did swap, it won 2/3 of the time (0.67)

This continues no matter how many runs I add. Even cranked up to 100 million runs, the pattern persists.

New Post, now with RSS!

The New Blog is Up!!!

Along with my entirely new site design!

Webbed-site Progress

Here's a little preview of my work on my personal site, which is built using an offline static site generator I made!

A static site generator = a program where you make your website as a combo of page templates and page content, and the generator stitches them together so youre not copy-pasting the same nav bar, the same copyright footer, etc, across potentially dozens of pages. And you're not putting strain on your webserver by asking it to generate those pages for you - which, even with caching schemes, may be a load on your site.

Generators can also have the ability to do logic to show something depending on the context, or populate lists of items - which I'm using for creating my own blog navigation and the above news feed.

I had decided to make my own blog instead of using a platform like Tumblr because Tumblr is too opinionated and wont let me style things the way I need for posts about code. I also wanted something easy to migrate to any other platform, and wanted something resiliant to manbaby takeovers.

Self-hosting a blog thats just a bunch of pages generated on my computer is totally resiliant to all of that.

This is a basic geometric(?*) dither that takes the fractional difference between each color and uses that to determine how frequently to show the prior color vs the next across its band (independently calculated per channel: r,g,b).

Note that this gradient normally shouldn't band as much; it's a darker gradient blown up to make the bands more visible.

No dither matrices / textures needed - and each pixel can be computed independent of every other, so it's perfect for shaders. You could probably just as easily use some noise function, but I wonder how it performs comparatively.

One downside is that there are definite geometric patterns you can see in the resulting gradient, but for a potential cheap solution for quick dithering, it might work out!

-

I’m currently writing a custom theme to bring myself into the dark theme ages.

It’s a mess right now, partially because of bad assumptions in the CSS and partially because Tumblr broke the formatting on random posts (i.e. post titles aren’t actually set as post titles, but instead inserted into the body’s markup...)

Will be tweaking and fixing things in the coming days!

You know, I just need a good setup for prototyping quick game ideas. Something I could game jam with.

An update on my previous post about reflection and using it to auto-bind C++ classes to Flash objects.

The experiment was a huge success, I believe! I made an entire new UI scene with 0 actionscript, relying entirely on auto binding... The scene's C++ is less than 200 lines- all interaction + logic. For comparison, this is a reimplementation of a previous scene which was 500 lines of C++ and 300 lines of ActionScript, most of which was the communication and traversal between the two.

Of the auto-bind features, I'm using 2: Auto-Binding based on member name and treating structs as containers. The latter was especially helpful! It lets you dig 1 element deeper and keep those sub-elements organized. e.g. previously coworkers would do "PromptABtn, PromptALabel, PromptBBtn, PromptBLabel" which is a hassle. Now you can make a struct and just have "PromptA, PromptB" which both have "Btn, Label". I even added a special keyword "Self" which let's you refer to the container if needed!

There were two other main features that made it in based on coworker feedback: Custom bindings and array binding.

Some co-workers didn't like the naming enforced by UnrealScript (if you don't follow a capitalization convention it could break the entire project), so they wanted a way to bind scene elements with class members that are of different names. That's set up and works perfectly with any supported type you provide! (like structs, arrays, and scene element classes) It's implemented to work with UC's Default Properties, and I'm a fan of the syntax:

Bindings.Add((AS="sceneName", UC="ClassMember"));

And array binding is just very convenient. It matches elements in the scene that have the array variable name + a number, and populates them into the array. This lets you easily manage a bunch of generic objects / list renderers without having to do the tedious custom hookups.

There’s a certain beauty about runtime reflection. It’s not a reflection of our faces, so that’s probably part of it, but the dynamics and convenience it enables really stand out in all that gloss. If you can keep it to non-critical systems, where performance isn’t too much of a concern or frequency of use is relatively low, it’s a great tool to have!

Runtime reflection, for those curious, is the ability to get information about your code while it’s running. Variable names, class layouts, function signatures, figuring out which class an object REALLY is, etc... You reflect upon your self~ at run time. Depending on what language you’re coming from, this probably sounds like the norm. Unfortunately, I hail from the lands of low-level pretentiousness where this type of thing is sorely frowned upon for the sake of frowning (plus a bad first attempt), but I digress.

At my day job, I work in Unreal Engine 3. This old iteration of the now-famous game dev suite pushed its own scripting language, UnrealScript (UC), to ease gameplay development and support complex systems with simple keywords, automatic memory cleanup, and language-level features. It’s pretty cool, despite being a total mess and the worst. BUT it does provide one key thing: reflection! AND we can access this runtime reflection FROM C++!!! Which conveniently works hand-in-hand with UC.

So What?~

So... We also work with this thing called Scaleform, which is the abysmal love-child of Adobe and Autodesk that puts Flash in games to use for user interfaces. THAT runs on Adobe’s language, ActionScript (AS). It’s like JavaScript, but somehow worse.

It has so many issues... Like the fact that there’s no project management, so whichever version of a script happens to load first is the one the game uses, even if it’s old. There’s no viable debugger for Scaleform, so you have to rely on old-school output logs to track issues down. Changing anything in Actionscript requires updating an Unreal package, which means it has to be processed for various test cases, doesn’t play well with source control, etc.. Not a fan...

And?.. What does that have to do with Reflection?

It all relates, promise! I despise the whole Scaleform process. ActionScript is workable, but everything around it and how it impacts our process really gets to me..

With C++ reflection of UnrealScript classes, we can subvert ActionScript in favor of UnrealScript and C++! Well, we could do that regardless, but this makes it way more convenient than having to manually setup the code for our scene to associate Flash objects with class members.

See, I made a base class (named FlashNativeWidget) that is associated with a Flash display object on creation. After creation, it uses reflection to check what object member variables it has; if there are any members that have flash object classes, it tries to get them from Flash by matching the variable name to display object sub-elements. ActionScript does this already- variables will auto-attach to objects in Flash that have the same name, so pulling this convenience up to C++ means that’s one less reason to use AS!

The nice thing about this reflection is that anything that inherits from that base class will just work with its logic. Any new member objects that they add will automatically try to associate with display sub elements because it’s reflecting over the most derived class’s members.

Previously, we would have to manually try to set up those associations on create, which lead to people being understandably resistant to the verbose mess needed to have multiple UC/C++ classes in a single Flash object. This resulted in what’re called “super classes”, which are massive chunks of code that, scientifically speaking, do way too damn much... Now, it’s just as easy as AS (maybe slightly easier) to associate with multiple classes, so hopefully we won’t get super classes as much (UC has it’s own headaches that contribute here, another talk).

Is that all? What’s Next?

It’s far from perfect, and far from ready to replace ActionScript. The real issue is that the game is so old that most of our controls / systems are AS-centered, so those will need to be transitioned over time. BUT being able to reflectively bind UC/C++ to Flash is a major win that’ll make the transition that much easier.

My next big plan with Reflection is to allow nested binding, where you can go into sub-elements of sub-elements without the need for an entire other class or manual load code. In previous C++-centric Flash scenarios this was a common occurrence, and provided the bulk of verbosity. Sometimes you just want to skip containers and get their children. I’m thinking about using data-only structures, where variables of struct types with Flash object members are treated as skipped containers and the members get populated. While the struct setup might be weird, it’ll make the access code mirror the scene layout, which can be great for logic!

Maybe after that, auto-bind lists of objects with dynamic arrays? Hmmm... The potential! I’m probably going overboard xD Time will tell

You don’t even know how terrified I was earlier while toying with the Git integration in Visual Studio.

I usually do most Git work in the Git for Desktop app, but thought: eh, let’s see how well this does! Maybe it’s on par with Perforce’s integration and will become my new go-to for at-home SVC; or ideally, better- doesn’t totally die whenever it requires a password again.

Huge mistake. I thought it would prompt me for a Git account, or use the one associated with the app. Nope! Without a single warning it made a new repo under my microsoft account AND it moved my project to a random folder on my OS drive (all of my dev work saves to an external drive).

Aight, experiment over, let’s go in and revert...

Bad idea. Instead of putting things back, it just deleted the entire project. Hours of work, poofed by the very thing that’s supposed to save me in this situation. Betrayed by the version control I trust.

I had a moment of panic, ngl. I'd made a solid mini C++17 project that was benchmarking better than the C++ and C standard equivalents in Release builds; I just needed to get the debug speeds up to compete with the C versions and compare with similar projects... to be done in later commits... All gone.

LUCKILY the revert was just on my local copy; when I clicked “add to source control” it immediately pushed to master. So I just had to rebase, manually copy the folder back where it was, THEN delete the repository.

Now it’s in my actual Git repo safe and sound, ready for updates.

if you go into Computer science, please know your number formats.

You don't have to have them mastered (like knowing all about the exact IEEE Floating point specification), but... at least know integer = whole number, float = may be fractional, etc.. and the limits of common formats.

It's just super helpful in general.

We just had a problem in our game where random players couldn't do various things. We couldn't reproduce it internally for the longest time until a QA guy pointed out that new accounts had issues with random other things.

So I spun up a new account and noticed that it's ID was pretty high, and the ID was morphing in some cases. It ended in 80, but would come back as 88 sometimes- whoop, that's why they can't do anything, they're using the wrong ID!

Which lead to discovering that where we previously thought we were storing IDs as integers, they were actually turning into floats for... legacy reasons... and floats start losing precision at around 100,000 (which this ID was well above) vs the signed (may be negative) integer cap of ~2billion. All of the problems are solved by making those actual integers!

For now anyways... We're stuck with signed integers for reasons, and we're getting close to that dreaded 2billion mark; unfortunately, converting unsigned to signed isn't strictly defined, so some platforms do "overflow resolution" where if a number would become negative because it's so big, they cap it or drop the negative... I know of one specifically that we work on <_<'''

If you ever see anything not code related here, I probably goofed n_n' Sorry!

For some reason one of our data sets was represented as an unordered map of IDs to data structs, which in turn had the IDs of their parent to look up in the map and... It was generally a very unpleasant setup. Even for the use case it was made for, it created the need for deep-nested for loops, far too much state, and hard to maintain code. Just grouping things by hierarchy, a common use case for this data, involved looping over all of the nodes and finding the ones with the same parent ID...

So I turned the map into a tree to better represent the relationships, using bi-directional nodes. Also implemented some easy iterators for ordered depth-first iterating and external-only (aka childless/furthest nodes) iterating.

Immediately better!

With those two iterators, I was able to create two new systems using only one loop a piece. The code is easier to understand, more efficient (no lookups every time we step- just some low-overhead node traversal), and more maintainable. I’ve already had to change the design for one of the new systems, and it adapted easily; the change was such that it would’ve been a pain under the previous system’s map as it involved grouping children, and then generating a label for each that included something from all of their parents up to- but not including- the root.

It even made sorting for display easier!

Always pick the data structure that is most appropriate for the information and problem presented to you. A map would have been fine for data that is randomly accessed and commonly used individually, but that doesn’t fit this case.

I think if anything can be learned from all of my struggles today, it's this:

Don't change dev-input values without giving some indication that you will do that. e.g. don't call something a stack and give it a "push" and "pop" if it's going to alter the data provided. Internal representation doesn't matter (like where it goes in the stack), but the data provided, itself, should remain intact..