Backports for 1.0.3

CITATION.cff

@@ -32,6 +32,19 @@ preferred-citation:
   - family-names: "Joswig"
     given-names: "Michael"
   title: "The Computer Algebra System OSCAR: Algorithms and Examples"
+  collection-type: "Series"
+  collection-title: "Algorithms and Computation in Mathematics"
+  abstract: >-
+    The book is an invitation to use OSCAR.  With discussions of
+    theoretical and algorithmic aspects included, it offers a
+    multitude of explicit code snippets. These are valuable for
+    interested researchers from graduate students through established
+    experts.
   year: 2024
+  month: 8
+  edition: 1
+  issn: "1431-1550"
+  url: "https://link.springer.com/book/9783031621260"
+  volume: 32
   publisher:
     name: "Springer"

Project.toml

@@ -1,7 +1,7 @@
 name = "Oscar"
 uuid = "f1435218-dba5-11e9-1e4d-f1a5fab5fc13"
 authors = ["The OSCAR Team <oscar@oscar-system.org>"]
-version = "1.0.2"
+version = "1.0.3"
 
 [deps]
 AbstractAlgebra = "c3fe647b-3220-5bb0-a1ea-a7954cac585d"

README.md

@@ -37,7 +37,7 @@ julia> using Oscar
  / _ \ / ___| / ___|  / \  |  _ \   |  Combining ANTIC, GAP, Polymake, Singular
 | | | |\___ \| |     / _ \ | |_) |  |  Type "?Oscar" for more information
 | |_| | ___) | |___ / ___ \|  _ <   |  Manual: https://docs.oscar-system.org
- \___/ |____/ \____/_/   \_\_| \_\  |  Version 1.0.2
+ \___/ |____/ \____/_/   \_\_| \_\  |  Version 1.0.3
 
 julia> k, a = quadratic_field(-5)
 (Imaginary quadratic field defined by x^2 + 5, sqrt(-5))
@@ -120,7 +120,7 @@ pm::Array<topaz::HomologyGroup<pm::Integer> >
 If you have used OSCAR in the preparation of a paper please cite it as described below:
 
     [OSCAR]
-        OSCAR -- Open Source Computer Algebra Research system, Version 1.0.2,
+        OSCAR -- Open Source Computer Algebra Research system, Version 1.0.3,
         The OSCAR Team, 2024. (https://www.oscar-system.org)
     [OSCAR-book]
         Wolfram Decker, Christian Eder, Claus Fieker, Max Horn, Michael Joswig, eds.
@@ -133,7 +133,7 @@ If you are using BibTeX, you can use the following BibTeX entries:
       key          = {OSCAR},
       organization = {The OSCAR Team},
       title        = {OSCAR -- Open Source Computer Algebra Research system,
-                      Version 1.0.2},
+                      Version 1.0.3},
       year         = {2024},
       url          = {https://www.oscar-system.org},
       }
@@ -144,6 +144,11 @@ If you are using BibTeX, you can use the following BibTeX entries:
       year = {2024},
       publisher = {Springer},
       series = {Algorithms and {C}omputation in {M}athematics},
+      volume = {32},
+      edition = {1},
+      url = {https://link.springer.com/book/9783031621260},
+      month = {8},
+      issn = {1431-1550},
     }
 
 ## Funding

docs/src/AlgebraicGeometry/Schemes/ArchitectureOfAffineSchemes.md

@@ -10,21 +10,21 @@ CurrentModule = Oscar
 Any type of ring ``R`` to be used within the schemes framework
 must come with its own ideal type `IdealType<:Ideal` for which
 we require the following interface to be implemented:
-```
-    # constructor of ideals in R
-    ideal(R::RingType, g::Vector{<:RingElem})::Ideal
+```julia
+# constructor of ideals in R
+ideal(R::RingType, g::Vector{<:RingElem})::Ideal
 
-    # constructor for quotient rings
-    quo(R::RingType, I::IdealType)::Tuple{<:Ring, <:Map}
+# constructor for quotient rings
+quo(R::RingType, I::IdealType)::Tuple{<:Ring, <:Map}
 
-    # ideal membership test
-    in(f::RingElem, I::IdealType)::Bool
+# ideal membership test
+in(f::RingElem, I::IdealType)::Bool
 
-    # a (fixed) set of generators
-    gens(I::IdealType)::Vector{<:RingElem}
+# a (fixed) set of generators
+gens(I::IdealType)::Vector{<:RingElem}
 
