Imagine you work at a company that sells cookies. The company signs a contract offering a customer a set variety of cookies at various prices, with a clause stating that if the customer wants another type of cookie the company makes later on, it will be priced and added to their list. This should be in the form of regular contract amendments/addendums, but it isn’t.
Several years go by, and in the course of that several different varieties of cookies have been added by the customer. The price given to them at the time may not account for the cost of materials and labor today, or how many of those cookies not mentioned in the contract are being ordered v. how many were expected, the fact that you outsourced some of those cookies, or brought some of those cookies in-house, etc. The cookie executive asks you “When did we offer customer x cookie y at price point z?”
Now, the company has a perfectly good database of cookies and price points for customers, but it’s very old tech and requires certain access privileges, which are very hard to give people outside of the accounting department. Accounting is never able to help with this, and the cookie executives try poorly and fail to get people like you access. But you do have years and years of cookie addition request forms, which are kept in chronological order by customer and contain a list of all types of cookies requested up to that point in time.This is where binary search helps - you can pretty quickly find the one where the cookie y was added even though there are hundreds of these forms.
It’s not a situation that should exist - we have a god damn cookie database where you can just pop in customer x and cookie y to get price z, with an effective date - but in my crazy cookie factory it helps a ton.
There’s other examples but they’re all pretty much variants of this thinly veiled analogy.
There’s lots of stuff about what I do that doesn’t make much sense :)
It works in this scenario because the stacks are reliably sorted by customer and date, and each form has a running tally of what cookies are on offer as things get added to the list.
Assume customer x’s forms are taken out, and you make two stacks of them without shuffling the forms. The very first form on the first stack from 2022-01-01 does not include cookie y. The first form on the second stack, from 2023-02-01, also does not contain cookie y. Based on this information and the conditions above, you can infer that the form you want is in the second stack.
Now, if the forms were not reliably sorted, or did not contain a running record, you’d need to approach this differently. Strategies would probably involve inferences or straight getting the info you need from other sources - custumer correspondence around “We want cookie y, how much?” (if it occurred when you were in a position to get such correspondence); knowledge of big changes to cookie offerings to the customer (contract renewals); bugging accounting at a regular, annoying cadence with progressive escalation until they answer/complain about you bugging them, etc.
Imagine you work at a company that sells cookies. The company signs a contract offering a customer a set variety of cookies at various prices, with a clause stating that if the customer wants another type of cookie the company makes later on, it will be priced and added to their list. This should be in the form of regular contract amendments/addendums, but it isn’t.
Several years go by, and in the course of that several different varieties of cookies have been added by the customer. The price given to them at the time may not account for the cost of materials and labor today, or how many of those cookies not mentioned in the contract are being ordered v. how many were expected, the fact that you outsourced some of those cookies, or brought some of those cookies in-house, etc. The cookie executive asks you “When did we offer customer x cookie y at price point z?”
Now, the company has a perfectly good database of cookies and price points for customers, but it’s very old tech and requires certain access privileges, which are very hard to give people outside of the accounting department. Accounting is never able to help with this, and the cookie executives try poorly and fail to get people like you access. But you do have years and years of cookie addition request forms, which are kept in chronological order by customer and contain a list of all types of cookies requested up to that point in time.This is where binary search helps - you can pretty quickly find the one where the cookie y was added even though there are hundreds of these forms.
It’s not a situation that should exist - we have a god damn cookie database where you can just pop in customer x and cookie y to get price z, with an effective date - but in my crazy cookie factory it helps a ton.
There’s other examples but they’re all pretty much variants of this thinly veiled analogy.
Sometimes that’s just the way the cookie crumbles, man
It’s a crummy job, but someone’s gotta do it.
Slightly irked you didn’t spell it “crumby” 😅
That doesn’t make sense at all. How would you - given two stacks of papers - know which stack the correct form is?
There’s lots of stuff about what I do that doesn’t make much sense :)
It works in this scenario because the stacks are reliably sorted by customer and date, and each form has a running tally of what cookies are on offer as things get added to the list.
Assume customer x’s forms are taken out, and you make two stacks of them without shuffling the forms. The very first form on the first stack from 2022-01-01 does not include cookie y. The first form on the second stack, from 2023-02-01, also does not contain cookie y. Based on this information and the conditions above, you can infer that the form you want is in the second stack.
Now, if the forms were not reliably sorted, or did not contain a running record, you’d need to approach this differently. Strategies would probably involve inferences or straight getting the info you need from other sources - custumer correspondence around “We want cookie y, how much?” (if it occurred when you were in a position to get such correspondence); knowledge of big changes to cookie offerings to the customer (contract renewals); bugging accounting at a regular, annoying cadence with progressive escalation until they answer/complain about you bugging them, etc.
Wow that got complicated very quickly. Bummer no-one can come up with a simple example of when quicksort is useful.