Skip to content
This repository has been archived by the owner on Jul 1, 2022. It is now read-only.

Extended functionality and documentation #38

Merged

Conversation

HereAround
Copy link
Member

@HereAround HereAround commented Sep 5, 2021

Content of this PR:

  • Provide support for more GAP functions of the ToricVarieties_project, including Betti numbers.
  • Initiate documentation.

@lkastner @fingolfin : I am uncertain if I meet all Oscar standards with the documentation. I can produce the documentation locally (julia make.jl in the docs folder). What additional steps are needed to publish this documentation on github?

@lkastner Are you ok with the new wrapper functions?

@fingolfin I am uncertain what to make to the following Gap <-> Julia behaviour. On the one hand, execute th following in Julia:

using JToric
P2 = projective_space( 2 )
ith_betti_number( P2, 0 )
-2

The correct answer is 1, not -2.

The wrapper function ith_betti_number executes the corresponding gap function. If I directly execute this gap code, then I indeed obtain the correct answer 1 (after fixing a bug yesterday):

LoadPackage( "ToricVarieties" );
P2 := ProjectiveSpace( 2 );
ith_betti_number( P2, 0 );
1

So it looks as if the Gap return value 1 is turned into a -2 in Julia. Am I missing something? Suggestions?

[Aside: This is the reason why I am currently excluding the computation of the 0-th Betti numbers from the tests.]

@codecov
Copy link

codecov bot commented Sep 5, 2021

Codecov Report

Merging #38 (736a41b) into master (35ad1fe) will decrease coverage by 0.80%.
The diff coverage is 97.32%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #38      +/-   ##
==========================================
- Coverage   96.00%   95.19%   -0.81%     
==========================================
  Files           4        4              
  Lines         200      229      +29     
==========================================
+ Hits          192      218      +26     
- Misses          8       11       +3     
Impacted Files Coverage Δ
src/JToric.jl 72.72% <50.00%> (-27.28%) ⬇️
src/AttributesAndMethods.jl 100.00% <100.00%> (ø)
src/ToricDivisors.jl 100.00% <100.00%> (ø)
src/ToricVarieties.jl 85.45% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd84220...736a41b. Read the comment docs.

@fingolfin
Copy link
Member

For publishing: you'll need a step doing that in your GitHub Actions. This is described in the Documenter.jl documentation. For a practical example, see here for how GAP.jl does it -- you may or may not want to remove the part where it runs the doctests.

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

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

Minor off-topic remarks

function map_from_weil_divisors_to_class_group( v::NormalToricVariety )
gap_MapFromWeilDivisorsToClassGroup = GAP.Globals.MapFromWeilDivisorsToClassGroup( v.GapNTV )
return map_from_weil_divisors_to_class_group( gap_MapFromWeilDivisorsToClassGroup )
end
export map_from_weil_divisors_to_class_group


"""
dimension( v::NormalToricVariety )
Copy link
Member

Choose a reason for hiding this comment

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

everywhere else in Oscar, we are using dim right now.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok. I will change this to dim.

name_of_variety( v::NormalToricVariety )

Returns the name of the normal toric variety `v`, if set. Otherwise returns "No name set for this variety".
"""
function name_of_variety( v::NormalToricVariety )
if ! ( Bool( GAP.Globals.HasNameOfVariety( v.GapNTV ) ) )
Copy link
Member

Choose a reason for hiding this comment

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

There is no need for Bool here, you can just write if ! GAP.Globals.HasNameOfVariety(v.GapNTV)

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you for the pointer. I will change this.

@fingolfin
Copy link
Member

I'll look into the ith_betti_number weirdness.

@fingolfin
Copy link
Member

@HereAround I could not reproduce the "-2" at first because I get this error instead:

julia> ith_betti_number(P2, 0)
#I  The Julia package 'Polymake' cannot be loaded.
ERROR: Error thrown by GAP: Error, no method found! For debugging hints type ?Recovery from NoMethodFound
Error, no 2nd choice method found for `FacetInequalities' on 1 arguments at /Users/mhorn/.julia/artifacts/8f22bf2645df36936a8a74cea9de55d6070017ed/share/gap/lib/methsel2.g:249 called from
FacetInequalities( polytope ) at /Users/mhorn/.julia/gaproot/v4.12/pkg/NConvex/gap/Polytope.gi:789 called from
NormalFan( PolytopeOfVariety( variety ) ) at /Users/mhorn/.julia/packages/CapAndHomalg/PE2rB/pkg/ToricVarieties_project/ToricVarieties/gap/ProjectiveToricVarieties.gi:88 called from
FanOfVariety( variety ) at /Users/mhorn/.julia/packages/CapAndHomalg/PE2rB/pkg/ToricVarieties_project/ToricVarieties/gap/ToricVarieties.gi:1026 called from
<function "ithBettiNumber for toric varieties">( <arguments> )
 called from read-eval loop at *defin*:0

Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:33
 [2] ThrowObserver(depth::Int32)
   @ GAP ~/.julia/packages/GAP/9XZl9/src/GAP.jl:63
 [3] _call_gap_func(func::GAP.GapObj, a1::GAP.GapObj, a2::Int64)
   @ GAP ~/.julia/packages/GAP/9XZl9/src/ccalls.jl:268
 [4] call_gap_func_nokw
   @ ~/.julia/packages/GAP/9XZl9/src/ccalls.jl:222 [inlined]
 [5] (::GAP.GapObj)(a1::GAP.GapObj, a2::Int64)
   @ GAP ~/.julia/packages/GAP/9XZl9/src/ccalls.jl:233
 [6] ith_betti_number(v::NormalToricVariety, i::Int64)
   @ JToric ~/Projekte/OSCAR/JToric/src/AttributesAndMethods.jl:583
 [7] top-level scope
   @ REPL[12]:1

I think this is caused by JConvex doing JuliaImportPackage("Polymake") -- but in the Julia project I have, there is only one top-level package (JToric), so this doesn't work, even though I have Polymake.jl installed.

This could be addressed in various ways; e.g. JToric could, in its __init__ function, do something like GAP.Globals.__Polymake_jl = Polymake and then JToric could look at the Julia module object... see also oscar-system/GAP.jl#687

@fingolfin
Copy link
Member

Indeed, with Polymake.jl loaded, I can also reproduce this from the GAP prompt, so I would suggest taking a look at the code in JConvex:

julia> JToric.GAP.prompt()
gap> LoadPackage( "ToricVarieties" ); # of course it was already loaded by JToric
true
gap> P2 := ProjectiveSpace( 2 );
<A projective toric variety of dimension 2>
gap> ithBettiNumber(P2, 0);
-2

@fingolfin
Copy link
Member

Just to illustrate how I think one can avoid using JuliaImportPackage, consider this (executed in Julia session after I did using JToric, Polymake)

julia> Polymake.version()
v"4.4.0"

julia> JToric.GAP.Globals.pm = Polymake
Polymake

julia> JToric.GAP.prompt()
gap> pm.version();
<Julia: v"4.4.0">

@HereAround
Copy link
Member Author

Ok. It seems we have multiple issues here.

  1. Properly call/import Polymake in JToric. If I understand correctly, then you propose to extend the __init__ of JToric by JToric.GAP.Globals.pm = Polymake and then making the calls to Polymake via pm.prefered_function? I understand you correctly?
  2. The ith_betti_number. Good point! Indeed
julia> using JToric;
julia> P2 = projective_space( 2 );
julia> GAP.Globals.FVector( GAP.Globals.FanOfVariety( P2.GapNTV ) )
GAP: [ 3, 0 ]

This should be the number of 1 and 2-dimensional cones, i.e. should be [3,3]. I will investigate.

@fingolfin
Copy link
Member

Yes regarding point 1. -- except that pm was just an example, it might be better to call it something like __Polymake or __PolymakeFromJulia or so or POLYMAKE_JULIA_MODULE or whatever, just to avoid clashes with user objects.

@fingolfin
Copy link
Member

Another thing: I noticed that in JConvex, you use JuliaEvalString a lot. That's inefficient and should almost never be necessary. It also leads to hard to debug code.

For example, if one defined pm as above, then this works just fine in GAP: pm.polytope.Polytope()

However, it also seems as if your function Polymake_V_Rep_command_string constantly creates new Polymake objects? Is there a reason why you don't just create one of these once, and keep it around? Or am I misunderstanding the code?

@@ -90,6 +150,11 @@ end
export is_very_ample


"""
is_numerically_effective( d::toric_divisor )
Copy link
Member

Choose a reason for hiding this comment

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

Is it not common to abbreviate this to nef these days?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thx. Just changed it.


"""
dimension_of_torusfactor( v::NormalToricVariety )
Copy link
Member

Choose a reason for hiding this comment

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

Should we change this to dim_of_torusfactor analogously then?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that is a good point. Changed as well.

@HereAround
Copy link
Member Author

@fingolfin :

Thank you for suggesting these improvements! To handle them efficiently, I have opened the following issues:

I will try to close them soonish.

… -> zariskiCotangentSheafViaPoincareResidueMap
@HereAround
Copy link
Member Author

@fingolfin I have reformatted all structs into camelCase. Also, I reverted the commit regarding GAP.Globals.POLYMAKE_JULIA_MODULE that you commented on above.

With these changes - are you ready to approve this PR?

######################
# 1: The Julia type for ToricDivisors
######################

struct toric_divisor
struct toricDivisor
Copy link
Member

Choose a reason for hiding this comment

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

So, I am realllly sorry for all the churn and work I cause you... but really the convention in Julia is to use CamelCase for structs, not camelCase...

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh... This one is on me. You wrote CamelCase above - I should have read carefully. Hence, no worries!

Since this PR is already terribly long (and you just approved), I opened a new issue: #44.

This one should be closed with the adjustment to CamelCase soon.

src/ToricVarieties.jl Outdated Show resolved Hide resolved
Checks if the normal toric variety `v` is projective, i.e. if the fan of `v` is the the normal fan of a polytope.

# Examples
```julia-repl
Copy link
Member

Choose a reason for hiding this comment

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

You could also use jldoctest, then these examples would also be run as part of the doctest step of the CI (provided that is set up), which has the advantage that the examples are tested, so one knows they actually are working and correct. But of course sometimes this is not desirable, e.g. if outputs are random or differ between Julia versions. Seems to be safe here, though?

Anyway, not important right now, but perhaps you'll want to change this down the road, so I thought I should mention it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you for the suggestion. Sounds like a valuable addition!

For the time being (and in repeating the above strategy), I placed this in a separated issue: #46.

Co-authored-by: Max Horn <max@quendi.de>
@HereAround HereAround merged commit 4de97a8 into oscar-system:master Sep 23, 2021
@HereAround HereAround deleted the ExtendedFunctionalityAndDocumentation branch September 23, 2021 22:02
@HereAround HereAround mentioned this pull request Sep 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants