[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

[Jakob Kroeker]

I asked in the Singular forum, how to change the exponent size for Singular:

https://www.singular.uni-kl.de/forum/viewtopic.php?f=10=2576

Is it transparent for overflow detection?
>

I don't understand the question.

My question is, does overflow detection work correcly with different 
exponent sizes than 16 bit?


Am Montag, 13. Februar 2017 21:40:03 UTC+1 schrieb Bill Hart:
>
> I can only answer one of your questions.
>
> On Saturday, 11 February 2017 17:16:29 UTC+1, Jakob Kroeker wrote:
>>
>> By default, Singular uses 16 bit exponents. But it is perfectly capable 
>>> of working with exponents up to 64 bits. That will be slower of course.
>>>
>>
>> How to change this? Is it runtime or compile-time?
>>
>
> I believe it can be set at runtime. Hans surely knows how to change it.
>  
>
>> Is it transparent for overflow detection?
>>
>
> I don't understand the question.
>  
>
>>
>> I guess it isn't easy for Sage to change the relevant ring upon overflow 
>>> to one using 64 bit exponents.
>>>
>>
>> I have no idea;
>>
>> Jakob
>>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: imaginary unit I is smaller than 1

[Jakob Kroeker]

In my opinion not this only particular case but the current bool() design 
in sage is a tremendous failure.
This was already discussed on sage-devel several times. 

Here is one of that threads:
https://groups.google.com/d/msg/sage-devel/vNxnHSeRBW4/UkaBOPGYT0QJ

Jakob

Am Sonntag, 19. Februar 2017 12:56:49 UTC+1 schrieb Daniel Krenn:
>
> Dear all, 
>
> I am surprised by 
>   sage: bool(I < 1) 
>   True 
>
> Best Daniel 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Timeouts on patchbots

[Jakob Kroeker]

>
> It is my subjective observation that timeouts on patchbots have become 
> more 
> frequent. For instance, for ticket 
> https://patchbot.sagemath.org/ticket/22340/ 
> two patchbots failed due to timeout, 
>


If I recall correctly, I did hit similar issues when testing sage.
Parallelism or any additional running processes during testing  may have 
negative impact on timings.
(e.g memory cache is shared between several applications) . 


As far as I know for testing the default is to use 3 parallel threads,
see 

https://wiki.sagemath.org/buildbot

Set it to 1 and see if the problem remains, run only one patchbot.
Please report your findings.

I know about the recommendation to avoid high system load; but this is 
> somewhat 
> hard to control. 
>

The best test environment is a separate computer for running patchbot and 
nothing else.


Jakob



Am Montag, 13. Februar 2017 12:33:14 UTC+1 schrieb Clemens Heuberger:
>
> It is my subjective observation that timeouts on patchbots have become 
> more 
> frequent. For instance, for ticket 
> https://patchbot.sagemath.org/ticket/22340/ 
> two patchbots failed due to timeout, 
>
> quasar times out with 
>
> sage: ls = J0(46)._calculate_endomorphism_generators() ; ls ## line 213 ## 
>
> ** 
> -- 
> sage -t --long src/sage/modular/abvar/abvar_ambient_jacobian.py  # Timed 
> out 
>
> whereas pbua times out with 
>
> sage: maxima._batch('10003;',batchload=False) ## line 869 ## 
>
> ** 
> -- 
> sage -t --long --warn-long 255.7 src/sage/interfaces/maxima.py  # Timed 
> out 
>
> Do we have any idea how this can happen at all? (Naively, one would 
> believe that 
> either the test works or it does not, I do not understand this quite 
> random 
> behaviour here). 
>
> I know about the recommendation to avoid high system load; but this is 
> somewhat 
> hard to control. On "my" two patchbots, I restrict myself to one or two 
> processes although sometimes I could volunteer more CPU time, but then, 
> timeouts 
> get more likely. 
>
> Can we do anything about that? Usefullness of patchbots is somewhat 
> limited with 
> that many false positives. 
>
> Regards, 
>
> Clemens 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

[Jakob Kroeker]

>
> By default, Singular uses 16 bit exponents. But it is perfectly capable of 
> working with exponents up to 64 bits. That will be slower of course.
>

How to change this? Is it runtime or compile-time? Is it transparent for 
overflow detection?

I guess it isn't easy for Sage to change the relevant ring upon overflow to 
> one using 64 bit exponents.
>

I have no idea;

Jakob

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

[Jakob Kroeker]

>If someone who knows what they are talking about [...]

to give a precise answer to the question on 
https://ask.sagemath.org/ 

question/36480/restricted-usability-of-singular-after-upgrade/ 

it would be helpful to examine the failing example.

First guess: 
because there _could be an overflow_ for some operation if an exponent in 
the input is bigger than 16 bit,
in recent Singular the input exponent is restricted to 16 bit. No explicit 
overflow test is implemented.
For example, if you try in recent Singular 

ring rng = 0,(x,y),dp;
short = 0;
poly h = x^2147483647;
//   ? OVERFLOW in power(d=1, e=2147483647, max=32767)


you get an overflow exception with the hint that max allowed exponent is 
32767. This was not the case for older Singular versions.

My second guess is: an overflow occurs in the computation by Singular 
which was not detected in older Singular version => result seems computable 
but is likely incorrect.
In the new Singular version and thus in Sage with upgraded Singular  the 
overflow is detected correctly so the computation 
is aborted.




Am Mittwoch, 8. Februar 2017 20:32:43 UTC+1 schrieb kcrisman:
>
>
>
>
> as far as I know, limiting to 16 bit exponents for _input_ was introduced 
>> to prevent undetected overflows;
>> it must be one of the tickets
>>>
>>>
>>>
>
> If someone who knows what they are talking about (i.e., not me) could 
> mention this on the ask.sagemath question that would be really helpful. 
> https://ask.sagemath.org/ 
> 
> question/36480/restricted-usability-of-singular-after-upgrade/ 
> 
> Seems to be an otherwise-satisfied customer who is at a loss.
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

[Jakob Kroeker]

as far as I know, limiting to 16 bit exponents for _input_ was introduced 
to prevent undetected overflows;
it must be one of the tickets

https://www.singular.uni-kl.de:8005/trac/ticket/630
https://www.singular.uni-kl.de:8005/trac/ticket/631
https://www.singular.uni-kl.de:8005/trac/ticket/696
https://www.singular.uni-kl.de:8005/trac/ticket/698

see commits in February 2015, like
https://github.com/Singular/Sources/commit/fc77091687ca4452f82b084b30f8522dec3b357d


There is a history of overflow issues in Singular, for example see
https://www.singular.uni-kl.de:8005/trac/ticket/232
https://www.singular.uni-kl.de:8005/trac/ticket/414

Thus I suspect (without proof) that it is still possible to construct 
various examples leading to overflows in the results.

So can someone try to find new(unknown) overflow issues in recent Singular?

Jakob

Am Dienstag, 11. Oktober 2016 09:33:57 UTC+2 schrieb Jean-Pierre Flori:
>
> Yes it is a feature of the Singular 4 update that Singular and Sage work 
> by default with 16 bit exponents on 32 and 64 bit platform by default.
> If only all of of you had read carefully the 543 comments of the update 
> ticket and remembered this tcomment 
> https://trac.sagemath.org/ticket/17254#comment:126 and commit 
> https://git.sagemath.org/sage.git/commit/?id=8c0275427c66b709413188b82da7845a3196e4bb
>  
> that would be obvious to you.
> Now if we want to give more bits when fewer variables are used that should 
> be possible.
> (I'm just kidding, this is a not so serious post except for the previous 
> sentence.)
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: GSoC 2017 kickoff

[Jakob Kroeker]

I have an idea for a project but no time this year for mentoring (maybe 
next one)

The idea boils down to develop a random testing framework to find (in some 
way minimal) failing examples (wrong answers or crashes)
using bots (like running patchbot to test sage). 

So if someone is willing, able and capable to take over this project, just 
do it

Jakob

Am Donnerstag, 19. Januar 2017 19:05:19 UTC+1 schrieb Harald Schilly:
>
> Hello, this year's Google Summer of Code 2017 just started. 
>
> I assume we will try again to be part of it, and therefore I've 
> started the registration process. 
>
> The most important aspect is to have mentors and project proposals. 
> For that, I've started this year's wiki page as a copy of last year: 
>
> https://wiki.sagemath.org/GSoC/2017 (compare with 2016) 
>
> The deadline for the application is Feb. 9th and I'm again working on 
> this like in the past 5 years. 
>
> -- Harald 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Testing corner cases

[Jakob Kroeker]

> I would also add a crosstesting several functions with known identity. 

Good idea. 


>Well, my "trivialcase-tester" is just those few lines of code. But as you 
> can see from https://trac.sagemath.org/ticket/21741 
<https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F21741=D=1=AFQjCNHOFlfe-YW8rN7vz7PBGr4aQuSa_w>
 
, it found quite many 
> error from graphs.

That is not surprising for me. Maybe it is surprising for non-testers ;-)

My code to catch bugs in Singular for groebner basis in Polynomial rings 
over integers was something like:

randomIdeal = generateRandomIdeal();
groebnerBase = groebner(randomIdeal );
groebnerBaseOnceAgain = groebner(groebnerBase);
checkResultEquivalence (groebnerBase, groebnerBaseOnceAgain);

But, If you catched issues for non-corner cases, the challenge is often to 
find a minimal/simple failing example,
which is often necessary for successful debugging.

>Should have a list of corner cases? I don't know if that would be easy to 
>do or not, something like modulename._cornercases() or so. 

I would expect that you will need corner cases per function and per data 
type (graph, Ideal, prime number...)

>In matrices I did not found that many errors, but I 
>only tested integer matrices. 

I recommend that you continue test sage library functions which you use in 
your own research projects,
or functions where you already found bugs or expect that they are 
improperly coded.

But probably you should not do that, you may get unpleasantly surprised...



Am Montag, 31. Oktober 2016 10:31:56 UTC+1 schrieb Jori Mäntysalo:
>
> On Mon, 31 Oct 2016, Jakob Kroeker wrote: 
>
> > So you have a mind of a tester? That's good to  know.  
>
> Well, my "trivialcase-tester" is just those few lines of code. But as you 
> can see from https://trac.sagemath.org/ticket/21741 , it found quite many 
> error from graphs. In matrices I did not found that many errors, but I 
> only tested integer matrices. 
>
> Should have a list of corner cases? I don't know if that would be easy to 
> do or not, something like modulename._cornercases() or so. 
>
> > In general I think it would be good to have a random testing framework  
> > together with a testbot in sage. 
>
> Yes, could be useful. 
>
> > Maybe you are also interested in the slides from my presentation about 
> bug hunting and bug preventing 
> > on 
> > https://wiki.sagemath.org/days66 
>
> Good slides. 
>
> I would also add a crosstesting several functions with known identity. For 
> example 
>
> len(list(Posets(4))) == len([g for g in digraphs(4) if 
> g.is_directed_acyclic() and g.is_transitively_reduced()]) 
>
> (I.e. a poset can be seen as just a special case for directed graph.) 
>
> or 
>
> Posets.RandomPoset(10, 0.1).order_ideals_lattice().is_modular() 
>
> (Every order ideal lattice is a distributive lattice and every 
> distributive lattice is modular.) 
>
> etc. 
>
> -- 
> Jori Mäntysalo

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Singular "share" files

[Jakob Kroeker]

Will we have to repackage Singular each time we want to upgrade/get the 
recent patched release?

I think we should stop repackaging Singular. 
If there are some general issues with packaging, we should solve them 
upstream.


Jakob

Am Mittwoch, 2. November 2016 16:19:47 UTC+1 schrieb Jean-Pierre Flori:
>
> Dear all,
>
> We currently repackage singular so merge the source code and help files 
> into a single archive (and renaming directories).
> Should we stop doing so by creating a "singular_share" package for the 
> latter files?
>
> Best,
> JPF
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Testing corner cases

[Jakob Kroeker]

@Jori Mäntysalo

So you have a mind of a tester? That's good to  know.  
In general I think it would be good to have a random testing framework  
together with a testbot in sage.


I'm working on that in Singular and Macaulay2 
  and already catched 
more than 100 bugs 
 Most of them were fixed (some by me). Unfortunately I make only slow 
progress, because I moved to industry a year ago.

Maybe you are also interested in the slides from my presentation about bug 
hunting and bug preventing on 
https://wiki.sagemath.org/days66

Jakob


Am Samstag, 22. Oktober 2016 10:06:18 UTC+2 schrieb Jori Mäntysalo:
>
> I just play a little with Python. I think others might also benefit on 
> this when testing corner cases like 0x0 or 1x1 matrices, 1-element groups 
> and so on. 
>
> G = Graph() 
> known_kaboom = ['is_prime', 'layout_graphviz'] 
> errors = [] 
> for f in [y for y in dir(G) if y[0] != '_']: 
>  if f in known_kaboom: 
>  continue 
>  try: 
>  attrcall(f)(G) 
>  except TypeError as e: 
>  if "takes exactly" in e.message: 
>  continue 
>  except Exception as e: 
>  print(f, e) 
>  print 
>  errors.append(f) 
>  continue 
> errors 
>
> (This found that for example is_triangle_free() and is_cayley() fails. 
> known_kaboom is needed as for example is_prime() don't just throw an 
> exception, it stops the whole workseet.) 
>
> -- 
> Jori Mäntysalo 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: slow doctest number_field_element.pyx on my machine

[Jakob Kroeker]

this is now https://trac.sagemath.org/ticket/21719#ticket

Am Dienstag, 4. Oktober 2016 22:13:50 UTC+2 schrieb Volker Braun:
>
> I've seen that time out often on the buildbot, too. Please, somebody 
> replace the test in there by something more reasonable.
>
>
>
> On Tuesday, October 4, 2016 at 9:53:13 PM UTC+2, Jakob Kroeker wrote:
>>
>> on my machine (fedora 23, 32 Bit) the test
>>
>> sage -t --long --warn-long 127.3 src/sage/rings/number_field/
>> number_field_element.pyx
>>
>>
>>
>> takes 1397.8 seconds (10 times more)
>>
>> And thus the patchbot test run for sage 7.4.beta6 fails 
>>
>> I have aIntel(R) Core(TM)2 Duo CPU E8200  @ 2.66GHz ; it should 
>> not be THAT slow.
>>
>> Any suggestions?
>>
>>
>>
>>
>>
>>
>>
>>
>>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] a 7(!) year old (Singular) overflow issue still holds

