Martin
I'd be willing to help with this. Aside from having worked with you on a
couple of the programs, I've been working on resurrecting the dynamic
algorithms of Caboara and Gritzmann and Sturmfels, using a new technique. I
also have some stuff you could probably use for introductory mate
On 2013-08-29, Martin Albrecht wrote:
> On Wednesday 28 Aug 2013 11:17:10 Rob Beezer wrote:
>> If you think this is a good project for the Sage community, then consider
>> demonstrate the viability by volunteering as an author, editor, producer
>> and/or manager of such an effort (in addition to
Ok, the reboot is done and the server now has 8 CPUs available.
Unfortunately this does not improve the performance of the interface much,
but I hope that it will now be more usable when many users are active.
-Keith
On Thursday, August 29, 2013 6:18:54 PM UTC-7, Keith Clawson wrote:
>
> I am i
On 2013-08-29, nil...@gmail.com wrote:
>
>
>>Am Donnerstag, 29. August 2013 23:33:43 UTC+2 schrieb Dima Pasechnik:
>>
>>
>> >This is a typical sign that a rebase in needed.
>> >cf. http://trac.sagemath.org/ticket/14031
>>
>>
> Yes, that worked. Many thanks !
>
> Unfortunately another error occur
I am increasing the number of CPUs available to Trac from 2 to 8 in order
to handle multiple users better. This requires rebooting the server, so
Trac will be unavailable for a minute or two.
-Keith
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gro
No. It's mostly done; I set out to finish it up just a couple of days ago
(but ran into a bunch of other issues trying to figure out what branch to
build, merge into, and the fact that tests didn't even all pass in the git
branch). Actually being able to pull, build, and pass tests is a
prerequisit
>Am Donnerstag, 29. August 2013 23:33:43 UTC+2 schrieb Dima Pasechnik:
>
>
> >This is a typical sign that a rebase in needed.
> >cf. http://trac.sagemath.org/ticket/14031
>
>
Yes, that worked. Many thanks !
Unfortunately another error occured, possibly caused by the same Python
issue ...
I benchmarked trac a while ago
(https://groups.google.com/d/msg/sage-git/Tv03f29jtK0/IHSleUwdk3MJ) and the
genshi page templating system is dog slow. But not tens-of-seconds slow,
just O(1s) per page serve.
On Thursday, August 29, 2013 10:14:30 PM UTC+1, Keith Clawson wrote:
>
> The apache2 p
On 2013-08-29, nil...@gmail.com wrote:
>> The Python interpreter included with Cygwin executes python -c "import
>> hashlib" >without incident, while the version built with Sage prints Aborted
>> (core >dumped). However, there is no problem if the version provided by Sage
>> is run >with no arg
The apache2 process is using 100% cpu for many seconds when I attempt to
view a ticket. Restarting apache doesn't seem to help. I don't know much
about trac, but this doesn't seem like correct behavior. I'm reading
trac.edgewall.org/wiki/TracPerformance to look for clues.
-Keith
On Wednesday,
Dear Matthew,
On Thu, Aug 29, 2013 at 09:21:20AM -0700, Matthew Weippert wrote:
>I believe there is a bug in sage's Combinations.random_element().
>Unfortunately, it's difficult (but not impossible) to reproduce. I need to
>search millions of combinations from a large set. In m
> The Python interpreter included with Cygwin executes python -c "import
> hashlib" >without incident, while the version built with Sage prints Aborted
> (core >dumped). However, there is no problem if the version provided by Sage
> is run >with no arguments and the line import hashlib is entere
Hi Matthew,
On 2013-08-29, Matthew Weippert wrote:
> Rather than re-creating the bug, I propose that the value returned from
> cardinality be cached in the Combinations class. Making calls to a gap
> subprocess sounds like a heavy-weight thing to do for every random call.
This sounds like a g
On Thursday, August 29, 2013 8:52:02 AM UTC-7, Simon King wrote:
>
> Hi Stefan,
>
> On 2013-08-29, Stefan > wrote:
> > Actually, this is not quite true. reduce() is, by default, called
> > automatically for elements of exact rings at creation time. It will
> > correctly get rid of common factor
I believe there is a bug in sage's Combinations.random_element().
Unfortunately, it's difficult (but not impossible) to reproduce. I need to
search millions of combinations from a large set. In many cases,
Combinations.random_element() works great. But if I have a largest enough
set, then it wi
Hi!
On Wed, Aug 28, 2013 at 04:11:13PM +, Simon King wrote:
> On 2013-08-28, Nils Bruin wrote:
> > There is a reason why (la)tex doesn't support arbitrarily deeply nested
> > lists: It's not readable for humans anymore by the time you're past
> > something like 5 levels.
I agree t
Hi Stefan,
On 2013-08-29, Stefan wrote:
> Actually, this is not quite true. reduce() is, by default, called
> automatically for elements of exact rings at creation time. It will
> correctly get rid of common factors, but it does not normalize the leading
> coefficients:
Bad. But of course, it
>
> But there is also a generically implemented method .reduce() for
> fraction field elements (so, not necessarily needed to implement it in
> subclasses). Of course, it is expensive and it may fail (if
> the gcd is not defined). But *if* it works, then fraction f1 is equal to
> fraction f2 i
Hello,
The following is I guess for the symbolic ring and is what we want
sage: cmp((x+1)^2, x^2 + 2*x + 1)
1
while the following is in a polynomial ring and is also what we want
sage: cmp((c+1)^2, c^2 + 2*c+1)
0
The only issue is about hashing and not == vs cmp, right ?
Note that there are oth
On Thursday, August 29, 2013 2:08:49 AM UTC-7, Simon King wrote:
>
> Hi Robert, hi Stefan,
>
>
>
> If I am not mistaken, containment in sets and dicts relies on cmp and
> not on ==. Hence, in this case, I think the hash is not to blame.
>
Indeed, comparing using == works:
sage: H5. = Frac
Hello,
so far, the patchbot is not able to test the tickets given by a git branch
(and it seems that it does not recognize the branch field)
Would it be hard to get that working ? There are already several tickets
with a git branch waiting for review (just one example #15054)
Frederic
--
You
On Wednesday 28 Aug 2013 11:17:10 Rob Beezer wrote:
> If you think this is a good project for the Sage community, then consider
> demonstrate the viability by volunteering as an author, editor, producer
> and/or manager of such an effort (in addition to those expressing interest
> already above).
Hi Robert, hi Stefan,
On 2013-08-28, Robert Bradshaw wrote:
> What could perhaps be added is some kind of a normalization routine
> (to be implemented by subclasses) that is called before performing a
> hash. This might be quite expensive.
Sorry, I intended to answer yesterday evening along the
23 matches
Mail list logo
