Hi Georg, Thanks for your help. I'm aware of the issues that arise with floating-point numbers, I just thought it feels unnatural to throw in reals and get back rationals. This is like throwing away the information that something is inexact. Changing the way things are printed would address this on the surface (although, actually, lattices would not be restricted to RR^n). Again, I'm just thinking that you should get the same type of things out (e.g. by .an_element()) that you put in (the basis vectors).
Beyond that, I want to make sure FreeModule is meant to be used the way I'm thinking of – it seems that there is no real distinction between the scalar ring R and the vector space K^n of points in the module/lattice, which is crucial for lattices. Thanks, Jan On Tuesday, June 5, 2012 4:14:35 PM UTC+2, Georg S. Weber wrote: > > > > 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
