Emulating multiple purchases within one expression.

justis

New member
Joined
Nov 7, 2017
Messages
11
Hey fellas, I'd love some help with this.

Say I've got an expression like so:
c = p^1.4/1000

Where p is the current price.
And c is the amount that price will be adjusted by. The change.

I'm writing a program where, if someone orders 1 item, the expression will be run and p will become p + c.
If someone orders 500 items, the expression will be run 500 times, getting the new price, then plugging that new price into the expression again that many times before getting the new price of the item after 500 purchases.

However, as you can imagine, especially for large orders, the process time for this can be extremely long.
I'm desperately looking for a math-y way to emulate all those purchases within just one passover of the expression.

Obviously, the price doesn't change by the same amount every time the expression is run, since it's dependent on its own price, so a simple "p = p + c * amount" won't work.

Thanks for everyone who's given this some thought. I really appreciate it.
 
I cannot understand your question.

Are you saying that given

\(\displaystyle p_x \implies p_{x+1} = p_x + \dfrac{p_x^{1.4}}{1000}\)

you want a formula for \(\displaystyle p_{x+n} \text {, where } n \in \mathbb Z \text { and } n \ge 1.\)

The initial formula looks a bit weird. For example

\(\displaystyle p_x = 100 \implies p_{x+1} \approx 100.63.\)

That's less than a 1% increase. But

\(\displaystyle p_x = 10000 \implies p_{x+1} \approx 1016.\)

which is more than a 1% increase.

if you want a constant percentage increase regardless of the initial price, this formula is not going to give you that.
 
Last edited by a moderator:
I cannot understand your question.

Are you saying that given

\(\displaystyle p_x \implies p_{x+1} = p_x + \dfrac{p_x^{1.4}}{1000}\)

you want a formula for \(\displaystyle p_{x+n} \text {, where } n \in \mathbb Z \text { and } n \ge 1.\)

The initial formula looks a bit weird. For example

\(\displaystyle p_x = 100 \implies p_{x+1} \approx 100.63.\)

That's less than a 1% increase. But

\(\displaystyle p_x = 10000 \impliesp_{x+1} \approx 1016.\(\displaystyle

which is more than a 1% increase.

if you want a constant percentage increase regardless of the initial price, this formula is not going to give you that.\)\)
\(\displaystyle \(\displaystyle

Yes, the percentage change increases as the price increase. I'm happy with that.
I've tried a constant percentage increases before, and wasn't seeing the price growth I wanted.

However, my concern is that I have to loop through the expression however many times a person wants to buy an item to apply the new price with the change every time.
That's the only issue.

Unclear:

If p = 250:

c = 250^1.4/1000 = 2.2757....

c = 250^(1.4/1000) = 1.0077....

However, like Jeff, can't follow what you're saying/doing.

Yes, I did mean it as proper order of operations implies. So the change to p would be 2.2757...
The resulting p would be 252.2757, and assuming someone bought more than 1 item, that price would be plugged into the equation again, and repeated for however many times the item was bought.

What I need is instead of repeating that expression on itself x amount of times, x being the number of purchases, find a way to plug x into the equation and get the same result.

Is this not possible?\)\)
 
Last edited:
Huh? Price goes up if you buy more than 1:confused:
I'm missing something fer sure, fer sure...

Can you show what happens with this 250 example
if 5 items are bought? Merci bocups!

Sure, though it would be easier if I didn't have to wait 6 hour for my posts to be approved by a moderator every time. >.< Makes things a bit difficult.
I've just run the program with 250 as the starting price, and 5 items are bought.
This was the output:
Code:
[COLOR=#000000]250.0[/COLOR]
[COLOR=#000000][/COLOR][COLOR=#000000]252.2757052537826[/COLOR]
[COLOR=#000000][/COLOR][COLOR=#000000]254.58046468348417[/COLOR]
[COLOR=#000000][/COLOR][COLOR=#000000]256.91475627053796[/COLOR]
[COLOR=#000000][FONT=Monaco]259.2790676311882

[/FONT][/COLOR]total of purchase: 
[FONT=Monaco]1273.0499938389928[/FONT]

As you can see, there is no wait period before prices adjust, it happens in real time, with every item that gets transacted, even if they are all to be purchased at once.
The total for such a transaction would be 1273.04999... (Whereas no price adjustment would come to 1250, but that's irrelevant)

The problem is, I had to loop through that expression I provided in my original post 5 times in order to output that total.
I need to optimize my code; and preventing myself from needing to do this calculation 1000+ times when someone purchases 1000+ of an item, and simply come to the total at once, that is what I'm looking to do here.
 
[FONT=Helvetica said:
mmm4444bot[/FONT]]--Quote (Originally by justis)---
Is [finding an algebraic formula to accomplish the same thing] not possible?
---End Quote---
It might not be. Your algorithm is recursive; that is, each new price calculation depends upon all of the preceeding prices.

Sometimes, a specific sequence of numbers will have an algebraic representation, but a recursive algorithm is often easier to find.

Why is processing the loop a concern? I started with an initial price of $1 and ran the loop repeatedly, until the unit price reached $1,091,782.32 (purchasing 2,500 items).

It took less than a fourth of a second.

My program is a little more complex than just a collection of numbers representing the prices of items.
The majority of items don't have a price, but instead derive their price from other items that make it up.
An example would be that a chair would depend on the price of the amount of wood it takes to build that chair, plus the price of all the screws used to build the chair, some glue if glue was used, and sometimes those items it depends on depends on the price of other items as well, for example, the glue would depend on the price of it's chemical makeup, and the plastic that went into making the bottle and it goes on and on. I've even got service worth toggleable in there.
So it's a bit slower than simply setting a single number. That's why the optimization is necessary.
However, as preferable as it would be if there was a way to simply factor in the amount of an item purchased when making the purchase, to come up with the total...
I have been working on a way to separate the items from the prices in terms of price adjustment, so that it can be, as a worst case, as slow as with your test.

Still, I'd not like to give up on simplifying this recursive algorithm process (as you described it) into a single expression, if there's any hope it can be done.
Unfortunately, I'm not that skilled with math and have always needed to push myself to the limits of my abilities in order to know how best to proceed.
 
… it would be easier if I didn't have to wait 6 hour for my posts to be approved every time. Makes things a bit difficult …
Approval isn't required "every time". You were supposed to have received two notifications that only the first three posts need to wait for approval. What specifically is made difficult, by waiting a while before you reply?


I've just run the program with 250 as the starting price, and 5 items are bought.
This was the output:
Code:
250.0
252.2757052537826
254.58046468348417
256.91475627053796
259.2790676311882


According to your original post, that last dollar amount above would be the unit price if four items were purchased, not five. Unless you mispoke.

… p is the current price …


… if someone orders 1 item, the expression will be run and p will become p + c.

What is your concern about running the loop? I ran it, until the unit price became too large for the software to display as a decimal number. It took less than a quarter second.

Do you realize that, if the pre-purchase price starts at $1 and 2,500 items are purchased, these items would be priced at more than $1,091,782 each?
 
Last edited:
Approval isn't required "every time". You were supposed to have received two notifications that only the first three posts need to wait for approval. What specifically is made difficult, by waiting a while before you reply?
Impatience, mostly, seeing members post questions to things I've already answered but they have not yet been able to see. Making progress less and confusion greater.
Though, I've already posted more than three posts, and still see the moderation screen. Even this message was moderated. https://gyazo.com/6025cc024af7ddb9af82889cda09ffb4
According to your original post, that last dollar amount above would be the unit price if four items were purchased, not five. Unless you mispoke.
The prices listed there were the prices that the five items were purchased at, the resulting price of the item after the five purchases was not included because it had not yet been purchased at that price. However, I've ran the simulation again to get the resulting price of the item after give purchases, and it would have been 261.67389624662684

What is your concern about running the loop? I ran it, until the unit price became too large for the software to display as a decimal number. It took less than a quarter second.
I did answer the bit about why I need to optimize in my previous message. I sent it right before you asked.
I shall quote it here:
My program is a little more complex than just a collection of numbers representing the prices of items.
The majority of items don't have a price, but instead derive their price from other items that make it up.
An example would be that a chair would depend on the price of the amount of wood it takes to build that chair, plus the price of all the screws used to build the chair, some glue if glue was used, and sometimes those items it depends on depends on the price of other items as well, for example, the glue would depend on the price of it's chemical makeup, and the plastic that went into making the bottle and it goes on and on. I've even got service worth toggleable in there.
So it's a bit slower than simply setting a single number. That's why the optimization is necessary.
However, as preferable as it would be if there was a way to simply factor in the amount of an item purchased when making the purchase, to come up with the total...
I have been working on a way to separate the items from the prices in terms of price adjustment, so that it can be, as a worst case, as slow as with your test.

Still, I'd not like to give up on simplifying this recursive algorithm process (as you described it) into a single expression, if there's any hope it can be done.
Unfortunately, I'm not that skilled with math and have always needed to push myself to the limits of my abilities in order to know how best to proceed.

Do you realize that, if the pre-purchase price starts at $1 and 2,500 items are purchased, these items would be priced at more than $1,091,782 each?

Yes, no worries, this growth is intentional for the default example use case which is not related to real life monetary values. I've made the change algorithm completely configurable for any future needs of its users.
In my example simulation, supply and demand happen simultaneously, it's not restricted by the time it takes to ship before usage or anything like that; so the price growth through purchases will be cancelled out by the price reduction as the change is applied inversely for every item that is supplied. Of course, even then, the example expression is still fast, which is also for the sake of demonstrating the simulation, and not necessarily the best rate of change for adjusting prices of every item in every use case.
Though, that's getting a bit more into specifics I never believed that his question necessarily needed.
Not that I'm trying to hide my project. I'm happy to share. Just don't see it leading to an answer to the question. Though, at this point, given what you said about it being recursive, which is completely true, it doesn't seem like the question will have the answer I'm looking for.
 
Last edited:
Top