No Slotting Arithmetic #126
Conversation
The rational is that, doing slotting arithmetic forces us to keep track of the 'slotsPerEpoch' which is in practice, rather tricky. We can _probably_ get away by leveraging the _chained_ aspect of the blockchain (that each block points to its previous one) and rewind the chain when needed.
| <$> choose (0 :: Int, 4 * (fromIntegral slotsPerEpoch)) | ||
| arbitrary = do | ||
| ep <- choose (0, 10) | ||
| sl <- choose (0, 100) |
There was a problem hiding this comment.
why not sl <- choose (0, 21600)?
Also is it possible to have slot 0? or epoch 0?
It is because it's just an Id I suppose?
There was a problem hiding this comment.
hm, is it even needed? I mean the whole generator for SlotId? The Slotting ordering test suite ^ is using only some explicit values for SlotId...
There was a problem hiding this comment.
Not only, there's a first property that compare arbitrary slots against the initial SlotId 0 0 (making sure they're all greater than it).
Why not 21600 ? Well, to really show that it doesn't matter here and is completely irrelevant for the testing of this module. The only thing we really test is that we compare slot correctly. There's no other assumption about SlotId (and that's what we try to preserve in the code as well).
|
Merged into #128 to serialize PR / CI builds |
Issue Number
#94
Overview
Ordautomatically, it just happened that we defined the epoch index before the slot number in the record declaration. Swapping those two would have dramatic effects ^^")Comments
As a side-effect, we don't have to test for any of the boundary cases because there are none 🎉