Expected Maximum Value

[rpigott]

Thanks for this tool! I really like the presentation and I hope we can make it as accurate as possible.

To that end, I'd like to propose an "Expected Maximum" column similar to the current "Guaranteed Minimum" and "Potential Maximum" columns. The Expected Maximum column would indicate the expected value of the maximum sell price in the remainder of the week. I made my case for including this metric in #170 while discussing the various non-uniformities in prices but, to summarize, it would be the most useful single metric to compare patterns between different islands, and it's fortunately not challenging to estimate.

Some patterns, like the peak of a small-spike, may have a non-obvious mean when the price distribution is non-uniform, and a naïve estimate based only on the bounds of the valid range could be misleading for users making comparisons. Providing an "Expected Maximum" column makes it much easier to accurately compare your expected profit between one island and another and decide to sell now or wait for the prices on your friend's island.

The expected maximum of a fluctuating subpattern is the expected maximum among all the remaining high phase days (rate ~ [0.9, 1.4)) or low phase days if no high-phase days remain (high phase 3 has duration 0). That's min + n*(max-min)/(n+1). It's above the mean high-phase price because the player has several chances to beat the mean.

The expected maximum of a high-spike subpattern is the expected value of the peak for days before the peak, equal to the current sell price on the falling edge of the peak, and similar to Fluctuating in the low phase.

For a decreasing subpattern the expected maximum is always the current selling price.

The expected maximum of a small-spike subpattern is the expected value of the peak for days before the peak, so rate=1.7 with unknown off-peak rate, or rate=1.4 + (2.0 - oprate)/log((2.0 - 1.4)/(oprate - 1.4)) given the off-peak rate. After the spike it's always the current selling price since the rate constantly decays.

[abrad45]

@RPigott I'd like to start this comment off by saying that... I no math good, and after reading your comment in #170 I feel I am barely clinging to an understanding of this math.

With that said, I think this may be a situation were providing people with a more specific projected value ("Expected Max") will be commonly misunderstood by users who will either be a support issue "what does this mean? how do I use it?") or belligerent ("the site said I should expect 400 but I got 190 wtf?!")

That we can display this to the sites' users may not be useful if we can't adequately explain, in plain english, what the value does and does not signify. I don't want to speak to members of the project, but looking through the github issues, I bet a plain english, non-technical explanation of what "Expected Max" means would increase the odds this makes it into the project :)

[theRTC204]

I share @abrad45's concerns here.

There's no doubt it's a fascinating data point - but I question what value it truly has to the vast majority of people who use this tool.

[rpigott]

@abrad45 Those are good points. Thanks for the feedback.

I am using Expected Value in the probabilistic sense here, mostly just because it has a specific definition, but I agree there is potential for user confusion.

There is an intuitive sense which suggests that the expected value of the maximum sell price is a good metric by which to decide when to sell: It is the same concept by which many players (and game-media outlets) have worked out that planting only 10k for their money trees maximizes their expected return by considering that there is only a 70% chance planting more than 10k will actually work.

The expected value of the maximum sell price is an equivalent metric for the Stalk Market. It is useful for calculating your return on investment on average. Needless to say, the Stalk Market is much more complex than money trees.

You are right that the expected value can easily be misinterpreted. It provides no guarantee of the predicted profit. It doesn't permit a specific claim about the probability that the actual maximum will match or exceed the predicted value, including whether or not that probability is >= 50%. Those misconceptions are hard to combat in a short description.

I think my best short description would be: "on average how much you make per-turnip given this pattern. (if you sell at the best offered price)" it's a sort of score that ranks, on average, how good that pattern is. I think describing it in terms of average earnings or bells might help. Additionally, the expected maximum for all patterns is just the weighted sum of each of the Expected Maximum for all possible patterns, so we could present this value in the All Patterns row to help users compare their town with a friends when the exact subpattern is not yet determined.

My main motivation for adding it comes from seeing that users, like in #170, are already trying their own estimates of their expected return in order to make this kind of decision. This does the math for them to make the comparison easier and more accurate.

You're right that it may not be worth the potential confusion. In most cases, I don't expect it will vary significantly from a naïve estimate anyway.

