Thanks for the feedback everyone.
Am Donnerstag, 22. November 2018 09:53:43 UTC+1 schrieb parisse:
>
> Did you make some comparisons with Giac ?
>
> Some benchmarks from Roman Pearce and my own tests, about 2 years old.
>
I have not done any comparisons, mainly because I cannot do anything about
On 2018-11-23 20:49, Simon King wrote:
> Hi Daniel,
>
> On 2018-11-23, Daniel Krenn wrote:
>> Singular is shipped with symodstd.lib (it contains an algorithm for
>> computing a Groebner basis in a special case).
>> How can I access it from within Sage?
>>
>> I looked up the code and coming from a
On 2018-11-23 21:18, 'Martin R. Albrecht' via sage-devel wrote:
> Indeed, this should work:
>
> _ = sage.libs.singular.function.lib("symodstd.lib")
> syModStd = sage.libs.singular.function.singular_function("syModStd")
Oh, this is easy. Thanks :)
--
You received this message because you are sub
Indeed, this should work:
_ = sage.libs.singular.function.lib("symodstd.lib")
syModStd = sage.libs.singular.function.singular_function("syModStd")
Simon King writes:
> Hi Daniel,
>
> On 2018-11-23, Daniel Krenn wrote:
>> Singular is shipped with symodstd.lib (it contains an algorithm for
>> co
Hi Daniel,
On 2018-11-23, Daniel Krenn wrote:
> Singular is shipped with symodstd.lib (it contains an algorithm for
> computing a Groebner basis in a special case).
> How can I access it from within Sage?
>
> I looked up the code and coming from an ideal's groebner_basis method,
> it is somehow c
Singular is shipped with symodstd.lib (it contains an algorithm for
computing a Groebner basis in a special case).
How can I access it from within Sage?
I looked up the code and coming from an ideal's groebner_basis method,
it is somehow clear how to extend this, but how do I make the actual
call
> In such a setup, doctest framework will need to keep a record of the
particular order, and output it for each failure. otherwise things are not
reproducible...
I think that this would be great, but at least in the cases I looked at,
the reason is that the reason for failure is different order
There is now a ticket (#26741) ready for review in which the changes have
been implemented. I decided not to refactor __call__ because the number of
failing doctest was quite big. Maybe this is a project for a separate ticket.
I have no idea on how to test reliably if the changes introduced any
In such a setup, doctest framework will need to keep a record of the
particular order, and output it for each failure. otherwise things are not
reproducible...
On Fri, 23 Nov 2018 15:23 Simon King Hi Jeroen,
>
> On 2018-11-23, Jeroen Demeyer wrote:
> > On 2018-11-22 18:45, 'Martin R' via sage-de
Hi Jeroen,
On 2018-11-23, Jeroen Demeyer wrote:
> On 2018-11-22 18:45, 'Martin R' via sage-devel wrote:
>> 1) would it be easy and desirable to make the patchbots run tests in
>> random order?
>
> Easy: yes
> Desirable: no, it would create a lot of doctest failures
... whose fixing is likely to
There are, in 21 different files, 31 @rename_keyword statements without a
trac number.
Could we fix them, and if so, is it possible to always require the ticket
number, i.e. deprecation-parameter?
--
Jori Mäntysalo
parisse writes:
> Le jeudi 22 novembre 2018 10:11:39 UTC+1, Thierry (sage-googlesucks@xxx) a
> écrit :
>>
>> Hi,
>>
>>
>> It was on my todo list for a while too, since our implementations are very
>> slow. Here "very" means "prohibitively", since some systems can not be
>> solved with Sage
On 2018-11-22 18:45, 'Martin R' via sage-devel wrote:
1) would it be easy and desirable to make the patchbots run tests in
random order?
Easy: yes
Desirable: no, it would create a lot of doctest failures
2) concerning https://trac.sagemath.org/ticket/26586, is it desirable to
define compariso
On 2018-11-22 18:45, 'Martin R' via sage-devel wrote:
* The tests of individual functions within a single file are ALL
executed in the same environment.
Same "environment" in the sense of same Python process (there is one
process for each file to be tested). But global variables are rese
14 matches
Mail list logo
