Zulip Chat Archive
Stream: general
Topic: ordered with pos
Damiano Testa (Jun 08 2021 at 12:44):
Dear All,
I am about to start preparing a PR to push the ordered
refactor across types with add
and mul
. This essentially involves asserting that multiplication by strictly positive elements be monotone (on top of what is already there for monotonicity of addition). While this is relatively easy to implement, there are two possible approaches that I have played with. I think that, in the long run, maybe we should implement both, but, for the moment, I would start with one. Below are the two approaches that I have in mind: let me know if you have a preference for either one of them or if you see problems/benefits with one or the other!
Thanks!
Approach 1: monotone multiplication. Simply introduce new typeclasses asserting
∀ (a : N) {b c : N}, (0 < a) → (b ≤ c) → (a * b ≤ a * c)
with various layers according to whether the inequality is strict or not, or whether multiplication is on the left or on the right. This is relatively straightforward. The main drawback is that it uses homogeneous multiplication. Thus, it may cause problems when trying to multiply a (unit nnreal)
by an ennreal
.
Approach 2: monotone action. Introduce a more general typeclass allowing an action of a Type M
on a second Type N
and asserting
∀ (m : M) {n₁ n₂ : N}, (n₁ ≤ n₂) → (m • n₁ ≤ m • n₂)
This approach of course allows for more general statements, and would work better developing some API for "positive subtypes" of types with an order. In the first instance, this can be quite short, only introducing a "Type of positive elements" whenever a type has_zero
and has_lt
.
My preference is for Approach 2. This works well in abstract Types, but also in concrete cases where you might want to multiply a positive rational number by an ennreal
and know that multiplication is monotone.
What are people's opinions on this? Should I create a poll?
Gabriel Ebner (Jun 08 2021 at 12:51):
Damiano Testa said:
Thus, it may cause problems when trying to multiply a
(unit nnreal)
by anennreal
.
Can you maybe give another example? You can multiply a units nnreal
and an ennreal
just fine (the unit will just coerce to an ennreal).
Damiano Testa (Jun 08 2021 at 13:22):
At the moment, I am actually failing to identify an example where there may not be a coercion saving the day. Maybe there is no need for the extra generality of the "proper action" and all can be resolved using coercions+multiplication?
I can only think of the following "dynamical-systems-like" example.
Suppose that you have a Type X
with a self-map f : X → X
. This determines an action of ℕ
on X
by iterating f
. You can then act on set X
elementwise via f^[n] ''
. On set X
there is an addition (taking unions) and a ≤
(taking subsets) and the ℕ
-action is monotone. At this level, there is no coercion from ℕ
to set X
that would work, I think.
Does this count? The answer could well be: "this is too contrived, so we do not need the greater generality"!
Damiano Testa (Jun 08 2021 at 13:27):
I guess that the main take-away from the example is that you do not need a multiplication on N
to have a monotonicity of something acting on it. I feel like I should know a good example of this, but I am not managing to bring it to my conscience!
Eric Wieser (Jun 08 2021 at 14:55):
Your approach 2 looks like a weaker version of docs#smul_lt_smul_of_pos
Eric Wieser (Jun 08 2021 at 14:57):
Gabriel Ebner said:
You can multiply a
units nnreal
and anennreal
just fine (the unit will just coerce to an ennreal).
It's not really the point of this thread, but I think there should be a algebra nnreal ennreal
instance somewhere, from which we'd get has_scalar (units nnreal) ennreal
automatically.
Johan Commelin (Jun 08 2021 at 14:58):
algebra R A
assumes that A
is a semiring, right? But ennreal
isn't.
Damiano Testa (Jun 08 2021 at 15:14):
Eric, thank you for digging out something that would likely be an application of Approach 2, (should Approach 2 become part of mathlib)!
While it is possible that most applications of the ordered
refactor could be solved by instances, I still think that it might be worthwhile to pursue both Approach 1 and Approach 2, although not in the same PR. I am now going to propose a poll, to see with which one to begin!
Damiano Testa (Jun 08 2021 at 15:16):
/poll mul_pos_monotone
Approach 1: monotone multiplication ∀ (a : N) {b c : N}, (0 < a) → (b ≤ c) → (a * b ≤ a * c)
Approach 2: monotone action ∀ (m : M) {n₁ n₂ : N}, (n₁ ≤ n₂) → (m • n₁ ≤ m • n₂)
Eric Wieser (Jun 08 2021 at 15:17):
Oh, I totally missed that. Then I guess I mean there should be a mul_action nnreal ennreal
?
Eric Wieser (Jun 08 2021 at 15:19):
Damiano, is the idea behind approach 2 to use a subtype M
for the 0 < a
condition?
Damiano Testa (Jun 08 2021 at 15:22):
Eric, yes, I would use the subtype that you mention to apply it, but only if approach 1 is not also developed.
Eric Wieser (Jun 08 2021 at 15:22):
Johan Commelin said:
algebra R A
assumes thatA
is a semiring, right? Butennreal
isn't.
docs#ennreal.canonically_ordered_comm_semiring suggests to me that ennreal is a semiring
Damiano Testa (Jun 08 2021 at 15:23):
(I do not view the two approaches as opposing: sometimes the "unbundled" approach 1 is better, other times the "bundled" approach 2 is better. it is not difficult to go from one to the other, though having direct paths both ways may be convenient)
Floris van Doorn (Jun 08 2021 at 15:25):
In approach 2 you are adding the assumption 0 < m
right?
Damiano Testa (Jun 08 2021 at 15:25):
In approach 2 you do not need to add the assumption 0 < m
, since you would only get an instance of that type if multiplication is monotone.
Johan Commelin (Jun 08 2021 at 15:25):
@Eric Wieser you're right. my bad
Damiano Testa (Jun 08 2021 at 15:26):
In other words, if multiplication of a type on another is monotone, likely the action of the first type is by positive elements.
Damiano Testa (Jun 08 2021 at 15:26):
But you need not have even an order relation on the acting type in order to get monotonicity of the action: the inequalities are all on the target type N
.
Floris van Doorn (Jun 08 2021 at 15:28):
Ah, I see.
Damiano Testa (Jun 08 2021 at 15:28):
Thus, Approach 2 is outsourcing to the typeclass system to make sure that you have a proof that the elements of the Type M
actually do have the correct monotonicity.
Floris van Doorn (Jun 08 2021 at 15:28):
One advantage of approach 2 is that it generalizes both approach 1 and the current covariant_class
, right?
Damiano Testa (Jun 08 2021 at 15:29):
Yes, indeed, covariant_class
would be applying approach 2 with twice the same type (i.e. M = N
).
and the "positive multiplication" would be using approach 2 with the "type of positive elements" acting on the actual type.
Damiano Testa (Jun 08 2021 at 15:34):
Mathematically, there is little difference. In Lean, instead of multiplying by the elements of a Type N
that happen to be positive, you allow yourself to act on N
with the elements of another type M
.
The use case is of course the one where M
is the subtype of the positive elements of N
, though this would not be required by the definitions.
Floris van Doorn (Jun 08 2021 at 15:36):
I think approach 2 is worth trying.
Eric Wieser (Jun 08 2021 at 15:42):
How about a third appoach:
class is_monotone (f : A → B) :=
(out : monotone f)
which you can then write approach 2 as using [∀ m : M, is_monotone ((•) m : N → N)]
Damiano Testa (Jun 08 2021 at 15:45):
Eric, I like your suggestion, although I would also want to allow the freedom of having strict_mono
. In other words, I was thinking of leaving the (order) relation as an input of the class, like for covariant
.
Damiano Testa (Jun 08 2021 at 15:46):
So, I could sometimes assume that multiplication is monotone and sometimes strictly monotone.
Floris van Doorn (Jun 08 2021 at 16:10):
Wait, covariant_class
can be used to do approach 2, right? covariant_class {x : M // 0 < x} M (•) (≤)
Eric Wieser (Jun 08 2021 at 16:19):
Damiano Testa said:
Eric, I like your suggestion, although I would also want to allow the freedom of having
strict_mono
. In other words, I was thinking of leaving the (order) relation as an input of the class, like forcovariant
.
my experiments in #7834 suggest that typeclasses with lots of (dependent) inputs as you're suggesting might be a bad idea - but it's also possible my problem is something else
Eric Wieser (Jun 08 2021 at 16:35):
Johan Commelin said:
Eric Wieser you're right. my bad
Damiano Testa (Jun 08 2021 at 16:39):
Eric, some similar comments on times had been raised before the introduction of covariant_class though some timings performed by Jannis Limperg suggested that the
covariant approach was (very marginally) faster than the current one with
ordered_...`. In any case, I will try to see how it works and then we can decide what is best. This will likely be tomorrow, though!
Damiano Testa (Jun 08 2021 at 16:40):
Floris, I think that I had tried to recycle covariant_class
, but had failed. I will try again and see how it works!
Damiano Testa (Jun 08 2021 at 16:40):
In any case, thank you all for the support!
Eric Wieser (Jun 08 2021 at 17:00):
My concern is not so much about speed, but about whether typeclass search will get stuck on the resulting dependent types.
Eric Wieser (Jun 08 2021 at 17:01):
Eric Wieser said:
I think there should be a
algebra nnreal ennreal
instance somewhere, from which we'd gethas_scalar (units nnreal) ennreal
automatically.
#7846 now provides distrib_mul_action (units ℝ≥0) ℝ≥0∞
Damiano Testa (Jun 09 2021 at 13:29):
Dear All,
here is a follow up, based on the discussion that we were having yesterday. Below is a beginning of code to convert lemmas about ordered_semiring
s into lemmas about covariant_class M N (some_action) (<)
.
[Floris, this seems to work: I think that I had something more general in mind that would require three types, instead of two.]
Main question. Can I make the final proof of mul_lt_mul_of_pos_left
"simpler"?
Side question. How would you improve the code?
Thanks!
import algebra.ordered_ring
/-- The positive elements of a type. -/
def posi (α : Type*) [has_zero α] [has_lt α] : Type* := { a : α // 0 < a }
namespace posi
/-- An element of `posi α` can be coerced into `α`. -/
instance (α : Type*) [has_zero α] [has_lt α] : has_coe (posi α) α :=
{ coe := λ a, a.1 }
/-- A positive element of `α` can be lifted into `posi α`. -/
instance (α : Type*) [has_zero α] [has_lt α] : can_lift α (posi α) :=
{ coe := coe,
cond := λ a, 0 < a,
prf := λ a ha, Exists.intro ⟨a, ha⟩ rfl }
/-- An ordered semiring automatically inherits a covariant_class for strictly monotone
multiplication by positive elements. -/
instance ordered_semiring.to_covariant_class_posi_left (α : Type*) [ordered_semiring α] :
covariant_class (posi α) α (λ a b, a * b) (<) :=
{ covc := λ a b c bc, mul_lt_mul_of_pos_left bc a.2 }
/- The lemma in general. -/
lemma mul_lt_mul_of_pos {M N : Type*} (μ : M → N → N) [has_lt N] [covariant_class M N μ (<)]
{m : M} {n o : N} (h₁ : n < o) : μ m n < μ m o :=
covariant_class.covc _ h₁
/- If possible, I would like this proof to be simply an application of the general lemma. -/
lemma mul_lt_mul_of_pos_left {α : Type*} [ordered_semiring α] {a b c : α}
(h₁ : a < b) (h₂ : 0 < c) : c * a < c * b :=
by { lift c to (posi α) using h₂,
convert posi.mul_lt_mul_of_pos (λ (x : posi α) (y : α), x * y) h₁ }
end posi
Damiano Testa (Jun 09 2021 at 13:42):
(also, I do not mind if a few initial lemmas have some awkwardness, but I would like to simply be able to apply most of the general lemmas in the ordered_semiring
context, without having to juggle around type-theoretic assumptions all the time.)
Kevin Buzzard (Jun 09 2021 at 15:03):
instance (α : Type*) [has_zero α] [has_lt α] : can_lift α (posi α) :=
{ coe := coe,
cond := λ a, 0 < a,
prf := λ a ha, ⟨⟨a, ha⟩, rfl⟩ }
Damiano Testa (Jun 09 2021 at 15:08):
Thanks Kevin! I edited the code above, to implement your suggestion!
Kevin Buzzard (Jun 09 2021 at 15:20):
local attribute [elab_simple] mul_lt_mul_of_pos
lemma mul_lt_mul_of_pos_left' {α : Type*} [ordered_semiring α] {a b c : α}
(h₁ : a < b) (h₂ : 0 < c) : ((⟨c, h₂⟩ : posi α) : α) * a < c * b :=
mul_lt_mul_of_pos (λ x y, x * y : posi α → α → α) h₁
lemma mul_lt_mul_of_pos_left {α : Type*} [ordered_semiring α] {a b c : α}
(h₁ : a < b) (h₂ : 0 < c) : c * a < c * b :=
mul_lt_mul_of_pos_left' h₁ h₂
Kevin Buzzard (Jun 09 2021 at 15:21):
not sure if that's the answer you wanted!
Damiano Testa (Jun 09 2021 at 15:22):
I need to digest it, but it might be close to what I had in mind!
Damiano Testa (Jun 09 2021 at 15:23):
The idea would be that "under the hood" you prove the lemmas with the '
in that style, but then you are allowed to use them in the familiar context with the "explicit" positivity assumption, rather than the one implicit in the subtype?
Damiano Testa (Jun 09 2021 at 15:25):
(I am also toying around with introducing a smul between posi α
and α
, but that is also a little heavy: having the explicit 0 < c
or 0 \le c
assumption in context is convenient, certainly for thinking about these lemmas.)
Kevin Buzzard (Jun 09 2021 at 15:37):
I'm not sure I know the idea, I was just trying to solve the puzzle you set :-)
Damiano Testa (Jun 09 2021 at 15:41):
Yes, that is a great start: thank you so much for your help!
Floris van Doorn (Jun 09 2021 at 18:05):
If you make the m
in mul_lt_mul_of_pos
explicit (which it should be), then the following also works:
lemma mul_lt_mul_of_pos_left {α : Type*} [ordered_semiring α] {a b c : α}
(h₁ : a < b) (h₂ : 0 < c) : c * a < c * b :=
(posi.mul_lt_mul_of_pos (λ (x : posi α) (y : α), x * y) ⟨c, h₂⟩ h₁ : _)
Kevin Buzzard (Jun 09 2021 at 19:11):
Aah, this is the correct solution. I knew you shouldn't be messing with the elaboration strategies but I've realised recently that I still don't properly understand the rules for which inputs should be explicit.
Damiano Testa (Jun 09 2021 at 19:24):
Floris, thank you so much! I had the correct argument explicit in the definition of covariant_class
but got lazy here: I will be more careful!
Reid Barton (Jun 09 2021 at 22:30):
Is there a reason to (at least in Approach 1) only require multiplication by positive elements to be monotone? It seems better mathematically to include the case 0 = a
. For example, the product of two types satisfying the condition with 0 < a
won't necessarily also satisfy it, because 0 < (a, a')
doesn't imply 0 < a
.
Is this a historical artifact perhaps? I seem to recall the Lean core library's definition of an ordered ring being odd, involving strict inequalities where <=
would be more natural.
Reid Barton (Jun 09 2021 at 22:34):
Of course in any sensible context it shouldn't matter since when 0 = a
we have 0 * b = 0 = 0 * c
.
Damiano Testa (Jun 10 2021 at 04:26):
Dear Reid,
you are completely right, of course!
The reason I chose specifically strict monotonicity was simply because I still want the existing lemmas in mathlib to "just work". In fact, the whole ordered
refactor started because I felt that the existing system was not designed to deal with order relations interacting with general algebraic operations, not necessarily commutative, for instance. Thus, I plan to prove lemmas for strict and non-strict monotonicity, but I certainly want to preserve the existing lemmas.
Reid Barton (Jun 10 2021 at 15:10):
OK, I don't know what order of refactors is best, but the eventually desired state should be one in which ordered_ring
has only mul_nonneg
as an axiom and not mul_pos
.
Ruben Van de Velde (Jun 10 2021 at 15:32):
order of refactors, huh
Damiano Testa (Jun 10 2021 at 15:55):
Reid, at the moment, I am simply introducing typeclasses for proving statements with more flexible (typeclass) assumptions. I am not thinking of changing the definition of ordered_ring
. At least, not yet!
Last updated: Dec 20 2023 at 11:08 UTC