[Jakob Kroeker]

https://trac.sagemath.org/ticket/6472

even for recent singular upgrade 

https://trac.sagemath.org/ticket/17254

and it was not(?) reported to upstream...














-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: slow doctest number_field_element.pyx on my machine

[Jakob Kroeker]

I'm not confident that there is no issue, maybe I could take a look.

I suspect that the implementation is optimized for or runs best on specific 
harware/environment, which is not a priori bad.

In addition I think that REALLY GOOD TIMING TESTS will need some extra 
effort, namely:
(multiple) (common) reference hardware, reference environment (os, 
installed package versions)
and reference timings for that specific environment.



Am Dienstag, 4. Oktober 2016 22:35:29 UTC+2 schrieb Thierry 
(sage-googlesucks@xxx):
>
> On Tue, Oct 04, 2016 at 01:13:49PM -0700, Volker Braun wrote: 
> > I've seen that time out often on the buildbot, too. Please, somebody 
> > replace the test in there by something more reasonable. 
>
> Just to be sure, are you confident that this is not pointing some issue ? 
>
> Ciao, 
> Thierry 
>
>
> > 
> > On Tuesday, October 4, 2016 at 9:53:13 PM UTC+2, Jakob Kroeker wrote: 
> > > 
> > > on my machine (fedora 23, 32 Bit) the test 
> > > 
> > > sage -t --long --warn-long 127.3 src/sage/rings/number_field/ 
> > > number_field_element.pyx 
> > > 
> > > 
> > > 
> > > takes 1397.8 seconds (10 times more) 
> > > 
> > > And thus the patchbot test run for sage 7.4.beta6 fails 
> > > 
> > > I have aIntel(R) Core(TM)2 Duo CPU E8200  @ 2.66GHz ; it 
> should 
> > > not be THAT slow. 
> > > 
> > > Any suggestions? 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] slow doctest number_field_element.pyx on my machine

[Jakob Kroeker]

on my machine (fedora 23, 32 Bit) the test

sage -t --long --warn-long 127.3 src/sage/rings/number_field/
number_field_element.pyx



takes 1397.8 seconds (10 times more)

And thus the patchbot test run for sage 7.4.beta6 fails 

I have aIntel(R) Core(TM)2 Duo CPU E8200  @ 2.66GHz ; it should not 
be THAT slow.

Any suggestions?








-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: classifying trac tickets as silently incorrect results

[Jakob Kroeker]

using a keyword  the ticket will not added to the list of mathematically 
wrong answers.

It is about make silent wrong answers _visible_. Stopgaps are an  extreme 
tool and are hard to enforce.

Also I do not (yet) have the time to create 72 stopgaps and nobody else 
seems to care. 


Jakob


Am Sonntag, 10. Juli 2016 00:32:57 UTC+2 schrieb vdelecroix:
>
> On 09/07/16 18:17, Jakob Kroeker wrote: 
> > 
> >> 
> >> Please don't. That field is suppose to be used for tickets which 
> implement 
> >> the stopgap when it is applicable 
> > 
> > 
> > Unfortunately stopgaps for all the silent wrong results will hardly be 
> > accepted. 
> > I already experienced heavy opposition as I created some and was not 
> able 
> > to create them in full extent. 
> > 
> > With labels on issues with silently wrong answers we will have at least 
> an 
> > up-to date list of them: 
> > https://trac.sagemath.org/wiki/TicketReports 
>
> If it is just a matter of classification then you could add a keyword 
> instead of using stopgap which is meant for something else. 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: classifying trac tickets as silently incorrect results

[Jakob Kroeker]

>
> Please don't. That field is suppose to be used for tickets which implement 
> the stopgap when it is applicable


Unfortunately stopgaps for all the silent wrong results will hardly be 
accepted.
I already experienced heavy opposition as I created some and was not able 
to create them in full extent.

With labels on issues with silently wrong answers we will have at least an 
up-to date list of them:
https://trac.sagemath.org/wiki/TicketReports

And of course it is possible to create all the stopgaps afterwards.

Jakob


Am Samstag, 9. Juli 2016 21:00:58 UTC+2 schrieb Travis Scrimshaw:
>
>
> If a ticket describes an issue where sage silently returns a wrong answer, 
>> please update the ticket description, adding a 'wrongAnswerLabel'  to the 
>> stopgap field.
>>
>> Please don't. That field is suppose to be used for tickets which 
> implement the stopgap when it is applicable (which it would be good for you 
> to create and implement said stopgaps).
>
> Best,
> Travis
>
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] classifying trac tickets as silently incorrect results

[Jakob Kroeker]

Hello,


today in my spare free time I continued looking for tickets with describes 
issues where sage silently returns a wrong answer and stopped at
https://trac.sagemath.org/ticket/15325


For the following tickets I'm not sure, 

if they should be classified as 'silently incorrect result' or not


https://trac.sagemath.org/ticket/13321
https://trac.sagemath.org/ticket/13655

https://trac.sagemath.org/ticket/13707
https://trac.sagemath.org/ticket/13776

https://trac.sagemath.org/ticket/13758
https://trac.sagemath.org/ticket/14012
https://trac.sagemath.org/ticket/14069
https://trac.sagemath.org/ticket/14125
 https://trac.sagemath.org/ticket/14274
https://trac.sagemath.org/ticket/14277
https://trac.sagemath.org/ticket/14590
https://trac.sagemath.org/ticket/14735
https://trac.sagemath.org/ticket/14736
https://trac.sagemath.org/ticket/14738
https://trac.sagemath.org/ticket/14889
https://trac.sagemath.org/ticket/15114
https://trac.sagemath.org/ticket/15153



If a ticket describes an issue where sage silently returns a wrong answer, 
please update the ticket description, adding a 'wrongAnswerLabel'  to the 
stopgap field.



Jakob



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Should RR coerce into RIF?

[Jakob Kroeker]

the ticket https://trac.sagemath.org/ticket/15114 seems orphan now...

Am Donnerstag, 20. März 2014 12:58:30 UTC+1 schrieb Marco Streng:
>
> Thanks for all the replies. It seems that everybody here agrees to 
> disallow coercions from RR to RIF, which is all that ticket 
> http://trac.sagemath.org/ticket/15114 is about, so that ticket can 
> proceed. 
>
> As for conversions or coercions RIF to RR, there doesn't seem to be 
> anybody strongly in favour having them, and it is not clear how it 
> should work, so I won't touch them. 
>
>
>
>
> 2014-03-19 16:39 GMT+01:00 Robert Bradshaw  >: 
> > +1 to all of this, specifically 
> > 
> > 1) allow 
> > 2) allow for point intervals (maybe) 
> > 3)  dissallow 
> > 
> > On Tue, Mar 18, 2014 at 3:02 PM, David Roe  > wrote: 
> >> Marc Mezzarobba wrote: 
> >>>Marco Streng wrote: 
>  So the choices are: 
>  
>  1) explicit conversion RR --> RIF: allow / disallow 
>  2) explicit conversion RIF --> RR: allow / disallow 
>  3) automatic coercisions: disallow / (RR-->RIF) / (RIF-->RR) 
> >>>[...] 
> >> 
>  My vote is: 
>  1) allow 
>  2) allow 
>  3) from RIF to RR 
> >>> 
> >>>Mine is: 
> >>> 1) allow 
> >> 
> >>> 2) allow for point intervals, require the use of explicit method calls 
> >>>(e.g., center()) for general intervals 
> >>> 3) disallow (but see below) 
> >>> 
> >>> Regarding 3), and in response to Thomas Coffee's arguments, I would be 
> >> 
> >>> in favor of also having "non-rigorous intervals", living in a separate 
> >>> parent, with a coercion from RR. In fact, one also needs intervals 
> with 
> >>> integer, rational or even symbolic endpoints from time to time. So 
> >>> unless I'm missing something, these "non-rigorous interval" could 
> simply 
> >>> be the elements of Intervals(RR), where Intervals(C) would work for 
> more 
> >>> or less arbitrary C. (And there could perhaps be a coercion from RIF 
> to 
> >>> Intervals(RR), but certainly not in the other direction.) 
> >> 
> >> I agree with Marc, though I note that C needs at least a partial 
> ordering, 
> >> which most rings don't come with. 
> >> 
> >> On Tue, Mar 18, 2014 at 2:16 PM, Thierry  > 
> >> wrote: 
> >>> 
> >>> 
> >>> It seems there are more precise cases to consider: 
> >>> 
> >>> - How do you plan to coerce a RIF element with non-trivial diameter to 
> a 
> >>>   RR element ? 
> >> 
> >> 
> >> I would say you don't even allow conversion in this case, let alone 
> >> coercion. 
> >> 
> >>> 
> >>> - How do you plan to convert 
> >>>   - from RealIntervalField(2) to RealField(100) ? 
> >> 
> >> If you start with a point interval, there's no problem.  Otherwise, 
> >> disallowed. 
> >>> 
> >>>   - from RealIntervalField(100) to RealField(2) ? 
> >> 
> >> Conversion should work as long as the upper and lower endpoints are the 
> same 
> >> in RealField(2). 
> >>> 
> >>>   - from RealField(100) to RealIntervalField(2) ? 
> >> 
> >> Smallest interval containing the input. 
> >>> 
> >>>   - from RealField(2) to RealIntervalField(100) ? 
> >> 
> >> Here you can use a point interval as the image. 
> >> 
> >> Of course, none of these should be coercions. 
> >> 
> >>> 
> >>> - How do you mix both (do you plan to deal with possible compensations 
> >>>   between number of bits of precision of the field and the diameter of 
> >>>   the intervals) ? 
> >> 
> >> 
> >> I would say yes: you can mix a change in precision with a change in 
> >> precision type. 
> >> 
> >>> 
> >>> For example, in which case do you allow (silent) coercion, and what 
> >>> should be the result of the (explicit) conversion: 
> >>> 
> >>> - RIF(-1,1) -> RR 
> >> 
> >> Coercion and conversion should both fail. 
> >>> 
> >>> - RealIntervalField(100)(1.1,1.2)) -> RealField(2) 
> >> 
> >> Coercion and conversion should both fail. 
> >>> 
> >>> - RealField(2)(pi) -> RIF  [which diameter, which endpoints ?] 
> >> 
> >> A point interval (3.0, 3.0) 
> >>> 
> >>> 
> >>> 
> >>> As for me, 
> >>> - it is clear that RIF(pi) should be coerced to RR(pi) 
> >> 
> >> I think that this actually isn't clear, since RIF(pi) is not a point 
> >> interval.  Of course, we could make a special case when the length of 
> the 
> >> interval is the minimum possible, and use the rounding mode of RR to 
> >> determine which endpoint to pick (though I don't know what we should do 
> in 
> >> the default 'RNDN' 
> >>> 
> >>> - i agree with coercing from x in RealIntervalField(a) to RealField(b) 
> >>>   when the endpoints of x are the same in RealField(b) 
> >> 
> >> Coercion needs to be defined on the whole domain.  This rule works for 
> >> conversion though. 
> >>> 
> >>> - i have no problem for explicit conversion from RIF(-1,1) to RR, but 
> it 
> >>>   should be well specified in the doc, since there is no canonical 
> way. 
> >> 
> >> I think it should be disallowed, since there are already functions to 
> get 
> 

Re: [sage-devel] Re: Is the glass half-full or half-empty ? Pick a standard.

[Jakob Kroeker]

>
> I think backward compatibility is a strong argument to keep returning True.
>

well, there is also the option to deprecate the is_connected() function for 
the empty graph
and then change the behaviour after a year.

By the way, what about defining that the empty graph is connected AND 
disconnected.
( I'm joking :-) )

But seriously, I just thought, what about dropping the definition for graph 
connectedness at all.
and introduce three different cases instead:

- a graph has 0 components
- a graph has exactly 1 component
- a graph has 2 or more components

At least we are able to count ;-)


I think If we cannot handle special cases consistently even in theory, we 
will never ever be able to implement it without getting tons of worms...

Jakob

Am Donnerstag, 22. August 2013 23:29:45 UTC+2 schrieb Stefan:
>
> I think backward compatibility is a strong argument to keep returning True.
>
> I also have an answer based on "my favorite definition is ...", namely the 
> analogue with matroid connectivity, where any matroid that is too small to 
> have a k-separation, is automatically k-connected. Extending this to 
> graphs, the empty graph should be infinitely connected.
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: The end of stopgaps

[Jakob Kroeker]

At least a user could look at the list of bugs silently producing wrong 
answers:

http://trac.sagemath.org/report/79

I updated the list by manually looking at open tickets from #1 to #13345 
and adding a stopgap marker 'todo' if required.

Remaining task (I will do that): 
check open tickets #13346 to #19383 for issues silently producing wrong 
answers
and add them to the list http://trac.sagemath.org/report/79 


Jakob


Am Donnerstag, 8. Oktober 2015 19:05:23 UTC+2 schrieb Nathann Cohen:
>
> Just to keep everybody aware of what is going on here: 
>
> - I tried to add a stopgap on a code that returns wrong results 
>
> - The stopgap was refused because it was "just before a stable 
> release" and people did not want to alarm the users by telling them 
> that Sage returns wrong results (even though it does) 
>
> - Jeroen noticed that if we add the stopgap now, the same thing may 
> happen for the next release cycle (as we are not sure that it will be 
> fixed in the meantime) 
>
> - Thus, they now decide that we will not add the stopgap at all. Ever. 
>
> So, no stopgap. Let us not tell the users that we return wrong 
> results. Let them deal with the consequences. 
>
> This enlightening conversation showing how trying to preserve our 
> public image can ruin a good software is available there: 
>
> http://trac.sagemath.org/ticket/19302#comment:27 
>
> Nathann 
>

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Various packages no longer exist

[Jakob Kroeker]

 kash and macaulay2 are hugely obsolete


which is the last commit with the interface to macaulay2?

Am Donnerstag, 27. August 2015 22:21:42 UTC+2 schrieb Dima Pasechnik:



 On Thursday, 27 August 2015 12:48:03 UTC-7, Jeroen Demeyer wrote:

 Some more packages are documented in Sage but no longer actually exist. 
 I found these when grepping for sage -i: 

 chomp 
 kash (also kash3-linux-2005.11.22 and kash3_onsx-2005.11.22)  

 macaulay2 


 kash and macaulay2 are hugely obsolete; but chomp is  not.

 Chomp definitely needs to be made available in some way.



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Online Bug report form: is it dead?

[Jakob Kroeker]

where do the sagenb reports end? 

here?

https://docs.google.com/spreadsheets/d/1GF_-hM-3DP0YcViieBWIhsign3JHegTlj32cs8ymPZE/pub



Am Freitag, 5. Juni 2015 12:52:06 UTC+2 schrieb Nathann Cohen:

 Hello everybody, 

 It is apparently possible to report bugs through an online form on 
 Sage's website [1]. Is anybody reading those reports? 

 If nobody tracks them and if nobody volunteers to do it from now on, I 
 propose that we remove this link. 

 By having users submit bug reports that nobody reads, we are only 
 wasting their time and missing bug reports that could have been sent 
 to sage-devel/sage-support otherwise. 

 Nathann 

 P.S.: In the links menu of our website, there are three successive 
 links named Report a Problem, About bugreporting and SageMath 
 Bugtracker. If you want to scare somebody who has a bug to report, 
 give her/him three links that all match what (s)he is looking for. 

 [1] http://www.sagemath.org/ (Links - Report a problem) 
 http://spreadsheets.google.com/viewform?key=pCwvGVwSMxTzT6E2xNdo5fA 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] please review #18320

[Jakob Kroeker]

In either case, this isn't a good solution to the long-standing 
patches-arent- 
being-reviewed-in-a-timely-
manner problem to which I have no solution except 
yet another attempt at an IRC sage hour a week where we all 
review/triage 
stuff.

What is about occasional time-limited (to prevent cheating)  bonus programs 
for reviewing? 
I could imagine to advertise ticket review requests of developers who 
performed 3 reviews in the last month.
Or spending a Sage shirt for developers who perform 20 reviews until 
October.
Or spend a one-week trip for the best  (quality and quantity) reviewer of 
the year.

Jakob

Am Dienstag, 19. Mai 2015 00:27:00 UTC+2 schrieb Martin Albrecht:

 Hi Vincent, 

 no hard feelings at all! It's hard to figure out a good balance for these 
 kinds of things and one way is to try it out: I sent a request and people 
 who 
 object to such requests …object. Then we discuss :) 

 Back to the topic of discussion: I guess I'm up for more such requests on 
 here, if it gets too much we may have to pull the breaks. 

 In either case, this isn't a good solution to the long-standing 
 patches-arent- 
 being-reviewed-in-a-timely-manner problem to which I have no solution 
 except 
 yet another attempt at an IRC sage hour a week where we all 
 review/triage 
 stuff. 

 Cheers, 
 Martin 

 On Monday 18 May 2015 21:37:50 Vincent Delecroix wrote: 
  On 18/05/15 20:43, John Cremona wrote: 
   One reason for setting up the other lists such as sage-nt (for number 
   theory) and sage-algebra was to provide a place for such requests. 
   But of course those lists will never cover everything. 
  
  Agreed. 
  
   I think that Martin (co-organiser with William and me of Sage Days 6 
   in 2007) has enough community-respect points for us to allow him such 
   bandwidth. 
  
  Some people are allowed for this kind of request and others not? Very 
  friendly. What about the following imaginary e-mail: 
   
  hey, this is my first ticket. Does anybody want to review it? 
   
  
  I feel unconfortable now since Martin might has taken my e-mail for 
  himself but it was not. So please, Martin forgive me to use your e-mail 
  as a pretext to send mine. 
  
   On 18 May 2015 at 19:13, kcrisman kcri...@gmail.com javascript: 
 wrote: 
   There are a *lot* of tickets which are short, fix bugs, increase 
 speed 
   and are waiting for reviews. If all authors are advertising their 
   tickets it will become a nightmare on sage-devel. 
   
   If you want your ticket reviewed, it would be better: 
- looks for somebody that is likely to do the review and e-mail him 
   
   personally 
   
- review another ticket and ask for a review back 
   
   That's all true.  That said, Martin is a long-time enough Sage 
   contributor 
   that perhaps in this case he felt it was warranted, so I wouldn't 
   second-guess it, for myself.  Maybe we need more, not fewer, review 
   requests on sage-devel?  (And I will finally have time now to do 
 some, 
   already writing an email about this right now!) 
  
  We already have a place to advertise needs review tickets which is 
  called trac. Isn't it enough? 
  
  Vincent 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: SIngular version

[Jakob Kroeker]

Hello, 

I think I can finish the update to Singular 4.0.2

The problem is that  I'm currently busy with writing a Macaulay2 package 
(together with H-C v. Bothmer) for the MEGA 2015 conference in Italy
(June 15-19, 2015). I'm also kind of involved in releasing Macaulay2 
version 1.8

So I can't promise something will happen before 20 June, sorry for the 
inconvenience.


 the prospective Singular user

which libraries/functions does he plan to use?
FYI: In case they are not widely used and/or I didn't already test/review 
them 
I strongly recommend the user to design and implement automated random 
tests for related routines first before using them. ;-)
(from the error rate I observed in 'primdec.lib' I estimate that Singular 
has about more than 1.000 undetected bugs inside)


Jakob

Am Donnerstag, 14. Mai 2015 10:06:26 UTC+2 schrieb John Cremona:

 Thanks for the update.  Since the prospective Singular user does not 
 know Sage at all he will not be able to help with that ticket;  and I 
 don't know Singular at all. 

 John 

 On 13 May 2015 at 22:45, leif not.r...@online.de javascript: wrote: 
  John Cremona wrote: 
  Is anyone planning to update the version of Singular  used by Sage? 
  
  http://trac.sagemath.org/ticket/17254 
  
  
  We appear to use 3.1.7 which is not listed at 
  http://www.singular.uni-kl.de/index.php/news.html but 3.1.6 was 
  released in 2012, there were two releases in 2014 and the current one 
  is 4.0.2 released on 2015-03-05. 
  
  I'm asking because a user of one of the machines I manage wants a more 
  recent version and I would like to not have to install a separate 
  system-wide one, though of course that should not be hard. 
  
  That's presumably the easiest and quickest solution. 
  
  
  -leif 
  
  
  -- 
  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+...@googlegroups.com javascript:. 
  To post to this group, send email to sage-...@googlegroups.com 
 javascript:. 
  Visit this group at http://groups.google.com/group/sage-devel. 
  For more options, visit https://groups.google.com/d/optout. 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: max(sin(x),cos(x)) = sin(x)

[Jakob Kroeker]

Really, bool(x) means known_true(x).
And of course, not(known_true(x))
is not the same as known_false(x).

Sure, but adequate naming is crucial, too.
Also the design as is does not prevent a developer from applying boolean 
operations (negating, and,or,...) by accident on the result.

A similar real world example is the 'size()' function in Singular.
That function omits zero ideal generators (is documented), but many devs  
(incorrectly) use size() to iterate over ideal generators.
There are alone about 40-80 size()-related bugs in Singular (see 
https://github.com/Singular/Sources/issues/611).
And the 'bool()' documentation does even not explicitly explain the 'false' 
return value case.

With 'bool()' as is only the bughunters (like me) will have fun. I' looking 
forward to find many related bugs ;-)


Jakob





Am Mittwoch, 13. Mai 2015 13:40:37 UTC+2 schrieb Samuel Lelievre:



 2015-05-12 21:03:27 UTC+2, Jakob Kroeker:


   Its just behaving as specified, False means cannot decide

  I find, this was a pretty unfortunate specification. 
  I think it would be kind of ok in case 'bool()' would be 
  named 'Holds_If_True_Otherwise_Unknown()' instead

 Really, bool(x) means known_true(x).
 And of course, not(known_true(x))
 is not the same as known_false(x).


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: max(sin(x),cos(x)) = sin(x)

[Jakob Kroeker]

 We cannot be satisfied with returning wrong answers in the meantime, 
however. 
 
I support Nathann's position.

 Returning 'Unknown' instead of nonsense would be a good first step. 

I disagree. That Unknown class/object should not be comparable/convertible 
to True/False,

especially 

 if not Unknown
 if Unknown
 if Unknown == True
 if Unknown == False

should fail

otherwise developers will introduce tons of bugs like

if not bool(sin(x) = 100+cos(x)) :
  ...

And it does not fail:

sage: Unknown ==True
False
sage: Unknown ==False
False
sage: Unknown ==Unknown
True
sage: not Unknown
True


@Volker

 Its just behaving as specified, False means cannot decide

I find, this was a pretty unfortunate specification. 
I think it would be kind of ok in case 
'bool()' would be named 'Holds_If_True_Otherwise_Unknown()' instead


Jakob

Am Dienstag, 12. Mai 2015 16:02:51 UTC+2 schrieb Nathann Cohen:

  I think Nils explained the situation pretty well.   Making max/min be 
  mathematical would definitely require some nontrivial effort. 

 Why? 'max_symbolic' and 'min_symbolic' already do the job, don't they? 

  I don't 
  know that I'm in favor of adding a third boolean option, 

 http://www.sagemath.org/doc/reference/misc/sage/misc/unknown.html 

  though of course 
  Maxima has various outcomes for e.g. limits.  But again, doing that 
 properly 
  would require pretty substantial work. 

 We cannot be satisfied with returning wrong answers in the meantime, 
 however. 

 sage: bool(sin(x) = 100+cos(x)) 
 False 

 Returning 'Unknown' instead of nonsense would be a good first step. 

 Nathann 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: dimension() broken for ideals?

[Jakob Kroeker]

 It is definitely a bug in the dimension method.


could you open a ticket and post the link here?

Am Sonntag, 3. Mai 2015 15:25:13 UTC+2 schrieb mmarco:

 It is definitely a bug in the dimension method.

 If singular can handle the ring, sage asks singular to compute the 
 dimension, which does correctly (the -1 is the singular convention for 
 empty varieties).

 The problem is that when the field is not supported by singular (which 
 happens with QQbar or finite fields of characteristic bigger than 2^31) , 
 then sage falls back to its own toy implementation. In that case, it 
 appears that the empty case is not treated separatedly than the zero 
 dimensional case.



 El viernes, 1 de mayo de 2015, 21:18:55 (UTC+2), gjorgen...@my.fit.edu 
 escribió:

 Hi,

 For the following ideal, dimension() returns 0,
 {{{
 R.s0,s1=QQbar[]
 I=R.ideal([ s0 + 1, s0*s1 + s0 + s1 + 1, (-2)*s0 + 1, (-10)*s1 + 5, 
 5*s0^2 + 10*s0*s1 ])
 I.dimension()
 }}}
 but its variety is empty.

 Also for any other ring, dimension() returns -1 for this ideal. Is this a 
 bug with dimension()? The documentation for dimension() doesn't seem to 
 mention the -1 case. 
 It provides the following example,
 {{{
 R.x,y = PolynomialRing(GF(2147483659),order='lex')
 I = R.ideal([x*y,x*y+1])
 I.dimension()
 }}}
 which yields dimension 0 for the ideal, yet the corresponding variety is 
 empty.

 What is the expected behavior for dimension()? When the variety of the 
 ideal in question has no points is dimension() always supposed to return -1?



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: arando patchbot spam

[Jakob Kroeker]

Ticket 15056 is also interesting - try run it explicitly and one will get:

Switched to branch 'patchbot/base'
Already on 'patchbot/base'
fatal: 'None' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

Is that connected to the fact that in ticket 15056 the 'git_branch' is 
empty and the ticket provides a patch file?



Am Dienstag, 24. März 2015 21:52:37 UTC+1 schrieb Frédéric Chapoton:

 Even worse: ticket 7298 may have been tested 15000 times ??

 in http://patchbot.sagemath.org/ticket/?base=6.5, see the last line

 15951  7298 use html5 video tag for animations

 I wonder if this is really possible ?

 Frédéric

 Le mardi 24 mars 2015 21:29:06 UTC+1, Frédéric Chapoton a écrit :

 Hello,

 the arando patchbot is now testing the same ticket again and again:

 http://patchbot.sagemath.org/ticket/12731/

 Did somebody fix it ? Is is running the 2.2 patchbot ?

 Is robertwb still taking care of the patchbot code, by the way ? I have 
 three pull requests on github.

 Frédéric



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: running multiple patchbots on a cluster

[Jakob Kroeker]

I don't think this will work unless you have separate source directories,

the source directories are separate

but this is only the first caveat that comes to mind.

how it is decided, which ticket is pulled by a patchbot? by 'random' value 
depending on datetime?
that would partly explain the behaviour


Why several patchbots? 

why run only one patchbot on 60 workstations?

at least one machine seems now excaped from the infinite loop

http://patchbot.sagemath.org/ticket/?machine=openSUSE%20:13.1:x86_64:3.11.10-25-desktop:rp04

the others tried again ticket 7298 in a loop. 
any idea why? will a 'make disctlean' help?

Jakob

Am Samstag, 7. März 2015 07:45:16 UTC+1 schrieb Ralf Stephan:

 On Friday, March 6, 2015 at 9:06:41 PM UTC+1, Jakob Kroeker wrote:

 Hello,

 I just tried to run several patchbots in local tmp folder on different 
 machines and something did not work as expected,
 see http://patchbot.sagemath.org/ticket/7298/ 

 I don't think this will work unless you have separate source directories,
 but this is only the first caveat that comes to mind.

 Why several patchbots? If you have several CPUs set your parallelism
 option.

 Regards,


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: running multiple patchbots on a cluster

[Jakob Kroeker]

 Before I even look closer: are you using git master 
of patchbot?

the advertised one. I must admit that for me it worked best to select
the tickets by hand
http://patchbot.sagemath.org/?machine=Ubuntu:12.04:x86_64:3.8.0-29-generic:groebnerstatus=needs_review
;-)

In case a patchbot state was suspicious ('failing tests on your install')
I did a build from scratch and selected a different ticket.

 you will have to find your own solutions. 

Ok, thanks for the hint. I will take a look and if I get stuck I will ask 
for help then.

Jakob

Am Samstag, 7. März 2015 22:24:03 UTC+1 schrieb Ralf Stephan:

 Before I even look closer: are you using git master 
 of patchbot? Have you had a look at my pull requests? 
 Be aware that the version advertised on the web page 
 may be not state-of-the-art and maintenance by the 
 author is rare, I.e., you will have to find your own 
 solutions. 



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] running multiple patchbots on a cluster

[Jakob Kroeker]

Hello,

I just tried to run several patchbots in local tmp folder on different 
machines and something did not work as expected,
see http://patchbot.sagemath.org/ticket/7298/ 
;-)

What went wrong?


Jakob

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: should bool(x 0) be False or an exception?

[Jakob Kroeker]

I changed the code to return an exception if the truth value is unknown 
and ran `sage -testall`. 

Did you upload the patch to somewhere? Where this change has to be made?

 I might be willing to fix these tests when I have time.

It seems that nothing happens for more than a year, 
so maybe someone else has time to fix this?

I opened a ticket :
http://trac.sagemath.org/ticket/17700


Jakob


Am Samstag, 10. August 2013 00:04:32 UTC+2 schrieb Eviatar:

 I changed the code to return an exception if the truth value is unknown 
 and ran `sage -testall`. Here are the results:

 sage -t devel/sage/sage/tensor/differential_form_element.py  # 43 doctests 
 failed   
 sage -t devel/sage/sage/tensor/differential_forms.py  # 1 doctest failed   
  
 sage -t devel/sage/sage/calculus/tests.py  # 4 doctests failed 
  
 sage -t devel/sage/sage/calculus/calculus.py  # 10 doctests failed 
  
 sage -t devel/sage/sage/calculus/desolvers.py  # 8 doctests failed 
  
 sage -t devel/sage/sage/calculus/wester.py  # 3 doctests failed   
   
 sage -t devel/sage/sage/symbolic/assumptions.py  # 8 doctests failed   
  
 sage -t devel/sage/sage/symbolic/expression.pyx  # Killed due to 
 segmentation fault 
 sage -t devel/sage/sage/symbolic/units.py  # Killed due to segmentation 
 fault   
 sage -t devel/sage/sage/symbolic/relation.py  # 2 doctests failed 
   
 sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx  # 2 doctests 
 failed   
 sage -t devel/sage/sage/doctest/forker.py  # 1 doctest failed 
   
 sage -t devel/sage/sage/misc/functional.py  # 2 doctests failed   
   
 sage -t devel/sage/sage/misc/cachefunc.pyx  # 1 doctest failed 
  
 sage -t devel/sage/sage/combinat/tutorial.py  # 9 doctests failed 
   
 sage -t devel/sage/sage/tests/french_book/recequadiff.py  # 25 doctests 
 failed

 Many of the failed tests are due to dependence on variables which would 
 have been assigned in previous tests, but failed due to the exception. I 
 might be willing to fix these tests when I have time.

 On Friday, 2 August 2013 07:04:42 UTC-7, Volker Braun wrote:

 I tend to be in favor of the True/False/raise Exception model for testing 
 equality, but has anybody looked into what would be involved to transition 
 the Sage ilbrary? I imagine we would have to adapt a lot of code. 

  

 On Wednesday, July 31, 2013 5:33:30 AM UTC-4, kro...@uni-math.gwdg.de 
 wrote:

 Am Sonntag, 13. April 2008 02:39:24 UTC+2 schrieb William Stein:
  On Sat, Apr 12, 2008 at 5:33 PM, Carl Witty cw...@newtonlabs.com 
 wrote:
  
On Apr 12, 8:58 am, Jason Grout jason-s...@creativetrax.com 
 wrote:
 Carl Witty wrote:
  On Apr 10, 1:41 am, Simon King k...@mathematik.uni-jena.de 
 wrote:
  On Apr 10, 4:18 am, Carl Witty cwi...@newtonlabs.com wrote:

  I like the raise an exception behavior, because it would 
 eliminate
  questions asking why form1 and form2 below are different 
 (from this
  sage-support threadhttp://
 groups.google.com/group/sage-support/browse_thread/thread/79d0...).
  (I have seen this exact problem at least twice on 
 sage-support.)  What
  do you think?
  I guess what i suggest wouldn't solve the plot-issue. However, 
 i think
  if one doesn't know whether an inequality holds, or if the 
 inequality
  simply makes no sense (such as in the case of an unordered 
 field) then
  bool() should neither raise an exception nor return False but 
 return
  None. I think it is much simpler to have
  
The reason why I eventually decided that throwing an exception was
 unpythonic was that I could not find a single case of current 
 python
 code which did that.  Actually, the one reference I did find was a
 bugfix to a project (I think SQLAlchemy), in which they changed
 __nonzero__ to not raise an exception since it was inconsistent 
 with
 other behavior.

 That, and the fact that Python by default returns True for objects
 instead of raising exceptions, tells me that raising exceptions 
 would
 also raise an exceptional number of eyebrows and probably voices 
 too.
  
I agree that raising an exception is somewhat unpythonic, but I 
 don't
think that's an automatic veto on the idea.  Sage does lots of
unpythonic stuff already, and I think we should at least consider
adding one more unpythonic behavior in this case.
  
I still think that most of the times people write if x  0:, they
will be implicitly wanting an unevaluated, symbolic conditional that
we can't automatically provide; in these cases, I think 

[sage-devel] Re: Several bugs

[Jakob Kroeker]

If you want 
to use different term orderings or a localisation, you should construct 
a multivariate polynomial ring with a single variable (I know, this it 
sounds silly and is not obvious). 

@Simon
As state above, the ordering is _silently_ ignored. Thus it is a bug from 
my point of view. Eof.
Or, did I overlook something?


Jakob

Am Donnerstag, 19. Februar 2015 19:22:30 UTC+1 schrieb Simon King:

 Hi Enrique, 

 On 2015-02-19, Enrique Artal enriqu...@gmail.com javascript: wrote: 
  This is not really an issue, the problem is the fact that the=20 
  function=20 
  accept the entry *order* but it ignores it silently.=20 
  
  Ahm, why do you think it is ignored?=20 
  
  I have rechecked that =20 
  *R.t=3DPolynomialRing(QQ,order=3D'neglex');(1+t).is_unit()* yields 
 False 

 The problem here is that you are constructing a univariate 
 polynomial ring, for which Sage does not use Singular. If you want 
 to use different term orderings or a localisation, you should construct 
 a multivariate polynomial ring with a single variable (I know, this it 
 sounds silly and is not obvious). 

 To do so, you should not only provide the list of generator names (this 
 is what you implicitly do when you write R.t = ...), but also the 
 number of generators. Hence: 

   sage: R.t = PolynomialRing(QQ, 1, order='negdeglex') 
   sage: R# Note: It is MULTIvariate 
   Multivariate Polynomial Ring in t over Rational Field 
   sage: R.term_order() 
   Negative degree lexicographic term order 
   sage: (1+t).is_unit() 
   True 

 in contrast to 
   sage: R.t = PolynomialRing(QQ, order='negdeglex') 
   sage: R# Note: It is UNIvariate 
   Univariate Polynomial Ring in t over Rational Field 
   sage: R.term_order() 
   Traceback (most recent call last): 
   ... 
   AttributeError: ... 

 Same for neglex (I actually didn't know that this exists, it is not 
 mentioned in the docstring): 
   sage: R.t = PolynomialRing(QQ, 1, order='neglex') 
   sage: R.term_order() 
   Negative lexicographic term order 
   sage: (1+t).is_unit() 
   True 

 Best regards, 
 Simon 



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: open blockers

[Jakob Kroeker]

 #17679 would need rebasing. 

done

 Also the proposed stopgaps are probably a bit too broad... is the 
testsuite passing with factorization disabled?

I'm new to sage; will the stopgaps break the testsuite? (checking...)

 Also the proposed stopgaps are probably a bit too broad

Factory is notoriusly buggy; it improved over time, but it is still buggy. 
There are more than 20 bugs in factory which are fixed in 4.0.1 but not in 
3.1.7
So, if I understand it right, stopgap is to warn the user if it is known 
that there are bugs leading to wrong results. That is probably
too heavy, but here the sage community have to decide about the policy and 
application of stopgap




Am Donnerstag, 12. Februar 2015 22:25:48 UTC+1 schrieb Volker Braun:

 Can somebody review #17677, #17679, #17681


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: open blockers

[Jakob Kroeker]

 Is there bugs where user gets wrong results?

Yes.


Am Freitag, 13. Februar 2015 12:09:03 UTC+1 schrieb Jori Mantysalo:

 On Fri, 13 Feb 2015, Jakob Kroeker wrote: 

  Factory is notoriusly buggy; it improved over time, but it is still 
  buggy. There are more than 20 bugs in factory which are fixed in 4.0.1 
  but not in 3.1.7 

 Is there bugs where user gets wrong results? I have seen only polynomials 
 giving error messages or halting randomly, but never wrong results. I ran 
 quite many test rounds, but only for multivariate QQ-polynomials. 

 -- 
 Jori Mäntysalo 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: open blockers

[Jakob Kroeker]

Is there bugs where user gets wrong results (from factory)? I have seen 
only polynomials 
giving error messages or halting randomly, but never wrong results


the (factory) stopgap http://trac.sagemath.org/ticket/17681

references a ticket (is a stopgap for)

http://trac.sagemath.org/ticket/17680

with a failing example. But there are more.

To find them I did millions of random examples for primary decomposition 
using two different variants GTZ and SY in Singular
In case the results did not coincide, there were bugs in 'primdec.lib' and 
sometimes in factory.



Jakob



Am Freitag, 13. Februar 2015 12:09:03 UTC+1 schrieb Jori Mantysalo:

 On Fri, 13 Feb 2015, Jakob Kroeker wrote: 

  Factory is notoriusly buggy; it improved over time, but it is still 
  buggy. There are more than 20 bugs in factory which are fixed in 4.0.1 
  but not in 3.1.7 

 Is there bugs where user gets wrong results? I have seen only polynomials 
 giving error messages or halting randomly, but never wrong results. I ran 
 quite many test rounds, but only for multivariate QQ-polynomials. 

 -- 
 Jori Mäntysalo 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: open blockers

[Jakob Kroeker]

 Are the bugs over all fields, e.g.? Maybe thats a way to narrow it down?

Over different fields, not sure if over all (I'm not the author of factory 
and not familiar with the code)


Were you going to set the tickets to needs review after working more on it?

Workaround for now: set prioriry to critical and status to 'need work' (I 
will be not available for the next 2 hours)




Am Freitag, 13. Februar 2015 12:22:24 UTC+1 schrieb Volker Braun:

 Are the bugs over all fields, e.g.? Maybe thats a way to narrow it down?

 Were you going to set the tickets to needs review after working more on it?

 Maybe we should add a boolean flag factorize(proof=None) and optionally 
 check the result depending on the base ring, isn't that much cheaper than 
 computing the factorization anyways?


 On Friday, February 13, 2015 at 12:02:06 PM UTC+1, Jakob Kroeker wrote:

 Factory is notoriusly buggy; it improved over time, but it is still 
 buggy. There are more than 20 bugs in factory which are fixed in 4.0.1 but 
 not in 3.1.7
 So, if I understand it right, stopgap is to warn the user if it is known 
 that there are bugs leading to wrong results.



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: open blockers

[Jakob Kroeker]

 Are the bugs over all fields, e.g.? Maybe thats a way to narrow it down?

Another way to narrow down issues in 'factory' would be to upgrade to 
recent Singular. There of course still bugs in,
but I did not catch them yet, or reported bugs were not tracked down to 
'factory'  ;-) 

I'm working on the upgrade to 4.0.1 (  #17254 
http://trac.sagemath.org/ticket/17254)
Maybe I will finish in a couple of days, maybe it will need one or two 
weeks.

The various issues in polynomial rings over Integers (ZZ) are not fixed 
yet. Adi Popescu is working on that.
Typical bugs in 'groebner()' are premature termination 
http://www.singular.uni-kl.de:8002/trac/ticket/629
non-reduced tail, eating all memory (same examples finish in Macaulay2 in a 
bit) or running forever.



Am Freitag, 13. Februar 2015 12:22:24 UTC+1 schrieb Volker Braun:

 Are the bugs over all fields, e.g.? Maybe thats a way to narrow it down?

 Were you going to set the tickets to needs review after working more on it?

 Maybe we should add a boolean flag factorize(proof=None) and optionally 
 check the result depending on the base ring, isn't that much cheaper than 
 computing the factorization anyways?


 On Friday, February 13, 2015 at 12:02:06 PM UTC+1, Jakob Kroeker wrote:

 Factory is notoriusly buggy; it improved over time, but it is still 
 buggy. There are more than 20 bugs in factory which are fixed in 4.0.1 but 
 not in 3.1.7
 So, if I understand it right, stopgap is to warn the user if it is known 
 that there are bugs leading to wrong results.



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] sage trac hangs when posting a comment with specific wording

[Jakob Kroeker]

Recently I hit a very weird issue on sage trac:

It was for me not possible to post a comment  with a specific wording, (see 
attached ASCII file),
neither did the trac preview work: it just hangs. When I change the text to 
some extent, the issue goes away

It does not matter on which ticket one tries to post that comment; but the 
commend was for ticket #5522.


Question: can someone reproduce the issue, or does it depend on browser 
version?
Try to paste the text without submitting, e.g. it in ticket #5522 and see 
what happens..


Jakob




-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
 This rules out the case where ./sage -ba would have made things better.

I appreciate that you tried to reproduce that issue. 
The issue happened to me when I tried to update Singular (from 3.1.7 to 4.0.1) 
(and will of course not happen if you compile from scratch(!!); that is 
equivalent to
'make distclean' and implies './sage -ba'!

So here some more hints, so I hope it is reproducible, (I'm not sure)

Re: [sage-devel] Is CMake OK for a standard spkg?

[Jakob Kroeker]

Anyway, as mentioned before, according to this thread:

   
http://groups.google.com/group/sage-devel/browse_thread/thread/e91a204a2902afd/ccbdaa4792872282?lnk=gstq=Heads+up#ccbdaa4792872282
singular is migrating to CMake.

For good or bad, Singular did not migrate to CMake. There was too much 
opposition, I guess.


Jakob

Am Montag, 1. März 2010 13:39:59 UTC+1 schrieb William:

 On Sun, Feb 28, 2010 at 11:40 PM, Peter Jeremy peter...@acm.org 
 javascript: wrote:

 For what is worth, we use cmake in FEMhub (femhub.org) as a standard
 package and we never had any problems with that.
 
  If CMake was widely used (and hence can be listed as a prerequisite for
  building Sage - like gmake, bash etc) then it would have no overhead
  for Sage.

 CMake is definitely not as widely used as gmake and bash, so I'm
 against making it a prerequisite for Sage. In the history of the Sage
 project, the only prerequisite that was ever added was gfortran, and
 that is really part of GCC (Gnu Compiler Collection), so fairly
 standard.

 Anyway, as mentioned before, according to this thread:


 http://groups.google.com/group/sage-devel/browse_thread/thread/e91a204a2902afd/ccbdaa4792872282?lnk=gstq=Heads+up#ccbdaa4792872282

 singular is migrating to CMake.  If that really happens, Sage will
 have to include CMake, whether we want to or not.

  -- William



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: singular 4.0.1 upgrade: cython compile for 'plural' peeks wrong lib

[Jakob Kroeker]

Now I tracked the issue down and solved it:
libs for plural in 'src/module_list.py' were incorrect. Since I'm new to 
python/cython, i didn't knew that and grep for 'singular' was not an option 
(too many hits)

Sorry for the noise.


Jakob


Am Donnerstag, 5. Februar 2015 13:38:34 UTC+1 schrieb Jakob Kroeker:

 I'm getting a strange cython behaviour when compiling 
 u/jakobkroeker/ticket.17254.squashed , 
 http://git.sagemath.org/sage.git/diff/?id2=d27f8497dcd19d70ec08155888e6fec9c74b839aid=6384b9b8d22905e7dcc72b84df33effae9c8a517

 cython tries to pick -lsingular instead of -lSingular when compiling 
 plural:

 g++ -pthread -shared -L~/Projects/sage/local/lib 
 build/temp.linux-x86_64-2.7/build/cythonized/sage/rings/polynomial/plural.o 
 -L~/Projects/sage/local/lib -L~/Projects/sage/local/lib -lcsage -lm 
 -lreadline -lsingular -lgivaro -lgmpxx -lgmp -lstdc++ -lpython2.7 -o 
 build/lib.linux-x86_64-2.7/sage/rings/polynomial/plural.so

 this does not happen for other modules (for them  libSingular.so  is 
 picked correctly !!)

 Remark: Singular v 4.0 and later changed the libnames from 'libsingular.so'  
 to  'libSingular.so'


 Any idea what is going on or where ask for help?






-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: how to explicitly recompile the python part of sage (no pkgs)

[Jakob Kroeker]

rebuild a package worked as described (sage -f singular),
thanks!

However, I have problems with 'sage -b':

sometimes it does not rebuild all python and cython stuff,
even not after a 'ccache -C'  and  'make clean'.
Do I miss something? 


Jakob


Am Montag, 2. Februar 2015 16:15:36 UTC+1 schrieb Volker Braun:

 On Monday, February 2, 2015 at 10:13:39 AM UTC-5, Jakob Kroeker wrote:

 - how to recompile only the python and cython part (no pkgs) ?


 sage -b
  

 - in case that sage is in a broken state, how to rebuild a single pkgs( 
 e.g. Singular) in case a patch file was updated ?


 sage -f singular
  


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] singular 4.0.1 upgrade: cython compile for 'plural' peeks wrong lib

[Jakob Kroeker]

I'm getting a strange cython behaviour when compiling 
u/jakobkroeker/ticket.17254.squashed , 
http://git.sagemath.org/sage.git/diff/?id2=d27f8497dcd19d70ec08155888e6fec9c74b839aid=6384b9b8d22905e7dcc72b84df33effae9c8a517

cython tries to pick -lsingular instead of -lSingular when compiling plural:

g++ -pthread -shared -L~/Projects/sage/local/lib 
build/temp.linux-x86_64-2.7/build/cythonized/sage/rings/polynomial/plural.o 
-L~/Projects/sage/local/lib -L~/Projects/sage/local/lib -lcsage -lm 
-lreadline -lsingular -lgivaro -lgmpxx -lgmp -lstdc++ -lpython2.7 -o 
build/lib.linux-x86_64-2.7/sage/rings/polynomial/plural.so

this does not happen for other modules (for them  libSingular.so  is picked 
correctly !!)

Remark: Singular v 4.0 and later changed the libnames from 'libsingular.so'  
to  'libSingular.so'


Any idea what is going on or where ask for help?




-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] how to explicitly recompile the python part of sage (no pkgs)

[Jakob Kroeker]

Hello,


I'm currently working on ticket #17254
and sometimes I introduce issues such that even if I fix them after a 
failed build trial,
the relevant part gets not rebuild and I'm only be able to  recover with a 
`make distclean`

question:

- how to recompile only the python and cython part (no pkgs) ?
- in case that sage is in a broken state, how to rebuild a single pkgs( 
e.g. Singular) in case a patch file was updated ?


Thanks,


Jakob


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Can We Trust Computer Algebra Systems?

[Jakob Kroeker]

I wrote 
 

 I'm aware of this(stopgame framework); it is a good start. AFAIK it does 
 not support 'stopgame' at function level, only at package level.


This statement was of course completely wrong.

@William
why did you not blame me for that?

You can see 52 tickets involving it here: 

http://trac.sagemath.org/search?q=stopgap 

 

If you know of *anything* that should be added, contributions are 
 greatly welcome. 



a first step:

http://trac.sagemath.org/search?q=stopgap+jakob


Jakob

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Place for internal documentation of a class

[Jakob Kroeker]

 Again it depends on the case. Not every algorithm needs to be documented, 
 some things are necessarily assumed to be known to anybody who wants to 
 make relevant changes. I don't think Sage explains the algorithm for 
 solving CRT anywhere...


Agree. I did not have in mind well-known algorithms.

See for example the compete documentation issue overview of Singulars 
'factory', 
https://github.com/Singular/Sources/issues/637

More than 60 percent of the source code is not documented at all.


How is the class hierarchy not best described by the code? If you can't be 
 bothered to read the code you can also use Python's inspection abilities.


You score a point  here (use Python's inspection abilities)

Despite from that I hope you understand what I have in mind with developer 
documentation.
I really hope that I'm wrong, but I predict that in case that it is missing 
or not adequate, 
in ten or twenty years sage may get serious problems with rotten and 
unmaintainable source code,
because at that point many current developers will have left the sage 
project and fresh developers may fail to understand the old sources.

And because in history predictors or carriers of bad news were burned, I 
will shut up now on that topic.


Jakob


Am Montag, 5. Januar 2015 22:41:32 UTC+1 schrieb Volker Braun:

 On Monday, January 5, 2015 5:45:21 PM UTC+1, Jakob Kroeker wrote:

 class diagrams,  state transition diagrams, internal code 
 interdependencies/implemented design patterns, call graphs


 How is the class hierarchy not best described by the code? If you can't be 
 bothered to read the code you can also use Python's inspection abilities.

 Adding a link/reference to the underlying algorithm is definitely 
 desirable.

 Despite from the fact that (I guess) this basic rule is obvious, in 
 reality its often violated, at least in Singular code.




-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Place for internal documentation of a class

[Jakob Kroeker]

 * Document the why, not the how


Does the 'why' implicate documentation for an abstract description of the 
implementation design (if not obvious) and the (reference to) underlying 
algorithms?

I just looked at the sage review checklist and did not find and advice to 
check for appropriate developer documentation (e.g. class design or 
reference to implemented algorithm)

If that is missing it may and will cost for a new developer/maintainer  
unreasonably  big effort  to understand a design or  reconstruct an 
algorithm from the source,
what is often mandatory to maintain or extend existing implementation.

Jakob

Am Montag, 5. Januar 2015 11:36:23 UTC+1 schrieb Volker Braun:

 The __init__ docstring is used as the class docstring if there is no 
 separate class docstring, this is what I would recommend if you want it 
 seen. Alternatively you can force sphinx to show it with a .. automethod: 
 instruction.

 As for what is appropriate to document, the usual adages apply:

 * Document the why, not the how
 * Place the documentation as close to the relevant code as possible.

 Anything that affects only a single method has no place outside of that 
 method. If it can be written as a code comment, then that is preferrable. 
 Only very high-level documentation should ever be placed in the class 
 scope, e.g. Performance-critical: This class implements geobuckets for 
 non-communative polynomials. 




-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Place for internal documentation of a class

[Jakob Kroeker]

 I don't understand what you mean by design. If you code isn't readable 
 then that can't be fixed by documentation, only by writing clear code.



The program architecture, the grand picture (if not obvious): class 
diagrams,  state transition diagrams, internal code 
interdependencies/implemented design patterns, call graphs;
 everything a developer cannot extract by a code inspection without major 
effort in comparison to reading the developer documentation.

AFAIK, Nathann Cohen did hit this issue when working on the poset 
implementation.


Adding a link/reference to the underlying algorithm is definitely desirable.


Despite from the fact that (I guess) this basic rule is obvious, in reality 
its often violated, at least in Singular code.
For me that is a reason to extend the review checklist by this point. What 
do you think?

Of course we cannot put everything on the checklist. In case it turns out 
mandatory to put on the checklist that the people should 
breath, I probably would give up and move away ;-)


Am Montag, 5. Januar 2015 16:00:54 UTC+1 schrieb Volker Braun:

 On Monday, January 5, 2015 3:15:07 PM UTC+1, Jakob Kroeker wrote:

 Does the 'why' implicate documentation for an abstract description of the 
 implementation design


 I don't understand what you mean by design. If you code isn't readable 
 then that can't be fixed by documentation, only by writing clear code.
  

 (reference to) underlying algorithms?


 Adding a link/reference to the underlying algorithm is definitely 
 desirable.

  

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: proposed amendment to code of conduct

[Jakob Kroeker]

As already mentioned by others, the bad thing (at least from my point of 
view) is that the 'code of conduct' splits the community.
To reduce the dissonance among us we could agree on something with broader 
support.
Otherwise I hope that this discussion will end at some point, and I will 
try to forget and fade out that there was
this discussion at all and that there is a 'code of conduct'

Jakob

Question 1: who of the initial 'yes' voters would insist to keep the term 
'code of conduct'
Question 2: who of the initial 'No' voters would accept the term 
'guidelines' instead with content as is 
Question 3: who would accept the term 'guidelines' and also insist on 
changing the content of the behaviour guidelines

Am Freitag, 28. November 2014 14:09:38 UTC+1 schrieb Nathann Cohen:

  I welcome your enthusiasm but please can we stick to established 
 nomenclature? 
  If you insist on not calling it Code then please also 
  explain why Fedora and Django have made a mistake in naming it. 

 O_o 

 Dear friend, I am getting slowly convinced that one of us is crazy. 
 Assuming, as I cannot disprove it, that I am the crazy one, I will 
 answer your question: 

 I cannot explain why Fedora or Django did differently, simply because 
 I do not know them. I have no idea what they do, how they work, or if 
 they have psychiatric problems. If we have to explain, for whatever we 
 do, why Fedora and Django did differently, we just can't take any 
 decision by ourselves. Unless you take them for us, of course. I 
 strongly believe that I am not the only one here who has no clue about 
 why Fedora and Django are great, and an example we should follow. 

 One very disturbing thing I noticed about Fedora and Django is that 
 they do not even seem to write mathematical code. I do not know what 
 to think about that. 

  A document 
  that you first need to reverse-translate from Frenglish to French to 
 English 
  to understand is not helpful. 

 I have no idea on earth what you are talking about. If you need 
 frenglish lessons I can give you some. It is very simple: just speak 
 french with an english accent. Of course most words will not 
 translate, but you have to keep a poker face all along. 

 Nathann 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: When/by who/how was the code of conduct initiated ?

[Jakob Kroeker]

Am Mittwoch, 26. November 2014 14:47:29 UTC+1 schrieb Viviane Pons:


I would be in favour of this: having guidelines and not an enforced code.


++ 

...that would require another voting which invalidates the previous one...


Jakob

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Can We Trust Computer Algebra Systems?

