Skip to content

Signed/Unsigned Inner Types #7

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

Closed
PTaylor-us opened this issue May 16, 2020 · 3 comments · Fixed by #22 or #28
Closed

Signed/Unsigned Inner Types #7

PTaylor-us opened this issue May 16, 2020 · 3 comments · Fixed by #22 or #28
Labels
discussion Something that needs more discussion

Comments

@PTaylor-us
Copy link
Member

PTaylor-us commented May 16, 2020

I began this journey after finding that the core::Duration was an unsigned value. I then investigated the time crate and found that while it does have signed Duration, it is focused more toward "wall-clock" time considerations. This led me to great this project.

I began my development with the use-case of a non-wrapping timer (typically chaining two 32-bit peripheral timers in a microcontroller). However, if this project is to be compatible with wrapping timers, that may fundamentally change its design.

Signed durations can be useful when calculating the difference between two instances. It allows the subtraction to be done in either order returning a logical result. For example, in the expression x - y, if x is earlier than y, a negative duration is returned. However, if wrapping timers are to be supported, a negative duration will never be returned as subtracting a "higher-value" instance from a "lower-value" assumes the timer wrapped, and a positive duration is returned.

@PTaylor-us
Copy link
Member Author

However, if wrapping timers are to be supported, a negative duration will never be returned as subtracting a "higher-value" instance from a "lower-value" assumes the timer wrapped, and a positive duration is returned.

This is inaccurate. In fact, a signed result of the wrapping arithmetic is important. Otherwise, Instances cannot be ordered.

@PTaylor-us
Copy link
Member Author

If it is absolutely necessary for the difference between two Instants to result in a signed Duration (which I believe it is), could other types still utilize unsigned inner types? At the lowest level, the hardware timers are virtually always treated as unsigned values. What gets messy is when support for that timer overflowing from the max value back around to 0. By using a signed wrapping_sub of the two Instant's inner values, we are able to account for that overflow (as long as the the actual difference between them is less than i32::MAX ticks).

Perhaps the inner types could be unsigned and only be cast to signed in the case of getting the difference of Instants. That would make Clock and Instant inner types unsigned, but Durations would still be signed.

@PTaylor-us PTaylor-us added the discussion Something that needs more discussion label Jun 22, 2020
@PTaylor-us PTaylor-us changed the title Signed/Unsigned Durations Signed/Unsigned Inner Types Jun 25, 2020
@PTaylor-us PTaylor-us reopened this Jul 1, 2020
@PTaylor-us PTaylor-us mentioned this issue Jul 1, 2020
@devjgm
Copy link

devjgm commented Aug 1, 2023

Why did you change from signed to unsigned in #22? It sounded like in this issue you were saying that signed durations are good. I would strongly agree that Durations should be signed. Algebraically, durations can be negative, so it's surprising that (by default) I can't create a duration that represents "1 minute ago". I.e., I can subtract a Duration from an Instant, but I can't add a negative Duration: I - D is OK, but I + -D is not?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Something that needs more discussion
Projects
None yet
2 participants