-    # writing an element as linear combination of the generators
-    coordinates(f::RingElem, I::IdealType)::Vector{<:RingElem}
+# writing an element as linear combination of the generators
+coordinates(f::RingElem, I::IdealType)::Vector{<:RingElem}
 ```
 The latter function must return a vector ``v = (a_1,\dots, a_r)``
 of elements in ``R`` such that ``f = a_1 \cdot g_1 + \dots + a_r \cdot g_r``
@@ -34,8 +34,8 @@ not belong to ``I``, it must error. Note that the ring returned by
 
 With a view towards the use of the `ambient_coordinate_ring(X)` for computations,
 it is customary to also implement
-```
-    saturated_ideal(I::IdealType)::MPolyIdeal
+```julia
+saturated_ideal(I::IdealType)::MPolyIdeal
 ```
 returning an ideal ``J`` in the `ambient_coordinate_ring(X)` with the property
 that ``a \in I`` for some element ``a \in R`` if and only if
@@ -51,9 +51,9 @@ this is another reason to include the ambient affine space in our abstract
 interface for affine schemes. In order to make the `ambient_coordinate_ring(X)`
 accessible for this purpose, we need the following methods to be implemented
 for elements ``a\in R`` of type `RingElemType`:
-```
-   lifted_numerator(a::RingElemType)
-   lifted_denominator(a::RingElemType)
+```julia
+lifted_numerator(a::RingElemType)
+lifted_denominator(a::RingElemType)
 ```
 These must return representatives of the numerator and the denominator
 of ``a``. Note that the denominator is equal to `one(P)` in case
@@ -63,8 +63,8 @@ Recall that the coordinates ``x_i`` of ``X`` are induced by the coordinates of
 the ambient affine space.
 Moreover, we will assume that for homomorphisms from ``R``
 there is a method
-```
-    hom(R::RingType, S::Ring, a::Vector{<:RingElem})
+```julia
+hom(R::RingType, S::Ring, a::Vector{<:RingElem})
 ```
 where `RingType` is the type of ``R`` and `a` the images
 of the coordinates ``x_i`` in ``S``. This will be important
@@ -83,7 +83,7 @@ Note that the morphism ``P → R`` is induced by natural coercions.
 
 The abstract type for affine schemes is
 ```@docs
-    AbsAffineScheme{BaseRingType, RingType<:Ring}
+AbsAffineScheme{BaseRingType, RingType<:Ring}
 ```
 For any concrete instance of this type, we require the following
 functions to be implemented:
@@ -92,7 +92,7 @@ functions to be implemented:
 
 A concrete instance of this type is
 ```@docs
-    AffineScheme{BaseRingType, RingType}
+AffineScheme{BaseRingType, RingType}
 ```
 It provides an implementation of affine schemes for rings ``R`` of type
 `MPolyRing`, `MPolyQuoRing`, `MPolyLocRing`, and `MPolyQuoLocRing`
@@ -102,8 +102,8 @@ concrete types `MyAffineScheme<:AbsAffineScheme` such as, for instance,
 group schemes, toric schemes, schemes of a particular dimension
 like curves and surfaces, etc. To this end, one has to store
 an instance `Y` of `AffineScheme` in `MyAffineScheme` and implement the methods
-```
-    underlying_scheme(X::MyAffineScheme)::AffineScheme # return Y as above
+```julia
+underlying_scheme(X::MyAffineScheme)::AffineScheme # return Y as above
 ```
 Then all methods implemented for `AffineScheme` are automatically
 forwarded to any instance of `MyAffineScheme`.
@@ -116,20 +116,20 @@ Of course, it can be overwritten for any higher type `MyAffineScheme<:AbsAffineS
 
 Any abstract morphism of affine schemes is of the following type:
 ```@docs
-    AbsAffineSchemeMor{DomainType<:AbsAffineScheme,
-               CodomainType<:AbsAffineScheme,
-               PullbackType<:Map,
-               MorphismType,
-               BaseMorType
-               }
+AbsAffineSchemeMor{DomainType<:AbsAffineScheme,
+            CodomainType<:AbsAffineScheme,
+            PullbackType<:Map,
+            MorphismType,
+            BaseMorType
+            }
 ```
 Any such morphism has the attributes `domain`, `codomain` and `pullback`.
 A concrete and minimalistic implementation exist for the type `AffineSchemeMor`:
 ```@docs
-    AffineSchemeMor{DomainType<:AbsAffineScheme,
-            CodomainType<:AbsAffineScheme,
-            PullbackType<:Map
-           }
+AffineSchemeMor{DomainType<:AbsAffineScheme,
+        CodomainType<:AbsAffineScheme,
+        PullbackType<:Map
+        }
 ```
 This basic functionality consists of
 - `compose(f::AbsAffineSchemeMor, g::AbsAffineSchemeMor)`,
