-
Notifications
You must be signed in to change notification settings - Fork 297
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
[Merged by Bors] - feat(data/sign): the sign function #12835
Conversation
Given that there's no clear canonical type for the
We could then define casts from As for theorems, I think the basic things should be enough, i.e. |
this field would be isomorphic to zmod 3, whilst being a more suitable output type. interesting, I think that's a nice idea |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @vihdzp's suggestion of creating a new type. If we add a coercion of the form
instance [has_zero α] [has_one α] [has_neg α] : sign → α
then we can recover the original ℤ
return value quite easily.
src/data/sign.lean
Outdated
|
||
variables [preorder α] [decidable_rel ((<) : α → α → Prop)] {a b : α} | ||
|
||
@[simp] lemma sign_zero : sign (0 : α) = 0 := by simp [sign] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For completeness, could you add the sign of positive and negative values?
hmm, it could be a field but I feel like mathematically it's more of a |
Let's go for |
I'm also not sure how to bundle this; I want to bundle |
I think I remember on zulip seeing some of the following suggested:
Were these ruled out as annoying, or just forgotten? |
Co-authored-by: damiano <adomani@gmail.com>
the first one I thought may be a bit annoying. the second could work, too; I do quite like this custom type solution as we get to have a coercion to anything without needing to mess with |
I think this should be good for review again, I'm not sure what other obvious things are missing. There is a couple comments in the code - if people could figure out whether we really need |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is starting to look very good, thanks for the hard work!
Co-authored-by: Anne Baanen <Vierkantor@users.noreply.github.com> Co-authored-by: damiano <adomani@gmail.com>
|
||
@[simp] lemma zero_eq_zero : zero = 0 := rfl | ||
@[simp] lemma neg_eq_neg_one : neg = -1 := rfl | ||
@[simp] lemma pos_eq_one : pos = 1 := rfl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we get -0 = 0
and --1 = 1
via some other instance below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just added neg_zero'
in another PR, and so it's fine because of the distrib neg. We have neg_neg as we have an involutive negation
src/data/sign.lean
Outdated
{ cases lt_irrefl 0 (h_1.trans $ h.trans_lt h_3) }, | ||
{ cases h_2 (h_1.trans_le h) }, | ||
{ cases h_2 (h.trans_lt h_4) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is referring to auto-generated names. Can you please rewrite?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, but I think it made it a bit more messy
Co-authored-by: Johan Commelin <johan@commelin.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 🎉
bors merge
Co-authored-by: Eric Rodriguez <37984851+ericrbg@users.noreply.github.com>
Pull request successfully merged into master. Build succeeded: |
Mostly for discussion about how this should be done - what should the output type be? What should we require? What basic theorems would make a good part of the API?