looks like the correct average was 0.3645699493261204

I explain my reasoning in this comment https://manifold.markets/chrisjbillington/will-someone-explain-to-me-why-this#XI6HBgvCRn0TSU6ODCT1

Will resolve NO unless someone points out a mistake in the next few hours

I thought I posted a link to this already, but if anyone figures out the reason the manifold API and the data scraped from the browser console are different, you can make some mana here:

With my script, the final average is 36.551%, making it closer to 37. The script can be found at https://gist.github.com/gbear605/0784d2f8b6712d1603b38621aa50771d - if anyone wants to run it, you just need an installation of Python 3 (I used Python 3.10.10) with the requests library installed.

I believe this properly accounts for limit orders, since when a limit order isn't immediately filled, the probAfter is the same as the probBefore, and the the averaging is done by total time.

Disclaimer: I don't hold a position in this market and I don't care which way it resolves, just want to provide full information.

@Gabrielle That's very nearly the same as mine, which gives 36.553:

https://gist.github.com/chrisjbillington/cc4e74659f1f65c7cdf09676e61ee330

I think your rounding is wrong, you're rounding to 3 and 2 decimal places when you should be rounding to 1 and 0 decimal places.

@Gabrielle thanks this was the issue raised by Chris yesterday and which they’ve been working through the night, I assume. That script, like Chris’s, must be overcounting or somehow giving positive time-weight to dupes or other non-price-moving transactions, since it differs from the average obtained by crunching the chart data (which is in fact what’s required by the resolution criteria) and which also matches what others arrive at. All can see it in real time in their own browser inspector’s network data.

@chrisjbillington The raw probabilities are from 0 to 1, and you're multiplying by 100 before rounding while I'm rounding the raw probabilities. So I'd take 0.0018533676872128058 and round it to 0.002, while you would multiple by 100, get 0.1853367687, and then round it to 0.2.

@Gabrielle Apologies, that's absolutely correct. I wonder why the small discrepancy then.

@chrisjbillington I suspect with this number of floating point calculations, very slight differences in how numpy versus normal Python handles them (32 bit float? 64 bit float?) could cause enough of a difference to explain two hundred thousandths of the result.

@Gabrielle My intuition is that floating point rounding error (everything should be 64 bit floats) would be about six or seven orders of magnitude smaller than that, but perhaps I am wrong. The logic of our scripts looks identical.

Actually, back to your rounding function, given you're not multiplying the probabilities by 100 to convert to percentages, the if statement should be "if percentage < .02 or percentage > 0.98", whereas in your code it's 2 and 98. (and calling it a percentage is a misnomer). That's probably it.

@Gabrielle btw just wanna say, loved your code, the script is easily readable for an amateur layman like me, and I’m pretty sure there’s no issues in its logic, instead the problem likely lies with the data.

@chrisjbillington ah right I concur, this line:

within_two_of_edges = (p < 2) | (p > 98)

should be .02 and .98

@chrisjbillington 🤦‍♀ Yes, the if statement is wrong. After correcting it, my final average is 36.553%, which matches with yours. So at this point the only confusion is why the calculations done from the browser console data differ from the calculations done against the API data.

@deagol woops I quoted your script lol… here’s @Gabrielle

if percentage < 2 or percentage > 98:

Resolves NO as 36 isn’t prime.

https://manifold.markets/Conflux/will-the-average-probability-of-thi#rnnMGsrgLF4VrEIaiMim

@deagol This is probably fair enough, as resolution was about what was displayed in the browser, so using the data obtained from the browser console makes sense. It is odd that it doesn't agree with the data from the API though.

@chrisjbillington https://manifold.markets/Conflux/will-the-average-probability-of-thi#BfeLJM7BJDNQu9KV1BFn

If a script averages by collecting every single transaction including a whole bunch of duplicated probAfter data, where the duplicates (limit fills) are probably biased toward the buy YES side, it’s obvious to me it’ll simply give the wrong answer, and probably with an upward bias.

@deagol The average is a time-weighted average, so duplicates with the same timestamp have zero weight in the average, that should make no difference.

I assume @AlexbGoode was doing a time-weighted average as well, this is what I understood "average percent shown by the page" to mean. If he is not, then I would argue the calculation is incorrect. I'll grab the data from chrome and reproduce using my other script.

@chrisjbillington of course we all know it’s a time-weighted average, and I can confirm his spreadsheet does that. That’s not the issue.

Aren’t the time-weights computed as the delta with the immediately previous timestamp? If you have several duplicates, wouldn’t they all get the same non-zero weight?

@deagol No, the dupes will have zero weight because the difference in two adjacent timestamps in the array of timestamps will be zero. I can see @AlexbGoode is doing this correctly.

@chrisjbillington ok, I guess it’d be best if someone from manifold can explain the difference. I’m sure it’s something very basic, but we all speculating in the blind here isn’t too helpful. Thanks again for all the work.

I am noticing something odd.

@AlexbGoode 's data, from a few hours ago, is a json file I don't know how to get a fresh copy of (I saved it at the time, it's too big for pastebin else I'd share), and it contains data about the probability graph as displayed on the page. It has 8487 datapoints.

But when I download bet data myself using manifoldpy, I get 12419 bets, and only a few are in the last couple of hours since @AlexbGoode's data, so that's definitely not enough to explain a discrepancy of about 4k points.

In the bet data, there are 1961 bets that have the same timestamp at millisecond precision. These look like when someone buys the opposite kind of contract to what they currently hold and a sale is done at the same time, or something like that (they are always paired one YES and one NO - I don't quite get it). But these ~2k duplicates are also not enough to explain a discrepancy of ~4k points. And they have the same probAfter value, so the potential arbitrariness of their ordering should not affect the calculated average probability.

But I get substantially different averages using the two methods.

With @AlexbGoode's data, I get the average to now (assuming 1.0% since the data was generated) is 37.259, and the average from now would have to be 2.4% for the all-time average to round to 37.

But with manifoldpy, I get the average to now is 37.336, and that it is impossible at this point for the average to round to 36.

Here's my script using manifoldpy:

https://gist.github.com/chrisjbillington/d1f5d975e53a74c7dbc174ca12e0c1cc

It prints:

avg as at 2023-04-02 22:58:30.664021 UTC: 37.323

result if 0% from now: 36.53977

result if 0.5% from now: 36.55026

result if 1.0% from now: 36.56075

result if 1.5% from now: 36.57124

result if 1.96% from now: 36.58089

result if 2.0% from now: 36.58173

-1.8955269489588682

The last figure being what the average would have to be below from now until close in order to round to 36% (thus saying it's impossible).

I've sold out of this market just because of the uncertainty of this! if I can't reproduce it and the result seems to depend on stuff I don't understand, so I best not be betting.

@chrisjbillington looks like maybe you are being confused by limit order fills ? you can just discard and ignore those, as only bets that are not limit orders can change the percentage

@chrisjbillington Thanks, it’s ok I’ll stay put. There must be duplicates in the other dataset since the market page itself reports 8.5k trades which includes limit orders. Those paired trades are just as you said, when you buy the other side, you cancel each share you bought with one (opposite) share you held, and get 1 mana back. Then there’s the limits. I think @AlexbGoode data excludes all that duplication. Anyway, wish me luck! :)

@chrisjbillington According to my script, the current average is 37.16%. I'm unsure what that means for this market, just thought it might be useful.

(If anyone would like to see the script, message me on Discord.)

@Gabrielle Thanks.

@Odoacre I can't quite make sense of which bets are limit order fills and which aren't, but it looks like the `probAfter` field is supposed to represent the actual market probability after the bet took place, and doesn't look like it is used for the limit probability of a limit order. `probAfter` is always identical for bets with identical timestamps, so my calculation should be unaffected by these duplicates.

I don't have anything at stake anymore, but it would be interesting if someone could specifically point to what is wrong with the calculation implied by my script, to reassure that it is in fact wrong and not the other scripts (the difference appearing to be in the data, rather than the logic).

I might make a market on whether someone will find the flaw lol