Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

2024-03-18 Thread Giacomo Pope
To make discussion on this point easier, I have made a GitHub 
issue: https://github.com/sagemath/sage/issues/37626

For progress on this code, we have all doctests passing from the old 
implementation except:

- we cannot define toric varieties over rings, so we can't have 
hyperelliptic curves over rings
- we cannot use the current rational_points method from algebraic_schemes 
due to missing methods in the homset of toric varieties

We are also working on pairings as well as isomorphisms on top of 
supporting all older features.

On Friday, March 15, 2024 at 6:47:02 PM UTC Giacomo Pope wrote:

> Back again with more class questions and general advice help
>
> While getting all the old sage code into this new project, I realised 
> there are places where we really rely on the underlying curve classes. One 
> example is that we need
>
> ```
> def dimension():
> return 1
> ```
>
> To avoid some crashes, but more generally we also need `rational_points()` 
> which lives all the way inside `Algebraic_scheme`. There's also a whole 
> bunch of other things...
>
> I started exploring more and I found `Curve_generic` which we can create 
> with the data I already have:
>
> ```
> sage: H = HyperellipticCurveSmoothModel(x^5 + x + 1)
> sage: C = Curve_generic(H._projective_model.ambient_space(), 
> H._projective_model.defining_polynomials())
> sage: type(C)
> 
> sage: C
> Generic Curve over Rational Field defined by -X^5*Z - X*Z^5 - Z^6 + Y^2
> sage: C.ambient_space()
> 2-d toric variety covered by 3 affine patches
> ```
>
> this gets us some of the way and I think is an OK starting point, but then 
> things like asking for the curve crash for weighted projective space:
>
> ```
> sage: Curve(H)
> ---
> TypeError Traceback (most recent call last)
> .
> TypeError: ambient space neither affine nor projective
> ```
>
> and calls to things like C.rational_points() have more issues
>
> ```
> sage: C.rational_points(bounds=2)
> ---
> KeyError  Traceback (most recent call last)
> .
> AttributeError: 'SchemeHomset_points_subscheme_toric_field_with_category' 
> object has no attribute 'points'
> ```
>
> Which just goes to show that these toric varieties are a little 
> underdeveloped.
>
> Something which might be really nice would be 
>
> ```
> class WeightedProjectiveCurve(Curve_generic, 
> AlgebraicScheme_subscheme_toric):
> ```
>
> Intended to mirror the similar:
>
> ```
> class ProjectiveCurve(Curve_generic, AlgebraicScheme_subscheme_projective):
> ```
>
> This could then be the class which is inherited by the Hyperelliptic curve 
> class and we could aim for better coverage here.
>
> Any opinions on this? Any idea of people who might have thought about or 
> made progress in this area?
>
> Otherwise, the project continues. Functions for finite fields are all 
> working, generic functions mostly and the padic functions are a WIP as we 
> need to adapt to the fact we have different points at infinity (and I dont 
> know how to properly handle the case when there's two (yet)).
>
> Finally, looking at the rational_points() method itself, this is something 
> people have at least considered:
>
> ```
> .. TODO::
>
> Implement Stoll's model in weighted projective space to
> resolve singularities and find two points (1 : 1 : 0) and
> (-1 : 1 : 0) at infinity.
> ```
>
>
> On Wednesday, March 13, 2024 at 6:23:38 PM UTC Giacomo Pope wrote:
>
>> Thanks so much for the context
>>
>> Oh interesting. In this case I wonder whether we should work on and 
>> include a new class (maybe something as simple as a WeightedProjectiveSpace 
>> and a curve from this) mirroring the implementation for the plane curves. 
>> Alternatively I could go into the old plane curve code and write these 
>> useful functions specifically for the hyperelliptic curves (and here even 
>> gain that these algorithms can be optimised). For example, I already had to 
>> include a `dimension()` method on the curve to properly compute the 
>> Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
>> inheritance
>>
>> On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:
>>
>>> One thing that may deserve a cursory check is the overhead involved in 
>>> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
>>> structures are optimized for prolonged use *after* creation and may do a 
>>> lot of caching/precomputation. There may be scenarios where one wants to 
>>> construct *lots* of hyperelliptic curves (for instance, when computing 
>>> reductions of hyperelliptic curves mod lots of primes). An expensive parent 
>>> may then add undue overhead. In that case it may be better to spin off the 
>>> functionality required into a "lightweight" structure that gets wrapped in 

[sage-devel] Re: Vote: Sage Code of Conduct

2024-03-18 Thread Dima Pasechnik
It's very important to note that with multiwinner approval voting, merely 
counting the votes per candidate and picking the top ones can lead to 
rather unfair results
(unlike in the single winner case).

For instance, if we elect k=3 candidates out of 6, say, $a,b,c,d,e,f$, and 
out of N=19 people, 10 vote for $a,b,c$, and 9 - for $d,e,f$, then, with 
approval voting, $a,b,c$ get elected (as $a,b,c$, get 10 votes each, more 
than $d,e,f$), and almost half the voters, 9 out of 10, get no 
representation of their views. 
This is obviously bad - in such a case a fair outcome would be something 
like $a,b,d$. Here "fair" has to be quantified, of course.
I've posted some details (and pointed at some solutions) on this here:
https://github.com/sagemath/sage/pull/37501#issuecomment-2004121053

It would be interesting to get the anonymised returned ballots and see if 
we did well on this occasion.
As well, adjustments ought to be made along the lines outlined above.

Dima

 
On Saturday, March 16, 2024 at 12:48:16 PM UTC kcrisman wrote:

> I also want to thank Vincent Delecroix, David Joyner, Harald Schilly, and 
> William Stein for their service on the committee up until this year.
>
>  
> Amen! 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ebc788db-79c3-4dc3-af55-23297d3c88c0n%40googlegroups.com.