Add new simplex matrix solver

[vapopescu]

Pros:

• No need to configure free variables
• Supports "independent" floors (limit exporting/importing intermediates to/from adjacent floors)
• Supports machine and item limits

Cons:

• It finds a solution, but it may not be the one you want
• Defining a good objective function is hard
• There's currently no way to indicate what went wrong when no solution is found
• In order to truly optimize stuff, there needs to be a cost associated with each item

[ClaudeMetz]

Alrighty cool. I'll still have to think about the UX of it all, but appreciate you already integrating it and stuff. I won't be able to look into this too much in the short term, as I want to focus on a few other things first. But I am interested in it as I said on Discord. @scottmsul feel free to have a look at this as well of course :)

Is there any context on the performance of this? Did you optimize it particularly, or is there still room for that? One detail I wonder about too, if performance won't be great, is whether it's possible to split up the calculations into chunks, so they could potentially be run over multiple ticks. That would require an estimation of how computationally expensive a certain solve is too, so it can be split up sensibly.

[ClaudeMetz]

Sorry that I keep making changes to the codebase that interfere with your PRs. I'll get to the two smaller ones now, and will get to this one soon. I am pondering UX currently.

One topic I'm curious about: Is there any overlap between this and the existing matrix solver with regards to the core math implementations? You achieved great performance it seems, and in general it'd be nice to de-duplicate. Or if not dedupe, maybe apply some optimization ideas to the other solver as well if it makes sense. This is obviously out of scope for this PR, and you don't need to look into it if you don't care to, but I was wondering about it.

[vapopescu]

Sorry that I keep making changes to the codebase that interfere with your PRs

It's fine, don't worry. I can keep up :)

Is there any overlap between this and the existing matrix solver with regards to the core math implementations?

No, not really. The only one I can think of that can be de-duped is the row-reduction step.

[...] maybe apply some optimization ideas to the other solver as well if it makes sense.

Yeah, makes sense. I'll see if any of them apply to calculating the matrix RREF, and open anther PR if I find something.

[vapopescu]

I have an idea for another optimization.

Considering that the factory only changes one line at a time (for the most part), caching the basis of the previous result and re-using it as much as possible should bring the initial solution very close to the optimum.

The downside is that the cached basis becomes a target for migrations (we could also just delete it).

[ClaudeMetz]

Interesting idea, sounds like it could be a huge speedup. Migrating it is definitely a big no-no, but that's fine because the solvers are already re-run on every factory when mod versions change, so there'll always be a cached version I think.

[ClaudeMetz]

Had a think about future input-based and per-floor-solver things, and had a cursory look at your PR, and I think you said this already but it looks all setup for that? After we get it merged, we should work towards making the other solvers use an internal approach and data structure that's more similar to your work. Then doing input-based and per-floor won't be too big a deal anymore I feel. We'll have to drop machine limits but I already have a better approach planned anyways (see #93). Should we get all that figured out, I'd be unbelievably happy, and it'll make FP probably have the best solver setup, as opposed to one of the worse ones currently.

Also, just to clarify, I won't really review the core solver for this PR. I am just not qualified for that, and I trust you to do a sensible job with it. So I'll just make sure I like all the parts where it interacts with the rest of the mod, and maybe some organizational things. I'll try to get a first review in this week, plus organizing the GUI differently like we eluded to.

[vapopescu]

The input-based stuff is pretty much ready, but due to the cost function not being very precise, there could be some hiccups to sort out when it comes to that.

For the per-floor solver stuff, the Gaussian matrix solver would have to be changed to solve per-floor as well. Which in turn means free items have to be configured per floor as well. After that, it should be just a matter of the solvers agreeing on the line data and result formats.

I'm glad you like the structures. I was thinking of refactoring the existing solver result structures to use the same serializing approach I used instead of putting each item in their own box depending on their type. It should also make Durandal's work with the quality easier.

As for the solver input data structure, all that both matrix solvers really care about is how much stuff would be going in/out of a line if it had only one machine (+ machine limits for simplex, at least for now). If you could align the sequential solver to use this principle as well, we could simplify things quite a lot.

[ClaudeMetz]

That all sounds great, thanks for all you do. Let's get this merged first and we'll go from there!