[Jakob Kroeker]

 Factoring is the hard one, there have been lots of factoring bugs in 
 Sage coming from Singular (and there still is #17251 in Singular-3-1-7). 


And as correctly noticed, the #17251 is not in Singular 4.0.1
Martin Lee, the former coauthor of 'Singular/factory' is meanwhile very 
familiar with 'factory' and underlying algorithms 
and is able to fix bugs quickly. He fixed all bugs I discovered until now!
The last fix is from 
today:https://github.com/Singular/Sources/commit/d1b07bbb98d7132b6aa0cda7d48dc948e89dae43

So if anybody is able to (auto) detect remaining bugs in Singular's recent  
'factory' (e.g. in 'char_series()' or 'factorize()' ),
in any kind of supported rings, please do so timely.

I have no idea for how long Martin Lee will still maintain 'factory'.


Jakob

Am Samstag, 1. November 2014 10:33:33 UTC+1 schrieb Jeroen Demeyer:

  it seems that Macaulay2 only uses Singular-Factory and Singular-Libfac 
 for a few functions (factor, gcd minimalprimes and 
 irreduciblecharacteristicseries). 

 Factoring is the hard one, there have been lots of factoring bugs in 
 Sage coming from Singular (and there still is #17251 in Singular-3-1-7). 



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Can We Trust Computer Algebra Systems?

[Jakob Kroeker]

 With which money? 


Funding money. If that is not allowed formally, convince funders. 
In fact, in particular cases active testing was already done by some Sage 
developers,
which (I do not know this) probably were not explicitly paid for that task. 
There is money for travel, why not for QA? QA is inherently natural for 
software development.
For example, we could find out, how reliable some routines are (otherwise, 
how to know?),
or how effective are the used development process policies:

The error rate (crash or incorrect result) for primary decomposition in 
recent Singular version
should be down to about 1 per 200.000 examples (I' stressing these routines 
at the moment)
The error rate for algebraic geometry related computations in polynomial 
rings over integers (e.g. groebner, intersect, syzygies...)
should be much worse. Go figure! Or look at the bug reports in the 
bugtrackers (Singular,sage).
In fact, std() over integers in Singular is broken for years.
A serious question: did someone who uses them not notice? And if not, why?


I suggest to think about offering bounties for new reported bugs 
and spend 10  to 30 percent of funding money for QA related tasks -
there is a rule of thumb that for three developers one tester is needed.
To some noticeable extent QA happens during the ticket review process, but 
I doubt
that reviewers stress the routines with random input and compare the 
results of different implementations.


Jakob


Am Mittwoch, 29. Oktober 2014 11:28:01 UTC+1 schrieb Jeroen Demeyer:

 On 2014-10-24 18:09, Jakob Kroeker wrote: 
  I suggest Sage to pay QA staff for actively hunting bugs. 
 With which money? 



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Can We Trust Computer Algebra Systems?

[Jakob Kroeker]

 The fact that it is possible to do it in principle is the important bit,


Mandatory, but of course not sufficient. Just recall the recently 
discovered bash shell bug which was lurking in the source for more than 10 
years.

The important bit is that one can go and check. 


I'm doing this: since in the recent project I ran into many bugs in a 
well-known CAS, and now
I do not trust any function I use and started to look actively for bugs 
(testing and code reviewing) and discovered about 100 bugs during the last 
year. 
Some code parts (which exist and were used for more than 10 years) I 
checked, reach an error rate about 5 bugs per 1000 lines.
Sage builds on top of this CAS and probably on top of other buggy packages.

Does Sage warn somehow the user if a user calls a function which is *known* 
to be buggy?

If possible, I suggest Sage to pay QA staff for actively hunting bugs.


Jakob




Am Freitag, 24. Oktober 2014 17:21:29 UTC+2 schrieb bluescarni:

 On 24 October 2014 05:30, kcrisman kcri...@gmail.com javascript: 
 wrote:


It was an interesting read. The article (at potential risk of starting 
 a firestorm) does seem to suggest that open-source software like Sage is 
 more trustworthy for computational proofs as one can (in principle) verify 
 the code's logic and can look at the list of known bugs.



 In principle.  But naturally we have a bug tracker for a reason.  Also, I 
 didn't have time to look at the article they referenced about some 
 experience with open source; perhaps someone could summarize it.


 The fact that it is possible to do it in principle is the important bit, 
 not if actually people do so. When I am writing a paper I don't necessarily 
 go and check each and every previous result on which the paper is built, 
 but it is essential to be able to do so if desired or needed.

 Likewise, it's not really important (from the point of view of this 
 discussion anyway) if Sage or another open-source software is more or less 
 trustworthy in practice than a closed-source system. The important bit is 
 that one can go and check. Trust and blind faith are two different things.

 I find it quite depressing how publications relying on (or describing) 
 black boxes are routinely accepted and I wish the research community were 
 intellectually honest about this issue.


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Can We Trust Computer Algebra Systems?

[Jakob Kroeker]

 It was fun to read that the day after reading that M-ma gets some 
 small integer determinants wrong! 


Of course, and now what? 
Does Sage a better job? # (attention, I'm needling and trolling):

Sage even fails to compute minimal associated primes of the unit ideal 
correctly:

R.x,y = QQ[x,y];
I = Ideal(R(1));
I.minimal_associated_primes()
#[Ideal (1) of Multivariate Polynomial Ring in x, y over Rational Field]

Sage did make progress in improving the QA in comparison to others.
Still, in my opinion  Sage   has to to improve the culture of QA even more, 
increase
the sensivity to missed special cases
and maybe spread this quality assurance culture among the other groups ,
 e.g. to those who develop packages which are used by Sage.


Jakob

Am Freitag, 24. Oktober 2014 18:21:43 UTC+2 schrieb John Cremona:

 To quote from a posting today to the nmbrthry mailing list: 

 Here I report my related discovery concerning zeta(3) involving the 
 harmonic numbers 

H(n) = Sum_{k=1}^n 1/k   (n = 1,2,3,...). 

 On October 22, 2014 I found that 

zeta(3) = Sum_{k0} (3*H(k)-1/k)/(k^2*binom(2k,k)) 
 .(1) 

 Via the Mathematica command 


 FullSimplify[Sum[(3*HarmonicNumber[k]-1/k)/(k^2*Binomial[2k,k]),{k,1,Infinity}]],
  


 Mathematica 9 could yield the desired result zeta(3) half an hour later. 
 So, (1) does have a proof. 

 It was fun to read that the day after reading that M-ma gets some 
 small integer determinants wrong! 

 John 

 On 24 October 2014 17:16, Jori Mantysalo jori.ma...@uta.fi javascript: 
 wrote: 
  On Fri, 24 Oct 2014, Jakob Kroeker wrote: 
  
  Does Sage warn somehow the user if a user calls a function which is 
  *known* to be buggy? 
  
  
  Sometimes, but for example 
  
  On Fri, 24 Oct 2014, Jean-Pierre Flori wrote: 
  
  We're stuck at http://trac.sagemath.org/ticket/17184. 
  I've also posted on Singular forum: 
  
  
  I know that Singular versions 3.x has a heisenbug, it stucks sometimes 
 when 
  factoring multivariate polynomials over rationals. There is no warning 
  message. 
  
  (But of course user do not get wrong answer, if there is no answer at 
 all.) 
  
  -- 
  Jori Mäntysalo 
  
  
  -- 
  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+...@googlegroups.com javascript:. 
  To post to this group, send email to sage-...@googlegroups.com 
 javascript:. 
  Visit this group at http://groups.google.com/group/sage-devel. 
  For more options, visit https://groups.google.com/d/optout. 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Can We Trust Computer Algebra Systems?

[Jakob Kroeker]

 If you know of *anything* that should be added, contributions are 
 greatly welcome. 


It is not clear yet if I will ever contribute something substantial to sage 
before leaving research, 
so here some suggestions (which are sadly of much less value):

For example, Sage has a 100% doctest policy, and people can inspect 
 the source code of Sage and see that we follow it.


If sage developers find it useful, spread this to other groups!
Consider that there is (e.g. in Singular) a difference between the official 
and practised policy!

- sensitize developers about testing and handling special cases

 - develop and use a framework for auto-testing routines by throwing random 
examples at them
and by comparing different implementations. To my knowledge, there was 
already something done in this direction by the sage group.

- pay QA stuff or users for bug hunting.


*YES, we do*.   At a Sage days a few years ago, Robert Bradshaw, David 
 Roe, me and others introduced a stopgame framework for exactly this. 


I'm aware of this; it is a good start. AFAIK it does not support 'stopgame' 
at function level, only at package level.
I have some suggestions here, but again they are much less worth than real 
contributions.

( AFAIK the user does not get any warnings if he uses polynomial rings over 
integers.
 This functionality is broken in Singular for years and should be 
completely disabled in my opinion until it got fixed.
 There is work in progress by Adi Popescu and Anne Frühbis-Krueger)
)

Jakob


Am Freitag, 24. Oktober 2014 19:01:58 UTC+2 schrieb William:

 On Fri, Oct 24, 2014 at 9:16 AM, Jori Mantysalo jori.ma...@uta.fi 
 javascript: wrote: 
  On Fri, 24 Oct 2014, Jakob Kroeker wrote: 
  
  Does Sage warn somehow the user if a user calls a function which is 
  *known* to be buggy? 

 *YES, we do*.   At a Sage days a few years ago, Robert Bradshaw, David 
 Roe, me and others introduced a stopgame framework for exactly this. 
 You can see 52 tickets involving it here: 

http://trac.sagemath.org/search?q=stopgap 

 If you know of *anything* that should be added, contributions are 
 greatly welcome. 

 I'm extremely appreciative that you (Jakob) are making repeated noise 
 about software quality.  Sage is sufficiently mature (at 10 years old 
 now) that the timing is very much right to have a new round of 
 discussion about how to improve quality. We had a similar 
 discussion around 2006 spurred mainly by Craig Citro and Michael 
 Abshoff, which led to numerous substantial improvements in Sage 
 development.  Last year we had a dramatic improvement in the technical 
 workflow (based on git branches instead of text-based patches) pushed 
 by Andrew Ohana and Volker Braun.But there is much room for 
 improvement. 

 For example, Sage has a 100% doctest policy, and people can inspect 
 the source code of Sage and see that we follow it.  That's something 
 Craig Citro convinced us to do 7 years ago, and it has had I think a 
 genuinely positive impact on our code quality, and ability to have a 
 larger number of developers. Michael Abshoff used to obsessively run 
 valgrind on Sage, which detected and fixed many issues with memory 
 leaks, pointer issues, segfaults, etc.  Is there another lead bullet 
 that we should add to our arsenal? 

 For me the biggest clear technical value in having access to source code 
 is: 

   - It makes it *much easier to adapt/change* for research purposes, 
 since what you *want* to do is often not exactly what the implementors 
 made available.Source code makes this much easier, since (if 
 nothing else) it no question at all makes it possible to more deeply 
 understanding what you're building on. 

   - Reading source code of math software you're using can help you 
 *decide how much to trust or not trust it*.  This is precisely your 
 point -- when you started reading through the code of Singular, you 
 definitely came to conclusion about how much to trust it. Looking 
 at code and deciding -- oh crap, this stuff is a mess -- even if you 
 still use the code in research, is very valuable.Sometimes even 
 bad code is very useful for research purposes, depending on the field 
 of mathematics. An obvious example is integer factorization. 
 Horrible buggy code is still useful there. 

  -- William 


  
  
  Sometimes, but for example 



  
  On Fri, 24 Oct 2014, Jean-Pierre Flori wrote: 
  
  We're stuck at http://trac.sagemath.org/ticket/17184. 
  I've also posted on Singular forum: 
  
  
  I know that Singular versions 3.x has a heisenbug, it stucks sometimes 
 when 
  factoring multivariate polynomials over rationals. There is no warning 
  message. 
  
  (But of course user do not get wrong answer, if there is no answer at 
 all.) 
  
  -- 
  Jori Mäntysalo 
  
  
  -- 
  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

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

[Jakob Kroeker]

I looked at the ticket #12536 and came to the following conclusion:

It is likely 
(I do not understand much about the changes and the #14019 issue)
that indeed  'relabel()'  is based on existing code, which is probably 
buggy,
 so the bug #14019 is only a subsequent error. At the same time I conclude 
that 'relabel()' was 
 not sufficiently tested! Responsible for the latter in my opinion are Anne 
and the reviewer. 
Of course this does not help much to solve the issue...

In general a couple of simple examples is not a sufficient test. But also 
consider
that  most mathematicians are not  professional software developers 
(e.g. at least with basic knowledge in software engineering and adequate 
practical experience)
and just didn't know better. I think that is a big problem.

There should be also resources for maintenance in addition of grants for 
the 'new fancy stuff'. 
Probably all of you would agree that at a certain point building on top of 
broken software
 is just stupid and leads to nowhere. But this happens in real life 
(probably less in Sage in comparison to other CAS, but who knows)
and therefore for me it seems that this insight is not yet in the heads of 
all research sponsors and researchers.


Jakob

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Tell me how the design of the Poset class is not flawed

[Jakob Kroeker]

Dima wrote  

 this is one of the realities of the research software - one has to do new 
 things 
 in academia (e.g. one cannot tell an MSc student that his project will be 
 to fix 
 Sage bugs - he has to do something new!). 

 
But how to deal with this problem?
I predict that if the Sage community fails to solve it, Sage will end up at 
the same point where Singular or other CAS project in trouble is now. 
With the SageMathCloud stuff William tries to get money for development, 
and I really hope that the project will succeed.

In short - you are in a small minority of people here who can afford to 
 spend 
 time on fixing Sage bugs instead of writing papers and grant applications. 

 
Each individual may of course gain some short-term benefit ignoring bugs or 
design issues. 
But the community _cannot_ afford to ignore quality problems(technical 
debt) and in the long term we all will pay the bills!
Or, to formulate it in a positive manner, in the long term adequate quality 
will likely lead to higher productivity.



Jakob


Am Donnerstag, 2. Oktober 2014 10:43:57 UTC+2 schrieb Dima Pasechnik:

 On 2014-10-02, Nathann Cohen nathan...@gmail.com javascript: wrote: 
  Hello ! 
  
 From a quick look-over of the code, it seems like we can always run 
 a 
  topological sort on the elements list passed into FinitePoset without 
 any 
  significant pentality (and should solve the equality issue), or better 
  yet, 
  push that into the linear_extension() method. 
  
  I do not think that it is sufficient: this is what my first message was 
  about. There is no unique linear extension in a Poset, and I see no way 
 to 
  compute a canonical one when the elements can be 'anything' (and do not 
  have a natural total order). 
  
  There doesn't appear to be any 
  linear extension code that is based on the ordering of the elements 
 being 
  passed into FinitePoset. I haven't looked too deeply into it but I 
 could 
  likely do so over the weekend and maybe come up with a working branch. 
  
  Beware, for in FinitePoset the ._list is not 'only' a list but has to be 
 a 
  linear extension. This is one of the things you find out when working on 
  that class. 
  
 Also Nathann, just for the record, I'm very tempted to not work on 
 this 
  based upon your comments because I don't want to make it seem like I'm 
  rewarding your behavior. 
  
  I do not need Poset equality to be true. I do not need this class to be 
  well-written. I don't use it. I don't trust its code anyway. 
  
  I am doing this because this thing is an open-source software, and that 
  when we write code that returns wrong answers we create trouble for 
 other 
  persons. They pay our carelessness. 
  
  My problem, and the reason why I am angry, is that absolutely nobody 
 cares 
  about that. That Florent promised that he would do it 20 months ago and 
  that he did absolutely nothing since. That those who use Posets do not 
 care 
  sufficiently to spend the time to fix that. 
  
  Furthermore, I hate with all my heart that the same persons who come 
 tell 
  me that they do not have sufficient time suddenly find all the time 
 they 
  need to write Grant proposals to the US or Europe, and get solid real 
 tens 
  of thousands of euros of public money or more because of what they will 
 do 
  in Sage. To pay for their planes, for their hotels, for their food. 

 I don't think you are fair here. This is basically a punch below the belt 
 from 
 someone who has great job security to do whatever one wants with their 
 time 
 aimed, perhaps inderectly, at Sage developers who depend on grant money 
 for the very possibility to work on Sage, or in science in general. 

  You are telling me that you do not want to reward a bad behaviour ? Look 
 at 
  me: all the work I do in Sage, all the bugs I fixed and the features I 
  added, all this is what they sell when they ask US and Europe to give 
 them 
  money. And I cannnot trust them even to fix the bugs they create when 
 they 
  code. When a problem happens, everybody ignores it and waits for 
 somebody 
  else to fix it. 

 this is one of the realities of the research software - one has to do new 
 things 
 in academia (e.g. one cannot tell an MSc student that his project will be 
 to fix 
 Sage bugs - he has to do something new!). 
 One of the aims of these grants would be to fund developers specifically 
 to 
 fix bugs. 

 In short - you are in a small minority of people here who can afford to 
 spend 
 time on fixing Sage bugs instead of writing papers and grant applications. 




  
  Even during two years. Even when the problem is so basic that beginners 
  will encounter it. And I obviously don't want you to believe that it is 
 the 
  only time this happened. 
  
  However, I will do so because I want Jori to 
  continue to develop for posets and I want to improve the overall 
 quality 
  of 
  Sage. 
  
  Yeah, me too. That's why I am here. That's why I tried to fix this many 

[sage-devel] Re: weird(?) patchbot build failures for patchbot 'groebner'

[Jakob Kroeker]

 to be related, is there a 
 symlink or something?



 On Monday, September 22, 2014 5:09:20 PM UTC+1, Jakob Kroeker wrote:

 It seems that my patchbot 'groebner' hits (at least in the past) too 
 many build failures, while other patchbots succeeds for the same tickets.
 So I suspect something is/was fishy.

 A typical log did look like 
   
 http://patchbot.sagemath.org/log/16878/debian/wheezy/sid/x86_64/3.8.0-29-generic/groebner/2014-08-29%2016:29:58%20+0200?short

 When I checkout the ticket by hand instead and run 'make -j 23 ' I cannot 
 reproduce the problems yet.

 Any idea about the causing issues?

 Remark: 
 maybe the issue is meanwhile fixed, but now the patchbots stuck in ticket 
 15339, see

   https://github.com/robertwb/sage-patchbot/issues/52

 so I stopped the patchbots 'andromeda' and 'groebner' for now.


 Jakob








-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] weird(?) patchbot build failures for patchbot 'groebner'

