Friday, August 1, 2014

Logarithm as a composite price

 Let the X axis be the index of an item, and dx / index is the price of the item. So, the X axis counts items, along a uniform price scale. Then when any object is necessarily composed of a set of items, ordered by index,  we have the composite price of the object being the area under the curve.   So the logarithm can be understood as a production cost schedule, the sum, of price/items, for all the items that compose a product. We can make dx finite or let it go to zero.

One can see we get a production graph, a minimum spanning tree that assembles each of the objects, going from left to right. LogB (N), is the sum of the production graph at the point N.  Do we get an exponent? In the limit we get the natural exponent.  Then we can change the base to correspond to a finite base and finite sum.  Let P =  LogB(N), and assume P is scaled to include 1/logB(e), so we get the natural log functions. B^PNP the composite cost of making N.

Does this make sense?

Sure, because we equalized prices along the X axis.  But prices of the items may not be separated uniformly.   In that case your production graph is not a minimum spanning tree.  You should fill the vacancies with value added add ons, or purchase your low cost inputs in bulk to make your production graph minimum again.

The inverse, B^(-P), has units item/price, giving 1/N, the fraction of item N having cost 1/P, or the item generated by composite cost  P. I think I have these units right. 

Now all ou inventory is arranged by price and prices are in equal intervals. Not very common, but we do it anyway. What is the prices are uncertain? Then add some space, enough to capture our uncertainty. The next composit price becomes LogB(1+N), for item N.  Now our  production graph includes a spot in inventory where any N produced will sit for up to one interval. So, we make N, then move it to output inventory. We are essentially making item N+1, and have added another level of node in our production graph. But we also have matched price jitter with interval between prices. We have defined the band limit, or transaction rate of our system.

But if our price jitter is uncorrelated with the price of any N, and we want to weight the noise properly, simply add in an exponent:

LogB((1+N)^k/B)), thus making the LogB for any N becomes  k/B*LogB(N). We set the k/B as slightly above one, but as close to 1, as long as the error is satisfactory for our owners.  The effect is to raise the composite price to accommodate external price jitter.

If we have scaled our prices such that indexed items are separated by a uniform 'one', and we add our noise exponent, then out logarithm looks like a finite  Zeta function.
The effect is to simply stretch out the X axis to add jitter buffer for the price of any item. And, as a by product, I think we have a simple proof of the Shannon information theorem. And for a bonus, we have provided a basis for the Hayek information theory of relative prices.

What is a good base? Use two for simple production, but  if you are makign anything having the Efimov property, use three.  You will have a 2-ary or 3-ary production graph.If you have lots of slow priced inputs, you can batch them up into a single price on the X axis. You can also add empty slots on the X axis for bulk purchases, the empty slots being inventory price.  The price per slot should be near equal on the X axis, and the components of production become the integer set. The finite log, or summation is implemented as a summation graph, and that graph is also your production chart. Then the exponent in your log shoudl rpesent all the erorrs , yours and others. The addition of the one is allows you that output inventory space, and you can make is larger than one or omit it.

And that yields the optimum logistics function.

No comments: