On Friday, June 8, 2018 at 9:56:56 AM UTC-7, vdelecroix wrote:
>
>
> 2) Laurent polynomials should conform to the rule (R0) and a / b
> should always be a rational fraction
>
> +1 to this. That seems to be the only consistent choice. There is a bit of
an issue, with the partial "division" operat
What Vincent has neglected to mention is the reasoning why I am suggesting
to keep the current behavior for Laurent polynomials. A casual user will
almost certainly do
1 / x^k
and then try to do a method on Laurent polynomials (say, iterate over such
element). The rational functions code does
On Friday, June 8, 2018 at 10:25:10 AM UTC-7, Jeroen Demeyer wrote:
>
> I vote for
>
> > 2) Laurent polynomials should conform to the rule (R0) and a / b
> > should always be a rational fraction
>
> by analogy with other parents, in particular polynomials.
>
Not to mention integers! While I
Yeah, I actually agree with that now after looking at it.
On Thursday, 7 June 2018 09:30:04 UTC+2, Vincent Klein wrote:
>
>
>> On side note: Is there any problem with alphabetical order if the whole
>> list is there?
>>
>>
> Yes in my opinion. The animation takes 180 sec to display the whole list
Use libgap:
sage: def SGS_libgap(G, gap_output=True):
: S = libgap(G).StabChain()
: libgap.eval(gap_cosets)
: cosets = S.CosetsStabChain()
: if gap_output:
: return cosets
:
sage: %time XX = SGS_libgap(A,True)
CPU times: user 31.7 ms, sys: 59 ยต
On Saturday, June 9, 2018 at 2:53:56 AM UTC+9, John H Palmieri wrote:
>
>
> On Friday, June 8, 2018 at 7:59:39 AM UTC-7, Marc Mezzarobba wrote:
>>
>>
>> Personally, I'd vote for keeping ceil(), and not adding any alias.
>>
>
> I agree with this. Another philosophy (at which Sage should do a be
On 2018-06-08, John Cremona wrote:
> On 8 June 2018 at 10:25, Jeroen Demeyer wrote:
>
>> I vote for
>>
>> 2) Laurent polynomials should conform to the rule (R0) and a / b
>>> should always be a rational fraction
>>>
>>
>> by analogy with other parents, in particular polynomials.
>
>
> +1
+1, too
See
also
http://doc.sagemath.org/html/en/developer/packaging.html#how-to-maintain-a-set-of-patches
On Friday, June 8, 2018 at 4:05:47 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Friday, June 8, 2018 at 9:25:33 AM UTC+1, Jeroen Demeyer wrote:
>>
>> On 2018-06-08 07:47, Ralf Stephan wrote:
>> > It
On Friday, June 8, 2018 at 7:59:39 AM UTC-7, Marc Mezzarobba wrote:
>
>
> Personally, I'd vote for keeping ceil(), and not adding any alias.
>
I agree with this. Another philosophy (at which Sage should do a better
job) is to not have too much in the global namespace. Because of Python, we
ha
On 8 June 2018 at 10:25, Jeroen Demeyer wrote:
> I vote for
>
> 2) Laurent polynomials should conform to the rule (R0) and a / b
>> should always be a rational fraction
>>
>
> by analogy with other parents, in particular polynomials.
+1
>
>
> --
> You received this message because you are sub
I vote for
2) Laurent polynomials should conform to the rule (R0) and a / b
should always be a rational fraction
by analogy with other parents, in particular polynomials.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
Dear all,
I am cleaning the Laurent polynomial in Sage in ticket #25524
(https://trac.sagemath.org/ticket/25524). One issue concerns
the following behaviour
{{{
sage: L. = LaurentPolynomialRing(ZZ)
sage: parent(L(q) / L(1))
Univariate Laurent Polynomial Ring in q over Integer Ring
sage: parent(L
John Cremona wrote:
> I hope it is not being suggested that we have to add tangent() as an
> alias to tan(), logoarithm() as an alias to log(), etc etc etc
I made the comparison with acos() because ceil() clearly is the usual
notation for me (I didn't know of any language or library calling it
c
I hope it is not being suggested that we have to add tangent() as an alias
to tan(), logoarithm() as an alias to log(), etc etc etc !
On 8 June 2018 at 05:47, Marc Mezzarobba wrote:
> Kwankyu Lee wrote:
> > I guess, one principle in Sage is to use the full name unless an
> > abbreviated form is
Kwankyu Lee wrote:
> I guess, one principle in Sage is to use the full name unless an
> abbreviated form is already firmly rooted in our culture
I consider ceil() about as standard as, say, acos()...
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-de
>
> Yes and no. I would rather keep ceil to be the default and ceiling to
> be an alias. It is more complient with mathematical libraries,
> programming languages, etc.
>
In a sense, I like the philosophy of Mathematica, where Ceiling[x] is
standard. I thought Sage shares the same philosophy.
On 08/06/2018 13:57, Kwankyu Lee wrote:
On Friday, June 8, 2018 at 8:50:48 PM UTC+9, vdelecroix wrote:
On 08/06/2018 08:21, Dima Pasechnik wrote:
ceil() is a standard Python function.
Thus, Sagemath has to live with it.
Not only Python. It is C standard function
from math.h. Also GMP, MPFR
On Friday, June 8, 2018 at 8:50:48 PM UTC+9, vdelecroix wrote:
>
> On 08/06/2018 08:21, Dima Pasechnik wrote:
> > ceil() is a standard Python function.
> > Thus, Sagemath has to live with it.
>
> Not only Python. It is C standard function
> from math.h. Also GMP, MPFR, etc does use ceil and
On 08/06/2018 08:21, Dima Pasechnik wrote:
ceil() is a standard Python function.
Thus, Sagemath has to live with it.
Not only Python. It is C standard function
from math.h. Also GMP, MPFR, etc does use ceil and
not ceiling.
Vincent
--
You received this message because you are subscribed to th
On Friday, June 8, 2018 at 9:25:33 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2018-06-08 07:47, Ralf Stephan wrote:
> > It might be an idea to semi-automatize this, i.e., build a tool that
> > takes a Sage version and creates forks of some packages A,B on github
> > under sage/sage-A, sage/sage-B.
On Friday, June 8, 2018 at 10:25:33 AM UTC+2, Jeroen Demeyer wrote:
>
> On 2018-06-08 07:47, Ralf Stephan wrote:
> > It might be an idea to semi-automatize this, i.e., build a tool that
> > takes a Sage version and creates forks of some packages A,B on github
> > under sage/sage-A, sage/sage-B.
On Friday, June 8, 2018 at 6:23:51 PM UTC+9, Samuel Lelievre wrote:
>
>
>
> Fri 2018-06-08 06:21:45 UTC, Dima Pasechnik:
> >
> > ceil() is a standard Python function.
> > Thus, Sagemath has to live with it.
>
> If we look at object methods rather than functions
> in the global namespace, it is al
Fri 2018-06-08 06:21:45 UTC, Dima Pasechnik:
>
> ceil() is a standard Python function.
> Thus, Sagemath has to live with it.
If we look at object methods rather than functions
in the global namespace, it is already the case that
both ceil and ceiling are available, with one of them
an alias to t
On 2018-06-08 07:47, Ralf Stephan wrote:
It might be an idea to semi-automatize this, i.e., build a tool that
takes a Sage version and creates forks of some packages A,B on github
under sage/sage-A, sage/sage-B.
Which problem would that solve?
--
You received this message because you are subsc
24 matches
Mail list logo
