Comments (42)
Yes, that's how it works. It saves the prices. That's how some people have more than 660. You would need to modify the save data instead of the game.
You mean they mod their Switch and somehow put a number bigger than 660
into the price table? One time I even remember a guy on https://turnip.exchange asking us to sell only 1 or 100 turnips... let's see... full bag is 4000, so 1 spot is 100. I remember the guy kept asking us to bring only 1 spot of turnip to his island and sell and he said "trust me"... and the end result was that the Bells that was returned in our bag was 4000 * 660 = 2640000 so I think he mod'ed the price table to be 26400
per turnip.
from turnip-calculator.
I did that and these are the 7 possibilities:
it is 350 lines of JSON data, so I put it in a gist:
https://gist.github.com/nonopolarity/26b00a1dd78b5ea8fa18df473368462d
from turnip-calculator.
This is somewhat tough, together with (1) using float instead of double and the numbers are quite inaccurate (2) having a weird ceil()
function.
The table I created, I thought about it. It seems to make it even better, it would be to check whether the turnip price of 90 can fit any of those pattern, and then 91, and so on, all the way until 110. This way, it will be even more accurate. But if so, I'd have to come up with 21 of such mappings, one for each turnip price. So if some price pattern can fit into that high spike table, but no initial turnip price can ever produce that price pattern, then it also would reject it as a high spike pattern.
from turnip-calculator.
HI! @nonopolarity
I think I found something in our code. An oversight on my end. Doing predictions with so little data got me confused. π
But something about your scenario helped me a lot. Thank you for reporting this.
Edit: The fix should be live in 2.1.3-build.1
from turnip-calculator.
HI! @nonopolarity
I think I found something in our code. An oversight on my end. Doing predictions with so little data got me confused. π
But something about your scenario helped me a lot. Thank you for reporting this.
Edit: The fix should be live in 2.1.3-build.1
Hi @elxris, could you add me to the credits or is it auto generated when I do a pull request? My id is @______________
from turnip-calculator.
It is auto generated. But you can do a small PR. I'll approve it. Bump the calculator to 2.2.0-build.0 π in the package.json
from turnip-calculator.
@elxris I am not sure if I did anything wrong... if on the Mac I pressed CMD-Shift-R to force a hard refresh, clear all data, and do a hard refresh again, and enter:
Go to Monday Morning, type 78
Go to Tuesday Afternoon, type 63
I still get the 660 scenario.
from turnip-calculator.
You're right, I see the same scenario.
Give me some time to check this.
from turnip-calculator.
@elxris
I dig into it, and got the following:
It is to analyze the big spike pattern.
https://gist.github.com/nonopolarity/4c0716f7cc6d13b092c5194c2f74edac
int main(int argc, char **argv)
{
TurnipPrices turnips;
turnips.rng.init();
float checkingMin = turnips.randfloatMockedMin(1000.0, 2000.0),
checkingMax = turnips.randfloatMockedMax(1000.0, 2000.0);
printf("checkingMin, checkingMax are %f %f exact? %d %d\n", checkingMin, checkingMax, checkingMin == 1000.0, checkingMax == 2000.0);
checkingMin = turnips.randfloatMockedMin(2000.0, 1000.0),
checkingMax = turnips.randfloatMockedMax(2000.0, 1000.0);
printf("checkingMin, checkingMax are %f %f exact? %d %d\n", checkingMin, checkingMax, checkingMin == 1000.0, checkingMax == 2000.0);
float rateLow = turnips.randfloatMockedMin(0.9, 0.85);
float rateHigh = turnips.randfloatMockedMax(0.9, 0.85);
for (int work = 2; work < 6; work++) {
int priceMin = 999999, priceMax = 0;
int priceLow, priceHigh;
for (int basePrice = 90; basePrice <= 110; basePrice++) { // could have added 20 directly
priceLow = turnips.intceil(rateLow * basePrice);
priceHigh = turnips.intceil(rateHigh * basePrice);
priceMin = std::min(priceLow, priceMin);
priceMax = std::max(priceHigh, priceMax);
}
printf("PRICE period %d low %d high %d\n", work, priceMin, priceMax);
rateLow -= 0.03;
rateHigh -= 0.03;
rateLow -= turnips.randfloatMockedMax(0, 0.02);
rateHigh -= turnips.randfloatMockedMin(0, 0.02);
}
return 0;
}
from turnip-calculator.
and the output:
$ ./a.out
checkingMin, checkingMax are 1000.000000 1999.999878 exact? 1 0
checkingMin, checkingMax are 1000.000122 2000.000000 exact? 0 1
PRICE period 2 low 77 high 99
PRICE period 3 low 73 high 96
PRICE period 4 low 68 high 93
PRICE period 5 low 64 high 90
So it seems for Tuesday afternoon, the minimum value it has to be is 64
. I think right now if I go to the website and clear out all data, and hard refresh, and enter 63
for Tuesday afternoon, it still shows possible 660
later on.
It actually takes 60
and thinks 660
is possible. It has to be 59
for it to reject 660
. So the minimum should be 64
.
from turnip-calculator.
the max can be higher, as it can already get past the first phase, but the above is to just analyze the minimum values of the first phase, with the subsequent values intceil(randfloat(0.9, 1.4) * basePrice)
etc which must be greater than or equal to 81
.
from turnip-calculator.
Thank you for this, it is useful, however, I think I have trouble with floats.
I added to the end of your script:
float testRate = turnips.randfloatMockedMin(0.9, 0.85);
testRate -= 0.03;
testRate -= turnips.randfloatMockedMax(0, 0.02);
testRate -= 0.03;
testRate -= turnips.randfloatMockedMax(0, 0.02);
testRate -= 0.03;
testRate -= turnips.randfloatMockedMax(0, 0.02);
printf("Test %f, 64? %d\n", 90 * testRate, turnips.intceil(90 * testRate) == 64 );
testRate = turnips.randfloatMockedMin(0.9, 0.85) - 0.09 - turnips.randfloatMockedMax(0, 0.06);
printf("Test %f, 64? %d\n", 90 * testRate, turnips.intceil(90 * testRate) == 64 );
testRate = turnips.randfloatMockedMin(0.9, 0.85) - 0.03 - turnips.randfloatMockedMax(0, 0.02) - 0.03 - turnips.randfloatMockedMax(0, 0.02) - 0.03 - turnips.randfloatMockedMax(0, 0.02);
printf("Test %f, 64? %d\n", 90 * testRate, turnips.intceil(90 * testRate) == 64 );
Output:
Test 63.000015, 64? 1
Test 63.000004, 64? 0
Test 63.000004, 64? 0
This may get me closer to some precision issues.
from turnip-calculator.
I have tried several things on rust, so far I hate the results because there is no easy fix for this.
PD I have fixed this, though, and reviewed some other things. It was the thing I removed trying to fix this issue.
It actually takes 60 and thinks 660 is possible. It has to be 59 for it to reject 660. So the minimum should be 64.
from turnip-calculator.
That's interesting... I also tried:
testRate = turnips.randfloatMockedMin(0.9, 0.85) - (0.03 + turnips.randfloatMockedMax(0, 0.02)) * 3;
printf("Test %f, 64? %d\n", 90 * testRate, turnips.intceil(90 * testRate) == 64 );
testRate = turnips.randfloatMockedMin(0.9, 0.85) - 0.03 * 3 - turnips.randfloatMockedMax(0, 0.02) * 3;
printf("Test %f, 64? %d\n", 90 * testRate, turnips.intceil(90 * testRate) == 64 );
and also got
Test 63.000004, 64? 0
Test 63.000004, 64? 0
so it seems their "1 line inaccuracy" is not the same as "multiple line inaccuracy". It is a bit surprising to me that the inaccuracy happens at the 6th decimal place (and even the 5th decimal place). I would have expected it to be the 10 or 12 decimal place or something like that... and the way the code does "ceiling":
int intceil(float val)
{
return (int)(val + 0.99999f);
}
makes it more complicated... It changes the definition of "ceiling" from the IEEE-754 to its own definition, which is to add 0.99999
and then truncate.
So I will look more into your Rust code... oh but how come Rust? Does the website front end (or backend?) run any Rust code or is it because you precompile the values in the table using Rust?
Right now I am thinking, if the code that Ninji has does this:
peakStart = randint(3, 9);
rate = randfloat(0.9, 0.85);
for (work = 2; work < peakStart; work++)
{
sellPrices[work] = intceil(rate * basePrice);
rate -= 0.03;
rate -= randfloat(0, 0.02);
}
then it would follow the "multiple line inaccuracy"... and so it should be 64
and not 63
, because it goes through the loop and put the values into the array. I'd think the mechanism of AC:NH is that when the game detects that it is a new week (or that when the user time travels to the past even 1 minute), then it re-populates this array for the rest of the week... if the user quits the game and then later on restart the game within that same week, then the seed was saved previously and is reused to repopulate the exact same array? If that's the case, we probably would like to emulate the behavior and just follow the multiple line inaccuracy to get those values.
from turnip-calculator.
So I will look more into your Rust code... oh but how come Rust? Does the website front end (or backend?) run any Rust code or is it because you precompile the values in the table using Rust?
Yes, I use Rust to generate a WASM binary that runs on the browser.
then the seed was saved previously and is reused to repopulate the exact same array?
No, as far as my understanding goes the game does not save the seed.
And actually Ninji's have said somewhere that we should not rely on seeds. The number generator is probably shared between other systems that will call and get a number while turnip prices are generated. So it's useless to "predict" a seed.
from turnip-calculator.
then it would follow the "multiple line inaccuracy"... and so it should be 64 and not 63, because it goes through the loop and put the values into the array
I have some ideas to follow this inaccuracy. But, I will probably take some time as I need to refactor some things. π
I think Rust handles better and more predictably this inaccuracies. But something tells me that I should probably build a way to test and compare.
from turnip-calculator.
Out of curiousity, I just tried:
float testFloat = 0.85;
printf("Test %f, 0.85? %d\n", testFloat, testFloat == 0.85);
and it gave a false
. If I make it 0.9
, it is also false
. It gives a true
when it is 1.0
And I couldn't reproduce it in Ruby or Node (JS)... but then I think that's because that is 64 bit. JavaScript Number has the possible integer max of about 53 bits, so the float is more than 53 bits, and therefore it is not 32 bit but 64 bit.
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number
The JavaScript Number type is a double-precision 64-bit binary format IEEE 754 value, like double in Java or C#)
So then, if Ninji's code were a double
, then it would be similar behavior with Ruby or JS... but since it uses float
, so it is 32 bit behavior. I suppose why it is inaccurate to the 5th and 6th decimal place. It is because it is 32 bit but not 64 bit.
If the C++ code above uses double
instead of float
, then the boolean would return true
for 0.85
from turnip-calculator.
No, as far as my understanding goes the game does not save the seed.
And actually Ninji's have said somewhere that we should not rely on seeds. The number generator is probably shared between other systems that will call and get a number while turnip prices are generated. So it's useless to "predict" a seed.
Oh wait... if the game doesn't save the seed, the game should save the "turnip price table"... because let's say we quit the game, and wait 3 seconds, and restart the game, the same exact turnip prices are there. It is true also if we wait 1 minute and restart the game. So somehow the turnip price table values are saved. So if the seed is not saved, then then turnips prices are saved.
And then, if we adjust the Switch time back by even 1 minute, then all the turnip prices are "re-rolled" (and saved).
from turnip-calculator.
Yes, that's how it works. It saves the prices. That's how some people have more than 660. You would need to modify the save data instead of the game.
from turnip-calculator.
So then, if Ninji's code were a double, then it would be similar behavior with Ruby or JS... but since it uses float, so it is 32 bit behavior. I suppose why it is inaccurate to the 6th decimal place. It is because it is 32 bit but not 64 bit.
Yes, I tried to force 32bit numbers and 32bit operations on JavaScript but it's not trivial. 32bit operations only occurs when both numbers are stored as 32bit. (TypedArrays)z That's why I chose Rust because it's highly explicit on type coercion.
from turnip-calculator.
So then, if Ninji's code were a double, then it would be similar behavior with Ruby or JS... but since it uses float, so it is 32 bit behavior. I suppose why it is inaccurate to the 6th decimal place. It is because it is 32 bit but not 64 bit.
Yes, I tried to force 32bit numbers and 32bit operations on JavaScript but it's not trivial. 32bit operations only occurs when both numbers are stored as 32bit. (TypedArrays)z That's why I chose Rust because it's highly explicit on type coercion.
oh... what if we precompile the price bounds using C++, exactly the same as Ninji's code... and then just let JS uses those numbers. Once the numbers become integers, then it is much easier to deal with and compare with... this is assuming Ninji's code is an accurate version of what the code is in Switch... if the code in Switch uses double
and Ninji's code uses float
, then it would throw us off a bit.
from turnip-calculator.
Yes, I use Rust to generate a WASM binary that runs on the browser.
a side note... back in 2013, I was talking to my coworker: oh boy, the way we use JS... it seems so low level and people uses CanJS or Backbone or Ember... it is kind of like JS is Assembly and we build things with it.
And my coworker said: yes, some people describe JS as web assembly (or assembly of the web)
ah... but WASM is not the same as JS, is it... it outright makes it lower level than JS. Is it true that people relatively rarely uses WASM directly, but uses other language that would compile / transpile into WASM to run on the browser, like in your case you use Rust.
from turnip-calculator.
So then, if Ninji's code were a double, then it would be similar behavior with Ruby or JS... but since it uses float, so it is 32 bit behavior. I suppose why it is inaccurate to the 6th decimal place. It is because it is 32 bit but not 64 bit.
Yes, I tried to force 32bit numbers and 32bit operations on JavaScript but it's not trivial. 32bit operations only occurs when both numbers are stored as 32bit. (TypedArrays)z That's why I chose Rust because it's highly explicit on type coercion.
oh... what if we precompile the price bounds using C++, exactly the same as Ninji's code... and then just let JS uses those numbers. Once the numbers become integers, then it is much easier to deal with and compare with... this is assuming Ninji's code is an accurate version of what the code is in Switch... if the code in Switch uses
double
and Ninji's code usesfloat
, then it would throw us off a bit.
That would be nice if I just needed some precompiled values. I really try narrow some results by calculating the rate with the provided values and using that as reference for predictions.
Which I am thinking that will not be fixable I am afraid.
But besides this precision issue I found something else I am analyzing.
This scenario in particular is interesting. Something else is off with the calculation but I can't tell what or why is off.
Give me a couple of days.
from turnip-calculator.
That would be nice if I just needed some precompiled values. I really try narrow some results by calculating the rate with the provided values and using that as reference for predictions.
If assuming Ninji's code is a very faithful reproduction of AC:NH's code... and that AC:NH is also in C++ (or C)... then using C++ would be the most accurate values, I think. (the mod community probably knows quite a bit about these). If it is other languages to simulate the behavior, maybe there could be tiny things that is overlooked, although theoretically, if it is all 32 bit float, then they should work the same... it could be interesting to run a set of numbers by C++ and then another set by another language and see if they give the exact same results... but if we just use one language, it might be most faithful to use C++.
from turnip-calculator.
By the way, I am trying a "phase 2":
void tellTheRange(TurnipPrices turnips, int work, float a, float b) {
int priceLow = turnips.intceil(turnips.randfloatMockedMin(a, b) * 90);
int priceHigh = turnips.intceil(turnips.randfloatMockedMax(a, b) * 110);
printf("{ period: %3d, range: { low: %6d, high: %6d } }\n", work, priceLow, priceHigh);
}
int main(int argc, char **argv)
{
TurnipPrices turnips;
turnips.rng.init();
int work;
for (int peakStart = 3; peakStart <= 9; peakStart++) {
for (work = 2; work < peakStart; work++) { // 1 period minimum
// irrelevant
}
tellTheRange(turnips, work++, 0.9, 1.4);
tellTheRange(turnips, work++, 1.4, 2.0);
tellTheRange(turnips, work++, 2.0, 6.0);
tellTheRange(turnips, work++, 1.4, 2.0);
tellTheRange(turnips, work++, 0.9, 1.4);
printf("\n");
}
return 0;
}
from turnip-calculator.
and the output:
I am just trying the value generation faithfully, but it can be simplified into: it is almost the same set of data, but just with the starting index of period
shifting by a 1
increment each time:
$ ./a.out
{ period: 3, range: { low: 81, high: 154 } }
{ period: 4, range: { low: 126, high: 220 } }
{ period: 5, range: { low: 180, high: 660 } }
{ period: 6, range: { low: 126, high: 220 } }
{ period: 7, range: { low: 81, high: 154 } }
{ period: 4, range: { low: 81, high: 154 } }
{ period: 5, range: { low: 126, high: 220 } }
{ period: 6, range: { low: 180, high: 660 } }
{ period: 7, range: { low: 126, high: 220 } }
{ period: 8, range: { low: 81, high: 154 } }
{ period: 5, range: { low: 81, high: 154 } }
{ period: 6, range: { low: 126, high: 220 } }
{ period: 7, range: { low: 180, high: 660 } }
{ period: 8, range: { low: 126, high: 220 } }
{ period: 9, range: { low: 81, high: 154 } }
{ period: 6, range: { low: 81, high: 154 } }
{ period: 7, range: { low: 126, high: 220 } }
{ period: 8, range: { low: 180, high: 660 } }
{ period: 9, range: { low: 126, high: 220 } }
{ period: 10, range: { low: 81, high: 154 } }
{ period: 7, range: { low: 81, high: 154 } }
{ period: 8, range: { low: 126, high: 220 } }
{ period: 9, range: { low: 180, high: 660 } }
{ period: 10, range: { low: 126, high: 220 } }
{ period: 11, range: { low: 81, high: 154 } }
{ period: 8, range: { low: 81, high: 154 } }
{ period: 9, range: { low: 126, high: 220 } }
{ period: 10, range: { low: 180, high: 660 } }
{ period: 11, range: { low: 126, high: 220 } }
{ period: 12, range: { low: 81, high: 154 } }
{ period: 9, range: { low: 81, high: 154 } }
{ period: 10, range: { low: 126, high: 220 } }
{ period: 11, range: { low: 180, high: 660 } }
{ period: 12, range: { low: 126, high: 220 } }
{ period: 13, range: { low: 81, high: 154 } }
from turnip-calculator.
And this is the same format, for phase 1:
{ period: 2, range: { low: 77, high: 99 } }
{ period: 3, range: { low: 73, high: 96 } }
{ period: 4, range: { low: 68, high: 93 } }
{ period: 5, range: { low: 64, high: 90 } }
{ period: 6, range: { low: 59, high: 86 } }
{ period: 7, range: { low: 55, high: 83 } }
{ period: 8, range: { low: 50, high: 80 } }
from turnip-calculator.
And this is phase 3:
void tellTheRange(TurnipPrices turnips, int work, float a, float b) {
int priceLow = turnips.intceil(turnips.randfloatMockedMin(a, b) * 90);
int priceHigh = turnips.intceil(turnips.randfloatMockedMax(a, b) * 110);
printf("{ period: %3d, range: { low: %6d, high: %6d } }\n", work, priceLow, priceHigh);
}
int main(int argc, char **argv)
{
TurnipPrices turnips;
turnips.rng.init();
int work;
for (int peakStart = 3; peakStart <= 9; peakStart++) {
for (work = 2; work < peakStart + 5; work++) { // 1 period minimum
// irrelevant
}
for (; work < 14; work++) {
tellTheRange(turnips, work, 0.4, 0.9);
}
printf("\n");
}
return 0;
}
from turnip-calculator.
phase 3 output:
$ ./a.out
{ period: 8, range: { low: 36, high: 99 } }
{ period: 9, range: { low: 36, high: 99 } }
{ period: 10, range: { low: 36, high: 99 } }
{ period: 11, range: { low: 36, high: 99 } }
{ period: 12, range: { low: 36, high: 99 } }
{ period: 13, range: { low: 36, high: 99 } }
{ period: 9, range: { low: 36, high: 99 } }
{ period: 10, range: { low: 36, high: 99 } }
{ period: 11, range: { low: 36, high: 99 } }
{ period: 12, range: { low: 36, high: 99 } }
{ period: 13, range: { low: 36, high: 99 } }
{ period: 10, range: { low: 36, high: 99 } }
{ period: 11, range: { low: 36, high: 99 } }
{ period: 12, range: { low: 36, high: 99 } }
{ period: 13, range: { low: 36, high: 99 } }
{ period: 11, range: { low: 36, high: 99 } }
{ period: 12, range: { low: 36, high: 99 } }
{ period: 13, range: { low: 36, high: 99 } }
{ period: 12, range: { low: 36, high: 99 } }
{ period: 13, range: { low: 36, high: 99 } }
{ period: 13, range: { low: 36, high: 99 } }
from turnip-calculator.
and when I combine all of them. Maybe can cross check with you:
priceRanges = {
"highSpike": {
"2": [
{
"low": 77,
"high": 99
}
],
"3": [
{
"low": 73,
"high": 96
},
{
"low": 81,
"high": 154
}
],
"4": [
{
"low": 68,
"high": 93
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
}
],
"5": [
{
"low": 64,
"high": 90
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
},
{
"low": 180,
"high": 660
}
],
"6": [
{
"low": 59,
"high": 86
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
},
{
"low": 180,
"high": 660
}
],
"7": [
{
"low": 55,
"high": 83
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
},
{
"low": 180,
"high": 660
}
],
"8": [
{
"low": 36,
"high": 99
},
{
"low": 50,
"high": 80
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
},
{
"low": 180,
"high": 660
}
],
"9": [
{
"low": 36,
"high": 99
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
},
{
"low": 180,
"high": 660
}
],
"10": [
{
"low": 36,
"high": 99
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
},
{
"low": 180,
"high": 660
}
],
"11": [
{
"low": 36,
"high": 99
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
},
{
"low": 180,
"high": 660
}
],
"12": [
{
"low": 36,
"high": 99
},
{
"low": 81,
"high": 154
},
{
"low": 126,
"high": 220
}
],
"13": [
{
"low": 36,
"high": 99
},
{
"low": 81,
"high": 154
}
]
}
}
from turnip-calculator.
But one more thinking is: maybe it is not good to combine the ranges like this. True: these are still all the ranges when high spike happens and I can check against them, but a better approach is to check what if peakStart
is 3
, then what are the possible ranges, and then what if peakStart
is 4
, then what are the possible ranges, etc, all the way up to 9
. This way, it is a better check as it follows what actually happens when the game runs.
from turnip-calculator.
Imagine you know that on Monday AM you have a buy price of 78.
And we want to check if we can have 63 on a High Spike Pattern.
We do not know the base price.
And 78 may be the ceiling of ~77.001
We know that every given price is rate * basePrice
.
So, we know the base prices and we know that the buy price is 78.
rate = 78 / basePrice
If basePrice is 90, then rate is ~.866
If basePrice is 110, then rate is ~.709
But, we know that rate can't be lower than ~.85 or higher than ~.9
If basePrice is 91, then rate is ~.857
If basePrice is 92, then rate is ~.847
So, we now know that 90 and 91 base prices are possible.
But, what will happen on next days.
For Min Price Mon PM
~.866 - 0.05 = ~.816
~.857 - 0.05 = ~.807
For Min Price Tue AM
~.816 - 0.05 = ~.766
~.807 - 0.05 = ~.757
For Min Price Tue PM
~.766 - 0.05 = ~.716
~.757 - 0.05 = ~.707
Then, to know the minim price we could get on Tue PM. We use our basePrices.
~.716 * 90 = ~64.4
~.707 * 90 = ~63.6
~.716 * 91 = ~65.0
~.707 * 91 = ~64.3
Then we know that 63 for Tue PM is not really possible using 78.
But we said that 78 may be ~77.001
Let's try
rate = 77 / basePrice
If basePrice is 90 then rate is ~.855
If basePrice is 91 then rate is ~.846
91 is below our known range of ~.85 to ~.9
Then on Tue PM
~.855 - ~.15 = ~.705
~.705 * 90 = ~63.45
It's not possible to have 63 as price for Tue PM given that Mon AM is 78.
from turnip-calculator.
So you are saying if Tue PM is 63, Mon AM cannot be 78. Let me take some time and double check.
However, in any event, I think if the form is all cleared, and then we enter Tue PM as 63, it should show 660 is not possible.
from turnip-calculator.
It's not possible to have 63 as price for Tue PM given that Mon AM is 78.
wait a second... are you saying those numbers are not possible for the high spike pattern? But it is not the high spike pattern. It is some other pattern. In fact, when given those numbers, it should say it is not a high spike pattern.
from turnip-calculator.
It's not possible to have 63 as price for Tue PM given that Mon AM is 78.
wait a second... are you saying those numbers are not possible for the high spike pattern? But it is not the high spike pattern. It is some other pattern. In fact, when given those numbers, it should say it is not a high spike pattern.
Yes, they are not possible for high spike. I didn't analyze for other patterns.
from turnip-calculator.
So you are saying if Tue PM is 63, Mon AM cannot be 78. Let me take some time and double check.
However, in any event, I think if the form is all cleared, and then we enter Tue PM as 63, it should show 660 is not possible.
No, what I am saying is that if Mon AM is 78 then Tue PM is not possible to have 63 in a high spike pattern.
This doesn't mean that Mon AM or Tue PM can't be 78 or 63 with other combinations. But that specific combination is not possible for high spike pattern.
from turnip-calculator.
No, what I am saying is that if Mon AM is 78 then Tue PM is not possible to have 63 in a high spike pattern.
This doesn't mean that Mon AM or Tue PM can't be 78 or 63 with other combinations. But that specific combination is not possible for high spike pattern.
So what I am saying is:
If it is Mon AM 78 and then Tue PM 63, THEN THE WEBSITE SHOULD NOT SHOW POSSIBLE 660 IN THE FUTURE. THAT'S IT.
IN FACT, EVEN IF IT IS SIMPLY Tue PM 63, THEN THE WEBSITE SHOULD NOT SHOW POSSIBLE 660 IN THE FUTURE.
from turnip-calculator.
No, what I am saying is that if Mon AM is 78 then Tue PM is not possible to have 63 in a high spike pattern.
This doesn't mean that Mon AM or Tue PM can't be 78 or 63 with other combinations. But that specific combination is not possible for high spike pattern.
So what I am saying is:
If it is Mon AM 78 and then Tue PM 63, THEN THE WEBSITE SHOULD NOT SHOW POSSIBLE 660 IN THE FUTURE. THAT'S IT.
IN FACT, EVEN IF IT IS SIMPLY Tue PM 63, THEN THE WEBSITE SHOULD NOT SHOW POSSIBLE 660 IN THE FUTURE.
Right, I forgot about 63, simply because .7 * 90 is 63. I keep insisting that 63 is a good answer.
But yeah. Two different bugs.
I'll keep you posted if I got to solve any of those.
from turnip-calculator.
from turnip-calculator.
It should be live in 2.2.0-build.2
from turnip-calculator.
are you using a universal range 90 to 110, or are you using 90, and one mapping, and 91, and another mapping, and so forth? I have a program that uses 90 to 110 mapping but I am thinking of converting it to individual mapping to make it more accurate (probably tighten the "belt" (or the "range") a little bit more).
from turnip-calculator.
I thought I fixed that, but I think I overcomplicated things and also didn't work. I just pushed some changes today and I think they look promising and made the code simpler. (15164c5). I pushed them to 2.2.1-build.1
In these changes, I do calculations with every base price step. Resulting in a much larger pattern chart but in a better prediction.
from turnip-calculator.
Related Issues (20)
- [QUESTION] HOT 1
- Doesn't predict when turnip buy price is above 100 HOT 1
- The price is bugged
- Guardar los datos de los nabos semanales del usuario HOT 1
- [BUG] Prediction wrong multiple times throughout the week.
- [BUG] HOT 2
- [FEATURE] Translation error in zh-CN HOT 1
- [BUG] Forecast eliminates High Spike incorrectly HOT 1
- [BUG] Prices above maximum predicted price HOT 3
- [BUG] buttons aren't padded
- [BUG] Crashes if you input specific numbers into "Buy Price" HOT 1
- [FEATURE] Previous pattern support
- [BUG] Monday morning 82, Tue afternoon 186 or 219, then Small Spike is gone?
- [BUG] Spanish version of the site contains english wording HOT 1
- [FEATURE] Last week's pattern
- [BUG] NO TRANSLATION I CAN TRANSLATE HOT 1
- Fluctuating pattern isn't accurate at all
- [FEATURE]
- [νΉμ§] new shape
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from turnip-calculator.