Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

+1 On Wed, 20 Feb 2019 11:14 Vincent Klein, wrote: > In ticket #23024 we made pplpy and independant package with gmpy2 as > return types. > > As opinion for having pplpy returning Sage's type has also been expressed, > the goal of this message is to check > if we globally agree to pass pplpy and

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

In ticket #23024 we made pplpy and independant package with gmpy2 as return types. As opinion for having pplpy returning Sage's type has also been expressed, the goal of this message is to check if we globally agree to pass pplpy and gmpy2 as standard packages. Vincent K. -- You received thi

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Fri, Mar 9, 2018 at 3:40 PM, jplab wrote: > Hi all, > > Allow me to jump in the discussion as a daily "Sage user" of code using the > ppl backend in the Polyhedron class. > I put the "Sage user" in quotes, because it seems that it was used for > different types of users. > > What's in for the n

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

Hi all, Allow me to jump in the discussion as a daily "Sage user" of code using the ppl backend in the Polyhedron class. I put the "Sage user" in quotes, because it seems that it was used for different types of users. What's in for the normal strictly routine not-developing user? Well, IMHO m

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On 07/02/2018 12:17, Volker Braun wrote: On Wednesday, February 7, 2018 at 10:31:43 AM UTC+1, Jeroen Demeyer wrote: But what is the "desired implementation"? Again, surely its "Sage integers" for users of Sage. Anything else is just dumping a giant turd on your users just because its the laz

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Wednesday, February 7, 2018 at 10:31:43 AM UTC+1, Jeroen Demeyer wrote: > > But what is the "desired implementation"? > Again, surely its "Sage integers" for users of Sage. Anything else is just dumping a giant turd on your users just because its the lazy thing to do. There are surely ways

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

Le mercredi 7 février 2018 09:49:29 UTC+1, vdelecroix a écrit : > > The gmpy2 way is not ideal (one more integer/rational/floating point > type) but it is > - convenient and error safe with respect to the points mentioned above > - has a working implementation > And a logical design cho

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On 2018-02-07 00:35, Volker Braun wrote: But implementation details can surely be worked out. A totally basic idea: put the specifics of the integer type and integer wrap/unwrapping in an cython include file. At build time, copy the include file with the desired implementation. But what is the

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Wednesday, February 7, 2018 at 9:49:29 AM UTC+1, vdelecroix wrote: > > what if library A needs library B with return type "X" > but the user wants it with return type "Y" So we solve the problem by making it impossible for the user to get the return type he wants (namely Sage intergers by yo

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On 07/02/2018 00:35, Volker Braun wrote: But implementation details can surely be worked out. A totally basic idea: put the specifics of the integer type and integer wrap/unwrapping in an cython include file. At build time, copy the include file with the desired implementation. I agree with Vol

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

But implementation details can surely be worked out. A totally basic idea: put the specifics of the integer type and integer wrap/unwrapping in an cython include file. At build time, copy the include file with the desired implementation. -- You received this message because you are subscribed

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On 2018-02-05 22:47, Volker Braun wrote: A better implementation would be to make the integer implementation(s) a build-time option; pplpy could internally use a fused type for all available implementations. I think that's a lot easier said than done. Also, a Python class cannot really contain

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Tuesday, February 6, 2018 at 2:25:58 PM UTC+1, Erik Bray wrote: > > "What's in it for Sage users?" -- Eventually, anyways, being able to > drop code from Sage in favor of other, better-supported code that > provides the same thing, so that Sage developers can work on other > things. > Well

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Mon, Feb 5, 2018 at 10:47 PM, Volker Braun wrote: > On Monday, February 5, 2018 at 8:14:12 PM UTC+1, vdelecroix wrote: >> >> And without having gmpy2 it is hard to set pplpy a standalone >> package. > > > > Obviously thats the only real argument here; The question is, whats in it > for Sage use

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Monday, February 5, 2018 at 11:58:27 PM UTC+1, vdelecroix wrote: > > How complicated? It would help with another example that is not about > factoring 10. Its a simplified example but not all that synthetic; The output of integral polyhedral computations is often about counting something, a

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On 05/02/2018 22:47, Volker Braun wrote: On Monday, February 5, 2018 at 8:14:12 PM UTC+1, vdelecroix wrote: And without having gmpy2 it is hard to set pplpy a standalone package. Obviously thats the only real argument here; The question is, whats in it for Sage users? None of your arguments

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Monday, February 5, 2018 at 8:14:12 PM UTC+1, vdelecroix wrote: > > And without having gmpy2 it is hard to set pplpy a standalone > package. Obviously thats the only real argument here; The question is, whats in it for Sage users? None of your arguments are particularly convincing. And

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On Monday, February 5, 2018 at 7:14:12 PM UTC, vdelecroix wrote: > > On 05/02/2018 15:33, Volker Braun wrote: > > Isn't having yet another integer type in Sage a huge liability without > > advantage? Anybody care to explain why we'd want two different gmp/mpir > > wrappers in Sage? Also, confu

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On 05/02/2018 15:33, Volker Braun wrote: Isn't having yet another integer type in Sage a huge liability without advantage? Anybody care to explain why we'd want two different gmp/mpir wrappers in Sage? Also, confusion factor for users... - because gmpy2 is de facto a Python standard (used in mp

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

Isn't having yet another integer type in Sage a huge liability without advantage? Anybody care to explain why we'd want two different gmp/mpir wrappers in Sage? Also, confusion factor for users... This introduces various breaking changes, for example right now I can do sage: from sage.libs.ppl

Re: [sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

On 2018-02-05 09:11, Vincent Klein wrote: This require to have pplpy as a standard package. As pplpy use gmpy2 the latter should be stantard too. Do we agree to do this ? Fine for me. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscr

[sage-devel] Proposal : Add pplpy and gmpy2 as standard packages.

Hi! As stated in sage ticket #23024 we propose to replace `sage.libs.ppl` by the standalone pplpy . This require to have pplpy as a standard package. As pplpy use gmpy2 the latter should be stantard too. Do we agree to