I still think this idea could be worth discussing, but for the time being I won't pursue a PR to implement it. Up to the maintainers whether or not to close this issue.

[abrad45]

@RPigott Thanks for the thoughtful reply.

Considering my personal lack of understanding of both math and the prediction algorithm, my “naive reading” of an expected 200-300 bell range would be 250 bells. Two questions:

1. How far off from the actual expected value is my naive reading?
2. Does how far off I am change based on the size of the range, or is it always roughly the midpoint?

[rpigott]

@abrad45 Except for the deviations from uniform I outlined before, for a given range that is the correct value.

If you really wanted to account for the exact frequency of the boundary values, the actual mean would vary by at most +/- 0.5, which is barely anything really.

The value-add of this feature comes from the fact that the expected maximum is not necessarily equal to the mean of an individual range, and may be evaluated for all patterns collectively.

In the Fluctuating pattern, there are always exactly 7 instances (out of 12 total prices) combined of the "high" phases, where the rate is selected from [0.9, 1.4). The maximum price will obviously occur during one of these times because the minimum here is greater than the maximum rate during the 5 "low" times.

At the beginning of the week, would you choose to sell on Monday AM if the first rate is over 1.15 = (0.9 + 1.4)/2, i.e. 115 bells if your buy price was 100? Probably not, because you are guaranteed 6 more chances to beat this value if you wait, and that's only if you are certain of a Fluctuating pattern, which is impossible at this point in the week – with our one known price it could still be a small spike. For this reason the expected value of the maximum sell price is greater than 1.15 for every Fluctuating subpattern that has more than 1 "high" value remaining. If your sell price is greater than the expected maximum for the remainder of the week (or the expected maximum on a friend's island), then it is probably a smart choice to sell.

The expected maximum for a small-spike pattern is also the mean of the peak range. Like I outlined in this comment when we know the off-peak price (the price immediately before the peak) the distribution of prices at the peak is biased within the updated range. The bias is accounted for in our calculation of the expected maximum by using the accurate mean for the peak price in this one specific case.

To be clear, even then the variation is not large. Here is a plot that shows the difference between these estimates for a buy price of 100 bells:

When the off-peak price is unknown, we always use the average of the range 170 = (140 + 200)/2. When the off-peak price is known, the peak price must be greater, so the possible range shrinks. The "naive" line shows our new mean if we only consider the new displayed range, and the "accurate" line shows the real mean considering the bias I described before.

Now, the off-peak price is itself biased toward the lower end of it's range, but even still most of the time the difference is less than 5 or 6 bells, and only rarely more than 10 bells.

The High-spike pattern has no biases and the biases in the Decreasing pattern are tiny and inconsequential to the expected maximum value anyway.

The expected maximum is useful because it's a single number to compare with your current buy price, or your friends island. You don't have to do any of the consideration I laid out above. Especially in the case where there are multiple possible patterns still, the expected maximum for all patterns combined is easy for us to calculate as the weighted sum of each individual expected maximum, but not at all obvious to the user.

Despite the challenges in interpreting the expected maximum value I mentioned before, unless I'm mistaken it has one very compelling interpretation: If you always sell when your price matches or exceeds the expected maximum, you will maximize your expected return. Just keep in mind that it may change a lot as we learn new prices.

The tool currently presents the guaranteed minimum and potential maximum. Neither of these numbers are very helpful when considering all patterns together. The expected maximum has a lot of utility for informing "when to sell" decisions, even in cases with few known prices, or among a collection of islands.

[ZZZZzzzzac]

I agree this expected peak value may help, and it is really easy to calculate but i'm afraid this may not only confuse user, but also introduce bias ,not statistic one but psychological one, because expected peak value of pattern 1 is 400, far higher than other pattern.

even with 88% probability for decreasing pattern and 12% for high spike pattern, the expected peak value is still greater than base price. We don't have enough time and money to achieve law of large numbers, and once you lose a lot your investment to next turn will be limited. If you only sell when price exceeds expected price, it's more likely you will lose a lot and never win back

[monicathieu]

First off, big thanks to @RPigott for digging so far into deriving the posterior probabilities of turnip prices for the various patterns, for example in #170 !

👍 to @abrad45 and @ZZZZzzzzac 's comments above about maximizing interpretability for stats novice users. To this point, I heartily support adding an expected value-type estimate for the All Patterns estimate ONLY.

Ultimately, for the end user, I suspect that knowing their turnip pattern is not the end goal in itself, but instead knowing the pattern is the single most useful piece of information for extracting the (maximum) expected turnip price, which is really the number driving decision making.

In more Bayesian terms, the user's question is:

Given last week's pattern, and the prices I've already observed, what is the posterior probability that a future turnip price will be at least X Bells?

The app could report, say, the median value (in Bells) of the All Patterns posterior distribution, to answer that question. The All Patterns posterior median tells you that you have a 50% chance that at some point your price will be greater than that value. As such, it also tells you that you have a 50% chance that your price will never be greater than that value for the whole rest of the week. Depending on people's risk tolerance, they might be able to use this number to decide whether to sell at island A sooner vs waiting to see if island B's prices improve later.

By reporting only the All Patterns estimate, this helps address @ZZZZzzzzac 's concern that people might improperly weight the pattern probabilities in their heads. If you were at 88% probability of decreasing, and 12% probability of high spike, the All Patterns posterior median should skew heavily toward 80-something Bells, since the posterior distribution will look 88% like a decreasing pattern. Thus, even though a large spike is not impossible, your turnip price is (at least) 50% likely never to go above base price, which should weight people's risk tolerance accordingly.

Alternatively, (though this would require analytically specifying the entire posterior distribution! Yikes!) the user could specify a percentile based on their risk tolerance, and the app could return the Nth percentile of the posterior turnip price distribution. The interpretation would be: "Your max turnip price is N% likely to be higher than X Bells at some point this week." OR "Your max turnip price is (100-N)% likely to be lower than X Bells for the entire rest of this week."

[theRTC204]

I really like all the deep discussion happening here; very cool to see so many people wanting to help out, and seeing different perspectives!

I do one to comment on one aspect of @monicathieu's last message.

Alternatively, the user could specify a percentile based on their risk tolerance...

I must admit, I'm hesitant about the idea of having the user provide a risk tolerance, and I don't imagine the average player having a high understanding of what that means.

[sobels]

I was just thinking about this today, so I'm glad to come across this thread. I think for me the biggest pain point in the tool is deciding what to do when I hit a fluctuating pattern. However, I don't think the expectation of the maximum value has the decision property you describe. The problem is that you may pass by the true maximum during your decision process if you think you can do better. This is an optimal stopping problem but I couldn't find anything exactly matching it in my brief Googling.

Here's how I constructed a decision process for the fluctuating pattern.

1. Perform scaling so WLOG we're fluctuating between min = 0 and max = 1 on high days.
2. Let EP[n] be the expected payout if we hold and instead sell in one of the n remaining high days
3. Clearly EP[1] = 1/2
4. EP[n] = EP[n-1] * Pr(hold on the next day) + E[Price on next day & sell on the next day]
5. Pr(hold on the next day) = 1 - Pr(sell on the next day) = EP[n-1]
6. After much simplification this means EP[n] = 1/2 (1 + EP[n-1]**2). You can use this to iteratively construct a table of EP[n] for the whole domain of concern (up to n=11) ahead of time.
7. Compare your (scaled) current turnip price against EP[n]. If it is greater than EP[n], sell.

The tricky thing about this expectation is that it is oracle-sensitive - I assumed an expected-payout-maximizing oracle but there are other oracles which you can construct given a different end user utility function. That said I don't think risk aversion figures too much into this tool because (a) it seems like a hard-ish problem to me, (b) there's relatively little downside in turnip trading anyway, and (c) we can communicate uncertainty to the user and leave the final decision in their hands.

I think it could be neat to provide a clearly-labelled "experimental" feature that prescribes whether or not you sell and explains why in plain English. I was sketching out an algorithm for this today and I think it is possible to construct a strategy for the general problem. There are a few notable corner cases -

