Rename Spec to AffineScheme

[paemurru]

We have the types Spec and ProjectiveScheme. To make the names consistent, we will change Spec into AffineScheme. The functions to construct affine and projective schemes will still be called spec and proj. This completes one bullet point in Schemes Meta Issue #3202.

For consistency, we need to also change many related types and functions like AbsSpec and SpecMor. See #3345 (comment) for the list of planned changes.

[fieker]

I don't have any (strong) opinion. Wha I would like you (all) to think about, is how someone who does not know what a scheme is can create and use the P^2(QQ), the projective space as introduced in many (classical) (basic) texts. How is this interaction going to be? Those will be the vast majority of users....

[simonbrandhorst]

The names of the underscore constructors won't change. So your question is tangential.
P = projective_space(QQ,2) will create projective space.
rational_points(P) should return the set of its rational points and P([0,0,1]) create the rational point [0:0:1] just like in a text book. We could consider P(QQ) to return the set of QQ rational points.
Further constructors could be
projective_space(ToricVariety, QQ, 2)
projective_space(Scheme, QQ, 2)
projective_space(Set, QQ, 2)
you name it.

[paemurru]

In yesterday's OSCAR meeting it was decided with @micjoswig, @wdecker, @jankoboehm and others to:

• keep the type ProjectiveScheme,
• rename the type Spec to AffineScheme,
• rename the function Spec to spec, and
• introduce an alias affine_scheme of spec.

[wdecker]

Similarly, we should have ProjectiveScheme, proj, and projective_scheme.

…

Am 17.02.2024 um 11:07 schrieb Erik Paemurru ***@***.***>: In yesterday's OSCAR meeting it was decided with @micjoswig <https://github.com/micjoswig>, @wdecker <https://github.com/wdecker>, @jankoboehm <https://github.com/jankoboehm> and others to: rename the type Spec to AffineScheme, rename the function Spec to spec, and introduce an alias affine_scheme of spec. — Reply to this email directly, view it on GitHub <#3345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASSXESHUZONGMY4YLKJCY3YUB6P5AVCNFSM6AAAAABDBPQ3T6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBZHEZDGMZTG4>. You are receiving this because you were mentioned.

[wdecker]

Yesterday, I was not aware of the original issue which suggests moving ProjectiveScheme to Proj etc. So this contradicts to what we decided yesterday. So why moving rojectiveScheme to Proj etc? Isn’t it fine, as it is?

…

Am 17.02.2024 um 11:07 schrieb Erik Paemurru ***@***.***>: In yesterday's OSCAR meeting it was decided with @micjoswig <https://github.com/micjoswig>, @wdecker <https://github.com/wdecker>, @jankoboehm <https://github.com/jankoboehm> and others to: rename the type Spec to AffineScheme, rename the function Spec to spec, and introduce an alias affine_scheme of spec. — Reply to this email directly, view it on GitHub <#3345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASSXESHUZONGMY4YLKJCY3YUB6P5AVCNFSM6AAAAABDBPQ3T6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBZHEZDGMZTG4>. You are receiving this because you were mentioned.

[paemurru]

@wdecker The original issue was the inconsistency that currently we have the types Spec and ProjectiveScheme. For consistency, we would like to have either AffineScheme and ProjectiveScheme or Spec and Proj.

If we rename Spec to AffineScheme, then yes, we will keep ProjectiveScheme as it is.

[wdecker]

o.k., so implementing yesterday’s decision for the affine case and leaving the projective stuff as it is will settle the problem.

…

Am 17.02.2024 um 12:45 schrieb Erik Paemurru ***@***.***>: @wdecker <https://github.com/wdecker> The original issue was the inconsistency that currently we have the types Spec and ProjectiveScheme. For consistency, we would like to have either AffineScheme and ProjectiveScheme or Spec and Proj. — Reply to this email directly, view it on GitHub <#3345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASSXESIZFBSSAYZWPRZHG3YUCJ7PAVCNFSM6AAAAABDBPQ3T6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBZHE3DANRTGE>. You are receiving this because you were mentioned.

[paemurru]

Below are eleven functions containing Spec or spec.

• Spec
• SpecMor
• SimplifiedSpec
• SpecOpen
• SpecOpenMor
• SpecOpenRing
• SpecOpenRingElem
• _is_open_func_for_schemes_without_specopen
• spec_open_ring_type
• ambient_via_spec
• standard_spec

If we rename the type Spec to AffineScheme, then the cleanest way is to rename all of the eleven functions above to using affine_scheme instead of spec. I suggest not having aliases for all the eleven functions above, perhaps only the alias spec for the function affine_scheme and proj for projective_scheme.

At the moment, there is a problem that proj is already defined in src/Rings/ReesAlgebra.jl and it is defined differently from projective_scheme in src/AlgebraicGeometry/Schemes/ProjectiveSchemes/Objects/Constructors.jl. Namely, proj checks that the ring is standard graded while projective_scheme does not. So I would prefer to first have a pull request which only does renaming and then have a separate pull request that creates aliases and fixes the above inconsistency between proj and projective_scheme.

Note that outside of algebraic geometry, the name proj suggests it is an abbreviation of projection. It is used in this meaning in local scope inside a function for group theory, src/Groups/sub.jl, unrelated to projective schemes.

[micjoswig]

If we rename the type Spec to AffineScheme, then the cleanest way is to rename all of the eleven functions above to using affine_scheme instead of spec. I suggest not having aliases for all the eleven functions above, perhaps only the alias spec for the function affine_scheme and proj for projective_scheme.

At the moment, there is a problem that proj is already defined in src/Rings/ReesAlgebra.jl and it is defined differently from projective_scheme in src/AlgebraicGeometry/Schemes/ProjectiveSchemes/Objects/Constructors.jl. Namely, proj checks that the ring is standard graded while projective_scheme does not. So I would prefer to first have a pull request which only does renaming and then have a separate pull request that creates aliases and fixes the above inconsistency between proj and projective_scheme.

Fine with me.

@fieker what do you think?

Note that outside of algebraic geometry, the name proj suggests it is an abbreviation of projection. It is used in this meaning in local scope inside a function for group theory, src/Groups/sub.jl, unrelated to projective schemes.

It is difficult to be globally consistent. After all, notation is not uniform across all of mathematics. I would encourage to use projection instead of projoutside of the algebraic geometry sections. But that should be decided by @fingolfin

[thofma]

Note that outside of algebraic geometry, the name proj suggests it is an abbreviation of projection. It is used in this meaning in local scope inside a function for group theory, src/Groups/sub.jl, unrelated to projective schemes.

It is difficult to be globally consistent. After all, notation is not uniform across all of mathematics. I would encourage to use projection instead of projoutside of the algebraic geometry sections. But that should be decided by @fingolfin

Our style guide says nothing about how one should name variables inside a function, so I don't think this is relevant here.

[wdecker]

I wonder if there could be more intuitive names. I have a Hard time guessing, what the names stand for. Matthias?Von meinem iPhone gesendetAm 17.02.2024 um 16:33 schrieb Tommy Hofmann ***@***.***>: Note that outside of algebraic geometry, the name proj suggests it is an abbreviation of projection. It is used in this meaning in local scope inside a function for group theory, src/Groups/sub.jl, unrelated to projective schemes. It is difficult to be globally consistent. After all, notation is not uniform across all of mathematics. I would encourage to use projection instead of projoutside of the algebraic geometry sections. But that should be decided by @fingolfin Our style guide says nothing about how one should name variables inside a function, so I don't think this is relevant here. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[afkafkafk13]

As I see it, most of these eleven identifiers are internal DataTypes or internal functions. The whole SpecOpen stuff is of technical relevance (and needed!), but by far to complicated to be user facing.

From my point of view, the relevant ones for the renaming are: Spec and SpecMor, which then become AffineScheme and AffineSchemeMorphism by renaming the respective data types and functions. Using this naming, we have to keep in mind a subtle difference: our affine_schemes are always the Spec of a ring, while the mathematical definition merely states that an affine scheme is isomorphic to the Spec of some ring. This is not meant as an argument against the renaming, but this detail needs to be stated as a sideremark in the documentation of the AffineScheme and AffineSchemeMorphism.

[simonbrandhorst]

@benlorenz @paemurru is working on a PR about this right now and running the test. Could we please backport that?
It is a rather big change of the interface that I would like to have in 1.0.
Edit: Hopefully the PR will be ready today.

[micjoswig]

Could we please backport that? It is a rather big change of the interface that I would like to have in 1.0. Edit: Hopefully the PR will be ready today.

What's the impact on the book?

@fieker

[benlorenz]

@benlorenz @paemurru is working on a PR about this right now and running the test. Could we please backport that? It is a rather big change of the interface that I would like to have in 1.0. Edit: Hopefully the PR will be ready today.

I will continue with the rc as planned for today, and we can decide later (maybe in the meeting today) if we can still merge this after the release candidate. (depending on the impact and further testing)

[wdecker]

I suggested to take into account that we distinguish here between types and user-facing functions. Has this be taken into account? It would be good to see a list of changes.

…

Am 23.02.2024 um 12:21 schrieb Michael Joswig ***@***.***>: Could we please backport that? It is a rather big change of the interface that I would like to have in 1.0. Edit: Hopefully the PR will be ready today. What's the impact on the book? @fieker <https://github.com/fieker> — Reply to this email directly, view it on GitHub <#3345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASSXERTTU6LNGPHJAJ63DDYVB3SRAVCNFSM6AAAAABDBPQ3T6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRGE2TEMJUGE>. You are receiving this because you were mentioned.

[simonbrandhorst]

Running a git grep -r "Spec" on the book I do not see any reference to Spec in the code. Thus my expectation is that there is no/little impact.

[paemurru]

@wdecker Yes, I am distinguishing between types and user-facing constructors. The types will be in CamelCase and the functions in snake_case.

The type Spec becomes AffineScheme. I am doing this change by hand because Spec is also used as an abbreviation for Spectrum in comments and strings. The type ProjectiveScheme stays how it is.

@wdecker By recommendation of @simonbrandhorst, I am renaming SpecOpen to AffineSchemeOpenSubscheme. It should now be clear from the type name what this type is for.

Apart from Spec, the other types and functions are easy to change. The list is below. The script is a modified version of the one from The Big Renaming.

Most of the changes below are either comments, types or internal functions that contain the type previously called Spec, now called AffineScheme. There are many local functions that are not exported but for consistency I change them also. Some changes are type names in comments containing a plural form.

#!/bin/sh
#

# some settings that avoid weirdness in sed when it tries to
# adapt to your locale (e.g. if your system uses German as system language)
export LANG=C
export LC_CTYPE=C
export LC_ALL=C

# Files to modify (default uses all files known to git,
# but obviously you can modify it)
FILES=$(git ls-files)

# on macOS, you may need to change the following
SED_I="sed -i"
#SED_I="gsed -i"
#SED_I="sed -i ''"

# Spec to AffineScheme
$SED_I \
-e "s;\bAbsSpec\b;AbsAffineScheme;g" \
-e "s;\bSpecMor\b;AffineSchemeMor;g" \
-e "s;\bAbsSpecMor\b;AbsAffineSchemeMor;g" \
-e "s;\bSimplifiedSpec\b;SimplifiedAffineScheme;g" \
-e "s;\bSpecOpen\b;AffineSchemeOpenSubscheme;g" \
-e "s;\bSpecOpenMor\b;AffineSchemeOpenSubschemeMor;g" \
-e "s;\bSpecOpenRing\b;AffineSchemeOpenSubschemeRing;g" \
-e "s;\bSpecOpenRingElem\b;AffineSchemeOpenSubschemeRingElem;g" \
-e "s;\bSpecSubset\b;AffineSchemeSubset;g" \
-e "s;\bStdSpec\b;StdAffineScheme;g" \
-e "s;\bSpecType\b;AffineSchemeType;g" \
-e "s;\bSpecOpenType\b;AffineSchemeOpenSubschemeType;g" \
-e "s;\bLeftSpecType\b;LeftAffineSchemeType;g" \
-e "s;\bRightSpecType\b;RightAffineSchemeType;g" \
-e "s;\bSpecOpenRingType\b;AffineSchemeOpenSubschemeRingType;g" \
-e "s;\bSpecMorType\b;AffineSchemeMorType;g" \
-e "s;\bSpecType1\b;AffineSchemeType1;g" \
-e "s;\bSpecType2\b;AffineSchemeType2;g" \
-e "s;\bMySpec\b;MyAffineScheme;g" \
-e "s;\bMySpecMor\b;MyAffineSchemeMor;g" \
-e "s;\bSpecOpen_1\b;AffineSchemeOpenSubscheme1;g" \
-e "s;\bSpecOpen_2\b;AffineSchemeOpenSubscheme2;g" \
-e "s;\bSpecOpen_3\b;AffineSchemeOpenSubscheme3;g" \
-e "s;\bSpecOpen_4\b;AffineSchemeOpenSubscheme4;g" \
-e "s;\bSpecL\b;AffineSchemeL;g" \
-e "s;\bSpecs\b;AffineSchemes;g" \
-e "s;\bSpecOpens\b;AffineSchemeOpenSubschemes;g" \
-e "s;\bSpecOpenRings\b;AffineSchemeOpenSubschemeRings;g" \
-e "s;\bSpecOpenMors\b;AffineSchemeOpenSubschemeMors;g" \
-e "s;\bSpecMors\b;AffineSchemeMors;g" \
-e "s;\bAbsSpecs\b;AbsAffineSchemes;g" \
-e "s;\b_is_open_func_for_schemes_without_specopen\b;_is_open_func_for_schemes_without_affine_scheme_open_subscheme;g" \
-e "s;\bspec_open_ring_type\b;affine_scheme_open_subscheme_ring_type;g" \
$FILES

[HereAround]

Sorry for the late notice (relative to the OSCAR book/version 1.0). I just realized that there might be one more place to adjust/consider for the renaming (unless already done):

https://docs.oscar-system.org/dev/AlgebraicGeometry/ToricVarieties/NormalToricVarieties/#proj-Tuple%7BVararg%7BToricLineBundle%7D%7D

[micjoswig]

Sorry for the late notice (relative to the OSCAR book/version 1.0). I just realized that there might be one more place to adjust/consider for the renaming (unless already done):

https://docs.oscar-system.org/dev/AlgebraicGeometry/ToricVarieties/NormalToricVarieties/#proj-Tuple%7BVararg%7BToricLineBundle%7D%7D

Should the toric guy be renamed to projectivization then?

@lkastner

[HereAround]

I just briefly checked with @wdecker - Wolfram and I would both be happy with projectivization.