-
Notifications
You must be signed in to change notification settings - Fork 2
Extended functionality and documentation #38
Extended functionality and documentation #38
Conversation
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
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. |
There was a problem hiding this 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
src/AttributesAndMethods.jl
Outdated
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 ) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
src/AttributesAndMethods.jl
Outdated
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 ) ) ) |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
I'll look into the |
@HereAround I could not reproduce the "-2" at first because I get this error instead:
I think this is caused by This could be addressed in various ways; e.g. |
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
|
Just to illustrate how I think one can avoid using
|
Ok. It seems we have multiple issues here.
This should be the number of 1 and 2-dimensional cones, i.e. should be |
Yes regarding point 1. -- except that |
Another thing: I noticed that in For example, if one defined However, it also seems as if your function |
src/ToricDivisors.jl
Outdated
@@ -90,6 +150,11 @@ end | |||
export is_very_ample | |||
|
|||
|
|||
""" | |||
is_numerically_effective( d::toric_divisor ) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx. Just changed it.
src/AttributesAndMethods.jl
Outdated
|
||
""" | ||
dimension_of_torusfactor( v::NormalToricVariety ) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
ab4e741
to
c710af8
Compare
Thank you for suggesting these improvements! To handle them efficiently, I have opened the following issues:
I will try to close them soonish. |
…omCharacterToPrincipalDivisor
…lDivisorsToClassGroup
…TorusInvariantDivisorGroup
…riskiCotangentSheafViaEulerSequence
… -> zariskiCotangentSheafViaPoincareResidueMap
This reverts commit 786d85f.
@fingolfin I have reformatted all structs into camelCase. Also, I reverted the commit regarding With these changes - are you ready to approve this PR? |
###################### | ||
# 1: The Julia type for ToricDivisors | ||
###################### | ||
|
||
struct toric_divisor | ||
struct toricDivisor |
There was a problem hiding this comment.
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
...
There was a problem hiding this comment.
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.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>
Content of this PR:
@lkastner @fingolfin : I am uncertain if I meet all
Oscar standards
with the documentation. I can produce the documentation locally (julia make.jl
in thedocs
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:The correct answer is 1, not -2.
The wrapper function
ith_betti_number
executes the correspondinggap
function. If I directly execute thisgap
code, then I indeed obtain the correct answer 1 (after fixing a bug yesterday):So it looks as if the
Gap
return value 1 is turned into a -2 inJulia
. 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.]