[sage-devel] Re: vtk optional package
The problem is that on Linux, if you don't have the opengl libraries (typically libgl1-mesa-dev) then vtk won't build but the package exits successfully. I guess I need to add my own tests for open gl libraries on linux like I do for tcl/tk. Josh On Nov 5, 10:09 pm, William Stein [EMAIL PROTECTED] wrote: Josh, I did a fresh install of Ubuntu 32-bit on my laptop (under parallels), then installed the latest sage from source. Next I installed your vtk metapackage from http://sage.math.washington.edu/home/jkantor/spkgs/ It of course didn't initially work, but after I install the tk devel package your metapackage built and successfully installed. However, upon trying to use it: sage: import vtk --- type 'exceptions.ImportError' Traceback (most recent call last) /home/was/Desktop/ipython console in module() type 'exceptions.ImportError': No module named vtk sage: import mayavi --- type 'exceptions.ImportError' Traceback (most recent call last) /home/was/Desktop/ipython console in module() /home/was/s/local/lib/python2.5/site-packages/mayavi/__init__.py in module() 3 # Hacks to make local name lookups work. Order is important and 4 # Common must be imported first. 5 import Common, Base.Objects 6 7 import Main /home/was/s/local/lib/python2.5/site-packages/mayavi/Base/__init__.py in module() 17 18 # needed by the LutHandler --- 19 import Objects 20 21 # now import Misc.LutHandler since we need it here. /home/was/s/local/lib/python2.5/site-packages/mayavi/Base/Objects.py in module() 19 20 import Tkinter, tkColorChooser --- 21 import vtk 22 import math 23 import Common, vtkPipeline.vtkPipeline type 'exceptions.ImportError': No module named vtk sage: -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] [Patch] Infamous Error 45 in clisp on MacOS X 10.5
Dear CLISP team,
I've recently built (vanilla) clisp-2.42 on MacOS X 10.5 (aka
Leopard). The resulting binary exhibited the infamous Error 45
problem [1], i.e. running
clisp | tee clisp.log # for example
yields the the following error message:
*** - UNIX error 45: Operation not supportd
(in an endless loop for CVS head even)
The MacPorts project [1] seems to work around this bug by compiling
clisp using
-D_NONSTD_SOURCE cflags. This however is an undesirable situation as
the include file /usr/include/sys/cdefs.h has the following to say
about this option:
/*
* COMPILATION ENVIRONMENTS
* [...]
* LEGACY Defining _NONSTD_SOURCE will get pre-POSIX APIs plus
Apple
* API extensions in scope.
*
* This is generally equivalent to the Tiger release
compilation
* environment, except that it cannot be applied to 64
bit code;
* its use is discouraged.
*
* We expect this environment to be deprecated in the
future.
* [...]
*/
The cause of the bug: Apple changed the value of EOPNOTSUPP to 102 in /
usr/include/sys/errno.h in the STANDARD compilation environment. This
seems to be due to the UNIX2003 certification that MacOS X 10.5 has
received. ENOTSUP however still is defined to be 45, and this is the
value the Darwin 9 kernel returns to user space. The problem can be
corrected by checking for both the ENOTSUP and the EOPNOTSUPP error
code in src/stream.d:
--- START PATCH ---
--- clisp-2.42/src/stream.d.ORIG2007-11-05 20:17:55.0 +0100
+++ clisp-2.42/src/stream.d 2007-10-03 15:30:26.0 +0200
@@ -3463,7 +3463,7 @@
if ((errno != EBADF) (errno != EACCES) (errno !=
EBADRQC))
#endif
#ifdef UNIX_DARWIN
- if ((errno != EOPNOTSUPP) (errno != ENOTSUP) (errno !
= ENODEV))
+ if ((errno != EOPNOTSUPP) (errno != ENODEV))
#endif
if (!(errno==EINVAL))
{ OS_error(); }
@@ -3474,7 +3474,7 @@
if (!( TCDRAIN(handle) ==0)) {
if (!((errno==ENOTTY)||(errno==EINVAL)))
#ifdef UNIX_DARWIN
-if (!((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV)))
+if (!((errno==EOPNOTSUPP)||(errno==ENODEV)))
#endif
{ OS_error(); } # no TTY: OK, report other Error
} else goto ok;
@@ -3523,7 +3523,7 @@
if ((errno != EBADF) (errno != EACCES) (errno !=
EBADRQC))
#endif
#ifdef UNIX_DARWIN
-if ((errno != EOPNOTSUPP) (errno != ENOTSUP) (errno !=
ENODEV))
+if ((errno != EOPNOTSUPP) (errno != ENODEV))
#endif
if (!(errno==EINVAL))
OS_error();
@@ -3549,7 +3549,7 @@
#endif
if (!((errno==ENOTTY)||(errno==EINVAL)))
#ifdef UNIX_DARWIN
-if (!((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV)))
+if (!((errno==EOPNOTSUPP)||(errno==ENODEV)))
#endif
{ OS_error(); } # no TTY: OK, report other Error
}
--- END PATCH ---
The patch has been tested against the current CVS head (as of Wed Nov
7 10:29:03 UTC 2007).
Kindest Regards,
Ralf-Philipp Weinmann
[1] Martin Costabel:
[Fink-devel] clisp, maxima and the UNIX error 45,
22 Jun 2005 01:59:06 -0700
http://www.mail-archive.com/[EMAIL PROTECTED]/msg11839.html
[2] MacPorts
http://www.macports.org/
--
Ralf-P. Weinmann [EMAIL PROTECTED]
TU Darmstadt, FB Informatik, Cryptography Computer Algebra
PGP fingerprint: 1024D/EF114FC02F150EB9D4F275B6159CEBEAEFCD9B06
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Fwd: [sage-support] sage-2.8.12 build report
This should really be sent to sage-devel, so I'm forwarding it there. -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Nov 7, 2007 11:07 AM Subject: Re: [sage-support] sage-2.8.12 build report To: [EMAIL PROTECTED] On Nov 7, 2007 11:02 AM, Kate Minola [EMAIL PROTECTED] wrote: I go away for a while, and now SAGE does not build on any of my machines of interest: Compiling from source using gcc-4.2.2, I get *** x86-Linux, ia64-Linux *** While compiling cvxopt-0.8.2.p4, I get gcc -pthread -shared build/temp.linux-i686-2.5/C/base.o build/temp.linux-i686-2.5/C/dense.o build/temp.linux-i686-2.5/C/sparse.o -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib/gcc-lib/i686-pc-linux-gnu/4.0.3 -lm -llapack -lblas -lf95 -o build/lib.linux-i686-2.5/cvxopt/base.so /usr/local/binutils-2.17/x86-Linux-gcc-4.1.1/bin/ld: cannot find -lf95 That's because you're using gfortran. Evidently Josh's fix for cvxopt not fully working fails for people using gfortran. I'll open a trac ticket: http://trac.sagemath.org/sage_trac/ticket/1125 *** x86_64-Linux *** While compiling libfplll-2.1-20071024, I get g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtbeginS.o .libs/fplll.o -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -lmpfr -lgmp -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2 -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/kate/sage/sage-2.8.12-x86_64-Linux/local/lib -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../.. /usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64/libstdc++.so -lm -lc -lgcc_s /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,-soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.0.0 /usr/bin/ld: /usr/lib/../lib64/libmpfr.a(exceptions.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/../lib64/libmpfr.a: could not read symbols: Bad value Why is Sage trying to use libmpfr.a out of /usr/lib? Should it not be using the version in [sage]/local/lib? I agree. Note that libfpll is a brand new package in Sage (it does very fast LLL reduction, so is quite important), but it hasn't been as widely tested as other components of Sage. This is now trac #1126: http://trac.sagemath.org/sage_trac/ticket/1126 I've made both trac tickets blockers. We'll fix them at Sage Days next week. William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: fraction field hashes (ticket 1075)
On Wednesday 07 November 2007 10:42, Martin Albrecht wrote: Sorry to reply to myself when I should have done my research beforehand. The issue is that multivariate polynomials over ZZ override hash and hash the tuple of tuples of exponents (roughly speaking). This is in stark contrast to the default implementation that hashes the string representation of an object. Thus, the hashes of mpolys over ZZ hash entirely differently than the fractionfield of mpolys over ZZ and hence the hashes are not equal. Hashing the string representation of self is a nice quick way to implement hashing but it is definitely quite inefficient however you want to look at it. I think writing more clever hashing functions is the right way to go. Also, Python internally doesn't hash string representations. I noticed that you called the singular p_String method in the hash function of the libsingular mpoly code. This pushes the string code down in to singular (and hence C) which is presumably *much* faster than some of the tricks we play in other poly __str__ methods. Was this more clever in your opinion? I'm not speaking for or against it, I'm just trying to get a better feel for what you are advocating. Hashing string is definitely one of the easiest ways to get a lot of semantics that we want ... i.e. agreement with '=='. In all other respects, it seems like one of the most awful hash algorithms one could imagine. However, I'm not saying it's a bad design decision since agreement with '==' is pretty much the central requirement. It does mean that using dictionaries with SAGE types has entirely different run-time characteristics than one might expect with dictionaries (although I think some actual benchmarks would be appropriate to support that claim and I plan to look into that a bit myself). -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: fraction field hashes (ticket 1075)
Joel's posting led me to read the old thread (March '07, before I
joined the sage lists) which was very interesting.
python wants hashes to be defined so that x==y implies
hash(x)==hash(y), while Sage wants to be clever mathematically so that
x==y is possible for a lot of complicated reasons. Including: (1) x
and y are the same member of the same parent (the easy case); (2) The
parents of x and y (say, X and Y) are such that there is a natural
coercion from X to Y -- or vice versa -- and coercion(x)==y; (3) more
generally again, there exists a structure Z into which both parents X
and Y can be coerced and coerce(x)==coerce(y) (in Z); all these seem
ok to me, provided that we restrict to injective coercions (e.g. ZZ in
QQ), but not when the coercions are not injective (e.g. ZZ to
ZZ(100)). That would be a complete nonsense since (for example, as
someone already noted) the coercion ZZ to ZZ(1) which is the trivial
rings maps all integers to 0.
Personally I would be happy for x==y to be false when x=ZZ(0) and
y=Integers(100)(0), since that leads to the relation == not being
transitive!
sage: x=ZZ(0)
sage: y=Integers(100)(0)
sage: z=ZZ(100)
sage: x==y
True
sage: y==z
True
sage: x==z
False
!!!
On 07/11/2007, Joel B. Mohler [EMAIL PROTECTED] wrote:
Hi,
I'd like some confirmation for the patch at
http://www.sagetrac.org/sage_trac/ticket/1075
The purpose of the patch is to fix the lack of substitution in the following
code snippet (it also has other ramifications in similar contexts):
sage: R.x,y=ZZ[]
sage: (x/y).subs({x:1})
x/y
The patch is to add a __hash__ method to the FractionFieldElement class to
make fractions with denominator 1 hash the same as the numerator. Thus, this
patch makes == and __hash__ agree for the case of embedding a ring into it's
fraction field.
For some reason, which is a mystery to me, that code snippet works as expected
if you replace ZZ with QQ. I realize that behind the scenes that gives you
an entirely different implementation (for the poly ring -- not the
fractionfield), but I don't understand why the hash values somehow work out
for the QQ case, but not the ZZ case.
Note that '==' and __hash__ have been hashed (pardon the pun) at some length
in the thread with this message:
http://groups.google.com/group/sage-devel/msg/b3812493e9d2d2c8
thanks
Joel
--
John Cremona
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: random polynomial generation
Hi everybody, I've attached a 'random_monomial.py' to http://trac.sagemath.org/sage_trac/ticket/980 which implements Steffen's and my proposal. Thoughts? Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: vtk optional package
I have a patch in my spkgs directory (vtk_plot.hg)
If you apply it, there will be 3 functions
vtk_plot_surface, vtk_plot_array, and vtk_plot_3d_iso
For example
sage: f=lambda x,y:sin(sqrt(x^2+y^2))
sage: vtk_plot_surface(f,-2,2,-2,2,num_points=100)
On Nov 7, 8:02 am, William Stein [EMAIL PROTECTED] wrote:
On Nov 7, 2007 1:00 AM, Joshua Kantor [EMAIL PROTECTED] wrote:
The problem is that on Linux, if you don't have the opengl libraries
(typically libgl1-mesa-dev) then vtk won't build but the package exits
successfully. I guess I need to add my own tests for open gl libraries
on linux like I do for tcl/tk.
Yes. I can confirm that after installing those package I have an install
of vtk and mayavi, since:
sage: import mayavi
sage: # no error!
Now what do I do? :-)
Josh
On Nov 5, 10:09 pm, William Stein [EMAIL PROTECTED] wrote:
Josh,
I did a fresh install of Ubuntu 32-bit on my laptop (under parallels),
then
installed the latest sage from source. Next I installed your vtk
metapackage
from
http://sage.math.washington.edu/home/jkantor/spkgs/
It of course didn't initially work, but after I install the tk devel
package your
metapackage built and successfully installed. However, upon trying
to use it:
sage: import vtk
---
type 'exceptions.ImportError' Traceback (most recent call
last)
/home/was/Desktop/ipython console in module()
type 'exceptions.ImportError': No module named vtk
sage: import mayavi
---
type 'exceptions.ImportError' Traceback (most recent call
last)
/home/was/Desktop/ipython console in module()
/home/was/s/local/lib/python2.5/site-packages/mayavi/__init__.py in
module()
3 # Hacks to make local name lookups work. Order is important and
4 # Common must be imported first.
5 import Common, Base.Objects
6
7 import Main
/home/was/s/local/lib/python2.5/site-packages/mayavi/Base/__init__.py
in module()
17
18 # needed by the LutHandler
--- 19 import Objects
20
21 # now import Misc.LutHandler since we need it here.
/home/was/s/local/lib/python2.5/site-packages/mayavi/Base/Objects.py
in module()
19
20 import Tkinter, tkColorChooser
--- 21 import vtk
22 import math
23 import Common, vtkPipeline.vtkPipeline
type 'exceptions.ImportError': No module named vtk
sage:
--
William Stein
Associate Professor of Mathematics
University of Washingtonhttp://wstein.org
--
William Stein
Associate Professor of Mathematics
University of Washingtonhttp://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: vtk optional package
On Nov 7, 2007 1:00 AM, Joshua Kantor [EMAIL PROTECTED] wrote: The problem is that on Linux, if you don't have the opengl libraries (typically libgl1-mesa-dev) then vtk won't build but the package exits successfully. I guess I need to add my own tests for open gl libraries on linux like I do for tcl/tk. Yes. I can confirm that after installing those package I have an install of vtk and mayavi, since: sage: import mayavi sage: # no error! Now what do I do? :-) Josh On Nov 5, 10:09 pm, William Stein [EMAIL PROTECTED] wrote: Josh, I did a fresh install of Ubuntu 32-bit on my laptop (under parallels), then installed the latest sage from source. Next I installed your vtk metapackage from http://sage.math.washington.edu/home/jkantor/spkgs/ It of course didn't initially work, but after I install the tk devel package your metapackage built and successfully installed. However, upon trying to use it: sage: import vtk --- type 'exceptions.ImportError' Traceback (most recent call last) /home/was/Desktop/ipython console in module() type 'exceptions.ImportError': No module named vtk sage: import mayavi --- type 'exceptions.ImportError' Traceback (most recent call last) /home/was/Desktop/ipython console in module() /home/was/s/local/lib/python2.5/site-packages/mayavi/__init__.py in module() 3 # Hacks to make local name lookups work. Order is important and 4 # Common must be imported first. 5 import Common, Base.Objects 6 7 import Main /home/was/s/local/lib/python2.5/site-packages/mayavi/Base/__init__.py in module() 17 18 # needed by the LutHandler --- 19 import Objects 20 21 # now import Misc.LutHandler since we need it here. /home/was/s/local/lib/python2.5/site-packages/mayavi/Base/Objects.py in module() 19 20 import Tkinter, tkColorChooser --- 21 import vtk 22 import math 23 import Common, vtkPipeline.vtkPipeline type 'exceptions.ImportError': No module named vtk sage: -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: point counting
Hi all, see http://trac.sagemath.org/sage_trac/ticket/1120 and http://trac.sagemath.org/sage_trac/ticket/1121 for the low hanging fruits. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] fraction field hashes (ticket 1075)
Hi,
I'd like some confirmation for the patch at
http://www.sagetrac.org/sage_trac/ticket/1075
The purpose of the patch is to fix the lack of substitution in the following
code snippet (it also has other ramifications in similar contexts):
sage: R.x,y=ZZ[]
sage: (x/y).subs({x:1})
x/y
The patch is to add a __hash__ method to the FractionFieldElement class to
make fractions with denominator 1 hash the same as the numerator. Thus, this
patch makes == and __hash__ agree for the case of embedding a ring into it's
fraction field.
For some reason, which is a mystery to me, that code snippet works as expected
if you replace ZZ with QQ. I realize that behind the scenes that gives you
an entirely different implementation (for the poly ring -- not the
fractionfield), but I don't understand why the hash values somehow work out
for the QQ case, but not the ZZ case.
Note that '==' and __hash__ have been hashed (pardon the pun) at some length
in the thread with this message:
http://groups.google.com/group/sage-devel/msg/b3812493e9d2d2c8
thanks
Joel
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
On Nov 7, 2007 12:52 PM, Joshua Kantor [EMAIL PROTECTED] wrote: Thats expected, since the fix I made was for g95 builds and it worked by linking in f95, which won't be around using gfortran. Should be easy to add a test for gfortran. I was going to test whether or not $SAGE_FORTRAN was set and use an appropriate setup.py depending on whether or not this is true. (if not assume g95, else assume gfortran) Watch out, since SAGE_FORTRAN need *not* be set. All that matters is that when the fortran spkg was installed the variable SAGE_FORTRAN was set. The important thing is the contents of local/bin/sage_fortran/. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: fraction field hashes (ticket 1075)
Sorry to reply to myself when I should have done my research beforehand. The issue is that multivariate polynomials over ZZ override hash and hash the tuple of tuples of exponents (roughly speaking). This is in stark contrast to the default implementation that hashes the string representation of an object. Thus, the hashes of mpolys over ZZ hash entirely differently than the fractionfield of mpolys over ZZ and hence the hashes are not equal. Hashing the string representation of self is a nice quick way to implement hashing but it is definitely quite inefficient however you want to look at it. I think writing more clever hashing functions is the right way to go. Also, Python internally doesn't hash string representations. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: fraction field hashes (ticket 1075)
On Wednesday 07 November 2007 08:33, Joel B. Mohler wrote:
I'd like some confirmation for the patch at
http://www.sagetrac.org/sage_trac/ticket/1075
The purpose of the patch is to fix the lack of substitution in the
following code snippet (it also has other ramifications in similar
contexts): sage: R.x,y=ZZ[]
sage: (x/y).subs({x:1})
x/y
...
For some reason, which is a mystery to me, that code snippet works as
expected if you replace ZZ with QQ. I realize that behind the scenes that
gives you an entirely different implementation (for the poly ring -- not
the fractionfield), but I don't understand why the hash values somehow work
out for the QQ case, but not the ZZ case.
Sorry to reply to myself when I should have done my research beforehand. The
issue is that multivariate polynomials over ZZ override hash and hash the
tuple of tuples of exponents (roughly speaking). This is in stark contrast
to the default implementation that hashes the string representation of an
object. Thus, the hashes of mpolys over ZZ hash entirely differently than
the fractionfield of mpolys over ZZ and hence the hashes are not equal.
This starts my thinking on a related tangent. I've heard the sentiment that
conversions to string need not be so fast since we are probably converting to
show them to the user. I agree with that sentiment, but here we are
converting to string to hash the object -- and thus, it is extremely
important to be fast (or else you've pretty much obliterated the point of
using a dictionary). I think this really is a point that bears more thought.
--
Joel
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
Thats expected, since the fix I made was for g95 builds and it worked by linking in f95, which won't be around using gfortran. Should be easy to add a test for gfortran. I was going to test whether or not $SAGE_FORTRAN was set and use an appropriate setup.py depending on whether or not this is true. (if not assume g95, else assume gfortran) Josh On Nov 7, 11:08 am, William Stein [EMAIL PROTECTED] wrote: This should really be sent to sage-devel, so I'm forwarding it there. -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Nov 7, 2007 11:07 AM Subject: Re: [sage-support] sage-2.8.12 build report To: [EMAIL PROTECTED] On Nov 7, 2007 11:02 AM, Kate Minola [EMAIL PROTECTED] wrote: I go away for a while, and now SAGE does not build on any of my machines of interest: Compiling from source using gcc-4.2.2, I get *** x86-Linux, ia64-Linux *** While compiling cvxopt-0.8.2.p4, I get gcc -pthread -shared build/temp.linux-i686-2.5/C/base.o build/temp.linux-i686-2.5/C/dense.o build/temp.linux-i686-2.5/C/sparse.o -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib/gcc-lib/i686-pc-linux-gnu/4.0.3 -lm -llapack -lblas -lf95 -o build/lib.linux-i686-2.5/cvxopt/base.so /usr/local/binutils-2.17/x86-Linux-gcc-4.1.1/bin/ld: cannot find -lf95 That's because you're using gfortran. Evidently Josh's fix for cvxopt not fully working fails for people using gfortran. I'll open a trac ticket: http://trac.sagemath.org/sage_trac/ticket/1125 *** x86_64-Linux *** While compiling libfplll-2.1-20071024, I get g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtbeginS.o .libs/fplll.o -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -lmpfr -lgmp -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2 -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/kate/sage/sage-2.8.12-x86_64-Linux/local/lib -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../.. /usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64/libstdc++.so -lm -lc -lgcc_s /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,-soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.0.0 /usr/bin/ld: /usr/lib/../lib64/libmpfr.a(exceptions.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/../lib64/libmpfr.a: could not read symbols: Bad value Why is Sage trying to use libmpfr.a out of /usr/lib? Should it not be using the version in [sage]/local/lib? I agree. Note that libfpll is a brand new package in Sage (it does very fast LLL reduction, so is quite important), but it hasn't been as widely tested as other components of Sage. This is now trac #1126: http://trac.sagemath.org/sage_trac/ticket/1126 I've made both trac tickets blockers. We'll fix them at Sage Days next week. William -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
Ok, then I'll look at sage_fortran --version. On Nov 7, 1:00 pm, William Stein [EMAIL PROTECTED] wrote: On Nov 7, 2007 12:52 PM, Joshua Kantor [EMAIL PROTECTED] wrote: Thats expected, since the fix I made was for g95 builds and it worked by linking in f95, which won't be around using gfortran. Should be easy to add a test for gfortran. I was going to test whether or not $SAGE_FORTRAN was set and use an appropriate setup.py depending on whether or not this is true. (if not assume g95, else assume gfortran) Watch out, since SAGE_FORTRAN need *not* be set. All that matters is that when the fortran spkg was installed the variable SAGE_FORTRAN was set. The important thing is the contents of local/bin/sage_fortran/. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
On Nov 7, 8:08 pm, William Stein [EMAIL PROTECTED] wrote: This should really be sent to sage-devel, so I'm forwarding it there. -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Nov 7, 2007 11:07 AM Subject: Re: [sage-support] sage-2.8.12 build report To: [EMAIL PROTECTED] On Nov 7, 2007 11:02 AM, Kate Minola [EMAIL PROTECTED] wrote: I go away for a while, and now SAGE does not build on any of my machines of interest: Compiling from source using gcc-4.2.2, I get *** x86-Linux, ia64-Linux *** While compiling cvxopt-0.8.2.p4, I get gcc -pthread -shared build/temp.linux-i686-2.5/C/base.o build/temp.linux-i686-2.5/C/dense.o build/temp.linux-i686-2.5/C/sparse.o -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib/gcc-lib/i686-pc-linux-gnu/4.0.3 -lm -llapack -lblas -lf95 -o build/lib.linux-i686-2.5/cvxopt/base.so /usr/local/binutils-2.17/x86-Linux-gcc-4.1.1/bin/ld: cannot find -lf95 That's because you're using gfortran. Evidently Josh's fix for cvxopt not fully working fails for people using gfortran. I'll open a trac ticket: http://trac.sagemath.org/sage_trac/ticket/1125 *** x86_64-Linux *** While compiling libfplll-2.1-20071024, I get g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtbeginS.o .libs/fplll.o -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -lmpfr -lgmp -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2 -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/kate/sage/sage-2.8.12-x86_64-Linux/local/lib -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../.. /usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64/libstdc++.so -lm -lc -lgcc_s /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,-soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.0.0 /usr/bin/ld: /usr/lib/../lib64/libmpfr.a(exceptions.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/../lib64/libmpfr.a: could not read symbols: Bad value Why is Sage trying to use libmpfr.a out of /usr/lib? Should it not be using the version in [sage]/local/lib? I agree. Note that libfpll is a brand new package in Sage (it does very fast LLL reduction, so is quite important), but it hasn't been as widely tested as other components of Sage. This is now trac #1126: Kate, could you try http://sage.math.washington.edu/home/mabshoff/libfplll-2.1-20071024.p0.spkg and report back it that solves the issue? Cheers, Michael http://trac.sagemath.org/sage_trac/ticket/1126 I've made both trac tickets blockers. We'll fix them at Sage Days next week. William -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: fraction field hashes (ticket 1075)
On Wednesday 07 November 2007, Joel B. Mohler wrote: On Wednesday 07 November 2007 10:42, Martin Albrecht wrote: Sorry to reply to myself when I should have done my research beforehand. The issue is that multivariate polynomials over ZZ override hash and hash the tuple of tuples of exponents (roughly speaking). This is in stark contrast to the default implementation that hashes the string representation of an object. Thus, the hashes of mpolys over ZZ hash entirely differently than the fractionfield of mpolys over ZZ and hence the hashes are not equal. Hashing the string representation of self is a nice quick way to implement hashing but it is definitely quite inefficient however you want to look at it. I think writing more clever hashing functions is the right way to go. Also, Python internally doesn't hash string representations. I noticed that you called the singular p_String method in the hash function of the libsingular mpoly code. This pushes the string code down in to singular (and hence C) which is presumably *much* faster than some of the tricks we play in other poly __str__ methods. Was this more clever in your opinion? Actually, no. I was just being lazy. It should loop over the terms and compute the hash directly. Off course this should be done in C. http://effbot.org/zone/python-hash.htm has an overview of Python's built-in hashes and I would say polynomials should be hashed like tuples there. I'm not speaking for or against it, I'm just trying to get a better feel for what you are advocating. Hashing string is definitely one of the easiest ways to get a lot of semantics that we want ... i.e. agreement with '=='. In all other respects, it seems like one of the most awful hash algorithms one could imagine. However, I'm not saying it's a bad design decision since agreement with '==' is pretty much the central requirement. Is it? Is this written down somewhere? It is just that I hear the first time about this requirement in this thread. I usually aimed for speed and small chance of clashes first. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
About the cvxopt problem Now the package checks sage_fortran -v and uses a setup.py that links against f95 if you have g95 and a setup.py that links against gfortran otherwise. (this package is in my spkgs cvxopt-0.8.2.p5.spkg) I have tested it with both g95 and gfortran. Josh On Nov 7, 3:16 pm, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Nov 7, 8:08 pm, William Stein [EMAIL PROTECTED] wrote: This should really be sent to sage-devel, so I'm forwarding it there. -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Nov 7, 2007 11:07 AM Subject: Re: [sage-support] sage-2.8.12 build report To: [EMAIL PROTECTED] On Nov 7, 2007 11:02 AM, Kate Minola [EMAIL PROTECTED] wrote: I go away for a while, and now SAGE does not build on any of my machines of interest: Compiling from source using gcc-4.2.2, I get *** x86-Linux, ia64-Linux *** While compiling cvxopt-0.8.2.p4, I get gcc -pthread -shared build/temp.linux-i686-2.5/C/base.o build/temp.linux-i686-2.5/C/dense.o build/temp.linux-i686-2.5/C/sparse.o -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib/gcc-lib/i686-pc-linux-gnu/4.0.3 -lm -llapack -lblas -lf95 -o build/lib.linux-i686-2.5/cvxopt/base.so /usr/local/binutils-2.17/x86-Linux-gcc-4.1.1/bin/ld: cannot find -lf95 That's because you're using gfortran. Evidently Josh's fix for cvxopt not fully working fails for people using gfortran. I'll open a trac ticket: http://trac.sagemath.org/sage_trac/ticket/1125 *** x86_64-Linux *** While compiling libfplll-2.1-20071024, I get g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtbeginS.o .libs/fplll.o -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -lmpfr -lgmp -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2 -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/kate/sage/sage-2.8.12-x86_64-Linux/local/lib -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../.. /usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64/libstdc++.so -lm -lc -lgcc_s /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,-soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.0.0 /usr/bin/ld: /usr/lib/../lib64/libmpfr.a(exceptions.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/../lib64/libmpfr.a: could not read symbols: Bad value Why is Sage trying to use libmpfr.a out of /usr/lib? Should it not be using the version in [sage]/local/lib? I agree. Note that libfpll is a brand new package in Sage (it does very fast LLL reduction, so is quite important), but it hasn't been as widely tested as other components of Sage. This is now trac #1126: Kate, could you try http://sage.math.washington.edu/home/mabshoff/libfplll-2.1-20071024.p... and report back it that solves the issue? Cheers, Michael http://trac.sagemath.org/sage_trac/ticket/1126 I've made both trac tickets blockers. We'll fix them at Sage Days next week. William -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
