I am trying to install the gap_packages in my sage installation so that I
can construct the McLaughlinGraph which uses the design package of GAP.
I tried the instructions mentioned
here: http://wiki.sagemath.org/InstallingGapPackages, and got the following
error,
checking whether the C
The webpage http://trac.sagemath.org/wiki/Cygwin64Port indicates that
sage can now be built under cygwin64 almost out of the box. So, I tried,
but I failed...
Here are the problems I encountered, maybe someone with better computer
skills can see what is going on. My sage version is sage
I am trying to install the gap_packages in my sage installation so that I
can construct the McLaughlinGraph which uses the design package of GAP.
I tried the instructions mentioned here:
http://wiki.sagemath.org/InstallingGapPackages, and got the following
error,
checking whether
On Friday, 9 January 2015 19:36:40 UTC+1, David Joyner wrote:
On Fri, Jan 9, 2015 at 10:53 AM, anurag bishnoi annu...@gmail.com
javascript: wrote:
I am trying to install the gap_packages in my sage installation so that
I
can construct the McLaughlinGraph which uses the design package
Did you build Sage from source, or did you get a binary distribution?
On Friday, January 9, 2015 at 7:53:46 AM UTC-8, anurag bishnoi wrote:
I am trying to install the gap_packages in my sage installation so that I
can construct the McLaughlinGraph which uses the design package of GAP.
I
1) should we keep the Sage dev scripts in Sage ?
2) Should we keep it in the doc ?
There is one very useful thing in the dev script: transform old
mercurial patches into git commit. There are still ticket on trac with
patches and I use this tool from time to time.
Vincent
--
You received
On Friday, January 9, 2015 at 5:10:03 PM UTC+1, martin@gmx.net wrote:
Hadn't known of git-trac before. Since the tool has some sage settings
hard-wired into it, perhaps it should be called git-sage instead, to avoid
clashes?
My goal was to keep git-trac as independent as possible from
Hadn't known of git-trac before. Since the tool has some sage settings
hard-wired into it, perhaps it should be called git-sage instead, to avoid
clashes?
Recently I've been using git the hard way for pretty much everything except
pushing, for which I used ./sage -dev push --ticket in the hope
Thanks for catching that - so it is faster, but it is wrong.
fast_callable gives wrong answer for float and RDF domains, but correct one
for RR... Which is quite annoying since 0^(2/3) does not look like an
ambiguous expression to me.
--
You received this message because you are subscribed to
On Friday, January 9, 2015 at 4:10:41 PM UTC-5, Andrey Novoseltsev wrote:
Hello,
I got 0^(2/3) = 1 as a result of fast_float. Trying to see what is wrong
with it, I found out that nobody worked on that file since 2010 and
fast_callable is a better replacement for it. Here is an example:
1) should we keep the Sage dev scripts in Sage ?
2) Should we keep it in the doc ?
There is one very useful thing in the dev script: transform old
mercurial patches into git commit. There are still ticket on trac with
patches and I use this tool from time to time.
Oh! I didn't
I am not sure I remember now how I installed SAGE on this system. Probably
it was already there when I started using it.
I have been using SAGE for past one year without any issues.
Here's what happens with those commands:
pccage35:Code bishnoi$ sage -sh
Starting subshell with Sage
On Fri, Jan 9, 2015 at 10:53 AM, anurag bishnoi annu2...@gmail.com wrote:
I am trying to install the gap_packages in my sage installation so that I
can construct the McLaughlinGraph which uses the design package of GAP.
You can do this by hand:
(1) Go to the GAP website (gap-system.org),
(2)
Hello,
I got 0^(2/3) = 1 as a result of fast_float. Trying to see what is wrong
with it, I found out that nobody worked on that file since 2010 and
fast_callable is a better replacement for it. Here is an example:
sage: f(x) = (x+1)^(2/3)
sage: print f(1), f(-1)
2^(2/3) 0
sage: timeit(f(1))
On Friday, January 9, 2015 at 9:49:52 AM UTC+1, Sebastien Gouezel wrote:
The webpage http://trac.sagemath.org/wiki/Cygwin64Port indicates that
sage can now be built under cygwin64 almost out of the box. So, I tried,
but I failed...
Here are the problems I encountered, maybe someone with
If it is in July, i would be happy to give a hand. Befire that would be
impossible for me because of my teaching duties.
El jueves, 8 de enero de 2015, 17:27:45 (UTC+1), William escribió:
On Thu, Jan 8, 2015 at 8:20 AM, kcrisman kcri...@gmail.com javascript:
wrote:
Would anybody be
That is easy to fix.
Just add gmp to the linked libraries in module_list.py for these files.
People should really pay attention to what they use in their code, Linux
is just too nice.
This is a very, very typical Cygwin-type fix, adding additional libraries
to module_list.py - but until
17 matches
Mail list logo
