Login
Ratjoy.com » Forums » EoS Club Rats Den » Economies of Scale (Math Guru Needed)

Economies of Scale (Math Guru Needed)


Scott (Admin)
RJ: Ratan Joyce
CO: Ratan Joyce

Post Rating: 0
+ / -

Total Posts: 1175
Karma: 5083
Joined: Jan 13, 2012
Just when I thought I got everything... I'm needing your help.

My previous goal is to add the economies of scale factor into the game 2 hours before now, by allowing for lower production cost with higher production quantity. But I'm stuck on getting an equation that is solvable for both y and x:

Example:
Assume 1 produced quantity costs 1 raw material quantity,
y = total produced quantity (between 0 and 99999999), x = total production cost, u = unit cost = 1 before the change

My favorite equation so far (plug it into spreadsheet and you'll see what I mean):
u = 0.5 + 0.5 / (y ^ 0.25)
So given y we can solve for u, and also solve for x:
x = y * u = y * (0.5 + 0.5 / (y ^ 0.25))

Trouble is, in order to allow people to use the Max button efficiently on the slider, I need to have an equation that calculates y when I'm given x, from the above equation I'm able to write x as a function of y, but my skills does not allow me to solve y as a function of x, and after looking at Wolfram Alpha's solution I decided maybe it's best to change the unit cost equation.

Issue is... anyone know something that CAN be solved easily and still provide a gradual cost drop to an asymptotic value from 1 to 0.5 as the above proposed equation?
Ay Vee
RJ: Ay Vee

Post Rating: 0
+ / -

Total Posts: 33
Karma: 29
Joined: Mar 30, 2012
This isn't as elegant as a straight formula, but since this is client side could you do something recursive like:

[pseudocode]
func getY(Xtarget, tryY):int
{
var Xthis = U(tryY) * tryY;

var dif = Xthis-Xtarget;

if (dif > some_positive_threshold) {
// x target is to small, so tryY is to small
var R = getY(tryY+1)
} else if (dif <some_negative_threshold) {
// x target is too big, so tryY was too big
R = getY(tryY-1)
} else falls out of if block and returns

return R
}

func U(Y):number
{
return .5 + (.5/Y^.25)
}
[/pseudocode]

It would converge relatively quickly, especially if you got sneaky with adjusting the trial Y based on the difference.
Kudaros Cornercutter
RJ: Kudaros

Post Rating: 0
+ / -

Total Posts: 17
Karma: 19
Joined: Mar 30, 2012
Here are some quick suggestions...not too much time today.

If you want to go for a new unit function, I would suggest looking at logarithmic functions or exponential decay.

You might have to program around any solution a little bit - using piecewise defined solutions, for example.

Take a look at ln(1+y)/y. At y=0, f->1. However it is not bounded below. This equation can be scaled, though it is more complicated then scaling an exponential function.

1/(exp^(y-5)+1) for example is nearly 1 at y=0. This equation is easily scalable, but again, the bounds may have to be 'forced'. Take a look at the 'Fermi Level' or 'Fermi energy' equation. You can divide y, or y-5 by some factor to scale it nicely. The -5 isn't even significant really, you can use that to scale that as well.

As for your original unit cost equation, implicitly solving 2x=y+y^(3/4) for y should give you some reasonable values. I'm not sure what you are using, but I would think that software packages for implicit numerical solutions (these will be very close approximations, but may not be efficient in terms of computation) should exist. I know they are available for fortran, but I have a feeling you aren't using that...

I can't think of any way off the top of my head to construct a nice function for clean, analytic solutions while simultaneously satisfying the boundary conditions. The ln(1+y)/y is the nicest I can come up with, since in the calculation of x, it goes as ln(1+y) directly, although it must of course be scaled, since it will drastically reduce unit cost for early values of y.

Edit: Yeah, if this is client side, why not go hog wild on forcing boundaries? The Fermi energy -esque equation can be scaled nicely and force-bounded.
Mister Death
RJ: McFlono McFloninoo

Post Rating: 0
+ / -

Total Posts: 266
Karma: 300
Joined: Feb 6, 2012
You're looking at it the wrong way I think.

What you really want is the (invertible) time function first, t(q), which has the asymptotic behaviour lim_{q->infty} t/q = 1.

So, why not t = q + k? This has the added bonus of having a logical explanation - k is the time it takes to set up (and/or tear down) the production run.

Edit: Just realised I answered the question you didn't ask. Never mind...But yeah, the same idea could apply. When you run the equations in econ, the important variable is C, total cost; if you really want average cost you get it from A = C/q, not the other way round.
Scott (Admin)
RJ: Ratan Joyce
CO: Ratan Joyce

Post Rating: 0
+ / -

Total Posts: 1175
Karma: 5083
Joined: Jan 13, 2012
I need to be able to solve for C as a function q, AND the other way around, either that or I'll need to remove the Max button, or use a recursive function (yes it is on client side, but considering the interface will be changed in the future to Ajax and there are people using Android and iOS to play this game, I'd like to be careful with the client-side efficiency too)
Mister Death
RJ: McFlono McFloninoo

Post Rating: 0
+ / -

Total Posts: 266
Karma: 300
Joined: Feb 6, 2012
You could simply use something like C = k1 q + k2... with k2 as the overhead costs. Nice and invertible.
Scott (Admin)
RJ: Ratan Joyce
CO: Ratan Joyce

Post Rating: 0
+ / -

Total Posts: 1175
Karma: 5083
Joined: Jan 13, 2012
Did more experimenting, still to no avail.

The problem is with the basic equation they are generally all solvable, but as soon as boundary conditions are put in and the speeds adjusted - even Wolfram Alpha will complain and timeout.

The flat overhead sounds simple, but I don't want to hear Garry whine about his airplanes, so let's not use that :-P

In the end I'm thinking we'll just use a recursive method for finding the max - here comes sloppy code!

On testing it out... everything converged within 4 tries, WOW!
Mister Death
RJ: McFlono McFloninoo

Post Rating: 0
+ / -

Total Posts: 266
Karma: 300
Joined: Feb 6, 2012
All hail Newton's method! (-:
Control Volume
RJ: ControlVolume
CO: Control Volume

Post Rating: 0
+ / -

Total Posts: 43
Karma: 122
Joined: Mar 31, 2012
Well you have economies in scale in, but I think it starts converging on the half-off limit way too quickly. Right now all it takes to get close to that limit is have a production run of more than 1000. The difference in cost between 20000 and 40000 is about 1.5%, and the difference between 200000 and 400000 is even smaller. Doesn't seem like it's going to have an appreciable effect beyond just making everything but airplanes, boats, and cars half off. Would be nice if it didn't converge in such a rapid fashion.
Fish Bike
RJ: FishBike
CO: FishBike

Post Rating: 42
+ / -

Total Posts: 22
Karma: 51
Joined: Mar 29, 2012
Did you end up using the u = 0.5 + 0.5 / (y ^ 0.25) formula for unit cost after all?

If so, and if you want to have it work differently for products that are easy to produce vs. those that are hard, you could change the y term there to be something like:

(1 + ( (y-1) / b) )

Where b is some sort of "batch size" standard for the particular product. Maybe the number that can be made in a day in a 10 sq. m factory or something.

Then you'd have still the same unit cost for a production quantity of 1 unit, but the improvement as the quantity goes up would be slow for items that are easy to produce and fast for items that take a long time to make.
Josh Millard
RJ: Tex Corman
CO: J. Quaff Arabica

Post Rating: 0
+ / -

Total Posts: 167
Karma: 231
Joined: Apr 3, 2012
What FishBike said! This doesn't have to be a horribly fiddly per-product coefficient, either; you can just create a few production-difficulty classes on a spectrum from easy to hard, like D1 ("Difficulty 1") through D5, and assign all products/processes to one of those. Attach a coefficient to each of those.

So one-stop stuff like water, electricity, fruit, etc. would end up in the D1 category, where scale economy would rise more slowly and/or converge at a smaller final discount. Processed raw stuff like flour and sugar would be D2; stuff that takes a couple steps up the chain to produce would be D3 stuff; particularly complicated derivative products would be D4 and D5 stuff.

That way you can assign all products once and then mostly just tweak the coefficients themselves to experiment with balance.
Fish Bike
RJ: FishBike
CO: FishBike

Post Rating: 0
+ / -

Total Posts: 22
Karma: 51
Joined: Mar 29, 2012
Well, I was thinking that basing a standard batch size on the production time would be easy because the production time is already configured for every item, so the batch size would just be something like a 1/t sort of calculation, instead of another thing to manually set up for every item or category.

But anyway, everything is easy when I'm not the person who'd have to implement it. :D

So this is more of a "here's one idea for you to do with as you see fit" rather than a "you should do this" kind of thing.
Scott (Admin)
RJ: Ratan Joyce
CO: Ratan Joyce

Post Rating: 0
+ / -

Total Posts: 1175
Karma: 5083
Joined: Jan 13, 2012
Thanks for the input. I can always write the coefficient as a function of the base value, so that won't be too difficult.
Pierre-Luc C
RJ: DrWard

Post Rating: 0
+ / -

Total Posts: 1
Karma: 10
Joined: Mar 25, 2012
So in the end, what formula did you use to model the factory economy of scale?
Scott (Admin)
RJ: Ratan Joyce
CO: Ratan Joyce

Post Rating: 0
+ / -

Total Posts: 1175
Karma: 5083
Joined: Jan 13, 2012
The combination of what I had in the beginning and something similar to fishbike's addition for the substitute


You need to register or login to post a reply.