Skip to content

Conversation

@xwu
Copy link
Collaborator

@xwu xwu commented Dec 20, 2017

This PR makes various and sundry changes to clean up and/or fix the implementation of DoubleWidth. Most prominently:

@xwu
Copy link
Collaborator Author

xwu commented Dec 20, 2017

/cc @natecook1000 I made some additional changes to DoubleWidth. There will need to be some tests added before merging, but see how you feel about where this is going.

Also, it'd be nice to see if it passes existing tests (I'm traveling and can't run them on a machine of my own right now).

@natecook1000
Copy link
Member

@swift-ci Please smoke test

@xwu
Copy link
Collaborator Author

xwu commented Dec 23, 2017

Hmm, I will need to look into the failure. Will revise soon.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a possibility of lowInT being negative here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because source.bitWidth > Base.bitWidth, and lowInT is the result of source masked by T(~0 as Low), which necessarily clears any sign bit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a test for this case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, as mentioned, this PR is missing any tests, and I intend to cover all changes thoroughly with new tests before this is merged.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Terrific, thank you.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this change is better, but the performance can degrade pretty quickly since division is slow, esp. if DoubleWidths are nested. What would you think about using hexadecimal instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is performance really a bottleneck? I think the ‘usual’ printing is very important and would argue that the performance of printing DoubleWidth<DoubleWidth<DoubleWidth<Int64>>> is not the right thing to optimize for here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds right. If somebody does run into trouble they can just use String(x, radix: 16) instead.

@natecook1000
Copy link
Member

Looking good after you chase down that FP conversion—just a couple questions for you!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems overdone to me. It looks like _combineHashValues by itself is all we'd need here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure is, but it’s what’s done for synthesized conformances. Given that Tony’s goal is eventually to allow synthesis for types with tuple members, I think we would do well to line things up here so that this extension could potentially be seamlessly deleted in the future.

@xwu
Copy link
Collaborator Author

xwu commented Dec 26, 2017

@natecook1000

Tests added, FP bug squashed. If you feel strongly I'll roll back the hashValue algorithm change. Otherwise, ready to go I think. Two follow-up changes planned: 1) to fix the analogous bug in remainderReportingOverflow for base types; 2) to improve division.

🎄

@xwu
Copy link
Collaborator Author

xwu commented Jan 2, 2018

@natecook1000 Ping.

@natecook1000
Copy link
Member

@swift-ci Please smoke test

lhs._storage.low |= Low(truncatingIfNeeded: highInLow)

lhs._storage.high >>= High(truncatingIfNeeded: rhs._storage.low)
lhs._storage.high >>= High(rhs._storage.low)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

II think, if High is signed, this conversion can trap.

Copy link
Collaborator Author

@xwu xwu Jan 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Performing a bit cast and obtaining a negative number on overflow would be very wrong in any case, but here no overflow is possible. It cannot occur (for any type where Base.bitWidth >= 4) because the value of rhs can be at most DoubleWidth.bitWidth - 1.

It's the same conclusion reached by the original author here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...which is not to say that the implementation couldn't be improved. I've just taken the opportunity to streamline the logic and use masking shifts instead.

@moiseev
Copy link
Contributor

moiseev commented Jan 3, 2018

@swift-ci Please smoke test and merge

@xwu
Copy link
Collaborator Author

xwu commented Jan 4, 2018

@moiseev Well, that last commit certainly wasn't an 'improvement'--I will fix tonight.

@xwu
Copy link
Collaborator Author

xwu commented Jan 4, 2018

@moiseev Embarrassingly, I was calculating x &>>= 0 wrong, thanks to the magic of masking shift. This is what I get for trying to add last-minute flourishes to well-tested patches. Fixed now, and test coverage for bit shifts is already ample so we’re good on that front.

@moiseev
Copy link
Contributor

moiseev commented Jan 4, 2018

@swift-ci Please smoke test and merge

@xwu
Copy link
Collaborator Author

xwu commented Jan 4, 2018

Once more, I think. CI seems to have ignored the last request.

@moiseev
Copy link
Contributor

moiseev commented Jan 4, 2018

@swift-ci Please smoke test and merge

@swift-ci swift-ci merged commit 9fbd809 into swiftlang:master Jan 4, 2018
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

Successfully merging this pull request may close these issues.

4 participants