Will Manifold reverse their decision to forbid floating point limits in the API?
9
3
100
resolved Aug 29
Resolved
NO

Resolves to NO at close unless either:

  1. A Manifold employee says that they are going to reverse the decision, or

  2. I can place a floating point limit at resolution time

(Honestly, I wish we could just use floating point limits in the GUI as well, but that's a different question)

Get Ṁ200 play money

🏅 Top traders

#NameTotal profit
1Ṁ40
2Ṁ17
3Ṁ8
4Ṁ3
5Ṁ3
Sort by:

Apologies for the delay, I just checked it on the API

bought Ṁ40 of NO

How does this resolve if you can only bet decimal point probabilities at a range in which they're semi relevant (say, below 5% or above 95%)?

@MattP In that case I will resolve to the size of range of probabilities where this is possible. So in your example I would resolve to 10%

What's the use case for <1% precision? I think using the same precision for display and math is probably for the best.

@wasabipesto also regarding #2 if you can make a bet at e.g. 42.7 but it's rounded to 43, does that count as reverted?

@wasabipesto No, it would not

@wasabipesto The main use case is that it makes limit orders slightly more predictable in execution order. Right now if there are 5 orders at 3%, it's difficult-to-impossible to tell which will execute first. If you could put your order at 3.1%, then you would essentially be paying a slight penalty to execute your order earlier.

Another way to resolve the core issue, for me, would be some text which explains the order. For example: "Limits are executed in a round robin fashion, when they are the same value" or "Limits are executed first-come-first-serve when at the same value, and we make sure they show up in execution order on the order book"

@LivInTheLookingGlass They should be executing oldest first if limit orders have the same limit probability.

I can double check what order is used in the displayed order book pop up.

@JamesGrugett Ok, I changed the ordering to consistently put limit bets created earlier first (if they have the same limit prob).

predicted NO

@LivInTheLookingGlass see to me, the main use case is "I'll have to pay a lot more attention to all of my limit orders because people will constantly be undercutting me by 0.1%". Limiting it to integers means that kind of treadmilling will converge a lot faster.

Also, anyone who says they have an actual belief about the probability of any of these events that goes down to the decimal level (again, excepting probabilities close to 0% and 100%) is lying. Humans simply don't think in that many sig figs.

This seems like a great resolution to the problem behind the problem. I am going to still argue that we should have 2 sigfigs all the way through, but I am happy with this outcome either way

More related questions