Trac #2436 adds the following algorithms from glib to libcsage:
Multiplatform threads
Thread pools
Asynchronous Queues
Memory Slices
Doubly and Singly linked lists
Queues
Sequences
Hash Tables
Arrays
Balanced Binary Trees
N-ary Trees
Quarks
In particular it features a slab memory allocator based
Honestly, independent of the spkg vs libcsage issue, which is really an
issue of semantics in my opinion, Sage has no high speed implementations of
C algorithms. Sage can not escape this forever. Either someone will have
to write their own at some point or we can use glib as a starting block. It
one of the big advantages is that they avoid much of the memory management
issues, so I don't expect them to be slower (and if they are, I may have to
fix that).
On Wed, Mar 26, 2008 at 3:06 PM, Robert Bradshaw <
[EMAIL PROTECTED]> wrote:
>
> On Mar 26, 2008, at 11:57 AM, Gary Fu
I'll move this to an spkg.
On Thu, Mar 27, 2008 at 2:07 AM, mabshoff <
[EMAIL PROTECTED]> wrote:
>
>
> > > Furthermore, I intend to help
> > > maintain the C algorithms. I fully intend to work on them actively if
> their
> > > speed is not sufficient. Making a seperate spkg dramatically increa
Alexander <[EMAIL PROTECTED]>
wrote:
>
>
> On 1-Apr-08, at 10:21 AM, Gary Furnish wrote:
>
> > Maybe. I see two real issues.
> > 1) Sage right now has really bad global namespace pollution issues
> > that make it very hard to import just one or two files. I
Maybe. I see two real issues.
1) Sage right now has really bad global namespace pollution issues that make
it very hard to import just one or two files. I don't see why this
shouldn't be fixable, it just needs someone to work on it. This would not
be that hard, and would probably catch some subt
wrote:
>
> On Apr 1, 11:23 am, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
> > On Apr 1, 2008, at 10:45 AM, Nick Alexander wrote:
> >
> > > On 1-Apr-08, at 10:36 AM, Gary Furnish wrote:
> >
> > >> Right now pulling in group theory may end up pullin
, Apr 1, 2008 at 1:36 PM, Robert Bradshaw
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote:
> >>> Wierd circular import issues can (should) be solved with circular
> >>> cdef imports. I think the easie
ssues
after a rings.basic... do we move to a rings.basic and rings.basic2 system?
On Tue, Apr 1, 2008 at 3:14 PM, Robert Bradshaw <
[EMAIL PROTECTED]> wrote:
>
> On Apr 1, 2008, at 2:08 PM, Gary Furnish wrote:
> > Why not use import sage.rings.integer_ring as module_integer_ri
evel). Does such a thing exist?
-- Gary Furnish
On Wed, Apr 23, 2008 at 9:49 AM, Bill Page <[EMAIL PROTECTED]>
wrote:
>
> On Wed, Apr 23, 2008 at 4:28 AM, Michael.Abshoff wrote:
> >
> > Martin Rubey wrote:
> >
> > > I do not see how the problem of diffe
> - It suffers from the "I can do it better", do-it-yet-again-in-python
>syndrome, where it will be discovered that python is too slow
>so we need to rewrite it in Cython and do obscure, undocumented,
>performance enhancing software hacks.
Unfortunately computers live in the physica
My point was that information on branch cuts should either A) be
publicly available or B) preferably available as an export option.
Mathematica and Maple both do A. Perhaps B is the better answer for
open systems. In any event I stand by my point that this is only an
issue because people have a
ro: Fix ModularSymbols(GammaH(8,[3])).decomposition()
>ModularSymbols(GammaH(81, [10])).decomposition();
> #3029: Tim Abbott: Move DEB_AUTO_UPDATE_DEBIAN_CONTROL out
>of Debian packages
> #3030: Gary Furnish: Cython working directory command line
>option patch
>
> /home/jec/sage-3.0.1.alpha1
> [EMAIL PROTECTED]
> COPYING.txt example.sage HISTORY.txt makefile README.txt sage
> sage-README-osx.txt spkg
>
>
> Pity, as I was looking forward to speeding up build time on a
> 4-processor machine!
>
> John
>
> 2008/5/
Tim Abbott: Debian lcalc package missing -DINCLUDE_PARI
> >flag
> > #3094: Tim Abbott: Update to SAGE Debian packaging
> > #3095: Lars Fischer, Michael Abshoff: Notebook, Documentation
> >of DATA has a small error
> > #3096: Michael Abs
Try building with SAGE_BUIILD_THREADS=2. If you are building with 3
threads on a 2 cpu system you could be seeing some type of
cache/scheduler issue as pbuild fully saturates the threads it
launches to 100% cpu usage.
On Tue, May 6, 2008 at 2:05 AM, Dan Drake <[EMAIL PROTECTED]> wrote:
> I have
So after a discussion on irc about how log2(8) should evaluate to 3 by
default, I thought I'd start taking feature requests for the symbolics
rewrite I'm currently working on. The current list is (with many of
these already done)
Symbolics must not rely on maxima for most operations.
Symbolics mu
There is definitely going to be some form of pattern matching, as it
is pretty much required by simplification. The exact syntax isn't
decided yet.
1) Everything has been converted to Cython and all of the internals
are pure Cython with no or very few python function calls. The code
is essential
+1. Planarity is a mess of non Cython files that are included in the
main tree and should probably be compiled as a library.
On Fri, May 23, 2008 at 9:05 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> On May 23, 12:55 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>
> Hi Robert,
>
>> Is there any
With the symbolics rewrite moving quickly, I'd like to request that if
possible people try to avoid adding more "Maxima-isms" to
sage.calculus. Specifically, if functionality is being added, please
try to keep it "general" in that the design of the functionality is
not dictated by what Maxima doe
I agree, which is why I supported making some sort of
canonical_comparison method for output, and then using <= for
subgroup.
On Fri, May 23, 2008 at 11:36 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> Following on from Nick's point, I cannot imagine that users will want
> or expect to sort a l
tar
>>>
>>> which fixes three issues:
>>>
>>> #3279: Michael Abshoff: Sage 3.0.2.rc0: Copy dsage_* scripts from the
>>> scrips.spkg
>>> #3280: Michael Abshoff: Sage 3.0.2.rc0: fix rebuild Sage documentation
>>> issues
>>> #3281
A bunch of the stuff in misc.functional is junk... I've deleted a
bunch of it in my symbolics rewrite without any issues.
On Sat, May 31, 2008 at 4:04 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Sat, May 31, 2008 at 2:32 PM, John H Palmieri <[EMAIL PROTECTED]> wrote:
>>
>> What is the rol
h you, but in this specific case I believe this
is 100% safe.
On Sat, May 31, 2008 at 4:40 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
> On Jun 1, 12:27 am, "Gary Furnish" <[EMAIL PROTECTED]> wrote:
>
> Hi Gary,
>
>> A bunch of the stuff in misc.functiona
>
> But if so then I want to have something like SymbolicNumber which is
> the subset of SymbolicRing that does not contain variables. And that
> this SymbolicNumber is coerced automatically down when used with
> RealField.
There are really, really severe issues with coercion out of the
SymbolicR
+1
On Sat, May 31, 2008 at 5:15 PM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jun 1, 1:02 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>> On Sat, May 31, 2008 at 3:56 PM, Gary Furnish <[EMAIL PROTECTED]> wrote:
>>
>> > The
-1 To this idea. Better to try to improve the coercion system to
support something that interacts with symbolics better.
On Sat, May 31, 2008 at 5:23 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Sat, May 31, 2008 at 3:33 PM, Jason Grout
> <[EMAIL PROTECTED]> wrote:
>>
>> Henryk Trappmann
We could easily change this so that we by default go ahead and coerce
the log(10) to RR if its multiplied by something in RR. (so that we
end up with a numeric result). This is probably a good idea.
On Mon, Jun 2, 2008 at 12:05 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
>
> On Jun 1, 2008,
-1. First, everything cwitty said is correct. Second, if we start
using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going
through the coercion system which was designed to be elegant instead
of fast, so this becomes insanely slow for any serious use. Finally,
this is going to requ
On Mon, Jun 2, 2008 at 11:41 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 2, 2008, at 12:55 PM, William Stein wrote:
>
>> On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> -1. First, everyt
On Tue, Jun 3, 2008 at 2:34 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 3, 2008, at 12:09 AM, Gary Furnish wrote:
>
>>
>> On Mon, Jun 2, 2008 at 11:41 PM, Robert Bradshaw
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On Jun 2, 2008,
ng it into the elements of say, ZZ,QQ,RR and then having
them call the coercion model only if those hardcodes can't figure the
situation out.
On Tue, Jun 3, 2008 at 11:48 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 3, 2008, at 7:13 AM, Gary Furnish wrote:
>
>>
On Tue, Jun 3, 2008 at 12:11 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 3, 2008, at 11:06 AM, Gary Furnish wrote:
>
>> I think we had a discussion on irc about how homsets still got used
>> for determining the result of something in parent1 op something
t; On Tue, Jun 3, 2008 at 3:09 AM, Gary Furnish <[EMAIL PROTECTED]> wrote:
>
>>
>> Your going to have a hard time convincing me that the default behavior
>> in Mathematica and Maple is wrong. This makes sense for number theory
>> but not for people using calculus
On Tue, Jun 3, 2008 at 2:48 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote:
>
>> On Tue, Jun 3, 2008 at 12:11 PM, Robert Bradshaw
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On Jun 3, 2008, at 11:0
On Tue, Jun 3, 2008 at 4:39 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 3, 2008, at 3:08 PM, Gary Furnish wrote:
>
>>
>> On Tue, Jun 3, 2008 at 2:48 PM, Robert Bradshaw
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> When a new morphism
On Tue, Jun 3, 2008 at 7:21 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 3, 2008, at 4:36 PM, Gary Furnish wrote:
>>>
>>> That depends on what they are being used for, but categories lend
>>> themselves very naturally to multiple i
I don't exactly understand these distributed control systems very
well, so hopefully this isn't an obvious question. Right now as I'm
working on symbolics I commonly have files from multiple branches open
(symbolics-stable/backup, symbolics-current, calculus-old). I also
have to frequently have t
This was not my point. My point was that if you use multiple branches
at the same time, your forced to have multiple physical branches of
the files, and while from my conversations on irc this may be
possible, its going to involve spending a bunch of effort to get what
we already have working aga
This code pickles and unpickles functions. Note it is simi-hackish
and I make no guarentee about it working in python 3.0 (but I'll be
maintaining a copy for distributed stuff I'm working on for dev1.
import new, types, copy_reg, cPickle
#See python cookbook for more details
def code_ctor(*args)
I already gave this a verbal +1, but does anyone know what happens if
you fork a sage process with open pexpect interface?
On Tue, Jun 24, 2008 at 10:26 AM, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jun 24, 2008 at 10:21 AM, Nick Alexander <[EMAIL PROTECTED]> wrote:
>>
>>> Anyway, sinc
I was one of the people who discussed this at dev1, and give a very
positive +1 to it (especially possible code auto generation).
On Tue, Jul 1, 2008 at 10:59 AM, <[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Tue, 1 Jul 2008, Carl Witty wrote:
>
>>
I can't find any caching for fast_float objects
On Tue, Jul 8, 2008 at 12:52 AM, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jul 7, 2008 at 9:12 PM, Elliott Brossard
> <[EMAIL PROTECTED]> wrote:
>> Hi William,
>>
>> I am becoming more familiar with both Linux and Sage now, which makes things
>> much easier. I finished porting the Maxim
This is done very often in physics; without this feature I largely
consider any units system useless.
On Mon, Jul 21, 2008 at 7:06 PM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On Jul 20, 1:52 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>>(1) Are the list of all units one uses pretty stand
I've been trying to get an answer for this question for the last few
weeks: Is the plan to extend ginac (write algorithms in C) or to
extend sage (write new algorithms in Sage) using cython/python? This
is very much a design related question, and in the hurry to get GiNaC
through review I feel th
"
Make it so sympy also runs on top of GiNaC. This will force the creation
of a clear interface specification.
"
If there is going to be a clear interface spec, then we should go and
make a clear interface spec so that anyone, not just GiNaC can
potentially conform to it. Perhaps this is the be
It should give the relative path to where you ran the test from... if
its not, thats a bug.
On Wed, Dec 17, 2008 at 2:31 PM, mabshoff wrote:
>
> On Dec 17, 1:27 pm, Jaap Spies wrote:
>> Jaap Spies wrote:
>
> Hi Jaap,
>
>> > --
Did you test for the sql alchemy bottleneck without using dsage?
There were some pretty severe (at times) speed issues fixed with dsage
in 3.2.2.
On Fri, Dec 19, 2008 at 11:24 AM, Jason Grout
wrote:
>
> Dan wrote:
>> Thanks for directing me.
>>
>> The bottleneck appears to be queries to a MySQL
Was that with a parallel test? I'm aware of the marker issue but
haven't been able to consistently reproduce it. The marker was a
temporary fix to solve even worse race conditions, so its still a step
in the right direction.
On Fri, Dec 19, 2008 at 12:51 PM, mabshoff wrote:
>
>
>
> On Dec 19,
49 matches
Mail list logo
