You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's clear to me now that making the end offset of each Domain exclusive was a mistake. It leads to situations that are hard to reason about, for instance to draw a strand backwards you have to think about jumping to offsets that are one greater than the one you really want, e.g.,
Note the awkwardness that the two offsets specified, 16 and 11, are not part of the strand at all. These seems less strange when specifying domains by creating explicit Domain objects, but here it's strange that calling draw_strand or cross with an offset, you don't know whether that offset will actually be part of the strand or not, until the next call to move or to that indicates whether the domain will be forward or reverse.
Add a field to Design called end_offsets_inclusive, with default value False, that controls this. If set to True then end offsets will be inclusive.
Some unit tests will need to be added to ensure the new interpretation works.
We can slowly deprecate first by changing the default value to True so that, after we make that change, users will need to explicitly specify a value of False in the Design constructor to make the old behavior appear. If it seems necessary we can eventually remove the field altogether and solely use inclusive offsets.
The text was updated successfully, but these errors were encountered:
It's clear to me now that making the
end
offset of eachDomain
exclusive was a mistake. It leads to situations that are hard to reason about, for instance to draw a strand backwards you have to think about jumping to offsets that are one greater than the one you really want, e.g.,Creates this design:
Note the awkwardness that the two offsets specified, 16 and 11, are not part of the strand at all. These seems less strange when specifying domains by creating explicit
Domain
objects, but here it's strange that callingdraw_strand
orcross
with an offset, you don't know whether that offset will actually be part of the strand or not, until the next call tomove
orto
that indicates whether the domain will be forward or reverse.Add a field to
Design
calledend_offsets_inclusive
, with default valueFalse
, that controls this. If set toTrue
then end offsets will be inclusive.Some unit tests will need to be added to ensure the new interpretation works.
We can slowly deprecate first by changing the default value to
True
so that, after we make that change, users will need to explicitly specify a value ofFalse
in theDesign
constructor to make the old behavior appear. If it seems necessary we can eventually remove the field altogether and solely use inclusive offsets.The text was updated successfully, but these errors were encountered: