On Tuesday, November 27, 2012 10:06:15 PM UTC-5, Timo Kluck wrote:
>
> Op woensdag 28 november 2012 03:48:11 UTC+1 schreef kcrisman het volgende:
>>
>>
>>>
>>> One is an updated Boost library (standard spkg), and the other is an
>>> update to polymake (optional spkg). I've had to upload them to
Op woensdag 28 november 2012 03:48:11 UTC+1 schreef kcrisman het volgende:
>
>
>>
>> One is an updated Boost library (standard spkg), and the other is an
>> update to polymake (optional spkg). I've had to upload them to my own
>> server because of the filesize limit on trac. It would be nice if s
>
>
>
> One is an updated Boost library (standard spkg), and the other is an
> update to polymake (optional spkg). I've had to upload them to my own
> server because of the filesize limit on trac. It would be nice if someone
> could review them.
>
> The first one may be a bit controversial beca
Hi,
These two spkg updates need review:
http://trac.sagemath.org/13767
http://trac.sagemath.org/13768
One is an updated Boost library (standard spkg), and the other is an update
to polymake (optional spkg). I've had to upload them to my own server
because of the filesize limit on trac. It woul
Hey everyone,
I'm (now) running 5.5.rc0 and ran `sage -docbuild reference html` and
tried to look at the documentation locally, but everywhere there is math
formatting, it (eventually) becomes `[Math Processing Error]`. It seems to
be looking for
`file:///$path/sage-combinat/doc/output/html/
On 11/27/12 4:05 PM, Robert Bradshaw wrote:
On Tue, Nov 27, 2012 at 9:34 AM, Nils Bruin wrote:
On Nov 27, 6:12 am, Christian Stump wrote:
sage: UCF. = UniversalCyclotomicField(); UCF
Universal Cyclotomic Field endowed with the Zumbroich basis
sage: E(5)
E(5)
sage: UCF. = UniversalCyclotomicFi
On Tue, Nov 27, 2012 at 9:34 AM, Nils Bruin wrote:
> On Nov 27, 6:12 am, Christian Stump wrote:
>> sage: UCF. = UniversalCyclotomicField(); UCF
>> Universal Cyclotomic Field endowed with the Zumbroich basis
>> sage: E(5)
>> E(5)
>> sage: UCF. = UniversalCyclotomicField()
>> sage: zeta(5)
>> zeta5
>> sage: UCF. = UniversalCyclotomicField(); UCF
>> Universal Cyclotomic Field endowed with the Zumbroich basis
>> sage: E(5)
>> E(5)
>> sage: UCF. = UniversalCyclotomicField()
>> sage: zeta(5)
>> zeta5
> Is there a reason they print differently?
I currently distinguish the name "E" as input from a
Robert Bradshaw writes:
> On Tue, Nov 27, 2012 at 10:51 AM, Jason Grout
> wrote:
>> On 11/24/12 7:41 PM, Robert Bradshaw wrote:
>>
>>> Cool. (The doable part, not the unholy mess part :-). If that's the
>>> case, how about we simply ignore the issue at the moment, remove it
>>> all in the git con
Robert Bradshaw writes:
> On Mon, Nov 26, 2012 at 9:46 AM, kcrisman wrote:
>> In sage-combinat,
>> again, the queue seems to solve this, and there is a lot of impressive
>> teamwork.
>
> Yes, and I think it'd be really interesting to get one of them to
> understand outline their goals (and how we
Robert Bradshaw writes:
> Another crazy idea: encourage uploading of unfinished code with
> optional nag reminders. I'd rather people upload code without tests
> and people start reviewing it than hold onto it until they "get around
> to" adding all the examples. Just having public "todo" lists ca
William Stein writes:
> On Mon, Nov 26, 2012 at 11:48 PM, Burcin Erocal wrote:
>>Package dependencies for optional/experimental packages is beyond
>>the capabilities of the sage packaging system. Adding
>>"sage -i " commands to spkg-install is a very ugly
>>hack.
>
> What's the si
On Tue, Nov 27, 2012 at 10:51 AM, Jason Grout
wrote:
> On 11/24/12 7:41 PM, Robert Bradshaw wrote:
>
>> Cool. (The doable part, not the unholy mess part :-). If that's the
>> case, how about we simply ignore the issue at the moment, remove it
>> all in the git conversion, and document + enforce a
On 11/24/12 7:41 PM, Robert Bradshaw wrote:
Cool. (The doable part, not the unholy mess part :-). If that's the
case, how about we simply ignore the issue at the moment, remove it
all in the git conversion, and document + enforce a no-whitespace
policy as as part of the new development workflow.
On 11/24/12 8:11 AM, Ivan Andrus wrote:
I have no idea how much work it would be though, and there's always the
slight chance you might break something that way.
Here's an example of code that changes behavior when there is trailing
whitespace:
print 1 + \
2
If there is a space after the \,
On Nov 27, 9:34 am, Nils Bruin wrote:
> As you see, Ka and Kb apparently have an arbitrary isomorphism between
> them that is preferred, but of course we can't expect that to be
> compatible with chosen embeddings.
This has actually more dangerous consequences than the example above
suggests:
s
On Nov 27, 6:12 am, Christian Stump wrote:
> sage: UCF. = UniversalCyclotomicField(); UCF
> Universal Cyclotomic Field endowed with the Zumbroich basis
> sage: E(5)
> E(5)
> sage: UCF. = UniversalCyclotomicField()
> sage: zeta(5)
> zeta5
OK, now we're firmly arriving in bikeshedding territory:
I
Thanks. I have forwarded the thread to sage-nt since tehre are
several number theorists who will be interested but who do not read
all of sage-devel so might not have noticed.
John
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this
On Tuesday, November 27, 2012 4:59:14 AM UTC-5, Simon King wrote:
>
> Hi David,
>
> On 2012-11-27, David Kirkby > wrote:
> > I feel the way to solve this is to have community contributed
> > packages, which don't form part of the core of Sage, but can be
> > installed by anyone if they wish t
> The options would then be None/False (=no embedding), True (standard
> embedding), or any indexable.
I implemented the requested modifications, except for the new embeddings.
This is:
- the file sage.rings.universal_cyclotomic_field.all is lazily
imported in sage.rings.all
- the class Univers
On Mon, Nov 26, 2012 at 11:48 PM, Burcin Erocal wrote:
> On Tue, 27 Nov 2012 01:53:31 +0800
> P Purkayastha wrote:
>
>
>> I think the Sage community could quickly expand and there could be
>> tens, if not hundreds, of git development branches once the switch to
>> git occurs. It would be quite h
On 27 November 2012 09:58, Simon King wrote:
> Hi David,
Hi Simon.
> On 2012-11-27, David Kirkby wrote:
>> I feel the way to solve this is to have community contributed
>> packages, which don't form part of the core of Sage, but can be
>> installed by anyone if they wish to. Projects like R, Pe
On 2012-11-27, Robert Bradshaw wrote:
>> A while ago, I have created a public worksheet on "how to implement
>> basic algebraic structures in Sage", using category framework and coercion.
>> I think at some point it was supposed to become part of the
>> documentation, but I think we lost momentum.
Hi David,
On 2012-11-27, David Kirkby wrote:
> I feel the way to solve this is to have community contributed
> packages, which don't form part of the core of Sage, but can be
> installed by anyone if they wish to. Projects like R, Perl, autoconf
> all have this.
What is wrong with Sage's experim
On Mon, Nov 26, 2012 at 11:48 PM, Burcin Erocal wrote:
> On Tue, 27 Nov 2012 01:53:31 +0800
> P Purkayastha wrote:
>
>
>> I think the Sage community could quickly expand and there could be
>> tens, if not hundreds, of git development branches once the switch to
>> git occurs. It would be quite h
Hello,
First of all, thanks to all of you !
Though differential algebra can be used to prepare differential systems
before numerically integrate them, the package does not contain any
function clearly related to numerical computations. Thus I would rather
view it in the "algebraic" part of Sage.
On Mon, Nov 26, 2012 at 9:53 AM, P Purkayastha wrote:
> On 11/27/2012 01:19 AM, Robert Bradshaw wrote:
>>
>> This is somewhat a continuation of the "permutations...again" thread,
>> but I think the topic is much broader than that. Over time
>> contributing Sage has become increasingly bureaucratic
Hi
It would also be nice, if like R, one could run a system-wide install for
users
(e.g. in a university lab environment) and users could have optional
packages
either installed system-wide, or locally (e.g. .sage), and that those
packages
gracefully stated their minimum sage version to work on, o
On Mon, Nov 26, 2012 at 9:46 AM, kcrisman wrote:
>
> Great thoughts, Robert; I don't know if it will go anywhere, but it's worth
> revisiting every so often.
>
>>
>>
>> Raising the bar on Sage code quality creates this limbo area of code
>> that's good enough to be shared/built upon, but not good
On Mon, Nov 26, 2012 at 2:43 PM, Paul-Olivier Dehaye
wrote:
> My impression is that Sage's directory structure tries to address different
>>
>> concerns (meaning here: different mathematical topics). Do you think
>> that the present directory structure does not succeed to keep different
>> concern
On 26 November 2012 17:19, Robert Bradshaw wrote:
> Raising the bar on Sage code quality creates this limbo area of code
> that's good enough to be shared/built upon, but not good enough to be
> included in Sage. The combinat folks seem to have realized this from
> the beginning (hence the combin
On Mon, Nov 26, 2012 at 6:34 AM, Simon King wrote:
> Dear Paul-Olivier,
>
> On 2012-11-26, Paul-Olivier Dehaye wrote:
>> My understanding of aspect-oriented programming in general: encourages the
>> developer to realize that there are several concerns that will be present
>> in a large project, a
32 matches
Mail list logo
