[Merged by Bors] - chore: make instSMulRealComplex scoped#12080
[Merged by Bors] - chore: make instSMulRealComplex scoped#12080MichaelStollBayreuth wants to merge 7 commits intomasterfrom
Conversation
|
!bench |
|
Here are the benchmark results for commit 3fc1b49. |
|
There is a positive effect on Mathlib.Data.Complex.Basic instructions 30,567 Mrd. -1,919 Mrd. -6,278 % 28,648 Mrd. This is likely caused by the instance now being top of the pile in these files, where it is really needed (but is not present outside). |
|
Does scoping an instance actually do anything? |
Yes: import Mathlib
variable (a b : ℂ)
#check a ≤ b -- failed to synthesize instance LE ℂ
open scoped ComplexOrder
#check a ≤ b -- a ≤ b : Prop |
|
I had a previous experiment where I tried to retroactively scope some parent projections which didn't work. But the problem was the instance erasure and not the scoping. I think scoped instances are a very good idea as another lever to guide typeclass synthesis. bors merge |
This scopes and moves to `Complex.SMul` the instance `instSMulRealComplex`.
Rationale: This instance is used in `Data.Complex.{Basic|Module}` to bootstrap `SMul` instances from the reals, but afterwards, instances `SMul R ℂ` should not need to rely on that (rather be obtained via `Algebra R ℂ`, for example). This speeds up the two mentioned files a bit (in fact, it reverts a slow-down caused by reducing the instance priority in #12070) and does not seem to have any adverse effects.
I think this is a cleaner solution compared to just reducing the instance priority.
See [here](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/simp.20prefers.20CharP.2Ecast_eq_zero.20over.20Nat.2Ecast_zero/near/432855625) on Zulip.
|
Pull request successfully merged into master. Build succeeded: |
This scopes and moves to `Complex.SMul` the instance `instSMulRealComplex`.
Rationale: This instance is used in `Data.Complex.{Basic|Module}` to bootstrap `SMul` instances from the reals, but afterwards, instances `SMul R ℂ` should not need to rely on that (rather be obtained via `Algebra R ℂ`, for example). This speeds up the two mentioned files a bit (in fact, it reverts a slow-down caused by reducing the instance priority in #12070) and does not seem to have any adverse effects.
I think this is a cleaner solution compared to just reducing the instance priority.
See [here](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/simp.20prefers.20CharP.2Ecast_eq_zero.20over.20Nat.2Ecast_zero/near/432855625) on Zulip.
This scopes and moves to `Complex.SMul` the instance `instSMulRealComplex`.
Rationale: This instance is used in `Data.Complex.{Basic|Module}` to bootstrap `SMul` instances from the reals, but afterwards, instances `SMul R ℂ` should not need to rely on that (rather be obtained via `Algebra R ℂ`, for example). This speeds up the two mentioned files a bit (in fact, it reverts a slow-down caused by reducing the instance priority in #12070) and does not seem to have any adverse effects.
I think this is a cleaner solution compared to just reducing the instance priority.
See [here](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/simp.20prefers.20CharP.2Ecast_eq_zero.20over.20Nat.2Ecast_zero/near/432855625) on Zulip.
This scopes and moves to `Complex.SMul` the instance `instSMulRealComplex`.
Rationale: This instance is used in `Data.Complex.{Basic|Module}` to bootstrap `SMul` instances from the reals, but afterwards, instances `SMul R ℂ` should not need to rely on that (rather be obtained via `Algebra R ℂ`, for example). This speeds up the two mentioned files a bit (in fact, it reverts a slow-down caused by reducing the instance priority in #12070) and does not seem to have any adverse effects.
I think this is a cleaner solution compared to just reducing the instance priority.
See [here](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/simp.20prefers.20CharP.2Ecast_eq_zero.20over.20Nat.2Ecast_zero/near/432855625) on Zulip.
This scopes and moves to `Complex.SMul` the instance `instSMulRealComplex`.
Rationale: This instance is used in `Data.Complex.{Basic|Module}` to bootstrap `SMul` instances from the reals, but afterwards, instances `SMul R ℂ` should not need to rely on that (rather be obtained via `Algebra R ℂ`, for example). This speeds up the two mentioned files a bit (in fact, it reverts a slow-down caused by reducing the instance priority in #12070) and does not seem to have any adverse effects.
I think this is a cleaner solution compared to just reducing the instance priority.
See [here](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/simp.20prefers.20CharP.2Ecast_eq_zero.20over.20Nat.2Ecast_zero/near/432855625) on Zulip.
This scopes and moves to `Complex.SMul` the instance `instSMulRealComplex`.
Rationale: This instance is used in `Data.Complex.{Basic|Module}` to bootstrap `SMul` instances from the reals, but afterwards, instances `SMul R ℂ` should not need to rely on that (rather be obtained via `Algebra R ℂ`, for example). This speeds up the two mentioned files a bit (in fact, it reverts a slow-down caused by reducing the instance priority in #12070) and does not seem to have any adverse effects.
I think this is a cleaner solution compared to just reducing the instance priority.
See [here](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/simp.20prefers.20CharP.2Ecast_eq_zero.20over.20Nat.2Ecast_zero/near/432855625) on Zulip.
This scopes and moves to
Complex.SMulthe instanceinstSMulRealComplex.Rationale: This instance is used in
Data.Complex.{Basic|Module}to bootstrapSMulinstances from the reals, but afterwards, instancesSMul R ℂshould not need to rely on that (rather be obtained viaAlgebra R ℂ, for example). This speeds up the two mentioned files a bit (in fact, it reverts a slow-down caused by reducing the instance priority in #12070) and does not seem to have any adverse effects.I think this is a cleaner solution compared to just reducing the instance priority.
See here on Zulip.