• The decreasing pattern and spike pattern are ambiguous for the first 1-7 half-days. The oracle would probably almost always judge to hold until it's no longer ambiguous. That said you could always provide canned explanations for both decisions: (a) "We can't tell if your pattern is decreasing or large spike. It makes sense to wait and see." or (b) "We can't tell if your pattern is decreasing or large spike, but we think you should limit your losses and risk losing out."
• Fluctuating patterns (as noted above) have an interesting decision process. A possible hold explanation is "You're in the fluctuating pattern. Because you have {{count}} days remaining, we think you stand a good chance of getting a better offer."
• There is a chance for ambiguity between fluctuation and small spikes if the first half-day is 90% base price and the second is 140% base price (in fact, this happened to me this week). This is an interesting situation where the oracle could cause you to potentially forego an additional 60% return if it told you to sell. An explanation could go, "You have a {{pr_spike}} chance of hitting a small spike, but this is literally the best you can do if it isn't, so we think you should sell."

I think the key is that by creating English explanations for some of these cases we can communicate uncertainty in a more digestible way than expecting that the users have taken a college stats course. And the explanations can be progressively added, we wouldn't need to do a big bang release.

It is a fair bit of work though. I'd gladly volunteer to throw together a prototype if people think it'd be worth it.

[abrad45]

@sobels Thanks for this. Two things here, from the guy who, above, noted that he has not taken any level stats courses :)

Downsides

“That said I don't think risk aversion figures too much into this tool because (a) it seems like a hard-ish problem to me, (b) there's relatively little downside in turnip trading...”

If, by this, you mean that buying at ~100 bells and selling for ~80 bells is a ~20 bell loss per turnip, and bells are easy to make in the game, I think that’s an odd argument, but fine.

But if, by this, you mean that people will not face any real-world financial consequences if they don’t sell root vegetables in a video game for profit, so it doesn’t 100% matter if this “fair bit of work” is done right, I think that misses the point.

People text me all the time to check my turnip prices. I have a slack channel at work with 30+ members who all check twice daily. People take this fairly seriously, so I think if we’re not sure we can add value with a feature like this, it’d be better to not do than to build a clearly label a feature “experimental” because we aren’t sure how much it’s going to help you but it made some math nerds happy ;)

The Stalk Market Multiverse

All of your plain english explanations assume that a stalk-owner, during each of the 12 buying periods, has two choices:

1. Sell
2. Hold

There are a myriad of other choices, which involve friends playing the game, other apps that offer turnip exchanges, discord groups, etc. There is not one stalk market: there are many, and while this site is clearly labeled “not a tracker for multiple islands” we shouldn’t advise minimizing losses by selling at home if a user can make a profit elsewhere.

I think we’d do well, here, to write all of the language in terms of the best a user can or cannot do on their particular island. That is, “Your island will not go higher than x”, versus “limit your losses by selling at x” — This might be obvious to users, but I think the tool should offer advice in line with all of the feature in the game, as there is not a single market.

[sobels]

@abrad45 Thanks for reading my wall of text! A few points here:

If, by this, you mean that buying at ~100 bells and selling for ~80 bells is a ~20 bell loss per turnip, and bells are easy to make in the game, I think that’s an odd argument, but fine.

That is what I was driving at. There is a Gambler's Ruin problem at play like @ZZZZzzzzac noted but I honestly don't know how frequently it would occur without constructing the sell/hold recommender and running a bunch of simulations with it.

I have a slack channel at work with 30+ members who all check twice daily. People take this fairly seriously, so I think if we’re not sure we can add value with a feature like this, it’d be better to not do than to build a clearly label a feature “experimental” because we aren’t sure how much it’s going to help you but it made some math nerds happy ;)

The Stalk Market Multiverse

I was hoping no one would mention multiple stalk markets 😅

If you want to treat the multi-market problem numerically, the decision becomes hold / sell at A / sell at B / sell at C / ... . From what I can tell I think this problem is much harder from an algorithms perspective, but in the limit where we're at 30+ islands the intuitive answer is obviously to wait for the nearly-inevitable large spike on someone's island.

So if you're a real turnip power user then the entire output could be replaced with a giant <h1>Have you hit a large spike yet?</h1><h2>YES/NO</h2> and almost no other feature can add value.

But if you're in 1, 2, or 3 markets at most like me you struggle to decide whether to sell / hold in many plausible scenarios (like say, you're both in a fluctuating pattern). Personally the guaranteed minimum / potential maximum don't really help me. If you have many "high" days left then you should have higher standards for selling - but exactly how high should your standards be? I'm definitely nerding out here but that's the value I'm chasing after. I'm not sure if a sell/hold oracle is the right way to do it but I'm a solid 80% sure that software could do it better than my feeble brain.

[abrad45]

Thanks for reading my wall of text!

I had to skip your ordered list full of math, but otherwise, any time ;)

I was hoping no one would mention multiple stalk markets 😅

😂 thanks for the laugh

So if you're a real turnip power user then the entire output could be replaced with a giant <h1>Have you hit a large spike yet?</h1><h2>YES/NO</h2> and almost no other feature can add value.

Yes and no. I use the feature to know what others may benefit from, too. I was simply saying that I think the goal should just be telling people the most they can get on their home island. If they don't have NSO and no one to Local Play with, then that's the most they can get, period. If they do have NSO and friends playing the game, then telling them to sell at 78 because it's only going to go down from there may be awful advice.

It was more about the wording of the feature than specifically saying your algorithm should account for the size of ones' social group and the likelihood that they'll have a higher price without knowing any information about their islands :) I believe you'd call that a hard-ish problem ;)

[monicathieu]

Walls of text incoming, but many of them are math so you can skip them if you like!

In the interest of providing the user with as few numbers as they need to make their judgment, we can probably make the following assumption per @abrad45 that if a user has a high likelihood of a lousy pattern on their own island, they already a suitable backup plan in mind. Maybe that plan is going to someone else's island, or maybe selling on their own island ASAP to cut losses. Accounting for all of those outcomes is, as @sobels indicated, wawawaway too complicated and probably not worthwhile.

The single best number to make this judgment, "Do I have a Good Pattern?", might be one that's already on the app! The % chance of being in a particular pattern (the one that sums over all the possible variations of that pattern) tells the user "How likely is it that my pattern is a Good Pattern (i.e. small or large spike)?"

Beyond that number, an All Patterns posterior percentile is telling you a different flavor of the same thing. In units of Bells, the All Patterns posterior percentile can tell you "How likely is it that my turnip price will be at least X Bells at some point this week?", or the opposite, "How likely is it that my turnip price will never go higher than X Bells anytime this week?" where X Bells is some Good Price.

Parsimony says just keep the overall pattern probabilities that are already on the app, and maybe make them more visually obvious. If a number in units of Bells is useful, then an All Patterns posterior Bell percentile cutoff might serve that job.

IF YOU ARE TRYING TO MAXIMIZE TURNIP PRICES IN A GROUP:

There might be some utility in a calculator where you put in your Turnip Prophet pattern probabilities, and the pattern probabilities of N other players, and it tells you the probability that at least one person in your group has a Good Pattern. However, here's why that might not tell you that much: Anyone in a turnip tracking group is already at a HUGE advantage just by strength in numbers.

In a group, assuming no additional information about what the group members' previous trends were, you only need a group of 3 people (you and 2 others) to have a better than 50% chance that at least 1 person in the group will have a large spike in any given week. With a group of 5, you have about a 75% chance that at least one person will have a large spike in a given week. With a group of 11, you have a 95% chance. As your group gets bigger, you can imagine that the probability that at least one person will large spike in a given week approaches 1. (but then you have the trouble of having like 30 people try to come to your island 😅)

IF YOUR WHOLE GROUP IS FLUCTUATING, NERD PROOF BELOW:

If you're in the trickiest scenario that @sobels presented, where you're in a group of, say, 2 players and every player is locked into fluctuating, that's its own thing. You'd need to know your desired profit margin, each of y'all's Sunday prices, and how many high days each of you have left at the time of calculation.

Say you want to sell for at least 120%, or 1.2x, your own Sunday price. The probability that either of y'all's prices will exceed your threshold at some point that week, P(any price > 1.2 * your Sunday price), is equal to:

1 - (P(your price is lower than 1.2 your Sunday price) # your high days left) P(their price is lower than 1.2 your Sunday price) * # their high days left)

This is one of those probability problems where it's easier to calculate the probability that the opposite of what you want happens, and then subtract that from 1 to get the probability of what you want. Any probability involving something happening at least once is much easier to calculate as (1 - P(the thing you want never happens)). So here, we calculate it as 1 - (P(none of your high day prices beat your threshold) AND P(none of their high day prices beat your threshold)).

Since the fluctuating high range is [0.9, 1.4], and your rate is drawn uniformly between those two, a threshold of 1.2 means you have a 60% chance that a high rate <= 1.2, because the width of the range is 0.5, and 1.2 is 0.2 away from 0.9, aka the bottom of that range. Thus, (1.2 - 0.9) / 0.5 = 0.6 or 60%.

You get a chance to draw this high rate once every remaining high-day (or half-day, to be precise) that week. So, P(your high rate NEVER exceeds your cutoff) = 0.6 * # your high days left, because it needs to happen every single high day remaining for you to fail to hit your threshold ever.

To calculate the probability that THEIR price is higher than YOUR threshold, it doesn't simplify down to a single number because it depends on the ratio between your price and their price. Essentially, 1.2 your Sunday price = X their Sunday price, where X is THEIR minimum rate needed to beat YOUR threshold. Divide both sides by their Sunday price, and X comes out to 1.2 * your Sunday price / their Sunday price. This accounts for the fact that if your pal's Sunday price was higher than yours, their Bell range is gonna be higher than yours, so you have a better chance to beat YOUR threshold on THEIR island. (And vice versa if their Sunday price was lower than yours.)

If we pop this into a similar formula like we used above, where P(rate <= desired, in a uniform distribution) = (desired - min) / width, we get:

P(their high price <= 1.2 your Sunday price) = ((1.2 your Sunday price / their Sunday price) - 0.9) / 0.5

To avoid dividing by fractions, we can rewrite this as:

P(their high price <= 1.2 your Sunday price) = 2 ((1.2 * your Sunday price / their Sunday price) - 0.9)

Again, your pal gets a chance to draw this high rate once every remaining high-day that week. So, P(your high rate NEVER exceeds THEIR cutoff) = 2 ((1.2 your Sunday price / their Sunday price) - 0.9) * # their high days left, because it needs to happen every single high day remaining for their price to fail to hit your threshold ever.

If we plug both of these probabilities in to the starter expression we had before,

P(every price for the rest of the week <= 1.2 your Sunday price) = ((0.6 # your high days left) (2 ((1.2 your Sunday price / their Sunday price) - 0.9) # their high days left))

Then, to flip this to get the probability that ANY price exceeds your cutoff:

P(any price for the rest of the week > 1.2 your Sunday price) = 1 - ((0.6 # your high days left) (2 ((1.2 your Sunday price / their Sunday price) - 0.9) # their high days left))

To generalize, the equation should be (if I didn't make any typos):

P(any price for the rest of the week > your threshold your Sunday price) = 1 - ((2 (your threshold - 0.9) # your high days left) (2 ((your threshold your Sunday price / Pal 1's Sunday price) - 0.9) # Pal 1's high days left) that term again, but for Pal 2 * ...)

Again, as you add pals, the probability that you beat your threshold on at least one pal's island approaches 1, because 1 - an ever decreasing fraction approaches 1 - 0. But if you're doing it for a couple pals, you can plug and chug the equation above.

ADDITIONAL NERD STUFF BELOW:

The week-to-week turnip pattern generator is a Markov chain, because the probabilities for the current week's pattern are different depending on last week's pattern. This Markov chain equilibrates--so, on average, it doesn't matter what your very first turnip pattern was. At any point in the future, without knowing the previous week's pattern, your turnip pattern probabilities are: 25% large spike, 25% small spike, 35% fluctuating, and 15% decreasing. Nintendo really wants us to make money!

[rpigott]

@sobels You're right, a player cannot maximize their expected return by selling at or above the EMSP.

When I initially thought to add this metric the fluctuating pattern was an afterthought, since the purpose was mostly to compare different spikes between islands. It's easy to see that in all other patterns we will never inadvertently miss the maximum value since the valid intervals do not overlap. If it weren't for the Fluctuating pattern, EMSP would be an optimal strategy for expected return.

I still feel that EMSP is a useful metric for it's original purpose of quick comparison between spikes, even if it doesn't immediately suggest an optimal stopping strategy in the general case. Especially since it is easy to calculate.

If it matters, I think maybe it could maybe be shown the EMSP is an upper bound on the expected return of the optimal strategy – since no strategy for identifying the maximum sale price can influence that actual maximum value, though it is just my conjecture.

It's not obvious to me how an optimal stopping strategy could be formed in the general case, when we intend to maximize the expected return across all possible patterns, but if you can demonstrate an optimal strategy that would definitely be cool.

I do worry that an indicator, such as "sell now" or "hold", even if optimal, may end up having less utility than a variety of metrics the player can use to inform themselves, but I suppose that's why we already present the individual sale price predictions. All metrics and strategies essentially suffer from the same weakness if the player is unable to check prices every day. There's really no way to query the user for "probability you'll play thursday morning". Overall, I would be interested in seeing an optimal strategy indicator implemented.

Finally, I agree it's worth considering utility functions other than the expectation of the return. In that vein, I think the suggestion from earlier in the thread could be helpful, a Median Maximum Sale Price (MMSP) to indicate when the probability of a future price exceeding the current one is 50-50. I believe an MMSP based strategy would optimize the probability of stopping on the maximum sale price (rather than the expected return – not useful in the case there is a 49% chance of the price dropping to 0, but no method is perfect for all players) but that is also just my conjecture. At the very least, the EMSP and MMSP are at least easy to calculate.

Actually even if we just present the probability a future price will exceed the current one, I think most users would naturally choose a MMSP-strategy by selling when the value is below 50%. That intuitive property seems very compelling to me when the primary issue with most other strategies we can imagine seems to be actually explaining their significance to users.

[ZZZZzzzzac]

Let's put things together. I think we shoule set 3 dimension for these kind problem:

x. the price probability distribution of one specific time. y. a time axis. often using statistic feature to describe, like the peak price probability distribution alone a week z. mulitple island with or without knowledge of their price PSD

given history price and pattern, we now have PSD of x-y plane, can give probability of price X at time Y. and potentially have z-axis if other island in that group also use this tool.

so there are many scenarios:

• alone x-axis: one want to compare price probability of two day. ( It's SatAM and I forgot to sell all my turnip, now my price is 80, should I sell right now or wait for SatPM?)

• alone y-axis: one want to predict peak price of his/her own island. ( I had small spike pattern last week, so I know the probabilities of each pattern this week, should I buy a lot turnips? and how much money can I make?)

• alone z-axis: only have current price of many islands doesn't really help...wait, I SEE A 660 !

• on x-y plane: one only want sell at his/her own island, want to predict future price and choose which day to sell. (the most common scenario)

• on x-z plane: one want to sell at many islands today, and want to know which island to go. (my friend have peak value 220 with small spike pattern today, but now I have 20% of high spike and 80% decreasing odds, should I sell right now or wait for 20% high spike?)

• on y-z plane: know history price of multiple island, want to compare peak value of each other (similiar to y-axis but for many islands, how much can I earn? what price is a good price to sell? when should I sell?)

• on x-y-z matrix: one only want sell at many islands, and want to predict future price and choose which day to sell. ( All my friends and I are in FLUCTUATING, what should I do?)

It is clear that user need different statistic analysis for different scenario and different question that user concerned. And for issue like #217, we may also need differnet graph representation for different scenario and question.

[NeatNit]

IF YOU ARE TRYING TO MAXIMIZE TURNIP PRICES IN A GROUP:

There might be some utility in a calculator where you put in your Turnip Prophet pattern probabilities, and the pattern probabilities of N other players, and it tells you the probability that at least one person in your group has a Good Pattern. However, here's why that might not tell you that much: Anyone in a turnip tracking group is already at a HUGE advantage just by strength in numbers.

In a group, assuming no additional information about what the group members' previous trends were, you only need a group of 3 people (you and 2 others) to have a better than 50% chance that at least 1 person in the group will have a large spike in any given week. With a group of 5, you have about a 75% chance that at least one person will have a large spike in a given week. With a group of 11, you have a 95% chance. As your group gets bigger, you can imagine that the probability that at least one person will large spike in a given week approaches 1. (but then you have the trouble of having like 30 people try to come to your island 😅)

Hi. This exact scenario is what ruined me* this week and it's the reason I came here to GitHub to see what people have suggested.

I'm playing with 2 friends, and by Tuesday PM our prices were these (really doesn't matter who is which):

• A: https://turnipprophet.io?prices=108.77.73.127.145........&pattern=3
• B: https://turnipprophet.io/?prices=95.82.99.149.267........&pattern=0
• C: https://turnipprophet.io?prices=101.89.85.81.77........&pattern=0

At this point I decided to sell ~60% of my turnips for 267, which would already put me in a profit, and hold out the rest for the potential large spike coming my way.

By Wednesday PM, it looked like this:

• A: https://turnipprophet.io/?prices=108.77.73.127.145..163......&pattern=3
• B: no longer tracking, maxed out yesterday
• C: https://turnipprophet.io/?prices=101.89.85.81.77.73.70......&pattern=0

It's now more likely that C is decreasing than not. I sold all my remaining turnips at A for 163.

And wouldn't you know it... Two days later, C looks like this: https://turnipprophet.io/?prices=101.89.85.81.77.73.70..99.189.499..&pattern=0

Don't even click it, just look at the URL. Ouch.

The big question is, did I read the data wrong to draw the wrong conclusion? Or did I make the right call, and just get unlucky?

And most importantly, is it possible for Turnip Prophet to provide better data/advice to help me make better decisions in the future?

* actually I still made a small profit but what's the fun in saying that? 😛

Also I do treat this as "just a game" and I'm not devastated, but it would have been super nice to get those massive bucks. I'm still pretty new to the game so this would have allowed me to upgrade my house to the max** and have lots of spending cash left over.

** what I assume is the max, I don't actually know

[monicathieu]

@NeatNit , I would say you actually should have taken the gamble that week. You can think about it like this, in a super rough way (doesn't take into account that you already sold enough of your turnips at 267 apiece to make a net profit over all turnips for the week):

2 choices as of Wednesday PM: SURE BET:

1. Sell for 163/turnip (profit of 163-95 = 68/turnip) with 100% probability on Wednesday PM

GAMBLE:

1. Sell for 57/turnip (loss of 38/turnip) on Friday AM with 61% probability
2. Sell for 404/turnip (profit of 306/turnip) Friday AM or PM with 35% probability

(I'm ignoring the 4% small spike trend atm, you'll see it doesn't end up making a difference). Both of the expected turnip prices for the gamble possibilities are roughly the midpoint of the uniform Bell price ranges for those days. I'm assuming you'd sell on Friday AM if you knew that Island C was on a decreasing trend, because by that time a large spike should have already started, so if you know you're decreasing at that point you should sell ASAP.

The sure bet has an expected value of +68/turnip, whereas the gamble here has an expected value of about .61 -38 + .35 +306 = +84/turnip. If you choose the option that has a higher expected value, you should take the gamble. Now, you might lose the gamble! And you have to decide how much loss you can tolerate, so maybe you don't want to be so risky. But in general, if you just go on the numbers, the big spike is SO profitable that in most cases, you should gamble on the big spike.

---

I think turnip gambling is giving a lot of people an unexpected crash course in probability theory 😅 For those who wish to do the probability calculations themselves, the Turnip Prophet is already providing all the numbers one might need to calculate a rough expected value of the profit for selling on a given day at a given island. It might be out of scope for the Turnip Prophet to ALSO then do expected value calculations across multiple islands, but maybe a secondary web app would be able to help with those calculations since it looks like a lot of people might get use out of it. Or maybe it does belong in the main app! I wouldn't want the main app to get too cluttered, but if the consensus is that such a gamble calculator fits in well with the main app then everything's good.

Probably the single biggest expected value question people have is like the question above:

"Should I take a sure bet and sell at a guaranteed price of X Bells/turnip now, or gamble on a spike-or-decreasing island?"

This expected value calculator, wherever it ends up living, could either take in Turnip Prophet permalinks for each gamble island and calculate all the relevant price ranges/probabilities, or people could input the Sunday price and current overall probabilities for each gamble island. I'm no Javascript expert, so I'm not sure how hard it would be to grab pattern probabilities from permalinks, but the math itself should just be algebra once the probabilities and price ranges are extracted.