-
Notifications
You must be signed in to change notification settings - Fork 233
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
generic Nonzero proposal #1175
Comments
I'm happy for you to add the definition to
We should not generalise the existing examples in
I think |
The generic Another point is that the approach of lib-1.3 with \top and \bottom and implicit Nonzero for Nat |
I have committed this PR.
And now there are the folders
on my machine. And I hope that they present the two independent branches and two independent PR-s. If so, then this is a great achievement. |
You have pushed the change to the divmod PR |
I am sorry. |
In lib-1.7,
Further, everywhere where (nz : NonZero) is needed as argument, it has to be used Algebra.Properties.Semiring.NonZero R, |
Currently I use this general definition under
And now I propose instead (for Standard):
Example of usage:
It is also possible to first define ButOne and NonZero may be in Algebra.Definitions, for the Raw structures, etc. ? |
Okay, in light of PR #1582 which adds fields, I've been thinking hard about how to come up with a generic definition for Definition 1: Does not use decidability
Definition 2: Uses decidability relation =ᵇ
(records are needed to make instance search play nice which is a separate issue) In general Definition 1 is definitely preferable as it applies to non-decidable domains such as the reals. However in decidable domains (e.g.
whereas if we use Definition 1 then we would have to write:
and I'm kind of reluctant to give that up... So there a two options I guess:
What are people's thoughts. Can anyone see any others? |
My leaning would be to have That way the decidable domains can be maximally usable. The other domains should be hard to deal with (constructively)! |
Of course, a definition for Also it is regularly is needed For example lib-1.7 has But as standard library has not DecSemigroup, DecSemiring etc,
? Also I wonder what is |
Yes, something like that seems to make sense. |
Jacques writes.
There is some mystery secret about this.
|
I found this work around definition And they also define field structure here |
It is desirable for Standard to intoduce the Field abstract domain: |
Parts of algebra are indeed quite a bit harder without decidable equality. A lot of algorithms need it. Classical mathematics builds it in (that's a consequence of excluded middle). This shows up most clearly when you try to compute with "fields of functions": you can't decide if an arbitrary function is constantly 0 or not. Even classically, Field is weird: it's not given equationally. Fields do not form a variety. |
Jacques writes
I recall, after my talk in 2013 Jacques asked me: why do I define various domain constructors (or polymorphic functions) specially for Semigroup, Group, etc, instead of doing this in a general way. But I think that even with this kind of conditions algebra is programmed more or less all right in Agda. ? |
Equality being boolean-valued is equivalent to asking for decidable equality. In the presence of decidable equality, many algorithms in Algebra do go through. It's quite fine to have a parallel hierarchy of Algebra that assumes that the underlying equality is decidable. The current library has made a different design decision: constructive and Setoid-based. So the main |
May be it is all right for Standard to have a Setoid-based Algebra only. I wonder of whether Standard needs these "Dec, Dec2" classes (from Magma to CommutativeRing). |
The master lib of April 28, 2020 has
NonZero
for Integer, ℚ and maybe for other special domains.I suggest to generalize this to
IsNonzero : Pred Carrier _
and
Nonzero = Σ Carrier IsNonzero
,declaring this for arbitrary Semiring. This can be put to Algebra.Properties.Semiring.
Motivation.
others) is a monoid by
_*_
. This sub-monoid is often used, it is an usual construction appliedto a (semi)ring.
Also I have an impression that they write in literature Nonzero rather than NonZero,
Nonempty rather than NonEmpty.
?
The text was updated successfully, but these errors were encountered: