Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ToricVarieties: Support for immaculate line bundles #2080

Merged
merged 4 commits into from
Oct 9, 2023

Conversation

HereAround
Copy link
Member

No description provided.

@HereAround HereAround marked this pull request as draft March 17, 2023 17:49
@HereAround HereAround force-pushed the immaculate branch 2 times, most recently from 563e167 to d1c9b80 Compare March 17, 2023 19:18
@HereAround HereAround marked this pull request as ready for review March 17, 2023 22:14
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.

Looks good to me from a purely technical POV (I can't comment on the mathematical content).

Thanks!

function cohomology_index(tvs::ToricVanishingSet)
return tvs.i::Int
function cohomology_indices(tvs::ToricVanishingSet)
return tvs.cis::Vector{T} where {T <: IntegerUnion}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is the abreviation 'cis' really standard or should we better use a longer/clearer form? (Keeping in mind that not only toric geometers are using Oscar).
I agree, however, that 'cis' is ok as a shorthand for internal use only, if it is well hidden behind a getter function.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is a purely internal variable, which is never revealed to a user. It is (my) abbreviation for cohomology_indices. When writing this out, the code becomes clunky and hard to read.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Then I am fine with 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.

Copy link
Collaborator

@afkafkafk13 afkafkafk13 left a comment

Choose a reason for hiding this comment

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

Looks good to me, but we should wait for @lkastner to approve it.

@HereAround
Copy link
Member Author

Thank you @benlorenz !

@thofma
Copy link
Collaborator

thofma commented Mar 20, 2023

Could the field

cis::Vector{T} where {T <: IntegerUnion}

be just

cis::Vector{ZZRingElem}

with the appropriate conversion when initializing? This would be a bit cleaner and friendlier for the compiler, but maybe there is a performance reason to store it as Int if possible?

@HereAround
Copy link
Member Author

HereAround commented Mar 20, 2023

Could the field

cis::Vector{T} where {T <: IntegerUnion}

be just

cis::Vector{ZZRingElem}

with the appropriate conversion when initializing? This would be a bit cleaner and friendlier for the compiler, but maybe there is a performance reason to store it as Int if possible?

You are right. This indeed looks cleaner. Thank you for the pointer.

As far as I can tell, there is no performance reason to store this as Int.

At least within the toric varieties, IntegerUnion is used frequently. Would you suggest that we change all of them to ZZRingElem?

@thofma
Copy link
Collaborator

thofma commented Mar 20, 2023

I think we allow IntegerUnion at many places for the convenience of the user and the programmer (for example, in your case when constructing the object), but internally, this will often be stored just as a ZZRingElem.

@HereAround
Copy link
Member Author

I think we allow IntegerUnion at many places for the convenience of the user and the programmer (for example, in your case when constructing the object), but internally, this will often be stored just as a ZZRingElem.

Ok. That makes sense.

Hopefully not too far into the future, I shall have the time to take a look at all of the toric varieties and check if and where we could replace IntegerUnion by ZZRingElem. For that reason, I opened a corresponding issue: #2086

@lkastner
Copy link
Member

I don't really understand what is going on but that might be due to covid. I see that IntegerUnion makes sense in the places it currently exists for the toric varieties. But for the cohomology indices I thought this is like an index in some chain complex. Is that wrong? Do we really expect to perform so well here that we leave the realm of just Int? Until reading this discussion to me these indices were something completely different than say the coefficients of a divisor. And I still think that we don't have to be consistent in all places, i.e. we don't have to use IntegerUnion or fmpz or whichever everywhere. It should be angemessen.

@HereAround
Copy link
Member Author

I don't really understand what is going on but that might be due to covid. I see that IntegerUnion makes sense in the places it currently exists for the toric varieties. But for the cohomology indices I thought this is like an index in some chain complex. Is that wrong? Do we really expect to perform so well here that we leave the realm of just Int? Until reading this discussion to me these indices were something completely different than say the coefficients of a divisor. And I still think that we don't have to be consistent in all places, i.e. we don't have to use IntegerUnion or fmpz or whichever everywhere. It should be angemessen.

I simply did not think long about Int vs. IntegerUnion vs fmpz/did not think it matter that much to people/for performance. But it appears that I was too naive...

My last rebase turned the cohomology indices into type Int.

@HereAround HereAround marked this pull request as draft March 21, 2023 10:30
@HereAround
Copy link
Member Author

HereAround commented Mar 21, 2023

@lkastner and I are discussing more on this in slack, as there exists similar (if not identical) functionality in Polymake. Hence, back to draft until we have evaluated the situation.

@fingolfin
Copy link
Member

What's the status of this PR?

@HereAround
Copy link
Member Author

There is functionality in Polymake that can compute immaculate bundles on toric spaces with different technology/algorithms. When @lkastner and I last discussed this matter, we agreed that it would be cool to support both variants/approaches. As such, it was agreed that @lkastner would adjust the corresponding Polymake functionality and report back once it is ready.

@fingolfin
Copy link
Member

@lkastner do you have any estimate when you might have time to get back to this?

Maybe a better (as in: less stressful for you, and overall saving time) approach would be to get this PR ready as-is, with one implementation; and then we can add the second Polymake based implementation whenever @lkastner has time for it?

@HereAround HereAround marked this pull request as ready for review October 9, 2023 12:38
@HereAround
Copy link
Member Author

As suggested by @fingolfin, it might be less stressful for @lkastner, if we merge this PR and eventually (whenever this may be) extend it with the corresponding Polymake functionality. Consequently, I have just rebased this PR.

Comment on lines 77 to 75
function cohomology_indices(tvs::ToricVanishingSet)
return tvs.cis
end
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
function cohomology_indices(tvs::ToricVanishingSet)
return tvs.cis
end
cohomology_indices(tvs::ToricVanishingSet) = tvs.cis

Co-authored-by: Max Horn <max@quendi.de>
@HereAround HereAround merged commit 51336ad into oscar-system:master Oct 9, 2023
9 of 12 checks passed
@HereAround HereAround deleted the immaculate branch October 9, 2023 19:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants