Skip to content
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

Non negative extended reals #375

Merged
merged 2 commits into from
Mar 22, 2022
Merged

Non negative extended reals #375

merged 2 commits into from
Mar 22, 2022

Conversation

proux01
Copy link
Collaborator

@proux01 proux01 commented May 4, 2021

I have this file in another development, don't know whether it may be worth having it in analysis?

This is now rebased on top of #511

TODO:

  • merge More lemmas on ereal #535
  • doc
  • discuss notations in scope (c.f. TODO in ereal.v)
  • instances for ereal_sup and ereal_inf
  • inductive spec

@CohenCyril
Copy link
Member

CohenCyril commented May 4, 2021

I have a version, in one of my workdirs that is supposed to cover everything (non negative, negative, positive, non positive, extended or not, symmetric on multiplication). I just did not have time to finish it :'(
Meanwhile, I do not mind having several copies.

@CohenCyril CohenCyril marked this pull request as draft May 5, 2021 16:26
@CohenCyril CohenCyril marked this pull request as ready for review May 5, 2021 16:27
@CohenCyril
Copy link
Member

I have a version, in one of my workdirs that is supposed to cover everything (non negative, negative, positive, non positive, extended or not, symmetric on multiplication). I just did not have time to finish it :'(
Meanwhile, I do not mind having several copies.

cf #511

@proux01
Copy link
Collaborator Author

proux01 commented Jan 11, 2022

Thanks, I'll rebase on top of it.

@CohenCyril
Copy link
Member

Thanks, I'll rebase on top of it.

Do you understand how to do it with minimal duplication?
Do you want to chat for a few minutes?

@proux01
Copy link
Collaborator Author

proux01 commented Jan 11, 2022

I hope so. I'll ask if I run into trouble (but if I understand correctly, that should mostly be a few canonical instances and a spec inductive with two cases (+oo or non negative real)).

@CohenCyril
Copy link
Member

CohenCyril commented Jan 11, 2022

I hope so. I'll ask if I run into trouble (but if I understand correctly, that should mostly be a few canonical instances and a spec inductive with two cases (+oo or non negative real)).

I expect that most (if not all) *_(nonzero|reality)_subdef can be reused as such and that their should be exactly one operator_snum_subproof to add and the corresponding canonical, per new supported operation (0, 1, +oo, -oo, negation, addition, multiplication, etc).

@CohenCyril
Copy link
Member

spec inductive with two cases (+oo or non negative real)).

I do not understand this bit...

@proux01
Copy link
Collaborator Author

proux01 commented Jan 11, 2022

spec inductive with two cases (+oo or non negative real)).

I do not understand this bit...

Something similar to nonneg_spec in #511

This was referenced Jan 30, 2022
proux01 added a commit that referenced this pull request Feb 6, 2022
Previously e%:sgn was failing when an unknown (or no, i.e., for which
no canonical instance is registered) operation was encountered in the
expression e, now some sign information can be inferred from the type
of the unknown sub expression.

This is generalizing the canonical instance already existing for the
type nat.

This is needed in #375 to be
able to infer that `|x|%E is non negative when nothing is known on x.

lignes
affeldt-aist pushed a commit that referenced this pull request Mar 5, 2022
* Make unify more generic

It was requiring an exact abstract value,
now any more-precise abstract value also works.

For instance `unify AnySign NonNeg` was failing
because NonNeg was too precise, whereas
`unify_r AnySign NonNeg` now works.

This is currently useless because one was only asking for most-precise
abstract values, but should become useful in the future.

* Make 1%:nng work

`expr%:nng` was failing when `expr%:pos` was working because the more
precise type `{posnum _}` was infered instead of `{nonneg _}`.

* Add =0 to the abstract domain

Otherwise, we didn't know wether 0 should be abstracted as >=0 or <=0.
The former made max(0, _) fail to be recognized as <=0 while the
latter would break min(0, _) similarly.

* No need to declare reality_cond a local coercion

* Add Arguments for the sake of uniformity

* Generalize min and max

Generalize min and max signed instances from numDomainType to
porderType. This way, they can be used for extended reals.

* Generalize morphism lemmas

This way, they can also be used for extended reals for instance.

* No need for P to be a canonical projection

* Add sign inference on type as a last resort

Previously e%:sgn was failing when an unknown (or no, i.e., for which
no canonical instance is registered) operation was encountered in the
expression e, now some sign information can be inferred from the type
of the unknown sub expression.

This is generalizing the canonical instance already existing for the
type nat.

This is needed in #375 to be
able to infer that `|x|%E is non negative when nothing is known on x.

Co-authored-by: Pierre Roux <pierre@roux01.fr>
proux01 added a commit that referenced this pull request Mar 5, 2022
Previously e%:sgn was failing when an unknown (or no, i.e., for which
no canonical instance is registered) operation was encountered in the
expression e, now some sign information can be inferred from the type
of the unknown sub expression.

This is generalizing the canonical instance already existing for the
type nat.

This is needed in #375 to be
able to infer that `|x|%E is non negative when nothing is known on x.
@proux01
Copy link
Collaborator Author

proux01 commented Mar 5, 2022

Rebased and ready for review (this is mostly a bunch of canonical instances).

Copy link
Member

@CohenCyril CohenCyril left a comment

Choose a reason for hiding this comment

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

Great!

@affeldt-aist affeldt-aist added this to the 0.4.1 milestone Mar 7, 2022
@affeldt-aist affeldt-aist merged commit c5437dd into math-comp:master Mar 22, 2022
@proux01 proux01 deleted the nngenum branch March 22, 2022 15:44
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.

3 participants