[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

[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.

Re: [sage-devel] Too many Maximas!

[William Stein]

On Wed, Feb 8, 2017 at 11:07 AM, Ralf Stephan  wrote:
> On Wednesday, February 8, 2017 at 4:58:26 PM UTC+1, kcrisman wrote:
>>
>> But there is no reason to *remove* the pexpect, just to make Sage not
>> dependent upon it for any "normal" operations.
>
>
> You mean we should leave its dead code in Sage when we're done, just to make
> sure porting stays inherently difficult?

As explained by several people above, it is not required for
symbolics, but it does implement several unique features that are not
available in any other way...

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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



-- 
William (http://wstein.org)

-- 
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] Too many Maximas!

[Ralf Stephan]

On Wednesday, February 8, 2017 at 4:58:26 PM UTC+1, kcrisman wrote:
>
> But there is no reason to *remove* the pexpect, just to make Sage not 
> dependent upon it for any "normal" operations.
>

You mean we should leave its dead code in Sage when we're done, just to 
make sure porting stays inherently difficult?

-- 
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] Too many Maximas!

[kcrisman]

> To answer this question for myself--as the discussion on what Maxima 
> is used for in Sage pointed me in the right direction--the 
> sage/calculus tests reliably start up at least 3 maxima processes, 
> which then run away with my CPU even after the those tests are 
> finished.  I'll see if I can see what exactly they are doing. 
>

I believe that some doctests explicitly start up maxima not via maxima_lib 
(as opposed to some perhaps silently doing this #17753), maybe in the 
tutorial or constructions documents.  I think it would be reasonable to 
replace some of those if they are causing problems.

But there is no reason to *remove* the pexpect, just to make Sage not 
dependent upon it for any "normal" operations.

-- 
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.

[sage-devel] Re: GSoC 2017 kickoff

[Dima Pasechnik]

On Wednesday, February 8, 2017 at 11:03:57 AM UTC, David Coudert wrote:
>
> That's clearly something we need.
> If the student is good and fast, (s)he can also try to implement the 
> split-decomposition which is a generalization of modular decomposition that 
> can be computed in linear time (roughly finds complete bipartite graph 
> separators).
>
> Also, we could consider adding efficient implementations of several 
> graph-traversals like LexBFS.
>

OK, I've added these too.
 

>
> David.
>
> Le mardi 7 février 2017 19:14:20 UTC+1, Dima Pasechnik a écrit :
>>
>> I've added a project on modular decomposition of graphs and digraphs.
>>
>> How many more we would like to have?
>>
>> On Thursday, January 19, 2017 at 6:05:19 PM UTC, Harald Schilly wrote:
>>>
>>> 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.

[sage-devel] Re: GSoC 2017 kickoff

[David Coudert]

That's clearly something we need.
If the student is good and fast, (s)he can also try to implement the 
split-decomposition which is a generalization of modular decomposition that 
can be computed in linear time (roughly finds complete bipartite graph 
separators).

Also, we could consider adding efficient implementations of several 
graph-traversals like LexBFS.

David.

Le mardi 7 février 2017 19:14:20 UTC+1, Dima Pasechnik a écrit :
>
> I've added a project on modular decomposition of graphs and digraphs.
>
> How many more we would like to have?
>
> On Thursday, January 19, 2017 at 6:05:19 PM UTC, Harald Schilly wrote:
>>
>> 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] Too many Maximas!

[Erik Bray]

On Wed, Feb 8, 2017 at 10:36 AM, Erik Bray  wrote:
> On Tue, Feb 7, 2017 at 6:49 PM, Jeroen Demeyer  wrote:
>> On 2017-02-07 17:30, Erik Bray wrote:
>>>
>>> A problem I've been having lately when running Sage's test suite on
>>> Cygwin (i.e. sage -t -a).
>>>
>>> Several of the tests that use Maxima are spinning up Maxima processes
>>> (I guess interacted with via pexpect?) and not killing them.
>>
>>
>> This is probably Cygwin-specific. It would help if you could give some more
>> details. For example: is the problem reproducible or does it only happen
>> sometimes? Do you know which files cause the problem? Do the doctests
>> actually pass? Does Cygwin have something like strace which might help to
>> debug this?
>
> Yes, almost certainly Cygwin-specific.  Though I'm not sure when it
> started--this didn't happen when I was running the tests a few months
> ago.
>
> It's reproducible insofar as every time I run the full test suite it
> happens.  I haven't pinpointed any specific tests that cause the
> problem--that's mainly what I was asking for help with. I.e. what are
> some tests that use Maxima?

To answer this question for myself--as the discussion on what Maxima
is used for in Sage pointed me in the right direction--the
sage/calculus tests reliably start up at least 3 maxima processes,
which then run away with my CPU even after the those tests are
finished.  I'll see if I can see what exactly they are doing.

-- 
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] Too many Maximas!

[Erik Bray]

On Tue, Feb 7, 2017 at 6:49 PM, Jeroen Demeyer  wrote:
> On 2017-02-07 17:30, Erik Bray wrote:
>>
>> A problem I've been having lately when running Sage's test suite on
>> Cygwin (i.e. sage -t -a).
>>
>> Several of the tests that use Maxima are spinning up Maxima processes
>> (I guess interacted with via pexpect?) and not killing them.
>
>
> This is probably Cygwin-specific. It would help if you could give some more
> details. For example: is the problem reproducible or does it only happen
> sometimes? Do you know which files cause the problem? Do the doctests
> actually pass? Does Cygwin have something like strace which might help to
> debug this?

Yes, almost certainly Cygwin-specific.  Though I'm not sure when it
started--this didn't happen when I was running the tests a few months
ago.

It's reproducible insofar as every time I run the full test suite it
happens.  I haven't pinpointed any specific tests that cause the
problem--that's mainly what I was asking for help with. I.e. what are
some tests that use Maxima?

And yes, the tests pass.  I just watch `ps` and every few minutes
there will be about a dozen new `maxima` processes running, each using
an equal percentage of the CPU time.  I kill them and it doesn't seem
to have any impact on the tests, as whatever tests were responsible
for starting them are long passed.

-- 
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] Too many Maximas!

[Erik Bray]

On Tue, Feb 7, 2017 at 9:35 PM, Jean-Pierre Flori  wrote:
> Our pexpect interface happily leaves zombies around on linux because it
> never waits on the processes it forks.
> At least for each instantiation of the pexpect class it tries to launch
> sage-cleaner to have at least one instance running and only the first does
> actual work, the other ones becoming zombies.
> Not sure about the real process, i.e. maxima, magma, ..., anymore.

What do you mean here exactly?  It would be fine if it left a zombie
process since that would ultimately be reaped.  What's weird is that
the processes are all busy-waiting.

-- 
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] Experience from Sage Review Day 3: An online hacking event

[Clement Pernet]

Hi,

Thanks Johan for this summary.
I definitely second your statement: it was a successful meeting with a very high output / 
organization overhead ratio.


For those interested in the details of this output:
- the framapad: https://bimestriel.framapad.org/p/SageReviewDay3
- trac tickets with keywords rd3: https://trac.sagemath.org/query?keywords=~rd3

Just a few more remarks/suggestions for further editions

- numerous tickets of various difficulty should be open (i.e. problems identified) before the 
beginning of the meeting.
- I found slack quite unfriendly to the user, due to popups (e.g. when writing #...) and weird 
scrolling behaviour. We might want to use gitter next time.
- This format of meeting is very likely less convenient for newcommers to join the project: the 
short time frame and the distance make communication work best with experienced developpers. IIRC, 
dev 1 (2008!) was already in this spirit : mostly directed to developpers with some experience already.


I'm planning to organize another such online dev meeting in the near future for linear algebra and 
linbox interface related topics.


Best
Clément

Le 08/02/2017 à 09:21, Johan S. H. Rosenkilde a écrit :

Hi sage-devel

Yesterday we held Sage Review Day 3, and it was a big success. I just
wanted to briefly share my experience with this.

Overall, 8 developers participated, most of them all day. We
communicated using Slack, Framapad and Trac. We got 14 tickets
positively reviewed, and had good progress on 3 more tickets.

Planning:
Minimal. We started as 5 developers who wished to give an extra push on
coding theory. We set a date, created a Sage wiki page, and announced on
sage-devel, as well as sending emails to participants of SD75. Just
before the event, we made sure the coding theory dev page on Trac,
https://trac.sagemath.org/wiki/SageCodingRoadMap, was updated; we
created a Slack team page; and a framapad with skeleton information.


During the day:
Communication was four-fold:

1) The coding theory dev page on trac served as a static list of tickets
needing work - everyone looked at that list for tasks.

2) Slack served as live chat and gave a nice atmosphere of working
together. Devs announced work, needs reviews, positive reviews, asked
for assistance, and made jokes. It was a huge motivator.

3) Framapad was a live reference list of what people were working on and
what had already been done.

4) Trac tickets were as always where "official" discussions were taking
place (posts/push followed by a poke on Slack usually).


Aftermath:
For me, this was a great way to set aside a well-defined amount of time
for Sage development. It was also much more efficient than usual
scattered efforts, since context switching takes a lot of time.
Interaction btw. developer and reviewer was immediate, and getting
response on a ticket 5 mins after posting the code is immensely
satisfying.

I feel that this is a fruitful, informal way to coordinate work on Sage.
There really was a mini-Sage Days feeling over it! One reason for the
big feeling of success was that coding theory had so many outstanding
tickets waiting review. Actual designing and serious implementation
would lead to much fewer tickets being finished, and perhaps less
dynamic interaction on the live chat. Perhaps this type of event is
therefore best for a "Review/Bug Day", or at least very focused type of
development.

I'm hoping that the other participants will chime in, or anyone else
with experience of similar events to share.

Best,
Johan



--
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] Experience from Sage Review Day 3: An online hacking event

[Johan S . H . Rosenkilde]

Hi sage-devel

Yesterday we held Sage Review Day 3, and it was a big success. I just
wanted to briefly share my experience with this.

Overall, 8 developers participated, most of them all day. We
communicated using Slack, Framapad and Trac. We got 14 tickets
positively reviewed, and had good progress on 3 more tickets.

Planning:
Minimal. We started as 5 developers who wished to give an extra push on
coding theory. We set a date, created a Sage wiki page, and announced on
sage-devel, as well as sending emails to participants of SD75. Just
before the event, we made sure the coding theory dev page on Trac,
https://trac.sagemath.org/wiki/SageCodingRoadMap, was updated; we
created a Slack team page; and a framapad with skeleton information.


During the day:
Communication was four-fold:

1) The coding theory dev page on trac served as a static list of tickets
needing work - everyone looked at that list for tasks.

2) Slack served as live chat and gave a nice atmosphere of working
together. Devs announced work, needs reviews, positive reviews, asked
for assistance, and made jokes. It was a huge motivator.

3) Framapad was a live reference list of what people were working on and
what had already been done.

4) Trac tickets were as always where "official" discussions were taking
place (posts/push followed by a poke on Slack usually).


Aftermath:
For me, this was a great way to set aside a well-defined amount of time
for Sage development. It was also much more efficient than usual
scattered efforts, since context switching takes a lot of time.
Interaction btw. developer and reviewer was immediate, and getting
response on a ticket 5 mins after posting the code is immensely
satisfying.

I feel that this is a fruitful, informal way to coordinate work on Sage.
There really was a mini-Sage Days feeling over it! One reason for the
big feeling of success was that coding theory had so many outstanding
tickets waiting review. Actual designing and serious implementation
would lead to much fewer tickets being finished, and perhaps less
dynamic interaction on the live chat. Perhaps this type of event is
therefore best for a "Review/Bug Day", or at least very focused type of
development.

I'm hoping that the other participants will chime in, or anyone else
with experience of similar events to share.

Best,
Johan

-- 
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.