@@ -144,7 +144,7 @@ should run naturally.
 We may derive higher types of morphisms of affine schemes `MyAffineSchemeMor<:AbsAffineSchemeMor`
 by storing an instance `g` of `AffineSchemeMor` inside an instance `f` of
 `MyAffineSchemeMor` and implementing
-```
-    underlying_morphism(f::MyAffineSchemeMor)::AffineSchemeMor # return g
+```julia
+underlying_morphism(f::MyAffineSchemeMor)::AffineSchemeMor # return g
 ```
 For example, this allows us to define closed embeddings.

docs/src/AlgebraicGeometry/Schemes/CoveredSchemeMorphisms.md

@@ -14,8 +14,8 @@ This information is held by a `CoveringMorphism`:
 ```
 The basic functionality of `CoveringMorphism`s comprises `domain` and `codomain` which 
 both return a `Covering`, together with 
-```
-    getindex(f::CoveringMorphism, U::AbsAffineScheme)
+```julia
+getindex(f::CoveringMorphism, U::AbsAffineScheme)
 ```
 which for ``U = U_i`` returns the `AbsAffineSchemeMor` ``f_i : U_i \to V_{F(i)}``.
 
@@ -27,10 +27,10 @@ in order to realize the covering morphism in the first place.
 ## The interface for morphisms of covered schemes
 Every `AbsCoveredSchemeMorphism` ``f : X \to Y`` is required to implement the following minimal 
 interface.
-```
-    domain(f::AbsCoveredSchemeMorphism)                 # returns X
-    codomain(f::AbsCoveredSchemeMorphism)               # returns Y
-    covering_morphism(f::AbsCoveredSchemeMorphism)      # returns the underlying covering morphism {f_i}
+```julia
+domain(f::AbsCoveredSchemeMorphism)                 # returns X
+codomain(f::AbsCoveredSchemeMorphism)               # returns Y
+covering_morphism(f::AbsCoveredSchemeMorphism)      # returns the underlying covering morphism {f_i}
 ```
 For the user's convenience, also the domain and codomain 
 of the underlying `covering_morphism` are forwarded as `domain_covering` and 
@@ -64,7 +64,7 @@ on ``X`` and ``Y`` can be extracted from the ``f^* v_i`` more directly.
 
 A lazy concrete data structure to house this kind of morphism is 
 ```@docs
-    MorphismFromRationalFunctions
+MorphismFromRationalFunctions
 ```
 Note that the key idea of this data type is to *not* use the `underlying_morphism` 
 together with its `covering_morphism`, but to find cheaper ways to do computations! 
@@ -81,12 +81,12 @@ there is no need to realize the full `covering_morphism` of ``f``.
 In order to facilitate such computations as lazy as possible, there are various fine-grained 
 entry points and caching mechanisms to realize ``f`` on open subsets:
 ```@docs
-    realize_on_patch(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme)
-    realize_on_open_subset(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
-    realization_preview(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
-    random_realization(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
-    cheap_realization(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
-    realize_maximally_on_open_subset(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
-    realize(Phi::MorphismFromRationalFunctions)
+realize_on_patch(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme)
+realize_on_open_subset(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
+realization_preview(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
+random_realization(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
+cheap_realization(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
+realize_maximally_on_open_subset(Phi::MorphismFromRationalFunctions, U::AbsAffineScheme, V::AbsAffineScheme)
+realize(Phi::MorphismFromRationalFunctions)
 ```
 

docs/src/AlgebraicGeometry/Schemes/CoveredSchemes.md

@@ -9,44 +9,44 @@ Oscar supports modeling abstract schemes by means of a covering by affine charts
 ## Types
 The abstract type for these is:
 ```@docs
-    AbsCoveredScheme{BaseRingType}
+AbsCoveredScheme{BaseRingType}
 ```
 The basic concrete instance of an `AbsCoveredScheme` is:
 ```@docs
-    CoveredScheme{BaseRingType}
+CoveredScheme{BaseRingType}
 ```
 
 ## Constructors
 You can manually construct a `CoveredScheme` from a `Covering` using 
 ```@docs
-    CoveredScheme(C::Covering)
+CoveredScheme(C::Covering)
 ```
 In most cases, however, you may wish for the computer to provide you with a ready-made 
 `Covering` and use a more high-level constructor, such as, for instance, 
 ```@docs
-    covered_scheme(P::ProjectiveScheme)
+covered_scheme(P::ProjectiveScheme)
 ```
 
 ## Attributes
 To access the affine charts of a `CoveredScheme` $X$ use 
 ```@docs
-    affine_charts(X::AbsCoveredScheme)
+affine_charts(X::AbsCoveredScheme)
 ```
 Other attributes are the `base_ring` over which the scheme is defined and 
 ```@docs
-    default_covering(X::AbsCoveredScheme)
+default_covering(X::AbsCoveredScheme)
 ```
 
 ## Properties
 An `AbsCoveredScheme` may have different properties such as 
-```
-    is_empty(X::AbsCoveredScheme)
-    is_smooth(X::AbsCoveredScheme)
+```julia
+is_empty(X::AbsCoveredScheme)
+is_smooth(X::AbsCoveredScheme)
 ```
 
 ## Methods
 ```@docs
-    fiber_product(f::AbsCoveredSchemeMorphism, g::AbsCoveredSchemeMorphism)
+fiber_product(f::AbsCoveredSchemeMorphism, g::AbsCoveredSchemeMorphism)
 ```
 
 ## The modeling of covered schemes and their expected behavior 
@@ -56,7 +56,7 @@ several reasons; for instance, a morphism $f : X \to Y$ between `AbsCoveredSchem
 will in general only be given on affine patches on a refinement of the `default_covering` of `X`.
 The list of available `Covering`s can be obtained using 
 ```@docs
-    coverings(X::AbsCoveredScheme)
+coverings(X::AbsCoveredScheme)
 ```
 Every `AbsCoveredScheme` $X$ has to be modeled using one original `default_covering` $C$, simply 
 to gather the data necessary to fully describe $X$. The `affine_charts` of $X$ return the 

docs/src/AlgebraicGeometry/Schemes/CoveringsAndGluings.md

@@ -6,24 +6,24 @@ CurrentModule = Oscar
 
 `Covering`s are the backbone data structure for `CoveredScheme`s in Oscar. 
 ```@docs
-    Covering
+Covering
 ```
 
 ## Constructors
 ```@docs
-    Covering(patches::Vector{<:AbsAffineScheme})
-    disjoint_union(C1::Covering, C2::Covering)
+Covering(patches::Vector{<:AbsAffineScheme})
+disjoint_union(C1::Covering, C2::Covering)
 ```
 
 ## Attributes
 ```@docs
-    affine_charts(C::Covering)
-    gluings(C::Covering)
+affine_charts(C::Covering)
+gluings(C::Covering)
 ```
 
 ## Methods
 ```@docs
-    add_gluing!(C::Covering, G::AbsGluing)
+add_gluing!(C::Covering, G::AbsGluing)
 ```
 
 # Gluings
@@ -34,32 +34,32 @@ of affine schemes along an isomorphism $f \colon U \leftrightarrow V \colon g$.
 ## Types 
 The abstract type of any such gluing is 
 ```@docs
-    AbsGluing
+AbsGluing
 ```
 The available concrete types are 
 ```@docs
-    Gluing
-    SimpleGluing
+Gluing
+SimpleGluing
 ```
 
 ## Constructors
 ```@docs
-    Gluing(X::AbsAffineScheme, Y::AbsAffineScheme, f::SchemeMor, g::SchemeMor)
+Gluing(X::AbsAffineScheme, Y::AbsAffineScheme, f::SchemeMor, g::SchemeMor)
 ```
 
 ## Attributes
 ```@docs
-    patches(G::AbsGluing)
-    gluing_domains(G::AbsGluing)
-    gluing_morphisms(G::AbsGluing)
-    inverse(G::AbsGluing)
+patches(G::AbsGluing)
+gluing_domains(G::AbsGluing)
+gluing_morphisms(G::AbsGluing)
+inverse(G::AbsGluing)
 ```
 
 ## Methods
 ```@docs
-    compose(G::AbsGluing, H::AbsGluing)
-    maximal_extension(G::Gluing)
-    restrict(G::AbsGluing, f::AbsAffineSchemeMor, g::AbsAffineSchemeMor; check::Bool=true)
+compose(G::AbsGluing, H::AbsGluing)
+maximal_extension(G::Gluing)
+restrict(G::AbsGluing, f::AbsAffineSchemeMor, g::AbsAffineSchemeMor; check::Bool=true)
 ```