[Jakob Kroeker]

It seems that my patchbot 'groebner' hits (at least in the past) too many 
build failures, while other patchbots succeeds for the same tickets.
So I suspect something is/was fishy.

A typical log did look like 
  
http://patchbot.sagemath.org/log/16878/debian/wheezy/sid/x86_64/3.8.0-29-generic/groebner/2014-08-29%2016:29:58%20+0200?short

When I checkout the ticket by hand instead and run 'make -j 23 ' I cannot 
reproduce the problems yet.

Any idea about the causing issues?

Remark: 
maybe the issue is meanwhile fixed, but now the patchbots stuck in ticket 
15339, see

  https://github.com/robertwb/sage-patchbot/issues/52

so I stopped the patchbots 'andromeda' and 'groebner' for now.


Jakob






-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] try to rebuild sage documentation once in case of an error?

[Jakob Kroeker]

Sometimes the build of the documentation fails with 

Error building the documentation.

Note: incremental documentation builds sometimes cause spurious
error messages. To be certain that these are real errors, run
make doc-clean first and try again.

Now I'm questioning if it is a good idea to doc-clean and auto-rebuild the 
documentation *once* by default in case of an error;
at least by the patchbot. If the error persists, do not try that again. 
For the final decision on this question it should be considered that too 
much complexity or intelligence may cause more harm than good.

Any opinions or other thoughts?




-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] patchbot: do not ask interactive questions by default?

[Jakob Kroeker]

 This is the plain vanilla upstream when this question is asked.


Ok, thanks!
Could that branch name be printed in the error message, just to avoid 
confusion for other patchbot users?

1. I find that this question should not be asked and the default should be 
 'No'

 Agreed. 


Should I open a ticket or are no further actions required?

Jakob


Am Dienstag, 16. September 2014 23:24:55 UTC+2 schrieb Robert Bradshaw:

 On Tue, Sep 16, 2014 at 7:07 AM, Jakob Kroeker kro...@uni-math.gwdg.de 
 javascript: wrote:

 Hello,


 I'm running several patchbots. Sometimes I get

 Failing tests in your install: TestsFailed. Continue anyways? [y/N]

 1. I find that this question should not be asked and the default should 
 be 'No'


 Agreed. 
  

 2. If the patchbot says 'Failing tests in your install..', which branch 
 is meant? ' 
('git branch' tells that current branch is patchbot/ticket_merged)...
 st to this group, send email to sage-...@googlegroups.com javascript:.
 Visit this group at http://groups.google.com/group/sage-devel.
 For more options, visit https://groups.google.com/d/optout.

  
 This is the plain vanilla upstream when this question is asked.


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] patchbot: do not ask interactive questions by default?

[Jakob Kroeker]

Hello,


I'm running several patchbots. Sometimes I get

Failing tests in your install: TestsFailed. Continue anyways? [y/N]

1. I find that this question should not be asked and the default should be 
'No'

2. If the patchbot says 'Failing tests in your install..', which branch is 
meant? ' 
   ('git branch' tells that current branch is patchbot/ticket_merged)...


Jakob



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: sparse linear algebra in sage

[Jakob Kroeker]

A long time ago I did numerical eigenvalue computations using 
SLEPC ( see http://www.grycap.upv.es/slepc/ )
There is also Trilinos/Anazazi (I did't use it)

But I was only interested in a part of the spectrum (smallest /largest),
Do you need to compute all eigenvalues?
Maybe (as William said) you should look for available software. 

I know about the following existing survey:
 http://www.grycap.upv.es/slepc/documentation/reports/str6.pdf 


Jakob

Am Samstag, 13. September 2014 20:53:50 UTC+2 schrieb wstein:

 On Sat, Sep 13, 2014 at 11:28 AM, Erik Slivken 
  wrote: 
  William- 
  
  I am trying to find the eigenvalues of a roughly 1x1 sparse 
 matrix 
  with entries from {0,1} (and would like to do this for even larger 
  matrices).  I don't know what could be done to increase the speed (right 
 now 
  it has been running for roughly half a day).  But it said to email you 
 to 
  raise a quota.  Also, if there is special faculty access, this is a 
 project 
  with Chris Hoffman from UW and I am sure he would sign on for more 
 computing 
  power. 
  
  Thanks for your time. 
  
  Cheers, 
  Erik Slivken 
  
  P.S.  How long should it take to find the eigenvalues of a 1x1 
  sparse matrix with entries from {0,1}?  What about a 10^6x10^6 sparse 
 matrix 
  with entries in from {0,1}? 

 Never.   Sage doesn't have any easily available sophisticated sparse 
 linear algebra algorithms, as far as I know.  Linbox (which is in Sage 
 -- a C++ library), might have something; and Cremona's eclib has some 
 gems hidden in it.  I wrote some really stupid sparse linear algebra, 
 which was sufficient for something I did once.   There's several 
 stages to sparse algorithms, and what is in Sage only implements the 
 first part -- the endgame, which is to solve a resulting dense 
 system at a certain point, isn't in sage.  Sebastian Pancratz and I 
 did implement it once 
 somewhere... (not sure), but it isn't in sage (and it was not easy), 
 and now Sebastian works at a bank. 

 Try typing 

 set_verbose(2) 

 to see what is happening, if you're using sage. 

 You should seriously consider searching the web for current available 
 software for sparse linear algebra.  Last I checked, unfortunately, 
 Sage is definitely not an off-the-shelf solution for anything 
 nontrivial involving sparse matrices, except for maybe efficiently 
 storing them. 

 (I've changed the subject and cc'd some people on this email, in case 
 anybody knows anything about sparse linear algebra and wants to chime 
 in.) 

  William 

 -- 
 William Stein 
 Professor of Mathematics 
 University of Washington 
 http://wstein.org 
 wst...@uw.edu javascript: 


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)

[Jakob Kroeker]

 Bill Hart::
 ... There is a lack of documentation on what algorithms are implemented, 
 what their complexities are, or references. Some projects are not 
 threadsafe. Testing is lacking and quite a bit of stuff just doesn't work 
 and never did. And there is a general lack of credit given to individual 
 developers in Europe by their own projects. Most importantly there is a 
 culture of not giving appropriate academic credit to individuals who have 
 made significant contributions to writing mathematical software.

 I don't see that Sage has contributed to fixing a single one of these hard 
 problems. 


I'm not sure if Singular/GAP did solve that problems either or has not more 
problems. Even if in general it is good to have alternatives (to Sage), in 
my opinion Singular+Gap is not the right way to do.  
So I hope there will be a new CAS star at the sky which blasts the dated 
Singular and GAP away.

@referees: if you are reading this, just (let experts) evaluate the code 
quality (readability, test coverage, correctness, maintainability, 
extensibility,...) or the development process. You will not like the 
outcome. Every couple of days I hit a bug in Singular and meanwhile I'm not 
always officially file an issue in their bug tracking system because I was 
asked to do so. Singulars interpreter language has not even support of 
references (yes, on a function call the data is (mostly) copied! ) and we 
are not talking about data structures for trees or hash tables. Their 
groebner basis computation over intergers is buggy over years and nobody 
noticed or cared ( well, I do, and now Adi Popescu and Anne 
Fruehbis-Krueger are working on that issues ) 

Why is this important? Because otherwise you would be taking European money 
 and using it to fund a project which originated in the US [...] This is 
 crucial from the point of view of referees, in my opinion (again, please 
 bear in mind this is my own personal opinion, and doesn't necessarily 
 reflect the opinion of anyone else I have anything to do with).


Unfortunately in the eyes of the referees some of this arguments (EU vs US) 
could play a role, since what I'm heard from rumors was that one argument 
of the Singular+GAP proposal was to have 
an European alternative to the Sage project...

Am Freitag, 29. August 2014 14:30:16 UTC+2 schrieb Bill Hart:

 One other important point when interpreting my interjection (which again I 
 stress is my own personal opinion), is that when mounting a campaign for a 
 large grant, here in Europe or elsewhere, one must very clearly communicate 
 what *need* is being addressed. If there isn't a clear need, you won't get 
 money.

 If your project is perfect, and you go around telling everyone that it is, 
 you will never be successful in getting the funding you desperately need. 
 The reality here in Europe is that mathematical research projects of a 
 computational nature struggle for their very existence. They are often run 
 out of a single lab with one or two main developers and a few postdocs and 
 PhD's if they are lucky.

 Some European mathematical software projects may not even be around 
 tomorrow if they don't get appropriate funding. Not because they aren't 
 worthy, or didn't have sufficient novelty, research value or smart people 
 working on them or because they weren't feasible, but because everyone just 
 assumed they would keep going on their own. They won't.

 These projects do not exist for the benefit of Sage. And in its current 
 state, no matter how noble or well-intentioned or international Sage is, 
 they can't!

 Sage does add value to those projects by widening the usership of those 
 projects, by contributing bug reports and build patches, by bringing them 
 publicity and in other ways. But one should never confuse this kind of 
 support with sustained funding. In the same way, those project are 
 benefiting Sage by being the best possible core components they can, given 
 the heavy constraints they have on manpower, time and budget. But the end 
 of those projects is not the enrichment of Sage, but the enrichment of 
 their direct beneficiaries, which from the perspective of a grant 
 application is the economy of the country who provided the grants, or the 
 scientific enrichment of the union.

 To that end, we must, in my opinion, be very careful when applying for 
 funds to work on Sage. Who are the beneficiaries? How will they benefit? 
 What is the strategy to achieve that goal? Is it sustainable, practical? 
 What scientific merit does it have? How does it leverage the local 
 expertise? What is its novelty? How well is it engineered?

 That's another 2c I'm owed for my personal opinion.

 Bill.

 On Friday, 29 August 2014 14:03:06 UTC+2, Bill Hart wrote:



 On Friday, 29 August 2014 13:17:40 UTC+2, Volker Braun wrote:

 First of all, it always saddens me when the ugly head of nationalism 
 rears its head. I thought the time where we only support German science 
 were 

Re: [sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)

[Jakob Kroeker]

 If Singular were not maintained, all those thousands of man-hours of work 
 would bitrot and become unavailable to the Open Source community, and it 
 would/could not be replaced!
 The most valuable commodity of the Singular project is the existing code, 
 and it needs direct and continued investment to maintain that functionality 
 and to extend and improve it.

[...] There's no point building a dog house if you don't feed the dog!


 
I'm with you here, so the new project should use a different funding and 
the funding of Singular+GAP should not be shut down (and I guess that the 
reviewers realize that, too)
However, I predict that Singular (kernel and interpreter) will slowly fade 
away.

Case in point. No less than 5 minutes ago, someone just showed me 
 parallelised polynomial factorisation code that will be in Singular 
 (hopefully) in the next release. It was developed as part of Singular's 
 Factory. That represents years of investment by the DFG.
 That code, on a single core, was already faster than Magma. It is now much 
 faster. Not a bad investment, I'd say!


Yes, it looks like. But consider that Martin Lee (he is currently the main 
factory developer)  leaves in a couple of weeks, but only 30 percent of the 
source code is documented. References to the implemented algorithms and 
code examples are mostly missing. There are only interface tests, no small 
meshed ones (that is, for every internal routine). 
I can't say much about factorization, but in 'char_series()', which is part 
of 'factory' I observed about 10 bugs in the last weeks. Does that still 
sound like a good investment?
For me it currently sounds that without appropriate counteractions the 
success story may turn into a Pyrrhic victory.


There has been some talk of making the Gap language a standard. Some people 
 seem to think it could be made so.


In comparison to Singular GAP is in my opinion the lesser of two evils. So 
if I would have to choose between Singular and GAP I would go with GAP.

Jakob


