On Tuesday, 5 June 2012 10:01:08 UTC+2, Jan Pöschko wrote: > > Hi everyone, > > I am working on the Summer of Code Lattices > project<http://gsoc-sage-lattices.blogspot.com>and ran into a problem when > trying to subclass > Lattice from FreeModule_submodule_with_basis_pid. If I'm getting it > right, the coefficient ring *R* is to be specified as parameter ambient(in > the form R^n), followed by the basis vectors in K^n. Now I don't > understand why the basis is coerced to the fraction field of R (if not R > itself), e.g. > > sage: from sage.modules.free_module import > FreeModule_submodule_with_basis_pid as FMs > sage: FMs(ZZ^2, [(0.5,0.25), (1.0,0)]) > Free module of degree 2 and rank 2 over Integer Ring > User basis matrix: > [1/2 1/4] > [ 1 0] > > I would like to allow creating lattices of points in RR^n (the real vector > space) with integer coefficients (ZZ), which is probably the most common > form of point lattices. As lattices really *are* free modules, it would > be good to inherit from them, but with the basis being kept in RR^n if > given therein. > > I tried a workaround by disabling checking and echelonization of the basis > (see the details of my > approach<http://gsoc-sage-lattices.blogspot.co.at/2012/06/preventing-freemodule-from-coercing-to.html>), > > but this doesn't work actually. > > Is there a reason why FreeModule is restricted in this way? Should it be > patched? Or should lattices subclass from something else? > > Thanks, > Jan >
Hi Jan, citing from yout blog entry: >>> we want to keep the original vector space, e.g. keep calculating with floating point numbers in RR. Why would one want to *calculate* with floating point numbers (which are inexact by nature), in cases where you actually are able to calculate with exact values (like in your example, or e.g. in a cyclotomic field)? Having to deal with inexact numbers (resp. inexact internal representations) has a lot of disadvantages, from rounding errors (and their progression during calculations), up to very basic questions becoming undecidable, like whether two given elements are linearly dependent, whether a given element is the "zero" vector, what's the rank of a matrix, and so on. So Sage tries hard to fall back to deal with exact values only, if it can, and has good reasons to do so (we do want exact answers, if at all possible!). On the other hand, to me, your problem seems to be one of perspective. Maybe you really only want to have printed the following? " User basis matrix: [0.5 0.25] [ 1 0] " Then all you need to do in your derived class is to alter the printing method (i.e. not using the inherited one, but make up a new one of your own) --- in there, just before printing, change the base_ring of the matrices (and vectors) to be printed to RR, and you should get what you want to see. You might also change the (printing of the) description of your class and the respective elements to something about "We assume all elements to lie in RR^n, for some n." (But note that due to the inexactness of general "reals", Sage has several (inexact) implementations which are suited to different purposes, e.g. RDF, python floats, the so-called "symbolic" ring --- some of which might be used internally for LLL-algorithm implementations, and such.) Hope that helps! Cheers, Georg -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
