On 2014-09-04 22:38, Simon King wrote:
And how can one build the debug version? I recall that one had to export
SAGE_DEBUG=yes before building, and I had several Sage versions on my
machine, all built from sources. But now, with git, I only have *one*
Sage install. Is it possible to switch back
On Thu, 4 Sep 2014, Volker Braun wrote:
ls -al /lib /lib64
ls: cannot access /lib64 : No such file or directory
You don't have a 64-bit system, it seems.
What the hell... I have just mechanically copied output without thinkin.
I have 64-bit system where /lib64 is symlink to
Hi Jean-Pierre and all,
Grat!
At some point, I pushed patches on linbox-devel (or something like that), but
never got any reply.
IIRC they were just tiny patches to ease ocmpilation on unusual archs.
I did not check recently, but one year ago or so they did not make it
upstream.
It would
The missing symbol is in libgfortran:
$ readelf -aW /usr/lib64/libgfortran.so.3 | grep
_gfortran_transfer_integer_write@@GFORTRAN_1.4
676: 000e1f40 5 FUNCGLOBAL DEFAULT 12
_gfortran_transfer_integer_write@@GFORTRAN_1.4
So it seems that we don't link libf77blas against
Permutation groups used to only handle permutations of 1,..n, and the
methods permute_rows and friends of matrices coped with this with an
ugly and potentially confusing shift by 1.
EVERYBODY is using those -1 and +1 everywhere. Those 1-based permutations
are just hell for whoever uses
Hi Jeroen,
On 2014-09-05, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
On 2014-09-04 22:38, Simon King wrote:
And how can one build the debug version? I recall that one had to export
SAGE_DEBUG=yes before building, and I had several Sage versions on my
machine, all built from sources. But
On Fri, 5 Sep 2014, Volker Braun wrote:
So it seems that we don't link libf77blas against libgfortran. Whats the output
of
sage -sh -c ldd local/lib/libf77blas.so
linux-vdso.so.1 = (0x7fffad3fe000)
libatlas.so.3 =
On Friday, September 5, 2014 11:42:21 AM UTC+2, Jori Mantysalo wrote:
On Fri, 5 Sep 2014, Volker Braun wrote:
So it seems that we don't link libf77blas against libgfortran. Whats the
output of
sage -sh -c ldd local/lib/libf77blas.so
linux-vdso.so.1 =
What is very curious is that you have a compilation error, yet you say
that setting LD_LIBRARY_PATH solve the problem. That variable
shouldn't influence compilation/linking, unlike LD_RUN_PATH or
LDFLAGS.
Are you using gold for linking?
François
On 5/09/2014, at 21:42, Jori Mantysalo
On Fri, 5 Sep 2014, Jean-Pierre Flori wrote:
Btw, I just installed a clean Fedora 20. At least yum install patch m4
is needed before compiling. Might be worth writing up somewhere the
packages that are needed to compile.
http://www.sagemath.org/doc/installation/source.html
The erroneous dependency on patch was fixed in #16794
On Friday, September 5, 2014 10:42:21 AM UTC+1, Jori Mantysalo wrote:
On Fri, 5 Sep 2014, Volker Braun wrote:
So it seems that we don't link libf77blas against libgfortran. Whats the
output of
sage -sh -c ldd
On Fri, 5 Sep 2014, Francois Bissey wrote:
What is very curious is that you have a compilation error, yet you say
that setting LD_LIBRARY_PATH solve the problem. That variable
shouldn't influence compilation/linking, unlike LD_RUN_PATH or
LDFLAGS.
Are you using gold for linking?
I have never
In
/home/jm58660/r-compile-test/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/src/main
What does
gcc -std=gnu99 -Wl,--export-dynamic -fopenmp
-L/home/jm58660/r-compile-test/sage-6.3/local/lib/ -o R.bin Rmain.o
-L../../lib -lR -Wl,--verbose
says.
Furthermore, does
gcc -std=gnu99
On Friday, September 5, 2014 11:30:44 AM UTC+1, Jori Mantysalo wrote:
I have never needed to think about what linker I am using. If gold is
installed as a default on Fedora, then I am using it.
Its not.
--
You received this message because you are subscribed to the Google Groups
On Fri, 5 Sep 2014, Francois Bissey wrote:
In
/home/jm58660/r-compile-test/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/src/main
What does
gcc -std=gnu99 -Wl,--export-dynamic -fopenmp
-L/home/jm58660/r-compile-test/sage-6.3/local/lib/ -o R.bin Rmain.o
-L../../lib -lR -Wl,--verbose
Sorry you should have started a sage shell first
/home/jm58660/r-compile-test/sage-6.3/sage -sh
On 5/09/2014, at 23:00, Jori Mantysalo jori.mantys...@uta.fi wrote:
On Fri, 5 Sep 2014, Francois Bissey wrote:
In
On Fri, 5 Sep 2014, Francois Bissey wrote:
Sorry you should have started a sage shell first
/home/jm58660/r-compile-test/sage-6.3/sage -sh
And then cd and gcc? Here:
(sage-sh) jm58660@localhost:sage-6.3$ cd
You appear to have bits of another gnu compiler in /usr/local. You
don't appear to have the binaries but some libs. Do you also have
libgfortran under /usr/local/lib64?
François
On 5/09/2014, at 23:14, Jori Mantysalo jori.mantys...@uta.fi wrote:
found libstdc++.so.6 at
On Fri, 5 Sep 2014, Francois Bissey wrote:
You appear to have bits of another gnu compiler in /usr/local. You
don't appear to have the binaries but some libs. Do you also have
libgfortran under /usr/local/lib64?
Yes. And of course /usr/local/* is checked before / and /usr. I have no
idea
Hi!
I just tried to build a debug version of Sage on my openSuse 12.3 laptop.
However, with SAGE_DEBUG=yes, the Singular spkg fails to build. I know
that in order to get a debug version a couple of years ago, we had to add
some patch to the Singular spkg. However, it *used* to work with that
Here is the code for is_isomorphic() on class FinitePoset:
if hasattr(other,'hasse_diagram'):
return . . .
else:
raise ValueError('The input is not a finite poset.')
So for example Posets.PentagonPoset().is_isomorphic(Hello everyone!)
gives the error
On Fri, Sep 5, 2014 at 7:22 AM, Jori Mantysalo jori.mantys...@uta.fi wrote:
Here is the code for is_isomorphic() on class FinitePoset:
if hasattr(other,'hasse_diagram'):
return . . .
else:
raise ValueError('The input is not a finite poset.')
So for
I just had a quick look at it, and the following looks downright scary:
+For backward compatibility, if a permutation group element
+acts on the integers `\{1,\ldots,n\}` or a subset thereof,
+the columns are considered as being numbered from `1`::
+
+
I just had a quick look at it, and the following looks downright scary:
It is one of this code's many wonders. Also, note that :
sage: Permutation([1,2,3])
[1, 2, 3]
sage: Permutation((1,2,3))
[2, 3, 1]
I hate that code.
Nathann
--
You received this message because you are subscribed to the
Your last example makes petgect sense in terms of mathematics:
the first one is a petmutation as a word and the second one is a
permutation as a group element. We need BOTH and we need both to be simple.
The diff between brackets and parenthesis is quite natural AND consistent
with mathematic
On Fri, Sep 5, 2014 at 11:00 AM, Nathann Cohen nathann.co...@gmail.com wrote:
I just had a quick look at it, and the following looks downright scary:
It is one of this code's many wonders. Also, note that :
sage: Permutation([1,2,3])
[1, 2, 3]
sage: Permutation((1,2,3))
[2, 3, 1]
I hate
And I must add that even so it is annoying for code, we do need the
1-starting permutations. All the combinatorists I know do not even think a
permutation can start at 0. It makes things more complicated for us and we
need to put extra care in code and documentation but we do need to print
and
On Friday, September 5, 2014 3:47:53 PM UTC+2, Volker Braun wrote:
I don't know of a ticket, feel free to fix it. All relevant files are in
build/pkgs/singular. It seems that the debug patches conflict with the
cygwin patch. Also, the debug patches should probably be applied strictly
The whole 0 vs. 1 based permutations (Python vs. Matlab :-) is always
confusing. And there is good reason and history in both conventions, so we
should IMHO accept that we'll have to live with it. Its not something that
can be solved satisfactorily by trying to guess the user's intentions, you
On 2014-09-05, Nathann Cohen nathann.co...@gmail.com wrote:
I just had a quick look at it, and the following looks downright scary:
It is one of this code's many wonders. Also, note that :
sage: Permutation([1,2,3])
[1, 2, 3]
sage: Permutation((1,2,3))
[2, 3, 1]
this actually makes
The Permutation0 might be a good idea, I don't know... It wouldn't change
the tuple vs. list thing which is used to distinguish between the cycle
notation and the word notation.
I agree some of the syntax could be improved. But I do think backward
compatibility is important. It's really annoying
On Fri, Sep 5, 2014 at 5:48 PM, Viviane Pons vivianep...@gmail.com wrote:
The Permutation0 might be a good idea, I don't know... It wouldn't change
the tuple vs. list thing which is used to distinguish between the cycle
notation and the word notation.
I agree some of the syntax could be
The Permutation0 might be a good idea, I don't know... It wouldn't change the
tuple vs. list thing which is used to distinguish between the cycle notation
and the word notation.
The cycle notation is incorrect too, as a permutation is a collection
of cycles. It also removes the need to
http://trac.sagemath.org/ticket/16745
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to
34 matches
Mail list logo