Am Freitag, 29. August 2014 16:30:43 UTC+2 schrieb Bill Hart:



 On Friday, 29 August 2014 15:12:05 UTC+2, Jakob Kroeker wrote:

 Bill Hart::
 ... There is a lack of documentation on what algorithms are implemented, 
 what their complexities are, or references. Some projects are not 
 threadsafe. Testing is lacking and quite a bit of stuff just doesn't work 
 and never did. And there is a general lack of credit given to individual 
 developers in Europe by their own projects. Most importantly there is a 
 culture of not giving appropriate academic credit to individuals who have 
 made significant contributions to writing mathematical software.

 I don't see that Sage has contributed to fixing a single one of these 
 hard problems. 


 I'm not sure if Singular/GAP did solve that problems either or has not 
 more problems. Even if in general it is good to have alternatives (to 
 Sage), in my opinion Singular+Gap is not the right way to do.  


 I didn't know it had even had much of a chance to get going. I do know 
 that it needs a lot more investment of time and money.
  

 So I hope there will be a new CAS star at the sky which blasts the dated 
 Singular and GAP away.


 I think that is the wrong approach. You are looking at it from a user's 
 perspective, in that you'd like to have a nice Sage-like interface with all 
 the functionality you require. 

 But just writing a shiny new CAS doesn't give that to you. You still need 
 the fast Groebner basis engine underneath, and the years of development 
 that has gone into the multivariate arithmetic and to some extent the 
 thousands of man-hours that have gone into libraries that use those things 
 developed by mathematical researchers, who whilst working on those projects 
 were the leading experts in their field.

 No amount of shiny CAS or even new funding, will give that to you all over 
 again.

 Case in point. No less than 5 minutes ago, someone just showed me 
 parallelised polynomial factorisation code that will be in Singular 
 (hopefully) in the next release. It was developed as part of Singular's 
 Factory. That represents years of investment by the DFG.

 That code, on a single core, was already faster than Magma. It is now much 
 faster. Not a bad investment, I'd say!
  


 @referees: if you are reading this, just (let experts) evaluate the code 
 quality (readability, test coverage, correctness, maintainability, 
 extensibility,...) or the development process. You will not like the 
 outcome. Every couple of days I hit a bug in Singular and meanwhile I'm not 
 always officially file an issue in their bug tracking system because I was 
 asked to do so. 


 Unfortunately referees tend to not have time to examine large codebases in 
 detail. They will however look at things such as past return on investment, 
 the merits of the scientific/mathematical proposal, benefit to 
 stakeholders, track record, how sound the proposal is from a technical 
 perspective

[sage-devel] Re: review requests

[Jakob Kroeker]

Hi Martin,

I will even review the 16585 or at least major parts of it, 
but i'm currently on vacation so it will not happen before the 15th 
september.



Jakob

Am Montag, 4. August 2014 19:26:44 UTC+2 schrieb Martin Albrecht:

 Hi all, 

 anyone up for reviewing: 

 1) 

   http://trac.sagemath.org/ticket/15672 

 which fixes a simple bug in the Magma interface when computing Gröbner 
 bases. 

 2) 

   http://trac.sagemath.org/ticket/16585 

 which improves Polynomial Sequences and fixes many small annoyances there. 

 Cheers, 
 Martin

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] upgrade to singular 4.0 in sage?

[Jakob Kroeker]

Hello,

in the meantime the fourth patch of Singular release 4.0 is available at 
http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-0-0/

(please ignore the offered 3.1.7 version on their homepage; I don't really 
know why they promote v3.7)

Among the re-factoring v4.0 contains a lot of bug fixes (and likely some 
new bugs). I also know that in 4.0 there will be no more major 
design changes (in 4.1 there will be).

I would really really like (for now, due to a lack of viable alternatives) 
to use singular 4.0 in sage to implement some special cases for resolution 
of singularities,
since it would be a pain to do it in singular due to missing language and 
library features.

Unfotrunately I'm not too familiar with sage and libsingular so I could not 
easily upgrade the used version in sage from 3.1.6 to 4.0 by myself
even if I wanted. So I'm asking here for help/volunteers for that task. 

In turn, I will work on other sage tickets and you can also file me known 
major singular bugs (for the recent version)
and I will annoy the Singular community to fix them.


Jakob


Remark: i would not depend that hard on Singular if sage had independent 
implementations e.g of 
primary decomposition (which is undocumented spaghetti mess in Singular 
libs anyway) and ring normalization algorithms.

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] failing doctest for sage/structure/sage_object.pyx

[Jakob Kroeker]

./sage -sh -c tar --version # not 'sage -sh -c tar --version' - 
multiple installations!
tells me the same (version 1.26)

rpm -qf /bin/tar: 
  tar-1.26-11.1.x86_64

Interesting, but the error message is not in tar

  
For me it _is_ in 'tar' on that machine. When I grep the string from above 
I get a hit for ' /bin/tar'. 
Maybe 'tar' was patched by the local admin?

I fixed the issue by installing 'tar' v1.28 from sources user-local.



Jakob


Am Mittwoch, 27. August 2014 10:55:24 UTC+2 schrieb Volker Braun:

 Interesting, but the error message is not in tar (and, grepping through 
 the tar git repo, has never been in Gnu tar). So you are using some other 
 tar in the sage shell?

 sage -sh -c tar --version

 If that doesn't bring anything up, run the doctest under strace -ff and 
 see which processes are being run.


 On Tuesday, August 26, 2014 11:44:47 PM UTC+1, Jakob Kroeker wrote:

 OS:
 openSUSE 12.3 (x86_64)
 VERSION = 12.3
 CODENAME = Dartmouth

 tar --version
 tar (GNU tar) 1.26

 Am Dienstag, 26. August 2014 23:11:43 UTC+2 schrieb vdelecroix:

 What's your tar version? (ie what does answer the command tar 
 --version). Looks like you have a very strange one. 

 And, by the way, what is the system you are interested in? Might be 
 useful to know for debugging... 

 Vincent 

 2014-08-26 22:06 UTC+02:00, Jakob Kroeker kro...@uni-math.gwdg.de: 
  
  Hello, 
  
  a doctest fails on an system I'm interested in (I want to run patchbot 
 on 
  that system) 
  
  File src/sage/structure/sage_object.pyx, line 1411, in 
  sage.structure.sage_object.unpickle_allFailed example: 
  sage.structure.sage_object.unpickle_all()  # (4s on sage.math, 2011) 
  Expected:doctest:... DeprecationWarning: This class is 
 replaced by 
  Matrix_modn_dense_float/Matrix_modn_dense_double.See 
  http://trac.sagemath.org/4260 for details.Successfully 
 unpickled ... 
  objects.Failed to unpickle 0 objects.Got:*** The 
 old 
  options style (`tar fx ...`) is highly discouraged, please use the 
 modern 
  form (leading dash before options).*** The standard way (with 
  expanded options; you can still bundle options) for your command would 
 be: 
  tar -f - -x... 
  
  Any idea about the cause/how to fix it? 
  
  -- 
  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+...@googlegroups.com. 
  To post to this group, send email to sage-...@googlegroups.com. 
  Visit this group at http://groups.google.com/group/sage-devel. 
  For more options, visit https://groups.google.com/d/optout. 
  



-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] failing doctest for sage/structure/sage_object.pyx

[Jakob Kroeker]

Hello,

a doctest fails on an system I'm interested in (I want to run patchbot on that 
system)

File src/sage/structure/sage_object.pyx, line 1411, in 
sage.structure.sage_object.unpickle_allFailed example:
sage.structure.sage_object.unpickle_all()  # (4s on sage.math, 2011)
Expected:doctest:... DeprecationWarning: This class is replaced by 
Matrix_modn_dense_float/Matrix_modn_dense_double.See 
http://trac.sagemath.org/4260 for details.Successfully unpickled ... 
objects.Failed to unpickle 0 objects.Got:*** The old 
options style (`tar fx ...`) is highly discouraged, please use the modern form 
(leading dash before options).*** The standard way (with expanded 
options; you can still bundle options) for your command would be: tar -f - -x   
 ...

Any idea about the cause/how to fix it?

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] failing doctest for sage/structure/sage_object.pyx

[Jakob Kroeker]

OS:
openSUSE 12.3 (x86_64)
VERSION = 12.3
CODENAME = Dartmouth

tar --version
tar (GNU tar) 1.26

Am Dienstag, 26. August 2014 23:11:43 UTC+2 schrieb vdelecroix:

 What's your tar version? (ie what does answer the command tar 
 --version). Looks like you have a very strange one. 

 And, by the way, what is the system you are interested in? Might be 
 useful to know for debugging... 

 Vincent 

 2014-08-26 22:06 UTC+02:00, Jakob Kroeker kro...@uni-math.gwdg.de 
 javascript:: 
  
  Hello, 
  
  a doctest fails on an system I'm interested in (I want to run patchbot 
 on 
  that system) 
  
  File src/sage/structure/sage_object.pyx, line 1411, in 
  sage.structure.sage_object.unpickle_allFailed example: 
  sage.structure.sage_object.unpickle_all()  # (4s on sage.math, 2011) 
  Expected:doctest:... DeprecationWarning: This class is replaced 
 by 
  Matrix_modn_dense_float/Matrix_modn_dense_double.See 
  http://trac.sagemath.org/4260 for details.Successfully 
 unpickled ... 
  objects.Failed to unpickle 0 objects.Got:*** The old 
  options style (`tar fx ...`) is highly discouraged, please use the 
 modern 
  form (leading dash before options).*** The standard way (with 
  expanded options; you can still bundle options) for your command would 
 be: 
  tar -f - -x... 
  
  Any idea about the cause/how to fix it? 
  
  -- 
  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+...@googlegroups.com javascript:. 
  To post to this group, send email to sage-...@googlegroups.com 
 javascript:. 
  Visit this group at http://groups.google.com/group/sage-devel. 
  For more options, visit https://groups.google.com/d/optout. 
  


-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] patchbot/build issues ?

[Jakob Kroeker]

Hello,

when I try to run *patchbot* on   machine 'A' I observe several errors, e.g.

Getting ticket list...
fatal: Invalid revision range 
389fbf0cd408302c14635d7979f39297c1f6a2b2..patchbot/base



Resolving sage.math.washington.edu... 128.208.160.197
Connecting to sage.math.washington.edu|128.208.160.197|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2014-08-11 12:06:57 ERROR 404: Not Found.

##

Traceback (most recent call last):
  File ~/Projects/sage/local/bin/patchbot/patchbot.py, line 439, in 
test_a_ticket
self.check_spkg(spkg)
  File ~/Projects/sage/local/bin/patchbot/patchbot.py, line 571, in 
check_spkg
do_or_die(wget --progress=dot:mega -O %s %s % (local_spkg, spkg))
  File /home/kroeker/Projects/sage/local/bin/patchbot/util.py, line 107, 
in do_or_die
raise exn_class, %s %s % (res, cmd)


Any idea what is getting wrong

and on another machine sometimes


[reference] WARNING: Unable to fetch 
~/Projects/sage-patchbot/src/doc/output/doctrees/en/reference/modfrm_hecketriangle/environment.pickle
Error building the documentation.
Traceback (most recent call last):
  File ~/Projects/sage-patchbot/src/doc/common/builder.py, line 1490, in 
module
getattr(get_builder(name), type)()
  File ~/Projects/sage-patchbot/src/doc/common/builder.py, line 291, in 
_wrapper
getattr(get_builder(document), 'inventory')(*args, **kwds)
  File ~/Projects/sage-patchbot/src/doc/common/builder.py, line 515, in 
_wrapper
getattr(DocBuilder(self.name, lang), format)(*args, **kwds)
  File ~/Projects/sage-patchbot/src/doc/common/builder.py, line 109, in f
execfile(sys.argv[0])
  File ~/Projects/sage-patchbot/src/doc/common/custom-sphinx-build.py, line 
210, in module
raise OSError(ERROR_MESSAGE)
OSError: [reference] WARNING: Unable to fetch 
~/Projects/sage-patchbot/src/doc/output/doctrees/en/reference/modfrm_hecketriangle/environment.pickle


or similar. Is that due to race condition during build?


Jakob

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: review requests

[Jakob Kroeker]

 Let me know if you need any help. 


Well, how to speed up the sage build??

Another unrelated issue I observed is, that sage has problems during 'make' 
  to start gap 
(to generate GAP documentation, I guess)
in case there is already an older GAP installed in the system, together 
with a 
user-defined* '.gap/gap.ini*' . However, at some point (was it trying to 
start GAP?), I got a hint what todo
and solved the problem.





Am Mittwoch, 6. August 2014 11:25:32 UTC+2 schrieb Martin Albrecht:

 Hi Jakob, 

 thanks! 

 Here is some documentation on how to review a patch in Sage: 

http://sagemath.org/doc/developer/trac.html#section-review-patches 

 but it essentially boils down to reading the code and checking if it is 
 sound 
 + checking that it indeed solves the problem + was a testcase added? 

 Note that the green circle in the top right of the ticket at 

http://trac.sagemath.org/ticket/15672 

 tells you that normal doctests pass and that the patch applies. This does 
 not 
 test optional doctests, though, i.e. those involving Magma. Let me know if 
 you 
 need any help. 

 Cheers, 
 Martin 

 On Wednesday 06 Aug 2014 01:12:55 Jakob Kroeker wrote: 
  Hi Martin, 
  
  
  I would review (the simple) 15672. 
  Since it is my first review in Sagemath, I have to find out how to 
 review 
  first 
  and how to check, that your patch is indeed correct. 
  
  
  Jakob 
  
  Am Montag, 4. August 2014 19:26:44 UTC+2 schrieb Martin Albrecht: 
   Hi all, 
   
   anyone up for reviewing: 
   
   1) 
   
 http://trac.sagemath.org/ticket/15672 
   
   which fixes a simple bug in the Magma interface when computing Gröbner 
   bases. 
   
   2) 
   
 http://trac.sagemath.org/ticket/16585 
   
   which improves Polynomial Sequences and fixes many small annoyances 
 there. 
   
   Cheers, 
   Martin

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: review requests

[Jakob Kroeker]

Hi Martin,


I would review (the simple) 15672.
Since it is my first review in Sagemath, I have to find out how to review 
first
and how to check, that your patch is indeed correct.


Jakob


Am Montag, 4. August 2014 19:26:44 UTC+2 schrieb Martin Albrecht:

 Hi all, 

 anyone up for reviewing: 

 1) 

   http://trac.sagemath.org/ticket/15672 

 which fixes a simple bug in the Magma interface when computing Gröbner 
 bases. 

 2) 

   http://trac.sagemath.org/ticket/16585 

 which improves Polynomial Sequences and fixes many small annoyances there. 

 Cheers, 
 Martin

-- 
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.