Hello!
To use the forum, login or register above.
(If you are already logged in above, please click here)
There should be a smarter part allocator for buying a wishlist
TLDR: The smart allocator should take the least commonly sold parts, find the stores that sell the most of those parts, then allocate the wishlist based on those stores. Crossreferencing which stores have what optimally is a pain in the block to do by hand.
Sorry if I over-explain anything —I'm naturally verbose—, but I hope in this setting it's better than making you guess what I'm saying. :V
When I had every store in north america/united states checked, it allocated to dozens of stores with only two or three pieces in each. What was a $20 build would have cost almost $300 with shipping, not to mention that I —unsurprisingly— didn't meet the minimum order requirement for most of them. If you don't implement my full idea, I still think it would be a good idea to prioritize using fewer stores then prioritizing meeting the minimum order amount as applicable rather than raw piece and shipping price (which is how I understand it works now).
What I ended up doing (because I had a number of —apparently— rarer pieces) is looking at what stores carried all that I needed of a single rare piece, and tried to find the stores that showed up more often for other rare pieces. I was eventually able to whittle it down to three stores as they had all the more common pieces, too. I fully admit that I don't really know what I'm doing, as this was my first time doing this, so I'm sure I could have been more thorough.
I don't have much of a formal compsci education, but I know that the process I used would be so much easier for a computer.
1. The user would input the search regions (like north america or the uk)
2. The engine generates a list of the number of stores in that region that stock each part
3. (for optimization) The engine looks at the parts with the fewest stores (either by top X andor using a threshold*) for steps 4-7
4. For each part, the engine pulls the list of stores that stock it and how many each store has in stock
5. The engine counts the frequency of each store
6. The engine chooses the most frequent store (weighted by whether the store has enough of each part in stock†) and tries to allocate‡ as many parts as it can
7. Because one store won't have everything, the engine takes what parts are left over and repeats steps 4-6
8. The engine tries to allocate the full parts list with the stores it has chosen, allocating to any stores with unfulfilled minimum orders first
9. If there are parts that can't be allocated with the chosen stores, loop back to step 3 with the missing part in the rare part list or something§
10: Push the final allocation list to the client
It might be worth implimenting a tooltip to the client to search a larger region (like both US and Canada instead of one or the other) if the number of stores chosen is too high or any minimum order sizes aren't fulfilled. Maybe it would be possible to weight some stores more or less in step 6 based on price (perhaps as a user option), or the search could be run multiple times with different criteria and show the cheapest version? I don't know.§
*if more than X number of parts have fewer than Y stores, they can be included in this step, where X and Y are arbitrary numbers that can be based on the number of total parts.
†I don't know how weighted decisions are implemented, but it would be used to avoid a situation like in the image provided: In the first example, stores 1 and 2 have more types of parts, so they would be chosen first, but they only have one of each part. Stores 3, 4, and 5 then get chosen and are allocated what is left. In the second example, stores 3, 4, and 5 had enough of each part they carried, making the first two stores unnecessary. Perhaps when calculating frequency, the stores are counted for each piece it has in stock that is required for the build? So in the examples, store 5 would be counted 6 times, and stores 1 and 2 would only be counted 4 times?
‡For optimization, it doesn't have to allocate the full wishlist, it can just just subtract the amount required by/from the amount it sees in stock, removing whichever reaches 0 if that happens.
§I've actually been composing this for hours and it's now 4am, so I'm too tired to think about —and too practically inexperienced to know— the effeciency of that, but it's the most robust idea I got other than skipping step 3 entirely, though I think that would mess up the frequency list.†
Sorry if I over-explain anything —I'm naturally verbose—, but I hope in this setting it's better than making you guess what I'm saying. :V
When I had every store in north america/united states checked, it allocated to dozens of stores with only two or three pieces in each. What was a $20 build would have cost almost $300 with shipping, not to mention that I —unsurprisingly— didn't meet the minimum order requirement for most of them. If you don't implement my full idea, I still think it would be a good idea to prioritize using fewer stores then prioritizing meeting the minimum order amount as applicable rather than raw piece and shipping price (which is how I understand it works now).
What I ended up doing (because I had a number of —apparently— rarer pieces) is looking at what stores carried all that I needed of a single rare piece, and tried to find the stores that showed up more often for other rare pieces. I was eventually able to whittle it down to three stores as they had all the more common pieces, too. I fully admit that I don't really know what I'm doing, as this was my first time doing this, so I'm sure I could have been more thorough.
I don't have much of a formal compsci education, but I know that the process I used would be so much easier for a computer.
1. The user would input the search regions (like north america or the uk)
2. The engine generates a list of the number of stores in that region that stock each part
3. (for optimization) The engine looks at the parts with the fewest stores (either by top X andor using a threshold*) for steps 4-7
4. For each part, the engine pulls the list of stores that stock it and how many each store has in stock
5. The engine counts the frequency of each store
6. The engine chooses the most frequent store (weighted by whether the store has enough of each part in stock†) and tries to allocate‡ as many parts as it can
7. Because one store won't have everything, the engine takes what parts are left over and repeats steps 4-6
8. The engine tries to allocate the full parts list with the stores it has chosen, allocating to any stores with unfulfilled minimum orders first
9. If there are parts that can't be allocated with the chosen stores, loop back to step 3 with the missing part in the rare part list or something§
10: Push the final allocation list to the client
It might be worth implimenting a tooltip to the client to search a larger region (like both US and Canada instead of one or the other) if the number of stores chosen is too high or any minimum order sizes aren't fulfilled. Maybe it would be possible to weight some stores more or less in step 6 based on price (perhaps as a user option), or the search could be run multiple times with different criteria and show the cheapest version? I don't know.§
*if more than X number of parts have fewer than Y stores, they can be included in this step, where X and Y are arbitrary numbers that can be based on the number of total parts.
†I don't know how weighted decisions are implemented, but it would be used to avoid a situation like in the image provided: In the first example, stores 1 and 2 have more types of parts, so they would be chosen first, but they only have one of each part. Stores 3, 4, and 5 then get chosen and are allocated what is left. In the second example, stores 3, 4, and 5 had enough of each part they carried, making the first two stores unnecessary. Perhaps when calculating frequency, the stores are counted for each piece it has in stock that is required for the build? So in the examples, store 5 would be counted 6 times, and stores 1 and 2 would only be counted 4 times?
‡For optimization, it doesn't have to allocate the full wishlist, it can just just subtract the amount required by/from the amount it sees in stock, removing whichever reaches 0 if that happens.
§I've actually been composing this for hours and it's now 4am, so I'm too tired to think about —and too practically inexperienced to know— the effeciency of that, but it's the most robust idea I got other than skipping step 3 entirely, though I think that would mess up the frequency list.†
This discussion has been closed.
Powered by Vanilla
Comments
Adding regions would even make it more better for users. For example, being in EU member country, it is a pita to uncheck some countries by hand afterwards (like UK) to avoid import taxes and etc. But long story short, the Brick Owl Magic is somewhat shortcoming in certain scenarios.
https://www.brickowl.com/forum#/discussion/comment/61437
https://www.brickowl.com/forum#/discussion/14749
You can import a Brick Owl wishlist and it will compute the most optimal selection of stores for you. Often saving you a lot of money (and time) compared to checking out all kinds of different store combinations in the Brick Owl wishlist assistant.