Ok, I think I understand.

When you talk about production positions - are they associated with an offer? Like when you're evaluation the production position that produced the 1888x777 window do you know what offer it was produced for?

I think the thing that most confuses me is why this post-hoc process exists when you must have known the mapping from Offer position to production at some point already (or else how do you know what to produce).

To me the solution to your settlement problem isn't an algorithm at the end of the process. It's just storing this information of how the offer was actually produced and pulling it out at the end.

I think it is safe to say we are all confused. I was approaching this from the idea that all variables are known and just calling for a db design, then got messed up with this whole fitting thing.

If you are only comparing the variations in the offers, you just need a report and the db design I posted upthread (with a lot of tweeks) will produce what you want. If you are manually attempting to "fit" windows into frames, then yes, you'd need an algorithm. The problem with best-fit algorithms is that it may not take into account other ideas of "best," such as cost, labor time, minimizing cuts, etc. At this point, you'd probably want to roll back to knapsack or greedy algorithms. IMO, jj is right, that if said system is better than a human, then the program has accomplished its goal. Even a 10% improvement over human is very good. I don't think that having a goal of 100% best to cover all the definitions of best is a good starting point, nor do I think it is entirely possible. There will be a trade-off somewhere.

Heh, we just covered the knapsack problem in Theory of Algorithms today.

It's all dependant on total number of solutions, if it's <= ~few hundred thousand, and you are able to measure them in various ways (cost and margin for example) I don't see why brute forcing wouldn't be the best solution then simply pick the best one. This sounds like a problem you can get the best solution for each time (if you're able to measure 'best' quantitatively)

I was thinking about the scoring mechanism of the knapsack algorithm, which he can still brute-force. Would it be easier to start with the perspective of knapsack or best-fit?

Well you hit the nail more or less on the head.
This would be our solution if some sort of algorithm would be too expensive to develop. The reasoning is exactly what you say someone else has already done it in their head and we just need to store that information.

Now the reason why I inquired about the algorithm was mainly for two reasons:
- The final settlement - when the process is being done for the second time - is often times years after it was done for the first time. So the return on implementing the storing mechanism would take a couple of years to materialize while an algorithm would have an immediate benefit.
- I do think that algorithms are very useful for what we are doing and we are currently doing very little in that space. So getting our feet wet and experimenting with it would have follow up benefits.

I think storing the rationale between production and offer in the database and have some sort of code to then untangle it will probably produce the best results.

Yeah sorry about that.

Well the final goal would be to replace the human a 100%, but I am aware that this is not possible immediately and maybe never.
There are very basic steps that take a lot of time that will be automated over time and I hope that I can introduce some sort of algorithm - even if it's only for the benefit of learning.

There is no way around algorithms. The step where production divides up the offer is definitely one step that can be easily automated.


Coming back to the algo discussion:
The scoring mechanism would definitely be iffy in that case. There are variables that are more important than others. On the other hand price per window could be something to make a pre-assessment of which position belongs to which. So having a scoring that heavily weights price and then size would probably already yield really good results.

Ok, cool - I understand you now. I disagree with your approach though. I'd recommend that you forget about the reconciliation algorithm and focus on the real problem.

Step 1. Get something basic out the door that starts capturing current the information from the current offer to production process.

Step 2. Start on the algorithm work to automate this process of translating an offer to a production run. Long term this seems way more valuable.

The reason I'd skip the reconciliation algorithm is that it actually takes a decent amount of time to develop/test/release/train people to use/etc. All of that time/effort/money ends up being wasted once you fix your first problem.

I agree with your assessment.

I will have to see to what extent I have influence to introduce an algorithm in production, since I am in a different department.


Talking more in general now, what is a good source to learn more about algorithms? Are there certain websites? Should I watch online university stuff? Just start with coding basic ones and improving (that's how I did it with coding)?