On 11/8/12 11:40 PM, R. Andrew Ohana wrote:
William and I are planning a workshop focused on transitioning Sage over
to Git. We have some funding available, so please contact me if you are
interested in attending; we don't need a commitment yet, but we do need
to gauge interest.
Dates: March 25-
On Nov 8, 9:20 pm, Robert Bradshaw
wrote:
> However, I agree with the sentiment that V.sum(W) grossly violates the
> principle of least surprise as well as being of dubious merit over the
> builtin sum(...).
And note that python's builtin sum is in sage shadowed by
sum=sage.misc.functional.symb
Hi Robert,
On 2012-11-09, Robert Bradshaw wrote:
> __len__ must return a (machine-sized) int, not elements of ZZ let
> alone infinity.
Sorry, I didn't know that. Then one should probably go the other way,
implement cardinality() for more parents, and use it in "sum".
Cheers,
Simon
--
You rec
William and I are planning a workshop focused on transitioning Sage over to
Git. We have some funding available, so please contact me if you are
interested in attending; we don't need a commitment yet, but we do need to
gauge interest.
Dates: March 25-29, 2013
Location: Portland, Oregon
Wiki Pag
On Thu, Nov 8, 2012 at 2:56 PM, Simon King wrote:
> On 2012-11-08, Nils Bruin wrote:
>> On Nov 8, 1:17 pm, Simon King wrote:
>>> Hi Volker,
>>>
>>> On 2012-11-08, Volker Braun wrote:
>>>
>>> > But then you'd always have to write a lot of
>>> > boilerplate to return an iterator. Its much easier
By the way, I happened to notice that it is looking for tune_fft.c for
some reason (I think it shouldn't be doing that). This file is in the
directory fft/tune, so you could copy it wherever it is expecting to
find it (tune or build.vc10/tune I think).
Maybe that will get the tune project to work
I'm sorry, I got that wrong. Here is what Brian wrote last time:
"I should mention that the tuning is very unreliable on Windows".
I misremembered that and thought that it wasn't supported.
It should work, but as Brian said last time, you do have to interleave
builds with tests and the same with
I believe tune is not supported on Windows.
I'll let Brian answer the question about the tests. Glad they built on
the second attempt.
Bill.
On 9 November 2012 00:01, Dann Corbit wrote:
> All of the projects build for me except for the tune project. The mpir-tests
> project had three failures
Hi all,
After a very long alpha/beta release cycle, MPIR 2.6.0 has finally
been released!
It is available from our website http://mpir.org/
This release is dedicated to the memory of Jason Moxham who passed
away recently.
The main new features in this release are:
* new FFT implementation for
On 2012-11-08, Nils Bruin wrote:
> On Nov 8, 1:17 pm, Simon King wrote:
>> Hi Volker,
>>
>> On 2012-11-08, Volker Braun wrote:
>>
>> > But then you'd always have to write a lot of
>> > boilerplate to return an iterator. Its much easier to use yield, but then
>> > you can't return any additional
On Nov 8, 1:17 pm, Simon King wrote:
> Hi Volker,
>
> On 2012-11-08, Volker Braun wrote:
>
> > But then you'd always have to write a lot of
> > boilerplate to return an iterator. Its much easier to use yield, but then
> > you can't return any additional information about finiteness.
>
> No? What'
> Could you attach the PARI log file (as mentioned in the message below
> the part you quoted).
>
I tried to attach the file, but google groups keeps giving me an error #340
when I try to post the message. We'll see if this message goes through.
Also I found out that the binaries in
sage-5
Hi Volker,
On 2012-11-08, Volker Braun wrote:
> But then you'd always have to write a lot of
> boilerplate to return an iterator. Its much easier to use yield, but then
> you can't return any additional information about finiteness.
No? What's wrong with __len__?
Cheers,
Simon
--
You recei
On 11/09/2012 12:16 AM, Jason Grout wrote:
On 11/8/12 6:26 AM, Simon King wrote:
Hi David and John,
On 2012-11-08, David Loeffler wrote:
It is *really awful* that V.sum(W) attempts to sum all the elements of
W! I don't know what general design decision underlies this but I
don't like it.
Th
On 11/8/12 6:26 AM, Simon King wrote:
Hi David and John,
On 2012-11-08, David Loeffler wrote:
It is *really awful* that V.sum(W) attempts to sum all the elements of
W! I don't know what general design decision underlies this but I
don't like it.
That's easy to explain. All additive semigroup
This occurred to me before, its nice to have iterators/generators but there
should be a mechanism to say that the iterator is over a finite or infinite
set. Just to avoid doing exhaustive searches over infinite sets. Similar to
C++ iterator traits, I guess. Of course if you were to manually impl
On 2012-11-08 08:56, Jeffrey Edlund wrote:
> On Debian Wheezy on x86_64 with kernel 3.2.0-3-amd64 I get the
> following error:
>
> gcc -o gp-dyn
> -L"/home/jedlund/Downloads/sage-5.3/spkg/build/pari-2.5.2.p0/src/Olinux-x86_64"
> -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -g
> -I/home
I don't think anyone is objecting to being able to add a list of
vectors (or any other objects which can be added). But in my example,
V.sum(W) is taking the (infinite) list of elements of W and adding
them up, which has nothing at all to do with V. Just replace QQ by a
finite field in my examp
Hi David and John,
On 2012-11-08, David Loeffler wrote:
> It is *really awful* that V.sum(W) attempts to sum all the elements of
> W! I don't know what general design decision underlies this but I
> don't like it.
That's easy to explain. All additive semigroups should be able to sum up a
list of
Thanks to all. The machine is still up, as I was able to stop the
computation with Crtl-C.
Now I see it, of course that's what V.sum(W) says that it does, except
that it in fact makes no sense, since adding up the (infinitely many)
elements of W has nothing to do with V.
I don't quite know how I
I suspect that what John wants is the sum of V and W as subspaces of a
common ambient space (not the direct sum embedded in the direct sum of
two copies of the ambient space, as Francis suggests). This can be
obtained (very quickly) by doing
sage: time V + W
Vector space of degree 100 and dimensio
On 11/08/2012 05:36 PM, John Cremona wrote:
Either I am doing something wrong or a simple operation which should
be fast is in fact very slow, but I do not know why.
If V,W are vector spaces over QQ, subspaces of the same ambient
space, then V.sum(W) should return their sum, with an echelon bas
Op donderdag 8 november 2012 10:36:51 UTC+1 schreef John Cremona het
volgende:
>
> Either I am doing something wrong or a simple operation which should
> be fast is in fact very slow, but I do not know why.
>
> If V,W are vector spaces over QQ, subspaces of the same ambient
> space, then V.sum
I think you want
sage: V.direct_sum(W)
Vector space of degree 200 and dimension 2 over Rational Field
Basis matrix:
2 x 200 dense matrix over Rational Field
Francis
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send em
Either I am doing something wrong or a simple operation which should
be fast is in fact very slow, but I do not know why.
If V,W are vector spaces over QQ, subspaces of the same ambient
space, then V.sum(W) should return their sum, with an echelon basis
obtained from the bases of V and W. But th
On Debian Wheezy on x86_64 with kernel 3.2.0-3-amd64 I get the
following error:
gcc -o gp-dyn
-L"/home/jedlund/Downloads/sage-5.3/spkg/build/pari-2.5.2.p0/src/Olinux-x86_64"
-O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -g
-I/home/jedlund/local/Linux-x86_64/include
-I/home/jedlund/loca
26 matches
Mail list logo
