[sage-devel] Re: [sage-combinat-devel] how to cure TestSuite failures involving Homs
Nicolas, > This __main__ trick is only for when you define python > functions "interactively" (e.g. in doctests), and you want to fake > them being picklable for TestSuite's pickling tests. Yes, but there are cases in which it is desirable for the code to create pure "orphan" functions, say, to help create morphisms. These morphisms will NOT pass pickling. And this is apparently enough for one's patch to be given the thumbs-down by the code barons, and perhaps rightfully so. Example. When constructing a tensor product of module morphisms, due to some existing "optimizations" like automatic flattening of nested tensors and this tensor-unit business, in order to create reasonably efficient tensor product maps, I feel it is necessary and hightly convenient to manufacture, on the fly, a pure "orphan" function as an "on_basis" function to feed to module_morphism. There is no natural "home" for such functions, which are somewhat complicated and are created each time someone wants to tensor some morphisms. It makes no sense for these functions to be lexically tethered somewhere, which is what the pickling seems to require. --Mark -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-combinat-devel] how to cure TestSuite failures involving Homs
Nicolas, There needs to be some serious thought about computability in Hom categories.. In what categories can one automatically compute the inverse of an invertible map, tell whether a morphism is zero, optimize composition of morphisms, etc. The TestSuites should be smart enough to automatically reflect this. I am coming around to the viewpoint that one should almost never need to use "orphan" functions. (Yet I have been using a lot of them for doctests in new smash product code, where the required actions are not necessarily already incorporated into existing objects). For identity morphisms, one can define a single global "_the_id" identity pure function and have everyone's identity morphism wrap it by calling SetMorphism. It passes pickling, is as cheap as possible, and provides identity morphisms, which, for categorical and other reasons, are needed. But the right solution is to do the same thing but "officially" by strengthening the Hom code to supply identity morphisms and their properties. Implementation of categories should be enhanced to have special objects such as identity objects. So when you get around to messing with Homs, please add identity morphisms as category-flavored wrappers around a single little pure identity function, and the knowledge to the Hom code that the identity morphism composes trivially. --Mark -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [sage-combinat-devel] how to cure TestSuite failures involving Homs
Hi Nicolas!
> > sage: f._test_pickling()
> > Traceback (most recent call last):
> > ...
> > PicklingError: Can't pickle : attribute lookup
> > __builtin__.function failed
>
> For this one, you can fake ``on_basis'' to be picklable using:
>
> sage: import __main__; __main__.on_basis = on_basis
I have been needing to define lots of morphisms using pure functions.
Here's a simple example: try to give every free module an identity morphism
in a way that passes pickling.
{{{
class ModulesWithBasis(Category_over_base_ring):
...
class ParentMethods:
...
def _identity_map(self):
def the_id(x):
return x
import __main__; __main__.the_id = the_id
return SetMorphism(Hom(self,self,self.category()),the_id)
}}}
This isn't going to work if the method is called multiple times
because the global reference will get overwritten.
Solutions?
--Mark
--
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 sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] how to cure TestSuite failures involving Homs
Is there an easy way to get rid of the following TestSuite failures? Or does it require an overhaul of how sage handles morphisms? I understand why the first two tests fail. --Mark sage: F=CombinatorialFreeModule(ZZ,[1]) sage: def on_basis(x): ... return x sage: f = F.module_morphism(on_basis=on_basis, codomain=F, category=ModulesWithBasis(ZZ)) sage: f._test_category() Traceback (most recent call last): ... AssertionError: False is not true sage: f._test_nonzero_equal() Traceback (most recent call last): ... NotImplementedError sage: f._test_pickling() Traceback (most recent call last): ... PicklingError: Can't pickle : attribute lookup __builtin__.function failed -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions
Paul, > Instead, I would advocate using a declarative domain specific language built > for semi-formalizing > mathematics The appeal of this paradigm is evident. It addresses a fundamentally important issue: how to structure the development process to encourage the code to reflect the mathematics in the most transparent fashion. Alas, it appears that this is a fair distance from being implemented in python, and many important details need to be worked out. If there was a prototype version with a demonstration-in-principle then it would be the right time to debate this approach. In the meantime, we all need a version of sage to work with... --Mark -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] problem building 5.2 from source
Tried to build version 5.2 from source. The make failed. Computer: Fujitsu Lifebook T900 Operating System: uname -a returns 3.5.0-2.fc17.x86_64 #1 SMP Mon Jul 30 14:48:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux (part of the error log follows) Installed /home/mshimo/sage-5.2/local/lib/python2.7/site-packages/dulwich-0.8.5- py2.7-linux-x86_64.egg Processing dependencies for dulwich==0.8.5 Finished processing dependencies for dulwich==0.8.5 Processing hg-git-0.3.2.tar.gz Running hg-git-0.3.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install-SVJXI1/h g-git-0.3.2/egg-dist-tmp-_JURwz zip_safe flag not set; analyzing archive contents... Adding hg-git 0.3.2 to easy-install.pth file Installed /home/mshimo/sage-5.2/local/lib/python2.7/site-packages/hg_git-0.3.2-p y2.7.egg Processing dependencies for hg-git==0.3.2 Finished processing dependencies for hg-git==0.3.2 Processing pyOpenSSL-0.12.tar.gz Running pyOpenSSL-0.12/setup.py -q bdist_egg --dist-dir /tmp/easy_install-FJAmUJ /pyOpenSSL-0.12/egg-dist-tmp-jj2aEg warning: no files found matching 'COPYING' warning: no previously-included files matching '*.pyc' found anywhere in distrib ution In file included from /home/mshimo/sage-5.2/local/include/python2.7/Python.h:8:0 , from OpenSSL/crypto/crypto.c:14: /home/mshimo/sage-5.2/local/include/python2.7/pyconfig.h:1183:0: warning: "_XOPE N_SOURCE" redefined [enabled by default] :0:0: note: this is the location of the previous definition In file included from OpenSSL/crypto/crypto.h:17:0, from OpenSSL/crypto/crypto.c:16: OpenSSL/crypto/x509.h:17:25: fatal error: openssl/ssl.h: No such file or directo ry compilation terminated. error: Setup script exited with error: command 'gcc' failed with exit status 1 Error installing pyOpenSSL-0.12.tar.gz. real0m18.257s user0m13.784s sys 0m3.061s Error installing package sagenb-0.9.1 -- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: More bugs in Laurent polynomials?
Simon, Many thanks for your patient answers. > > However if all coercion maps involved are injective then > > can't I expect == to be preserved? > > Why do you think that all coercions are injective? The coercion from ZZ > to GF(2) is certainly not injective. I meant not that all coercions were injective, but that all the coercion maps involved in my situation were injective homomorphisms. I suppose it would be hard in general for the coercion mechanism to keep track of such details on the fly (remember whether all the maps used so far been injective). > > Since the coercion from S to FractionField(R) > > is injective, the pushout must necessarily be > > FractionField(R). > > Here is the problem: > > sage: S. = LaurentPolynomialRing(QQ) > sage: R = S.polynomial_ring() > sage: K = R.fraction_field() > sage: K.has_coerce_map_from(S) > False > > There are two possibilities: Either the "obvious" embedding of S into K > would create problems with the axioms above. Probably it is fine. > > Or it was forgotten to teach Sage that it is fine. > > Note that conversion from S to K is implemented: > sage: K(x) > x > sage: K(1/x) > 1/x > > So, the only problem is that Sage does not think (yet) that this > conversion qualifies as coercion. I am not sure how to fix it. The first > one might think of is the method K._coerce_map_from_: This is where > the existence of basic coercion maps is defined. However, K is a generic > fraction field - it would be very bad style to have tests for "Laurent > polynomial rings" in a very general method. Yeah, how can K generally know about some "random" subring like S? I understand that part. --Mark -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: More bugs in Laurent polynomials?
Thanks, Simon, for the explanation of coercions. > > I encountered some weird behavior in LaurentPolynomialRing, such as > > the nontransitivity of the '==' relation. > > Note that it is virtually impossible to have a transitive ==-relation > that at the same time provides certain mathematical features that are > wanted by most people. However if all coercion maps involved are injective then can't I expect == to be preserved? > > Also, factoring in the fraction field caused an error. > > It is implemented by factoring numerator and denominator, see below; > the problem is in factoring Laurent series. It fails in factoring the unit element of S. That is pretty strange to me. > > If R is the polynomial ring underlying S > > then there should be a canonical isomorphism installed between F and > > the fraction field K > > of R. > > There *is* a coercion from K to F, but of course not in the opposite > direction: Yeah, this unimpeachable coercion comes from the universal mapping property of fraction fields. > sage: S. = LaurentPolynomialRing(QQ) > sage: F = S.fraction_field() > sage: F > Fraction Field of Univariate Laurent Polynomial Ring in x over > Rational Field > sage: R = S.polynomial_ring() > sage: K = R.fraction_field() > sage: F.has_coerce_map_from(K) > True > Note that there is a coercion from S to F which is injective > and also Sage can not find the pushout: > sage: pushout(S, FractionField(R)) > Traceback (most recent call last): > ... > CoercionException: ... Since the coercion from S to FractionField(R) is injective, the pushout must necessarily be FractionField(R). On the other hand, FractionField(R) does not know about membership in the subring S. > > sage: (1/S.gen(0)).factor() > > Traceback (most recent call last) > > ... > > AttributeError: 'sage.rings.integer.Integer' object has no attribute > > 'dict' s = 1/S.gen(0) sn = s.numerator() sn.factor() > The last line will show you the source code, and you will see that it > is attempted to factor numerator and denominator. As it turns out, the > problem lies in the factorisation of Laurent series. The problem occurs when the Laurent polynomial ring unit element is factored! --Mark -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] More bugs in Laurent polynomials?
Bug report: I encountered some weird behavior in LaurentPolynomialRing, such as the nontransitivity of the '==' relation. Also, factoring in the fraction field caused an error. See below. Feature request: I would like elements of the fraction field F of a Laurent polynomial ring S (say with base ring a field) to be able to tell if they are actually in S. If R is the polynomial ring underlying S then there should be a canonical isomorphism installed between F and the fraction field K of R. Since elements of K know when they are in R, an element of L can tell if it is in S by mapping itself to K and checking whether its denominator is a monomial. More generally, if S is any integral domain with fraction field F, I would like to have the option of equipping the pair (S,F) with methods that can detect whether an element of F is in S, and the ability to compute the quotient of elements of S and return an element of S if the answer is indeed in S and not just F. - Sage Version 5.0.beta7, Release Date: 2012-03-05 Current Mercurial branch is: combinat sage: S = LaurentPolynomialRing(QQ,['x']) sage: F = S.fraction_field() sage: R = S.polynomial_ring() sage: K = R.fraction_field() sage: F == K False sage: R.gen(0) == S.gen(0) True sage: 1/R.gen(0) == 1/S.gen(0) True sage: 1/S.gen(0) == (S.gen(0))^(-1) True sage: 1/R.gen(0) == (S.gen(0))^(-1) False # What!?? sage: R.gen(0)^(-1) in S False sage: S.gen(0)^(-1) in S True sage: 1/S.gen(0) in S False sage: (1/R.gen(0)).factor() x^(-1) sage: (1/S.gen(0)).factor() Traceback (most recent call last) ... AttributeError: 'sage.rings.integer.Integer' object has no attribute 'dict' -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] creating custom subclasses of polynomial rings
Suppose I want to create a custom subclass of a polynomial ring. >From which class should it inherit? It should not care so much about the eventual base ring. I'm a sage development newbie. Where can I read about the class hierarchy for sage polynomials? I'm a little confused at the organizational principle behind the following output. sage: R = PolynomialRing(QQ,['x']) sage: R.__class__ sage: R.an_element().__class__ sage: S = PolynomialRing(QQ,['x','y']) sage: S.__class__ sage: S.an_element().__class__ --Mark -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] consistent trouble building sage from source
Sorry to be spamming everyone. I have had very consistent trouble building sage from source: versions 4.8, 5.0beta7, and 5.0beta8 all failed to build in the same kind of way. I can build and run the prepackaged version of sage-4.8-linux-64bit-fedora_release_15_lovelock_-x86_64-Linux Any help with fixing the source install problems would be greatly appreciated. Here is the end of the installation log for sage-5.0beta8. It starts with a core dump, prints some complaints and then appears to hang. Then I get impatient and control-C it. The error file "error_Corei264SSE3.tgz" gets generated. Dunno how to attach it though (through this google-group interface). --Mark gcc -DL2SIZE=4194304 -I/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build/include -I/home/msshimo/sage-5.0.beta8/spkg/ build/atlas-3.8.4.p1/ATLAS-build/../src//include -I/home/msshimo/ sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ATLAS-build/../src//include/ contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux - DATL_ARCH_Corei2 -DATL_CPUMHZ=1199 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 - DATL_USE64BITS -DATL_GAS_x8664 -DATL_NCPU=4 -fomit-frame-pointer - mfpmath=sse -mavx -O2 -fno-schedule-insns2 -fPIC -m64 -o xL1 L1CacheSize.o time.o /home/msshimo/sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ATLAS-build/bin/ ATLrun.sh /home/msshimo/sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ATLAS- build/tune/sysinfo xL1 64 /home/msshimo/sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ATLAS-build/bin/ ATLrun.sh: line 4: 32318 Illegal instruction (core dumped) $atldir/ $* make[7]: *** [RunL1] Error 132 make[7]: Leaving directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build/tune/sysinfo' xsyssum: /home/msshimo/sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ATLAS- build/../src//tune/sysinfo/GetSysSum.c:47: GetL1CacheSize: Assertion `system(ln) == 0' failed. make[6]: *** [/home/msshimo/sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ ATLAS-build/include/atlas_ssysinfo.h] Aborted (core dumped) make[6]: Leaving directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build/tune/sysinfo' make[5]: *** [/home/msshimo/sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ ATLAS-build/include/atlas_ssysinfo.h] Error 2 make[5]: Leaving directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build/src/auxil' make[4]: *** [IStage1] Error 2 make[4]: Leaving directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build/bin' ERROR 437 DURING CACHESIZE SEARCH!!. CHECK INSTALL_LOG/Stage1.log FOR DETAILS. make[4]: Entering directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build/bin' cd /home/msshimo/sage-5.0.beta8/spkg/build/atlas-3.8.4.p1/ATLAS- build ; make -j1 error_report make[5]: Entering directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build' make -j1 -f Make.top error_report make[6]: Entering directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build' uname -a 2>&1 >> bin/INSTALL_LOG/ERROR.LOG gcc -v 2>&1 >> bin/INSTALL_LOG/ERROR.LOG Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.1/lto- wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/ bugzilla --enable-bootstrap --enable-shared --enable-threads=posix -- enable-checking=release --with-system-zlib --enable-__cxa_atexit -- disable-libunwind-exceptions --enable-gnu-unique-object --enable- linker-build-id --enable-languages=c,c++,objc,obj-c+ +,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk -- disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj- jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with- ppl --with-cloog --with-tune=generic --with-arch_32=i686 -- build=x86_64-redhat-linux Thread model: posix gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) gcc -V 2>&1 >> bin/INSTALL_LOG/ERROR.LOG gcc: error: unrecognized option ‘-V’ gcc: fatal error: no input files compilation terminated. make[6]: [error_report] Error 4 (ignored) gcc --version 2>&1 >> bin/INSTALL_LOG/ERROR.LOG tar cf error_Corei264SSE3.tar Make.inc bin/INSTALL_LOG/* gzip --best error_Corei264SSE3.tar mv error_Corei264SSE3.tar.gz error_Corei264SSE3.tgz make[6]: Leaving directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build' make[5]: Leaving directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build' make[4]: Leaving directory `/home/msshimo/sage-5.0.beta8/spkg/build/ atlas-3.8.4.p1/ATLAS-build/bin' Error report error_.tgz has been created in your top-level ATLAS directory. Be sure to include this file in any help request. cat: ../../CONFIG/error.txt: No such file or directory cat: ../../CONFIG/error.txt: No such file or directory IN STAGE 1 INSTALL: SYSTEM PROBE/AUX COMPILE make[3]: *** [build] Error 255
