[BUG] Future price wrong? about turnip-calculator

[nonopolarity]

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.

[nonopolarity]

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

[nonopolarity]

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.

[elxris]

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

[nonopolarity]

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 @______________

[elxris]

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

[KennethKinLum]

@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.

[elxris]

You're right, I see the same scenario.
Give me some time to check this.

[nonopolarity]

@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;
}

[nonopolarity]

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.

[nonopolarity]

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.

[elxris]

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.

[elxris]

I have tried several things on rust, so far I hate the results because there is no easy fix for this.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c08c6b37e85f036e377962ea9ea252a5

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.

[nonopolarity]

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.

[elxris]

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.

[elxris]

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.

[nonopolarity]

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

[nonopolarity]

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).

[elxris]

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.

[elxris]

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.

[nonopolarity]

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.

[nonopolarity]

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.

[elxris]

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.

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.

[nonopolarity]

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++.

[nonopolarity]

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;
}

[nonopolarity]

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 } }

[nonopolarity]

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 } }

[nonopolarity]

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;
}

[nonopolarity]

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 } }

[nonopolarity]

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
      }
    ]
  }
}

[nonopolarity]

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.

[elxris]

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.

[nonopolarity]

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.

[nonopolarity]

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.

[elxris]

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.

[elxris]

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.

[nonopolarity]

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.

[elxris]

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.

[elxris]

Fixed!

[elxris]

It should be live in 2.2.0-build.2

[nonopolarity]

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).

[elxris]

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.