On Friday, 21 September 2012 17:09:25 UTC+8, Jeroen Demeyer wrote:
>
> On 2012-09-21 10:52, Volker Braun wrote:
> > If there is an implementation that is *always* faster than the
> > alternatives then it makes no sense to keep others around.
> ...unless you have a simple but slow algorithm whi
On Wednesday, September 19, 2012 12:09:34 PM UTC-7, Volker Braun wrote:
>
> +1 to:
>
> * rename v.normalization() -> v.normal_form() unless somebody has a better
> name
> * replace v.normalization() with he usual division by L2-norm.
>
normal_form() is good, and to be standard with the other co
Hey
> In the long run I definitely vote for option 1, with
> sage.combinat.partitions.number_of_partitions pointing at any time to
> whatever implementation is fastest. I am also all fine with option 1
> in the short run if the user gets a useful error message when passing
> extra options; s
There is support for this in qhull, at least numerically. This is somewhat
wrapped by Scipy:
http://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.Delaunay.html
It would be great to integrate that and your other suggestions into
PointConfigurations as Volker suggests.
-Marshall H
Hmm looks like brain damage in Suse's gcc / toolchain. Can you try building
Sage's own gcc? That is,
export SAGE_INSTALL_GCC=yes
make distclean
make
On Friday, September 21, 2012 3:35:51 PM UTC+1, Aleksey Rukhlenko wrote:
>
> I have gmp-devel installed. Also, there's libgmp.so.7 in
> sage-5.3/
On 2012-09-21 16:35, Jeroen Demeyer wrote:
> On 2012-09-21 16:16, John Cremona wrote:
>> It would be helpful to know what a review of such a ticket would
>> entail. I have a laptop running ubuntu-12.04 which built recent sages
>> with no trouble, does that disqualify me?
> You could *uninstall* gf
On 2012-09-21 16:16, John Cremona wrote:
> It would be helpful to know what a review of such a ticket would
> entail. I have a laptop running ubuntu-12.04 which built recent sages
> with no trouble, does that disqualify me?
You could *uninstall* gfortran and then check whether Sage builds.
--
Yo
Thank you for reply.
In fact, I had libffi-devel installed. But copying of libffi* to
sage-5.3/local/lib helped.
However, I encountered new problem. Compilation of pari fails:
gcc -o gp-dyn
-L"/home/aleksey/temp/sage-5.3/spkg/build/pari-2.5.2.p0/src/Olinux-x86_64"
-O3 -Wall -fno-strict-alias
It would be helpful to know what a review of such a ticket would
entail. I have a laptop running ubuntu-12.04 which built recent sages
with no trouble, does that disqualify me?
John
On 21 September 2012 15:09, Jeroen Demeyer wrote:
> We should use environment variables LIBRARY_PATH and CPATH to
On 9/21/12 7:00 AM, Volker Braun wrote:
Sounds great. We already have a PointConfiguration class that lets you
iterate over the triangulations of the convex hull, your code should fit
in there perfectly. Definitely open a trac ticket, and please cc me on it.
And here are some more links to t
We should use environment variables LIBRARY_PATH and CPATH to support
the GCC spkg on recent Debian and Ubuntu systems.
*Blocker* because this causes a lot of support requests.
Please review:
http://trac.sagemath.org/sage_trac/ticket/13515
Thanks,
Jeroen.
--
You received this message because
On Friday, September 21, 2012 5:09:25 AM UTC-4, Jeroen Demeyer wrote:
>
> On 2012-09-21 10:52, Volker Braun wrote:
> > If there is an implementation that is *always* faster than the
> > alternatives then it makes no sense to keep others around.
> ...unless you have a simple but slow algorithm
Sounds great. We already have a PointConfiguration class that lets you
iterate over the triangulations of the convex hull, your code should fit in
there perfectly. Definitely open a trac ticket, and please cc me on it.
On Friday, September 21, 2012 12:33:38 PM UTC+1, moritz wrote:
>
> I though
I thought it might be a good idea to add a new feature: Voronoi diagrams.
I am not quite sure what the right class of objects would be but to get an
idea what I mean, I wrote the following function:
Given a list of k points in \RR^d return a list of voronoi cells, i.e.
polyhedra, in R^d:
def
On Friday, 21 September 2012 14:09:19 UTC+10, Dima Pasechnik wrote:
>
> This decreases the pedagogical value of Sage code for no good reason.
>
> Hi Dima,
If you reread my post you will see that ALL of the current functionality of
number_of_partitions is still supported by Partitions(*).cardin
On Thu, Sep 20, 2012 at 07:25:42PM -0700, Andrew Mathas wrote:
>Please let me know which of the following options you prefer:
> 1. deprecate the options to number_of_partitions and have the function in
>the global namespace point directly to
>sage.combinat.partitions.number_
On 2012-09-21 10:52, Volker Braun wrote:
> If there is an implementation that is *always* faster than the
> alternatives then it makes no sense to keep others around.
...unless you have a simple but slow algorithm which can be used to
check the result of the complicated fast algorithm.
--
You rec
If there is an implementation that is *always* faster than the alternatives
then it makes no sense to keep others around. The pedagogical value of
being able to pick a slow algorithm is really limited (especially if the
only thing that changes is the time it takes to spit out the same number),
18 matches
Mail list logo
