BitD Example

[synthality]

https://anydice.com/articles/blades-in-the-dark/

I'm guessing this is pretty trivial to produce in dyce, but I can't easily figure out how to do it. Any help would be appreciated!

[posita]

Thanks for the question, @synthality!

There are a ton of ways to skin that proverbial cat, some more esoteric and complicated than others. Some of those might be fun puzzles, or useful exercises for optimizing performance in environments calling for dozens (or hundreds!) of dice. But I have found it's best to start simple and obvious and move from there.

To that end, I think dyce's version can be pretty close (at least in spirit) to AnyDice's. Some major differences to accommodate in the translation are:

1. Generally, dyce tries not to rely on magic (e.g., implied conversions of data types). It requires users to select the appropriate primitive and use an appropriate interface. Translation between primitives tends to require callers to be explicit about that. (A roll, for example, is not substitutable for a pool or a histogram.) This comes at the cost of requiring familiarity with the primitives and interfaces and at a cost of code compactness, but the end result is that you shouldn't have to guess too much about what's going on. At least that's the intention. We'll see how close it gets.
2. AnyDice sequences start at index 1, whereas Python's start at 0. (Python also supports negative indexes that are interpreted from the opposite end of the sequence.)
3. AnyDice sequences are ordered greatest-to-least, whereas dyce's are ordered least-to-greatest (which feels more "Pythonic").
4. The closest translation of AnyDice's m@nd6 (take the mth largest value among a pool of n d6s) is dyce's d6 = H(6) ; (n@P(d6)).h(-m), which is harder to read and more verbose. (This is where AnyDice's dedicated grammar wins on readability.)
5. The closest translation of AnyDice's [func nd6] is dyce's P.foreach(func, param_name=n@P(H(6))), which is also more verbose.

With that out of the way, here's a translation about as close in spirit and form to original source as I can muster:

from dyce import H, P

d6 = H(6)

def blades(roll):
    if roll[-1] == 6:
        return 2 + (len(roll) > 1 and roll[-2] == 6)
    return int(roll[-1] >= 4)

results = {
    n: P.foreach(blades, roll=P((2@P(d6)).h(0)) if n == 0 else n@P(d6))
    for n in range(0, 8)
}

I don't find that particularly helpful as a learning tool, however, because there's a lot of ball-hiding there. To that end, I've created a much more thorough exploration of iterations on that approach that try to leverage dyce and Python to make it more accessible. You can find it here:

I hope that helps, but I also know that designing ergonomic interfaces is hard. If you are willing, I'm curious to hear your take on what might have made a dyce-based solution more approachable to you. Any insight you can give is greatly appreciated. If that's "none", then you'll get no judgment from me. 😊 I'm very happy for the engagement and the opportunity to explore the topic in more detail. The mere asking of the question helps oodles, so thank you for that!

[posita]

A couple different warts (I'm reluctant to call them "bugs" just yet) that crop up in the burst graphs generated in that exploration (reproduced below):

First, the color of the burst graphs changes between those with only three results (0d6 and 1d6) and those with four. That's potentially jarring, but I don't immediately know how I might cure that via a general approach.

Second, the 0d6 example is without labels from the IntEnums. This is a result of the histogram generated from the P(…).h(…) expression. More specifically, this is an artifact of suming outcomes in that function's implementation. I can imagine more sophisticated approaches that would cure that defect, but I'm not sure they're necessarily helpful in this context.

[posita]

FYI, I'm currently working on what I hope to be a slightly more flexible/ergonomic solution than P.foreach. It will likely converge on something like this:

from enum import IntEnum
from dyce import H, P
from dyce.expandable import HResult, PResult, expandable

class BitdResult(IntEnum):
    BAD_TIMES = 0
    MESSY_SUCCESS = 1
    CLEAN_SUCCESS = 2
    CRITICAL_SUCCESS = 3

d6bitd = H((
    BitdResult.BAD_TIMES,      # 1
    BitdResult.BAD_TIMES,      # 2
    BitdResult.BAD_TIMES,      # 3
    BitdResult.MESSY_SUCCESS,  # 4
    BitdResult.MESSY_SUCCESS,  # 5
    BitdResult.CLEAN_SUCCESS,  # 6
))

@expandable
def blades(result: HResult | PResult):
    if isinstance(result, PResult):  # from n@P(6) where n > 0
        best = result.roll[-1]
        next_best = result.roll[-2] if len(result.roll) > 1 else 0
    elif isinstance(result, HResult):  # from least_of_2d6bitd where n is 0
        best = result.outcome
        next_best = 0
    else:
        assert False, "unrecognized result type {result!r}"
    if best == BitdResult.CLEAN_SUCCESS == next_best:
        return BitdResult.CRITICAL_SUCCESS
    else:
        return BitdResult(best)

pool_2d6bitd: P = 2@P(d6bitd)
least_of_2d6bitd: H = pool_2d6bitd.h(0)

results = {
    n: blades(result=least_of_2d6bitd if n == 0 else n@P(d6bitd))
    for n in range(0, 8)
}

[posita]

It's been awhile since I offered anything here, and while the above approaches still work, I wanted to revisit in light of introducing the dyce.evalution package. Here's an updated version that also makes use of pool selection to remain performant for large pools (e.g., 30). Here's the meat:

from dyce import H, P
from dyce.evaluation import PResult, PWithSelection, foreach
from enum import IntEnum, auto

class BitdResult(IntEnum):
    BAD_TIMES = auto()
    MESSY_SUCCESS = auto()
    CLEAN_SUCCESS = auto()
    CRITICAL_SUCCESS = auto()

d_bitd = H((
    BitdResult.BAD_TIMES,  # 1
    BitdResult.BAD_TIMES,  # 2
    BitdResult.BAD_TIMES,  # 3
    BitdResult.MESSY_SUCCESS,  # 4
    BitdResult.MESSY_SUCCESS,  # 5
    BitdResult.CLEAN_SUCCESS,  # 6
))

def bitd(n: int) -> H:
    assert n >= 0

    def _mechanic(res: PResult):
        assert len(res.roll) >= 2
        if res.roll[-2] == BitdResult.CLEAN_SUCCESS:
            # Because rolls are ordered least-to-greatest, if the penultimate
            # value is a clean success (i.e., a six), then the ultimate value
            # must be one as well; in other words, we have at least two clean
            # successes (sixes) and therefore a critical success
            return BitdResult.CRITICAL_SUCCESS
        else:
            # Return the highest value, whatever it may be
            return BitdResult(res.roll[-1])

    if n == 0:
        # Take lower of two dice (no critical success possible)
        return (2 @ P(d_bitd)).h(0)
    elif n == 1:
        # Just return a single die (also no critical success possible)
        return d_bitd
    else:
        # We're rolling a pool of dice, so engage our mechanic
        return foreach(_mechanic, PWithSelection(n @ P(d_bitd), (slice(-2, None),)))

On my machine:

In [1]: %timeit bitd(30)  # works for huge pools
136 µs ± 1.45 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

This makes generating outcomes for zero through eight dice pretty easy (the eighth being where a critical success is more likely than any other outcome):

Interactive version: 👉👉👉 👈👈👈

As an aside, I was also able to address the visual shortcomings via substantial changes to anydyce, including the (as-of-yet poorly documented) initial_burst_zero_fill_normalize argument to jupyter_visualize, which allows for consistent coloring across burst graphs, even if a particular burst graph is missing an outcome.

[posita]

@synthality, please feel free to let me know if anything is unclear, deserves more detail, or if you have any questions!