Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for floating point output #16

Open
saranvdev opened this issue Jun 28, 2018 · 7 comments
Open

Support for floating point output #16

saranvdev opened this issue Jun 28, 2018 · 7 comments

Comments

@saranvdev
Copy link

What do you think?
things like roll(1d2/3)
would return 0.3(3) or 0.6(6)

@calebj
Copy link
Collaborator

calebj commented Jun 30, 2018

I don't think I want to support this, since dice and decimal numbers don't mix in my experience. @borntyping thoughts?

Floating point numbers can also be hairy to work with. Can you point to any systems or games that could make use of this feature?

@borntyping
Copy link
Owner

I'm not sure what you'd be able to use it for. If we did add it, maybe we could do it as a Python-2 style "true division" operator using // as the symbol. It might break other things though, as IIRC a lot of the other operators expect an integer.

@saranvdev
Copy link
Author

I wanted it for things like calculating damage done, including fire resistance for example. 75dmg/0.10% = 7.5 blocked damage. I need to cover all possible cases of rolls, because I don't know what players will use.

It's just an idea, though

@saranvdev
Copy link
Author

If we did add it, maybe we could do it as a Python-2 style "true division" operator using // as the symbol.

Or what about optional argument? roll("1d10/20", float=True), something like this, I don't know how many changes are needed to support such feature.

@posita
Copy link

posita commented Aug 17, 2021

dyce will do this. It's pretty flexible on what it accommodates as outcome (face) types:

>>> from dyce import H
>>> 1@H(2) / 3
H({0.3333333333333333: 1, 0.6666666666666666: 1})
>>> _.roll()
0.3333333333333333

>>> from fractions import Fraction
>>> 1@H(2) / Fraction(3)
H({Fraction(1, 3): 1, Fraction(2, 3): 1})
>>> _.roll()
Fraction(2, 3)

You'd have to settle on a grammar, but you might be able to lean on it under the covers if you can identify something you like.

I'm happy to consult on this, if there's interest.

@borntyping
Copy link
Owner

borntyping commented Aug 17, 2021

dyce looks really neat. If I ever rewrite this library (I've not really touched it in a long time) it'd make doing a lot of the analysis I originally wanted to be able to do with it possible. Has anyone else done built a dice parser/grammer on top of dyce yet?

(side note: you've cited me as Clemens et al. in the docs - that should be Clements et al. if that's something easy to fix 😅)

@posita
Copy link

posita commented Aug 17, 2021

Oh dear! 🤦 How embarrassing…. I'll have a fix for that soon. Should be fixed. Thanks for bringing this to my attention! 😊

To get to the meat of your question: The only person who has tried so far is me, and so far in private. That has been helpful, but eating one's own dog food only takes one so far. The real test is whether it's helpful to others.

My original goal was to support finite discrete distributions to assist with dice mechanic design (much like what AnyDice does). But then I realized that there were some limitations that don't suit all cases. For example, consider when someone wants to roll sixteen d20s and take the best five. If the approach is to enumerate all outcome probabilities and then pick from those, it probably isn't getting done anytime soon. (Computationally, it's just too expensive.) That got me thinking about cases where a particular roll was important, not the entire distribution. That meant deferring the math until roll time. That, and I noticed that avrae/d20 has a capability not only to generate rolls, but dissect their constructions, which is also neat.

So (at least as of this writing) dyce now has three goals:

  1. Assist with mechanics design through distribution enumeration
  2. Generate weighted random rolls that aren't bound by distribution computation for use at game time
  3. Support transparency of computation for roll generation (for auditing, education, etc.)

I think the first is pretty well baked. (Time will tell.) The second two that are pretty new efforts. The hope is that one could build specialized grammars that leveraged dyce in any of those contexts, depending on what one was trying to accomplish.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants