[sage-devel] graded Hilbert series

[john_perry_usm]

Hello

For anyone who is interested in weighted Hilbert Series, as opposed to 
"mere" standard Hilbert Series, I have what *should* be a very easy patch 
to review in ticket #17298. Ordinarily, I wouldn't draw anyone's attention 
to it, but this is my first time uploading a patch via git, and the 
Developer's Guide says,

If you go to the web interface to the Sage trac development server then you 
> can click on the “Branch:” field and see the code that is added by 
> combining all commits of the ticket.


I can't seem to click on the green text in the "Branch:" field, so I can't 
verify that the changes I thought I made show up there. Hence, even if you 
aren't inclined to review it, I'd be grateful if someone could verify that 
the changes are in fact visible to someone else.

john perry

-- 
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 4 Nov 2014 19:16, "rjf" 
>> Perhaps the mathematical community needs to have an open-access database
of bug reports for commercial software. A discussion of the usefulness,
legality,  practicality, commercial benefits etc. of such a database could
be interesting.
> think it's
>  not the "mathematical community" that should do this, but the
> "users of software XYZ".

What I think might be useful, to a fairly large number of mathematicians,
and so a reasonable subset of the "mathematical community", is a database
where anyone was able to report bugs in Mathematica, Maple, Macsyma and
other commercial mathematics software.  Similar to the the databases of
several open source math packages including both Maxima and Sage, but with
the commercial software package name being such a category.

It would not be particularly time consuming to set such a database up, and
probably one could get a significant number of bug reports. BUT I am not
sure how practical it would be to get

1) User-errors closed as "invalid"

2) Bugs that get fixed change to "fixed" when a particular bug was fixed.

With such a database outside the control of the software developers, it may
genuinely useful. Errors such as the one found in Mathematica, could have
been reported much earlier.

That's the point I was trying to make,  and perhaps didn't phrase it too
well.

I think such a suggestion could be usefully put in a response to the
editors about the paper by the trio of mathematicians.

Dave

-- 
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: Slowness in comparing symbolic expressions

[Robert Dodier]

On 2014-11-05, Nils Bruin  wrote:

> On Tuesday, November 4, 2014 3:46:55 PM UTC-8, Robert Dodier wrote:
>>
>> I don't know a work-around for is(equal(1,exp(256*(x+1. As always, 
>> a bug report will be very helpful. http://sourceforge.net/p/maxima/bugs 

> I'm not so sure it's a bug or that something can be done about it, but you 
> can track progress at https://sourceforge.net/p/maxima/bugs/2836/

Well, it's certainly disconcerting to have everything grind to a halt
when one tries a simple operation ... I've bumped into this same
bug/feature in various contexts.

Incidentally I observe that Sympy has the same behavior, so we can't
just nick their factoring algorithm -- maybe some other package we can
try the same example to see if any of them handle it quickly?

best

Robert Dodier

-- 
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] Nature article mentions Sage

[Jason Grout]

FYI, this nature article from today, mainly about the IPython notebook, 
also mentions Sage: 
http://www.nature.com/news/interactive-notebooks-sharing-the-code-1.16261


"A number of notebooks and notebook-like programs exist in the 
open-source world; knitr works with the R coding language, which is 
especially powerful for statistical analysis. And the Sage mathematical 
software system, which is also based on the Python language, supports 
its own notebook."


Kyle Kelly from Rackspace, who works a lot with the IPython lead devs 
with the nbviewer, also set up a tmpnb to allow for small interactive 
notebooks for random internet users: 
http://www.nature.com/news/ipython-interactive-demo-7.21492


Thanks,

Jason

--
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[Volker Braun]

On Wednesday, November 5, 2014 11:27:03 PM UTC, William wrote:
>
> Yes.  Note that though Volker called it a "subtle bug" 


What I meant was: not easily found since it only occurred in a narrow 
window of input parameters (i.e. matrix sizes).

-- 
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[William Stein]

On Wed, Nov 5, 2014 at 3:15 PM, Ursula Whitcher  wrote:
> At some point, William wrote:
>
>> I wrote that det code in Sage (though in Sage-6.4 it'll likely be
>> replaced by a call to FLINT...). It computes det(A) in a very
>> interesting way, which is asymptotically massively faster than
>> Mathematica. To compute det(A), choose a random vector v and solve
>> Ax = v using a p-adic lifting algorithm (the one
>> inhttps://cs.uwaterloo.ca/~astorjoh/iml.html). One can prove --using
>> Cramer's rule--that the lcm of the denominators of the entries of x
>> will then be a divisor d of det(A), and with high probability one
>> expects that det(A)/d is a tiny integer. One can then provably
>> (using the Hadamard bound) find det(A) by working modulo a few
>> additional primes and using the Chinese Remainder theorem.
>
>
> At some other point, Volker wrote:
>
>> There have been subtle bugs in determinants of integer matrices in
>> Sage before, e.g. http://trac.sagemath.org/ticket/14032
>> "determinant() of integer matrices of size in [51,63] broken". Open
>> source doesn't make Sage magically bug-free.
>
>
> The note on ticket 14032 about the bug's solution is:
>
> "The problem was an infinite recursion where we compute a determinant over
> ZZ by working mod p and we compute a determinant over GF(p) by lifting to
> ZZ..."
>
> Was the algorithm that should have been used here for finding a determinant
> over GF(p) the same as the one that William is describing?

Yes.  Note that though Volker called it a "subtle bug" it wasn't
anything like the Mathematica bug.  It just failed with "RuntimeError:
maximum recursion depth exceeded".  It's not wrong answers popping
out.  The problem was that we upgraded Linbox, which changed to
require working modulo bigger primes than we were previous requesting
to work modulo.   There wasn't anything mathematically wrong.   I
really think the statement "There have been subtle bugs in
determinants of integer matrices in
Sage" in reference to this is misleading.  Perhaps Jereon who fixed
the bug feels differently.

I looked at the patch on 14032 and introduces a typo that's still
there now.  Search for "efficienct" in
src/sage/matrix/matrix_integer_dense_hnf.py; maybe the referee of the
patch (Volker) will be amused.

>  Or did it rely on
> a different way to compute a determinant over ZZ by working mod p?

The last part of what I describe above is "One can then provably
(using the Hadamard bound) find det(A) by working modulo a few
additional primes..." and that step involves calling whatever black
box you have available for finding determinants mod p.

 -- William

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



-- 
William Stein
Professor of Mathematics
University of Washington
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[Ursula Whitcher]

At some point, William wrote:


I wrote that det code in Sage (though in Sage-6.4 it'll likely be
replaced by a call to FLINT...). It computes det(A) in a very
interesting way, which is asymptotically massively faster than
Mathematica. To compute det(A), choose a random vector v and solve
Ax = v using a p-adic lifting algorithm (the one
inhttps://cs.uwaterloo.ca/~astorjoh/iml.html). One can prove --using
Cramer's rule--that the lcm of the denominators of the entries of x
will then be a divisor d of det(A), and with high probability one
expects that det(A)/d is a tiny integer. One can then provably
(using the Hadamard bound) find det(A) by working modulo a few
additional primes and using the Chinese Remainder theorem.


At some other point, Volker wrote:


There have been subtle bugs in determinants of integer matrices in
Sage before, e.g. http://trac.sagemath.org/ticket/14032
"determinant() of integer matrices of size in [51,63] broken". Open
source doesn't make Sage magically bug-free.


The note on ticket 14032 about the bug's solution is:

"The problem was an infinite recursion where we compute a determinant 
over ZZ by working mod p and we compute a determinant over GF(p) by 
lifting to ZZ..."


Was the algorithm that should have been used here for finding a 
determinant over GF(p) the same as the one that William is describing? 
Or did it rely on a different way to compute a determinant over ZZ by 
working mod p?


UAW

--
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: Posets: interval/closed_interval

[Travis Scrimshaw]

There's a minor difference between redirecting vs alias in that an alias 
does not respect inheritance:

class Foo:
def f(self):
 return 5
alias = f
def redirct(self):
 return self.f()

class Bar:
def f(self):
return -1

F = Foo()
F.alias()
5
F.redirect()
5
B = Bar()
B.alias()
5
B.redirect()
-1

Best,
Travis


On Wednesday, November 5, 2014 11:15:11 AM UTC-8, Frédéric Chapoton wrote:
>
> Probably one should keep *closed_interval* as an alias of *interval*
>
> I also noticed today that *interval_iterator* forgets about trivial 
> intervals [v,v].
>
> Le mercredi 5 novembre 2014 12:17:10 UTC+1, Jori Mantysalo a écrit :
>>
>> What is the logic having both interval() and closed_interval() defined on 
>> posets? Last one is really defined as a function, but is just calls first 
>> one. 
>>
>> -- 
>> 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] ./sage -br "quite fast"?

[William Stein]

On Wed, Nov 5, 2014 at 2:47 PM, john_perry_usm  wrote:
> Thank you for the reply.
>
>> What happens after you iterate the above operation?  More precisely,
>> after it does finish building, what happens
>> if you change that Python file and again do "sage -br"?
>
>
> Your question is apt: in fact, I had a typo in the file, so Sage crashed
> when it tried to restart after building. I fixed the typo, and sage -br
> quickly incorporated the changes, which seem to work great (have to check it
> by hand though).
>
> Does that explain what it was?
>
> john perry

It's an important data point for whoever looks into this further (not me).

William

-- 
William Stein
Professor of Mathematics
University of Washington
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] ./sage -br "quite fast"?

[john_perry_usm]

Thank you for the reply.

What happens after you iterate the above operation?  More precisely, 
> after it does finish building, what happens 
> if you change that Python file and again do "sage -br"? 
>

Your question is apt: in fact, I had a typo in the file, so Sage crashed 
when it tried to restart after building. I fixed the typo, and sage -br 
quickly incorporated the changes, which seem to work great (have to check 
it by hand though).

Does that explain what it was?

john perry

-- 
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] ./sage -br "quite fast"?

[William Stein]

On Wed, Nov 5, 2014 at 1:41 PM, john_perry_usm  wrote:
> Hello
>
> According to the developer's guide, the command "./sage -br" should be
> "quite fast." I just made a 2-3 line alteration to
> sage/rings/polynomial/multipolynomial_ideal.py and got this output:
>
>> sage$ ./sage -br
>> scons: `install' is up to date.
>> Updating Cython code
>> Compiling sage/algebras/quatalg/quaternion_algebra_element.pyx because it
>> depends on ./sage/structure/element.pxd.
>> Compiling sage/algebras/letterplace/free_algebra_letterplace.pyx because
>> it depends on ./sage/structure/element.pxd.
>> Compiling sage/algebras/letterplace/free_algebra_element_letterplace.pyx
>> because it depends on ./sage/structure/element.pxd.
>
>
> ...and there's lots more where that came from. Looks like I'll be waiting a
> while, in fact. I modify a handful of lines in one Python (!) file, and the
> entire Cython (!) structure gets rebuilt? Did I do something wrong?
>
> This is on OSX, by the way, with Sage 6.3. I don't believe it's a binary
> download, but it might be. If either of those is the cause of this, I'd be
> grateful for explicit confirmation.

What happens after you iterate the above operation?  More precisely,
after it does finish building, what happens
if you change that Python file and again do "sage -br"?

William

-- 
William Stein
Professor of Mathematics
University of Washington
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] ./sage -br "quite fast"?

[john_perry_usm]

Hello

According to the developer's guide, the command "./sage -br" should be 
"quite fast." I just made a 2-3 line alteration to 
sage/rings/polynomial/multipolynomial_ideal.py and got this output:

sage$ ./sage -br
> scons: `install' is up to date.
> Updating Cython code
> Compiling sage/algebras/quatalg/quaternion_algebra_element.pyx because it 
> depends on ./sage/structure/element.pxd.
> Compiling sage/algebras/letterplace/free_algebra_letterplace.pyx because 
> it depends on ./sage/structure/element.pxd.
> Compiling sage/algebras/letterplace/free_algebra_element_letterplace.pyx 
> because it depends on ./sage/structure/element.pxd.


...and there's lots more where that came from. Looks like I'll be waiting a 
while, in fact. I modify a handful of lines in one Python (!) file, and the 
entire Cython (!) structure gets rebuilt? Did I do something wrong?

This is on OSX, by the way, with Sage 6.3. I don't believe it's a binary 
download, but it might be. If either of those is the cause of this, I'd be 
grateful for explicit confirmation. 

thanks
john perry

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

VS: [sage-devel] Re: Posets: interval/closed_interval

[Jori M]

Use relations_iterator(). It should be mentioned in "see also" -part of 
interval_iterator().

- Alkuperäinen viesti -
Lähettäjä: Frédéric Chapoton
Lähetetty: 5.11.2014 21:15
Vastaanottaja: sage-devel@googlegroups.com
Aihe: [sage-devel] Re: Posets: interval/closed_interval


Probably one should keep closed_interval as an alias of interval



I also noticed today that interval_iterator forgets about trivial intervals 
[v,v].

Le mercredi 5 novembre 2014 12:17:10 UTC+1, Jori Mantysalo a écrit :
What is the logic having both interval() and closed_interval() defined on 
posets? Last one is really defined as a function, but is just calls first 
one. 

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

-- 
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: Posets: interval/closed_interval

[Frédéric Chapoton]

Probably one should keep *closed_interval* as an alias of *interval*

I also noticed today that *interval_iterator* forgets about trivial 
intervals [v,v].

Le mercredi 5 novembre 2014 12:17:10 UTC+1, Jori Mantysalo a écrit :
>
> What is the logic having both interval() and closed_interval() defined on 
> posets? Last one is really defined as a function, but is just calls first 
> one. 
>
> -- 
> 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: Opinions wanted on simplification method for real expressions

[Michael Orlitzky]

On 11/05/2014 08:34 AM, kcrisman wrote:

> 
> Just to clarify, current behavior is
> 
> sage: a = sqrt(x^2)
> sage: a.simplify_radical()
> x

Yeah, previously, simplify_radical() was silently setting the domain to
'real', calling radcan(), and then setting the domain back to 'complex'.

The round trip through Maxima (with the domain set to 'real') made the
simplification sqrt(x^2) -> abs(x), at which point radcan() could do
nothing with it. By fixing one bug, the output actually became worse
because now radcan() sees the full sqrt(x^2) and will choose one root
"arbitrarily but consistently."


> Anyway, as to your solution, I think that after this time rws is
> probably right that since no one actually implemented a context manager
> or domain parameter or whatever else then the option on the ticket
> (which needs to be a branch, sigh) is better than nothing.  At least it
> finally allows sqrt(x^2) -> abs(x) again.  Though it should be tried
> with lots of irrelevant and perhaps strange assumptions like integer
> around to make sure it really re-assumes all assumptions when needed.

I just posted a branch with an additional test for assumptions(). It
also fixes an earlier bug (that I most likely introduced!) -- a test
earlier in the file that didn't forget() its assumptions.


>>  So you're kind of on your own regarding how many simplifications to
> try and in what order.
> 
> Yes, that is currently the case anyway.  

We could always brute-force them. Tools like pngcrush use this to find
the best compression settings. Expression.simplify_rectform() already
checks to see if the result is "simpler" (via a highly complicated
algorithm, len(str(x))), so there's no reason we couldn't try 100
simplifications and see which is "less complex."

-- 
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: Trac field "priority"

[kcrisman]

>
>
> >> How DOES bug prioritization work in Sage?  You can pick 
> >> blocker/critical/major/minor/trivial when you're creating a ticket. 
>
> > - -There is certainly very little double-checking, and very little 
> > setting to anything other than major: 
>
> Is there even documentation about using trac fields? How should one 
> differentiate between major and minor? 
>
>
No documentation other than various email assertions about blockers being 
true blockers (see the thread you forwarded this from for an example!). 
 The real question is "major to whom"?  But that is not easy to answer, 
other than on obvious things like "Sage doesn't start on popular platform X 
but did last week".

(And to be sure, too much documentation about this will probably become a 
roadblock to people actually reporting stuff, because they have to agonize 
over the priority.)

-- 
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[kcrisman]

>
> > It would be interesting to do a query against how many "minor" ones were 
> > created by the same people... I was expecting fewer (there are about 800 
> > currently open), but perhaps more recently people have gotten better 
> about 
> > this?  Still, there is very little triage - it mostly follows "scratch 
> your 
> > itch". 
>
> Just to add to that, what Karl is describing is just the sort of 
> steady state.  In the *past*, we have done massively more.  See, e.g., 
> the list of "Bug Day" things we had: 
>
>http://wiki.sagemath.org/Workshops#Bug_Days 
>
> Also we had  sequence of bug days workshops in which we had intense 
> bug triage sessions, where we (a group of people in a room with a 
> project and trac) would systematically go through hundreds of bugs and 
> revisit/prioritize/categories them.   Thousands of people hours have 
> been spent on these sorts of activities. 
>
>
Yes, good point.  I'll then counter that it was mostly at such events that 
this happened, though.
 

> It is however difficult to maintain the momentum for this sort of work. 
> For example, many of the people heavily involved in the above now have 
> full time non-math jobs... 
>
>
So new recruits welcome!

-- 
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] Git weirdness ?

[Vincent Delecroix]

2014-11-05 12:37 UTC−06:00, Emmanuel Charpentier
:
>
>
> Le mercredi 5 novembre 2014 19:15:27 UTC+1, vdelecroix a écrit :
>>
>> What is the point of doing git fetch followed by git pull ?
>
>
> Seemed to be the mos treamlined to keep my tree up to date...
>

git pull should be enough.

>> Note that
>> with git fetch (or git pull) you download *all* the remote branches on
>> the trac server while you seemed only interested to pull the develop
>> branch. You should have done
>>
>>   git pull trac develop
>>
>> where trac is the name you choose for the remote git server at
>> trac.sagemath.org.
>>
>> You should really learn git before using it ;-)
>

The name "trac" I used in my example depends on your configuration. It
is the name you used to define the remote server trac.sagemath.org. It
might also be "origin" or even something else. To know the name that
you need to put instead of "trac" you need to run

git remote -v

(this will output the list of the declared remote servers). You can then do

git pull NAME_OF_THE_SERVER develop

to update only the main development branch.

Best
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[Volker Braun]

On Wednesday, November 5, 2014 5:28:44 PM UTC, Ursula Whitcher wrote:
>
> essentially up to the folks working on a given ticket?  Is the rule that 
> "blocker"-level bugs must be fixed before releasing a new version of Sage?


Yes. There is a trac query for blocker tickets 
on http://trac.sagemath.org/wiki/TicketReports

 

-- 
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: Git weirdness ?

[Emmanuel Charpentier]

Le mercredi 5 novembre 2014 19:32:07 UTC+1, Volker Braun a écrit :
>
> At one point there was a branch 
> trac/public/combinat/zabrocki/fixstrongtableaux/17252. This one has since 
> been deleted. A new branch trac/public/combinat/zabrocki/fixstrongtableaux 
> has been created. The two branch names conflict, you can't have a branch as 
> a "subdirectory" of another branch. 
>

Thank you, Volker. That makes sense. 

>
> The conflict is only in your local copy of the trac remote. You can either 
> wait until the stale copy is garbage collected, or run "git remote prune 
> trac" (or "git fetch --prune") to get rid of it right now.
>

I followed Vincent's suggestion gefore seeing your answer. It seems to have 
been efficient.

Thank you (again).

--
Emmanuel Charpentier

-- 
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: can not install optional package cryptominisat-2.9.6

[Volker Braun]

Try to build Sage from source. 

You most likely don't have the command line tools installed. Run 
"xcode-select --install" on the command line.



On Wednesday, November 5, 2014 4:34:08 PM UTC, Qi wrote:
>
> Hello everyone,
>
> I'm new to sage and have just installed sage-6.3 on my mac osx 10.10. It 
> seems everything works fine. But now I'm trying to install the package 
> *cryptominisat-2.9.6*. As I see online, I typed the following content on 
> the shell:
>
>
> 
>
> Then, I got a feedback like this:
>
>
> 
>
> Is this because mac osx 10.10 is not compatible with cryptominisat-2.9.6 
> which is like the error in the  part in the above screenshot or 
> some other reasons?
>
> Any pointer would be appreciated. Thanks in advance!
>
>
>

-- 
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] Git weirdness ?

[Emmanuel Charpentier]

Le mercredi 5 novembre 2014 19:15:27 UTC+1, vdelecroix a écrit :
>
> What is the point of doing git fetch followed by git pull ?


Seemed to be the mos treamlined to keep my tree up to date...
 

> Note that 
> with git fetch (or git pull) you download *all* the remote branches on 
> the trac server while you seemed only interested to pull the develop 
> branch. You should have done 
>
>   git pull trac develop 
>
> where trac is the name you choose for the remote git server at 
> trac.sagemath.org. 
>
> You should really learn git before using it ;-)


You're right... :-] I probably went too fast on this.

Anyway : My tree still is at rc0 : "make" just "rebuilt" the docs (which 
was already up to date).

Currently re-making after "git pull trac develop ... results overnight.

[ Snip ...]

Sincerely,

--
Emmanuel Charpentier

-- 
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: Git weirdness ?

[Volker Braun]

At one point there was a branch 
trac/public/combinat/zabrocki/fixstrongtableaux/17252. This one has since 
been deleted. A new branch trac/public/combinat/zabrocki/fixstrongtableaux 
has been created. The two branch names conflict, you can't have a branch as 
a "subdirectory" of another branch. 

The conflict is only in your local copy of the trac remote. You can either 
wait until the stale copy is garbage collected, or run "git remote prune 
trac" (or "git fetch --prune") to get rid of it right now.



On Wednesday, November 5, 2014 6:06:11 PM UTC, Emmanuel Charpentier wrote:
>
> Trying to update a sage tree (currently at 6.4rc0) :
> charpent@SAP5057241:/usr/local/sage-6.4$ git status
> Sur la branche develop
> Votre branche est à jour avec 'trac/develop'.
> rien à valider, la copie de travail est propre
> charpent@SAP5057241:/usr/local/sage-6.4$ git fetch
> remote: Counting objects: 2372, done.
> remote: Compressing objects: 100% (1207/1207), done.
> remote: Total 1653 (delta 1320), reused 563 (delta 432)
> Réception d'objets: 100% (1653/1653), 422.75 KiB | 433.00 KiB/s, fait.
> Résolution des deltas: 100% (1320/1320), complété avec 226 objets locaux.
> [ Lots of branch publications ... ]
>  * [nouvelle branche] u/vinceknight/finishedresponsetobigreview -> 
> trac/u/vinceknight/finishedresponsetobigreview
>  * [nouvelle étiquette] 6.4.rc1-> 6.4.rc1
> charpent@SAP5057241:/usr/local/sage-6.4$ git status
> Sur la branche develop
> Votre branche est en retard sur 'trac/develop' de 43 commits, et peut être 
> mise à jour en avance rapide.
>   (utilisez "git pull" pour mettre à jour votre branche locale)
> rien à valider, la copie de travail est propre
> charpent@SAP5057241:/usr/local/sage-6.4$ git pull
> error: there are still refs under 
> 'refs/remotes/trac/public/combinat/zabrocki/fixstrongtableaux'
> Depuis trac.sagemath.org:sage
>  ! [nouvelle branche] public/combinat/zabrocki/fixstrongtableaux -> 
> trac/public/combinat/zabrocki/fixstrongtableaux  (impossible de mettre à 
> jour la référence locale)
> [ ??? ]
> charpent@SAP5057241:/usr/local/sage-6.4$ git branch
> * develop
>   master
>   t/16711/752190c8b5dcd7964ddbae59a4f7899100d787be
>
> I *suppose* that my tree is now *correctly* at RC1, and I'll try to 
> compile it (overnight : this is a small and slow machine...).
>
> Still, it's scary : I can't make sense of the message...
>
> HTH,
> --
> Emmanuel Charpentier
>

-- 
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] Git weirdness ?

[Vincent Delecroix]

What is the point of doing git fetch followed by git pull ? Note that
with git fetch (or git pull) you download *all* the remote branches on
the trac server while you seemed only interested to pull the develop
branch. You should have done

  git pull trac develop

where trac is the name you choose for the remote git server at
trac.sagemath.org.

You should really learn git before using it ;-) See
http://git-scm.com/book/en/v2

Vincent

2014-11-05 12:06 UTC−06:00, Emmanuel Charpentier
:
> Trying to update a sage tree (currently at 6.4rc0) :
> charpent@SAP5057241:/usr/local/sage-6.4$ git status
> Sur la branche develop
> Votre branche est à jour avec 'trac/develop'.
> rien à valider, la copie de travail est propre
> charpent@SAP5057241:/usr/local/sage-6.4$ git fetch
> remote: Counting objects: 2372, done.
> remote: Compressing objects: 100% (1207/1207), done.
> remote: Total 1653 (delta 1320), reused 563 (delta 432)
> Réception d'objets: 100% (1653/1653), 422.75 KiB | 433.00 KiB/s, fait.
> Résolution des deltas: 100% (1320/1320), complété avec 226 objets locaux.
> [ Lots of branch publications ... ]
>  * [nouvelle branche] u/vinceknight/finishedresponsetobigreview ->
> trac/u/vinceknight/finishedresponsetobigreview
>  * [nouvelle étiquette] 6.4.rc1-> 6.4.rc1
> charpent@SAP5057241:/usr/local/sage-6.4$ git status
> Sur la branche develop
> Votre branche est en retard sur 'trac/develop' de 43 commits, et peut être
> mise à jour en avance rapide.
>   (utilisez "git pull" pour mettre à jour votre branche locale)
> rien à valider, la copie de travail est propre
> charpent@SAP5057241:/usr/local/sage-6.4$ git pull
> error: there are still refs under
> 'refs/remotes/trac/public/combinat/zabrocki/fixstrongtableaux'
> Depuis trac.sagemath.org:sage
>  ! [nouvelle branche] public/combinat/zabrocki/fixstrongtableaux ->
> trac/public/combinat/zabrocki/fixstrongtableaux  (impossible de mettre à
> jour la référence locale)
> [ ??? ]
> charpent@SAP5057241:/usr/local/sage-6.4$ git branch
> * develop
>   master
>   t/16711/752190c8b5dcd7964ddbae59a4f7899100d787be
>
> I *suppose* that my tree is now *correctly* at RC1, and I'll try to compile
>
> it (overnight : this is a small and slow machine...).
>
> Still, it's scary : I can't make sense of the message...
>
> HTH,
> --
> Emmanuel Charpentier
>
> --
> 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.
>

-- 
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: Trac field "priority"

[Jori Mantysalo]

On Wed, 5 Nov 2014, kcrisman wrote:

How DOES bug prioritization work in Sage?  You can pick 
blocker/critical/major/minor/trivial when you're creating a ticket.


- -There is certainly very little double-checking, and very little 
setting to anything other than major:


Is there even documentation about using trac fields? How should one 
differentiate between major and minor?


--
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[William Stein]

On Wed, Nov 5, 2014 at 9:44 AM, kcrisman  wrote:
>> How DOES bug prioritization work in Sage?  You can pick
>> blocker/critical/major/minor/trivial when you're creating a ticket.
>> Does someone double-check those choices, or is prioritization
>> essentially up to the folks working on a given ticket?  Is the rule that
>> "blocker"-level bugs must be fixed before releasing a new version of Sage?
>
>
> In practice, the only things that happen are
>
> * default is major
> * on occasion truly trivial things are set to trivial and minor things are
> made minor
> * a bit more often, people set things they personally think are critical
> (but perhaps aren't) to critical
> * very rarely, things are set to blocker, and the current practice is nearly
> always that this is to fix an unacceptable bug before release - usually one
> discovered in testing new functionality for that release
>
> And that's it.  There is certainly very little double-checking, and very
> little setting to anything other than major:
>
> 925 tickets versus 2334 tickets:
>
> http://trac.sagemath.org/query?priority=!major&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
>
> http://trac.sagemath.org/query?priority=major&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&col=id&col=summary&col=priority&col=status&col=type&col=milestone&col=component&order=id
>
> It would be interesting to do a query against how many "minor" ones were
> created by the same people... I was expecting fewer (there are about 800
> currently open), but perhaps more recently people have gotten better about
> this?  Still, there is very little triage - it mostly follows "scratch your
> itch".

Just to add to that, what Karl is describing is just the sort of
steady state.  In the *past*, we have done massively more.  See, e.g.,
the list of "Bug Day" things we had:

   http://wiki.sagemath.org/Workshops#Bug_Days

Also we had  sequence of bug days workshops in which we had intense
bug triage sessions, where we (a group of people in a room with a
project and trac) would systematically go through hundreds of bugs and
revisit/prioritize/categories them.   Thousands of people hours have
been spent on these sorts of activities.

It is however difficult to maintain the momentum for this sort of work.
For example, many of the people heavily involved in the above now have
full time non-math jobs...

 -- William


-- 
William Stein
Professor of Mathematics
University of Washington
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Git weirdness ?

[Emmanuel Charpentier]

Trying to update a sage tree (currently at 6.4rc0) :
charpent@SAP5057241:/usr/local/sage-6.4$ git status
Sur la branche develop
Votre branche est à jour avec 'trac/develop'.
rien à valider, la copie de travail est propre
charpent@SAP5057241:/usr/local/sage-6.4$ git fetch
remote: Counting objects: 2372, done.
remote: Compressing objects: 100% (1207/1207), done.
remote: Total 1653 (delta 1320), reused 563 (delta 432)
Réception d'objets: 100% (1653/1653), 422.75 KiB | 433.00 KiB/s, fait.
Résolution des deltas: 100% (1320/1320), complété avec 226 objets locaux.
[ Lots of branch publications ... ]
 * [nouvelle branche] u/vinceknight/finishedresponsetobigreview -> 
trac/u/vinceknight/finishedresponsetobigreview
 * [nouvelle étiquette] 6.4.rc1-> 6.4.rc1
charpent@SAP5057241:/usr/local/sage-6.4$ git status
Sur la branche develop
Votre branche est en retard sur 'trac/develop' de 43 commits, et peut être 
mise à jour en avance rapide.
  (utilisez "git pull" pour mettre à jour votre branche locale)
rien à valider, la copie de travail est propre
charpent@SAP5057241:/usr/local/sage-6.4$ git pull
error: there are still refs under 
'refs/remotes/trac/public/combinat/zabrocki/fixstrongtableaux'
Depuis trac.sagemath.org:sage
 ! [nouvelle branche] public/combinat/zabrocki/fixstrongtableaux -> 
trac/public/combinat/zabrocki/fixstrongtableaux  (impossible de mettre à 
jour la référence locale)
[ ??? ]
charpent@SAP5057241:/usr/local/sage-6.4$ git branch
* develop
  master
  t/16711/752190c8b5dcd7964ddbae59a4f7899100d787be

I *suppose* that my tree is now *correctly* at RC1, and I'll try to compile 
it (overnight : this is a small and slow machine...).

Still, it's scary : I can't make sense of the message...

HTH,
--
Emmanuel Charpentier

-- 
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[kcrisman]

>
> How DOES bug prioritization work in Sage?  You can pick 
> blocker/critical/major/minor/trivial when you're creating a ticket. 
> Does someone double-check those choices, or is prioritization 
> essentially up to the folks working on a given ticket?  Is the rule that 
> "blocker"-level bugs must be fixed before releasing a new version of Sage? 
>

In practice, the only things that happen are

* default is major
* on occasion truly trivial things are set to trivial and minor things are 
made minor
* a bit more often, people set things they personally think are critical 
(but perhaps aren't) to critical
* very rarely, things are set to blocker, and the current practice is 
nearly always that this is to fix an unacceptable bug before release - 
usually one discovered in testing new functionality for that release 

And that's it.  There is certainly very little double-checking, and very 
little setting to anything other than major:

925 tickets versus 2334 tickets:

http://trac.sagemath.org/query?priority=!major&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority

http://trac.sagemath.org/query?priority=major&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&col=id&col=summary&col=priority&col=status&col=type&col=milestone&col=component&order=id

It would be interesting to do a query against how many "minor" ones were 
created by the same people... I was expecting fewer (there are about 800 
currently open), but perhaps more recently people have gotten better about 
this?  Still, there is very little triage - it mostly follows "scratch your 
itch".

-- 
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[Ursula Whitcher]

On 11/4/2014 6:04 AM, Volker Braun wrote:


Agree. A reasonable article should

[...]

b) talk about bug tracking and prioritization, stopgaps


How DOES bug prioritization work in Sage?  You can pick 
blocker/critical/major/minor/trivial when you're creating a ticket. 
Does someone double-check those choices, or is prioritization 
essentially up to the folks working on a given ticket?  Is the rule that 
"blocker"-level bugs must be fixed before releasing a new version of Sage?


UAW

--
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] can not install optional package cryptominisat-2.9.6

[Qi]

Hello everyone,

I'm new to sage and have just installed sage-6.3 on my mac osx 10.10. It 
seems everything works fine. But now I'm trying to install the package 
*cryptominisat-2.9.6*. As I see online, I typed the following content on 
the shell:



Then, I got a feedback like this:



Is this because mac osx 10.10 is not compatible with cryptominisat-2.9.6 
which is like the error in the  part in the above screenshot or 
some other reasons?

Any pointer would be appreciated. Thanks in advance!


-- 
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[William Stein]

On Tue, Nov 4, 2014 at 8:29 AM, Ursula Whitcher  wrote:
> On 11/3/2014 4:05 PM, William Stein wrote:
>>
>> I'm sure the
>> AMS would be very interesting in publishing more pieces that involve
>> computational mathematics/software, and likely only don't because they
>> don't have quality submissions enough to choose from.   I published
>> one there several years ago about open source [1].
>>
>>   -- William
>
>
> Did you write the full article and then submit it to the Notices, or did you
> query the editors with a proposal first?

I don't _remember_ querying editors -- I think we just wrote it and
sent it.   That said,
it's always a good idea to query editors first, when possible.

> They officially accept both types
> of submissions; do you know whether one method has better chances in
> practice?

If we^* write up something reasonably short and very polished which hits
the points suggested in this thread, *especially those suggested by
Volker above*, I think it's almost certainly going to be published by
the Notices.   I wouldn't be surprised if the Notices article that
started this discussion was by far the most read thing in that issue
of the Notices, and the editors will know that a good followup is also
likely to be of interest to readers, which is the sort of criteria
they should be applying.

If somebody contacted the Notices and gave them a heads up about our
planned submission, perhaps the Notices would also contact Steve
(Wolfram) and solicit a similar follow up article about the
engineering methodology they use to address such quality issues.
Including both our submission and something from Wolfram side-by-side
in the same issues of the Notices would be of even more interest to
readers.

* By "we write up" above, I mean you write up something very, very
rough, post it here, and get feedback.

 -- William

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



-- 
William Stein
Professor of Mathematics
University of Washington
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Should we ship vanilla upstream tarballs or stripped-down ones?

[Volker Braun]

See also http://trac.sagemath.org/ticket/15642

On Wednesday, November 5, 2014 1:39:15 PM UTC, Thierry 
(sage-googlesucks@xxx) wrote:
>
> On Wed, Nov 05, 2014 at 05:22:17AM -0800, Jean-Pierre Flori wrote: 
> > 
> > 
> > On Wednesday, November 5, 2014 2:17:29 PM UTC+1, Volker Braun wrote: 
> > > 
> > > There is already a "make download". If you want you can add a "make 
> > > download-more" (or so) to also download popular optional packages... 
>
> I did not know that option, thanks for pointing this out. 
>
> > Doesn't make download already download everything? 
> > Or was it fixed/changed? 
>
> According to the makefile, it calls ./src/bin/sage-download-upstream 
> which starts with 'for pkg in $SAGE_ROOT/build/pkgs/*' 
>
> So, it seems that all git-layouted packages are downloaded. 
>
> That said, it does not fix the question of aborted slow downloads. 
> However, it seems possible to pass an URL_GRABBER variable in 
> sage-download-file to override the use of urllib, so we could use this 
> as a workaround. In the longer term, it could be nice to have a --slow 
> option or something like that, the difficulty will be to let this work 
> on any machine, so preferably with some urllib python standard stuff. 
>
> Ciao, 
> Thierry 
>
>

-- 
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 we ship vanilla upstream tarballs or stripped-down ones?

[Jean-Pierre Flori]

On Wednesday, November 5, 2014 2:39:15 PM UTC+1, Thierry 
(sage-googlesucks@xxx) wrote:
>
> On Wed, Nov 05, 2014 at 05:22:17AM -0800, Jean-Pierre Flori wrote: 
> > 
> > 
> > On Wednesday, November 5, 2014 2:17:29 PM UTC+1, Volker Braun wrote: 
> > > 
> > > There is already a "make download". If you want you can add a "make 
> > > download-more" (or so) to also download popular optional packages... 
>
> I did not know that option, thanks for pointing this out. 
>
> > Doesn't make download already download everything? 
> > Or was it fixed/changed? 
>
> According to the makefile, it calls ./src/bin/sage-download-upstream 
> which starts with 'for pkg in $SAGE_ROOT/build/pkgs/*' 
>
> So, it seems that all git-layouted packages are downloaded. 
>
> Yes, that what I remember.
In particular it will already download huge optional tarballs, not only 
standard ones.

That said, it does not fix the question of aborted slow downloads. 
> However, it seems possible to pass an URL_GRABBER variable in 
> sage-download-file to override the use of urllib, so we could use this 
> as a workaround. In the longer term, it could be nice to have a --slow 
> option or something like that, the difficulty will be to let this work 
> on any machine, so preferably with some urllib python standard stuff. 
>
> Sure. 

> Ciao, 
> Thierry 
>
>

-- 
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 we ship vanilla upstream tarballs or stripped-down ones?

[Thierry]

On Wed, Nov 05, 2014 at 05:22:17AM -0800, Jean-Pierre Flori wrote:
> 
> 
> On Wednesday, November 5, 2014 2:17:29 PM UTC+1, Volker Braun wrote:
> >
> > There is already a "make download". If you want you can add a "make 
> > download-more" (or so) to also download popular optional packages...

I did not know that option, thanks for pointing this out.

> Doesn't make download already download everything?
> Or was it fixed/changed? 

According to the makefile, it calls ./src/bin/sage-download-upstream
which starts with 'for pkg in $SAGE_ROOT/build/pkgs/*'

So, it seems that all git-layouted packages are downloaded.

That said, it does not fix the question of aborted slow downloads.
However, it seems possible to pass an URL_GRABBER variable in
sage-download-file to override the use of urllib, so we could use this
as a workaround. In the longer term, it could be nice to have a --slow
option or something like that, the difficulty will be to let this work
on any machine, so preferably with some urllib python standard stuff.

Ciao,
Thierry

-- 
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: Opinions wanted on simplification method for real expressions

[kcrisman]

> In http://trac.sagemath.org/ticket/14630, I have a patch that adds a 
> simplify_real() method to symbolic expressions. Pretty much the only 
> thing it does is simplify, 
>
>   sqrt(x^2) -> abs(x) 
>
> In the past, you could obtain this with simplify_radical(), even though 
> the variable `x` involved was assumed to be complex. That was busted, so 
> it was removed. But some people need the simplification above (see e.g. 
>

Just to clarify, current behavior is

sage: a = sqrt(x^2)
sage: a.simplify_radical()
x


 

> #14305), so the patch at least provides a way to get it. 
>
>
Still well worth a read, though perhaps too many opinions to come to 
resolution.

Anyway, as to your solution, I think that after this time rws is probably 
right that since no one actually implemented a context manager or domain 
parameter or whatever else then the option on the ticket (which needs to be 
a branch, sigh) is better than nothing.  At least it finally allows 
sqrt(x^2) -> abs(x) again.  Though it should be tried with lots of 
irrelevant and perhaps strange assumptions like integer around to make sure 
it really re-assumes all assumptions when needed.

>  So you're kind of on your own regarding how many simplifications to try 
and in what order.

Yes, that is currently the case anyway.  

-- 
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 we ship vanilla upstream tarballs or stripped-down ones?

[Jean-Pierre Flori]

On Wednesday, November 5, 2014 2:17:29 PM UTC+1, Volker Braun wrote:
>
> There is already a "make download". If you want you can add a "make 
> download-more" (or so) to also download popular optional packages...
>
> Doesn't make download already download everything?
Or was it fixed/changed? 

-- 
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 we ship vanilla upstream tarballs or stripped-down ones?

[Volker Braun]

There is already a "make download". If you want you can add a "make 
download-more" (or so) to also download popular optional packages...



On Wednesday, November 5, 2014 1:13:40 PM UTC, kcrisman wrote:
>
> > >> 
>> > >> There are people who have a very bad band-with. In my case, it's 
>> fine 
>> > >> when I am at university. But other than that, I only have a mobile 
>> > >> internet stick, for which 50MB more or less really matters. 
>> > > 
>>
>> +1 with this point of view. 
>>
>> However, when lacking good internet connection, unless the bandwidth is 
>> so slow that it was already impossible to download sage itself (in such 
>> (frequent) cases the question is irrelevant, and workarounds like the 
>> self replicating live USB may apply), as for me the problem is not much 
>> the total size (one can wait), but the fact that some spkgs are a huge 
>> single file and must be downloaded all at once. 
>>
>> A concrete example for me is "sage -i database_gap" which always 
>> requires a lot of attempts because in the download duration, there is 
>> always a timeout at some point that forces to redownload everything from 
>> the beginning. A manual solution is to use repeated "wget --continue" 
>> within the upstream/ directory, which 'sage -i' is not offering by 
>> default. I am not sure if urllib has such an obstination option. 
>>
>
> Hmm, this is a good point.  And Mac doesn't have `wget` so one has to use 
> `curl` which perhaps doesn't have the same options, and I don't know what 
> Sage uses internally to download all this. 
>

-- 
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 we ship vanilla upstream tarballs or stripped-down ones?

[kcrisman]

>
> > >> 
> > >> There are people who have a very bad band-with. In my case, it's fine 
> > >> when I am at university. But other than that, I only have a mobile 
> > >> internet stick, for which 50MB more or less really matters. 
> > > 
>
> +1 with this point of view. 
>
> However, when lacking good internet connection, unless the bandwidth is 
> so slow that it was already impossible to download sage itself (in such 
> (frequent) cases the question is irrelevant, and workarounds like the 
> self replicating live USB may apply), as for me the problem is not much 
> the total size (one can wait), but the fact that some spkgs are a huge 
> single file and must be downloaded all at once. 
>
> A concrete example for me is "sage -i database_gap" which always 
> requires a lot of attempts because in the download duration, there is 
> always a timeout at some point that forces to redownload everything from 
> the beginning. A manual solution is to use repeated "wget --continue" 
> within the upstream/ directory, which 'sage -i' is not offering by 
> default. I am not sure if urllib has such an obstination option. 
>

Hmm, this is a good point.  And Mac doesn't have `wget` so one has to use 
`curl` which perhaps doesn't have the same options, and I don't know what 
Sage uses internally to download all this. 

-- 
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] Posets: interval/closed_interval

[Jori Mantysalo]

What is the logic having both interval() and closed_interval() defined on 
posets? Last one is really defined as a function, but is just calls first 
one.


--
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems

[Ursula Whitcher]

On 11/3/2014 4:05 PM, William Stein wrote:

I'm sure the
AMS would be very interesting in publishing more pieces that involve
computational mathematics/software, and likely only don't because they
don't have quality submissions enough to choose from.   I published
one there several years ago about open source [1].

  -- William


Did you write the full article and then submit it to the Notices, or did 
you query the editors with a proposal first?  They officially accept 
both types of submissions; do you know whether one method has better 
chances in practice?


UAW

--
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 we ship vanilla upstream tarballs or stripped-down ones?

[Thierry]

Hi,

On Wed, Nov 05, 2014 at 01:20:26AM -0800, Robert Bradshaw wrote:
> On Fri, Oct 31, 2014 at 5:27 AM, kcrisman  wrote:
> >>
> >> >
> >> > IMHO we should only modify upstream tarballs if we have to (e.g. strip
> >> > out
> >> > non-free parts). The upstream tarballs are cached, so its just a
> >> > one-time
> >> > download anyways.
> >>
> >> There are people who have a very bad band-with. In my case, it's fine
> >> when I am at university. But other than that, I only have a mobile
> >> internet stick, for which 50MB more or less really matters.
> >
> > And outside the developed world this can be even more of a problem.
> > Especially for upgrades I notice it can take a while even on my relatively
> > fast US connection - gcc took several minutes at least to download on my
> > last `git pull`.
> 
> These packages are already big enough that, for most people, it's not
> interactive (i.e. one starts the download, does something else for a
> while, then checks back to see if it's done). As such the difference
> between 4 minutes and 10 is really not that big of a deal. I think
> there are few people that have an internet connection that is
> 
> * Good enough to download Sage, but
> * poor enough that an extra 50 or even 100 megabytes is an undue burden.
> 
> Certainly not worth re-packaging upstream tarballs unless absolutely 
> necessary.

+1 with this point of view.

However, when lacking good internet connection, unless the bandwidth is
so slow that it was already impossible to download sage itself (in such
(frequent) cases the question is irrelevant, and workarounds like the
self replicating live USB may apply), as for me the problem is not much
the total size (one can wait), but the fact that some spkgs are a huge
single file and must be downloaded all at once. 

A concrete example for me is "sage -i database_gap" which always
requires a lot of attempts because in the download duration, there is
always a timeout at some point that forces to redownload everything from
the beginning. A manual solution is to use repeated "wget --continue"
within the upstream/ directory, which 'sage -i' is not offering by
default. I am not sure if urllib has such an obstination option.

Ciao,
Thierry


-- 
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 we ship vanilla upstream tarballs or stripped-down ones?

[John Cremona]

On 5 November 2014 09:20, Robert Bradshaw  wrote:
> On Fri, Oct 31, 2014 at 5:27 AM, kcrisman  wrote:
>>>
>>> >
>>> > IMHO we should only modify upstream tarballs if we have to (e.g. strip
>>> > out
>>> > non-free parts). The upstream tarballs are cached, so its just a
>>> > one-time
>>> > download anyways.
>>>
>>> There are people who have a very bad band-with. In my case, it's fine
>>> when I am at university. But other than that, I only have a mobile
>>> internet stick, for which 50MB more or less really matters.
>>
>> And outside the developed world this can be even more of a problem.
>> Especially for upgrades I notice it can take a while even on my relatively
>> fast US connection - gcc took several minutes at least to download on my
>> last `git pull`.
>
> These packages are already big enough that, for most people, it's not
> interactive (i.e. one starts the download, does something else for a
> while, then checks back to see if it's done). As such the difference
> between 4 minutes and 10 is really not that big of a deal. I think
> there are few people that have an internet connection that is
>
> * Good enough to download Sage, but
> * poor enough that an extra 50 or even 100 megabytes is an undue burden.
>
> Certainly not worth re-packaging upstream tarballs unless absolutely 
> necessary.

What proportion of the total Sage tarball would be taken up by these
upstream ones?  I can imagine two versions of Sage's tarbal, one with
and one without, so that it would still be possible to download the
whole thing at once, but also possible to download the small one (with
none of the upstream ones) and have the build system download those as
needed, rather as happens with a git-based install.  In the latter
case it would even be possible to grab the upstream tarballs from an
upstream website instead of sage's own (with a filename and checksum
check to make sure that the correct version was used)?

Of course the possibility to download everything at once and build
online will always remain.

John

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

-- 
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 we ship vanilla upstream tarballs or stripped-down ones?

[Robert Bradshaw]

On Fri, Oct 31, 2014 at 5:27 AM, kcrisman  wrote:
>>
>> >
>> > IMHO we should only modify upstream tarballs if we have to (e.g. strip
>> > out
>> > non-free parts). The upstream tarballs are cached, so its just a
>> > one-time
>> > download anyways.
>>
>> There are people who have a very bad band-with. In my case, it's fine
>> when I am at university. But other than that, I only have a mobile
>> internet stick, for which 50MB more or less really matters.
>
> And outside the developed world this can be even more of a problem.
> Especially for upgrades I notice it can take a while even on my relatively
> fast US connection - gcc took several minutes at least to download on my
> last `git pull`.

These packages are already big enough that, for most people, it's not
interactive (i.e. one starts the download, does something else for a
while, then checks back to see if it's done). As such the difference
between 4 minutes and 10 is really not that big of a deal. I think
there are few people that have an internet connection that is

* Good enough to download Sage, but
* poor enough that an extra 50 or even 100 megabytes is an undue burden.

Certainly not worth re-packaging upstream tarballs unless absolutely necessary.

- Robert

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