From vmueller at ukdw.ac.id Mon Sep 3 04:51:33 2001 From: vmueller at ukdw.ac.id (Volker Mueller) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Bug in bigmod Message-ID: Hello all, I found a nice (but disturbing) bug in bigmod, more precisely in src/base/include/LiDIA/bigmod.h. The unary minus is encoded as operator - (const bigmod & a) { bigmod c; <====== c.negate(); return c; } such that the result is ALWAYS 0 !! You should change "bigmod c" to "bigmod c(a)" and recompile, if you're using bigmod. For developers: The bug fix is already commited to the repository. Cheers, Volker From enge at lix.polytechnique.fr Tue Sep 4 14:51:21 2001 From: enge at lix.polytechnique.fr (Andreas Enge) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Bug in int::jacobi In-Reply-To: Message-ID: Hi, before filing another bug report, let me say that I am quite satisfied with the pre5 of LiDIA 2.1, which compiles without problem on my Linux computer. Also, I have been using it for some time now and did not notice any errors with my programme in its present form. Today, however, I tried to compute Jacobi symbols on ints, precisely several values of (13 / .), and I obtain erroneous results. I suppose that this has again to do with the sign of "a % b", as already observed for gcds, since the results are correct when I cast the second parameter to bigint. While for gcds, the final sign does not matter (except that it makes checking for coprime values more awkward), this is not quite true for Jacobi symbols... With best regards, Andreas _______________________________________________________________________________ Andreas Enge Laboratoire d'Informatique (LIX) Ecole Polytechnique 91128 Palaiseau CEDEX France Phone: +33 1 69 33 34 79 Fax: +33 1 69 33 30 14 E-mail: enge@lix.polytechnique.fr URL: http://www.math.uni-augsburg.de/~enge From tier at monet.fh-friedberg.de Thu Sep 6 11:27:52 2001 From: tier at monet.fh-friedberg.de (Joerg Reinhardt) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Qt 2.3.0 & LiDIA Message-ID: <001801c136b6$33a650d0$2e0c8c92@pc808> Hello, has someone experience using LiDIA with Qt v.2.3.0 on Windows operating systems? I'm getting the following error message: c:\program files\microsoft visual studio\vc98\include\ios.h(146) : error C2872: 'streambuf' : ambiguous symbol c:\program files\microsoft visual studio\vc98\include\ios.h(159) : error C2872: 'ostream' : ambiguous symbol c:\program files\microsoft visual studio\vc98\include\ios.h(159) : error C2872: 'ostream' : ambiguous symbol This message doesn't appear with Qt v.2.0.1. I think this problem has its origin in the difference between the following files 'iostream' and 'iostream.h'. Has someone experienced the same problems? Has someone an idea what I can do about it? With best regards, Joerg From fatphil at altavista.com Thu Sep 6 13:20:20 2001 From: fatphil at altavista.com (Phil Carmody) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Qt 2.3.0 & LiDIA Message-ID: <20010906112020.11301.cpmta@c012.sfo.cp.net> From: "Joerg Reinhardt" > c:\program files\microsoft visual studio\vc98\include\ios.h(146) : error > C2872: 'streambuf' : ambiguous symbol > This message doesn't appear with Qt v.2.0.1. > I think this problem has its origin in the difference between the following > files 'iostream' and 'iostream.h'. Has someone experienced the same > problems? Has someone an idea what I can do about it? The difference between iostream and iostream.h should be only that of namespaces, in particular iostream puts everything in the 'std::' namespace. If you are including iostream, then you should be using ios, and if you are using the .h version, then you should be using both .h versions. If ios includes ios.h, and that's why the above says "ios.h", then the problem is deeper. Perhaps you can pull up an include dependency tree and see if two parts of the system rely on different header files. Phil Mathematics should not have to involve martyrdom; Support Eric Weisstein, see http://mathworld.wolfram.com Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com From a_bellezza at libero.it Sat Sep 15 15:12:26 2001 From: a_bellezza at libero.it (Antonio Bellezza) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Sparse bigint_matrix Message-ID: Hi. I am working on a program making heavy use of linear algebra over the integers. At some point, I need to handle a matrix of very large size with few non-zero entries. A call to the constructor bigint_matrix A (rows, columns) uses far too much memory. I saw that in LiDIA 2.0.1 there are a few files and classes relating to sparse matrices. Are sparse matrices handled transparently or do I need to call special methods or to work in classes different from bigint_matrix? Any help will be more than welcome. Thanks Antonio Bellezza From Stefan.Neis at t-online.de Sun Sep 16 19:00:00 2001 From: Stefan.Neis at t-online.de (Stefan.Neis@t-online.de) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Sparse bigint_matrix Message-ID: <15ifH2-2HfUCOC@fmrl00.sul.t-online.com> > I am working on a program making heavy use of linear algebra over the > integers. At some point, I need to handle a matrix of very large size with > few non-zero entries. A call to the constructor > bigint_matrix A (rows, columns) > uses far too much memory. I saw that in LiDIA 2.0.1 there are a few files > and classes relating to sparse matrices. Well, I'm currently mostly using some customized 1.x version of LiDIA, but I suppose the following is essentially valid for 2.x as well: By default, bigint_matrix assumes the matrix to be stored to be a dense matrix, so it uses way to much memory in your case. If you want to get a sparse matrix, you need to explicitly say so. This is done by code like matrix_flags bitfield; bitfield.set_storage_mode(sparse_representation); // depending on the precise form of you matrix, // mixed_representation might be worth a try as well. bigint_matrix A(rows, columns, bitfield); HTH, Stefan From enge at lix.polytechnique.fr Tue Sep 18 11:18:26 2001 From: enge at lix.polytechnique.fr (Andreas Enge) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Bug in decimal_length (bigint) In-Reply-To: Message-ID: Hi, I am not quite sure if this bug has been reported before, I vaguely remember some discussion concerning decimal_length, but did not find any reference in my mail folder after the LiDIA-2.1pre4 release. On large numbers, decimal_length returns the fixed negative value -2147483647 = - (2^31 - 1), as demonstrated by the attached code. In a need of freeing hard disk space I recently deleted the LiDIA source code, so I cannot provide a patch, but I assume the solution will be rather simple. Greetings, Andreas #include #include using namespace std; using namespace LiDIA; int main () { bigint tmp; string_to_bigint ("99929582166253054902511662749406244409669576555\ 801999427984607608740492890513142350584787653709487300854497751798\ 500202034215865275549411232426288856515559538943628274022210905084\ 458590666515867618790035787724399075322379494258614938795688937336\ 517376218245932463337440954257612460217604105453852438544633275964", tmp); cout << tmp << endl << decimal_length (tmp) << endl; } _______________________________________________________________________________ Andreas Enge Laboratoire d'Informatique (LIX) Ecole Polytechnique 91128 Palaiseau CEDEX France Phone: +33 1 69 33 34 79 Fax: +33 1 69 33 30 14 E-mail: enge@lix.polytechnique.fr URL: http://www.math.uni-augsburg.de/~enge From a_bellezza at libero.it Fri Sep 21 17:18:07 2001 From: a_bellezza at libero.it (Antonio Bellezza) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Sparse bigint_matrix In-Reply-To: <15ifH2-2HfUCOC@fmrl00.sul.t-online.com>; from Stefan.Neis@t-online.de on Sun, Sep 16, 2001 at 07:00:00PM +0000 References: <15ifH2-2HfUCOC@fmrl00.sul.t-online.com> Message-ID: <20010921171807.A1612@ulisse.beautylabs.it> On Sun, Sep 16, 2001 at 07:00:00PM +0000, Stefan.Neis@t-online.de wrote: > > > I am working on a program making heavy use of linear algebra over the > > integers. At some point, I need to handle a matrix of very large size with > > few non-zero entries. [...] > > Well, I'm currently mostly using some customized > 1.x version of LiDIA, but I suppose the following is > essentially valid for 2.x as well: > By default, bigint_matrix assumes the matrix to be stored to be > a dense matrix, so it uses way to much memory in your case. > If you want to get a sparse matrix, you need to explicitly > say so. This is done by code like [...] First of all, thanks a lot for the quick answer. I tried what you suggested and a simple wrapper class only redefining constructors does the trick. The problem is that some of the methods don't work any more. For instance, with mixed representation the number of rows and columns always turns out as 0 and lll segfaults on matrices in sparse form. Before trying to address these issues, have they been solved in later versions of LiDIA? I am using 2.0.1 on Linux. Best regards Antonio Bellezza From Stefan.Neis at t-online.de Fri Sep 21 18:22:23 2001 From: Stefan.Neis at t-online.de (Stefan.Neis@t-online.de) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Sparse bigint_matrix Message-ID: <15kT4M-0IEB0aC@fmrl05.sul.t-online.com> Addressed to: lidia@cdc.informatik.tu-darmstadt.de ptheobald@usd.de Antonio Bellezza wrote: > On Sun, Sep 16, 2001 at 07:00:00PM +0000, Stefan.Neis@t-online.de wrote: > > > > > I am working on a program making heavy use of linear algebra over the > > > integers. At some point, I need to handle a matrix of very large size with > > > few non-zero entries. > [...] > > > > Well, I'm currently mostly using some customized > > 1.x version of LiDIA, but I suppose the following is > > essentially valid for 2.x as well: > > By default, bigint_matrix assumes the matrix to be stored to be > > a dense matrix, so it uses way to much memory in your case. > > If you want to get a sparse matrix, you need to explicitly > > say so. This is done by code like > [...] > > First of all, thanks a lot for the quick answer. I tried what you > suggested and a simple wrapper class only redefining constructors does the > trick. The problem is that some of the methods don't work any more. For > instance, with mixed representation the number of rows and columns always > turns out as 0 That's strange - and new to me. But then, I never used this mixed representation myself. ;-) > and lll segfaults on matrices in sparse form. That's to be expected, LLL is hard-wired to using dense matrices, feeding it anything else simply won't work. But with LLL, the result will usually be a dense matrix anyway, even if the input is sparse, so I don't really see the point of trying to feed a sparse matrix to it. It will just cause more memory fragmentation as the memory needed is slightly increasing all the time, so you're supposedly consuming even less memory if you do already start with a dense matrix. > Before trying to address these issues, have they been solved in later > versions of LiDIA? I am using 2.0.1 on Linux. Probably not. 2.1 is essentially a release trying to accomodate all the changes that happened to C++ standard over the years ... Regards, Stefan From enge at lix.polytechnique.fr Mon Sep 24 10:57:02 2001 From: enge at lix.polytechnique.fr (Andreas Enge) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Eco il mondo In-Reply-To: <15kT4M-0IEB0aC@fmrl05.sul.t-online.com> Message-ID: Hi, I am having problems using the eco package. The following programme yields the error message error_handler::base_bigmod::normalize::The modulus is set to zero! This is quite weird since on the other hand, the documentation incites me to call the point counting functions with parameters of type gf_element. Thus, I have to transform the bigmods I am working with in my real code into gf_elements, just to find out that behind the scenes, things seem to be transformed back into bigmod without taking the gf_element type into account. Uncommenting the line setting the modulus results in a different error message: error_handler::base_elliptic_curve< T >::get_model() const::e == NULL This time, I am quite at a loss on what to do. Greetings, Andreas #include #include #include using namespace std; using namespace LiDIA; int main () { galois_field f (293); gf_element a (f), b (f); a.assign (179); b.assign (141); // bigmod::set_modulus (293); eco_prime e; e.set_curve (a, b); cout << e.compute_group_order () << endl; } _______________________________________________________________________________ Andreas Enge Laboratoire d'Informatique (LIX) Ecole Polytechnique 91128 Palaiseau CEDEX France Phone: +33 1 69 33 34 79 Fax: +33 1 69 33 30 14 E-mail: enge@lix.polytechnique.fr URL: http://www.math.uni-augsburg.de/~enge From lidiaadm at cdc.informatik.tu-darmstadt.de Tue Sep 25 11:37:33 2001 From: lidiaadm at cdc.informatik.tu-darmstadt.de (LiDIA - Administrator) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Re: LiDIA 2.1pre5 and RH Linux 7.1 In-Reply-To: <661826566.20010924211529@swsoft.mipt.ru> (message from Alexandr Kshevetsky on Mon, 24 Sep 2001 21:15:29 +0400) References: <661826566.20010924211529@swsoft.mipt.ru> Message-ID: <200109250937.LAA27760@cdc-ultra1.cdc.informatik.tu-darmstadt.de> Hi, I tried to install LiDIA-2.1-pre5 and there was a compilation error with the file SF_BIGINT.H. I used the next configuration: PII processor, RH Linux 7.1, gcc-2.96, gmp-3.1.1. Should I use another version of gcc [...]? yes. ====================================================== g++ output: ------------------------------------------------------ /LiDIA-2.1pre5/src/base/include/LiDIA/base/sf_bigint.h:232: Internal compiler error in pop_binding, at ../gcc/cp/decl.c:1215 well, this says everything ... besides this, gcc-2.96 was never meant to be a production release, the gcc staff hasn't left any doubts about that. I don't know why the idiots from RH included it. This means, move on to gcc-3.01 or gcc-3.02 (in a few days). -- LiDIA-Administrator mailto:lidiaadm@cdc.informatik.tu-darmstadt.de http://www.informatik.tu-darmstadt.de/TI/LiDIA unsolicited commercial e-mail is strictly not wanted! From vmueller at ukdw.ac.id Fri Sep 28 07:23:27 2001 From: vmueller at ukdw.ac.id (Volker Mueller) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Eco il mondo In-Reply-To: Message-ID: Hi Andreas, > I am having problems using the eco package. The following programme yields > the error message > error_handler::base_bigmod::normalize::The modulus is set to zero! > This is quite weird since on the other hand, the documentation incites me > to call the point counting functions with parameters of type gf_element. > Thus, I have to transform the bigmods I am working with in my real code > into gf_elements, just to find out that behind the scenes, things seem > to be transformed back into bigmod without taking the gf_element type into > account. You found two problems here: 1. The first one is a bug in eco_prime, that I have fixed now in the cvs version. When the modulus of bigmod is not yet set, then the program crashes (internally eco_prime still uses bigmods and not gf_elements, due to "historic reasons" and lack of free time). Now the modulus is set first if not yet defined. 2. On the other hand, if you set the bigmod-modulus manually with bigmod::set_modulus, then an "old bug" in eco_prime caused the program to crash. In my curretn version, everything is fine, no crash. Note that in the ec and ec_order code of LiDIA pre5 there are quite a few bugs since the latest version of the code was not yet checked into the repository when pre5 was released. Most of these bugs (at least all I know of) are now fixed, and the latest version of the code is submitted to the cvs. Safuat, we should think about releasing a new pre version with the new ec and eco code included. I think there are also a few other minor bug fixes. Cheers, Volker From enge at lix.polytechnique.fr Fri Sep 28 09:50:31 2001 From: enge at lix.polytechnique.fr (Andreas Enge) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Eco il mondo In-Reply-To: Message-ID: On Fri, 28 Sep 2001, Volker Mueller wrote: > You found two problems here: > > 1. The first one is a bug in eco_prime, that I have fixed now in the > cvs version. When the modulus of bigmod is not yet set, then the > program crashes (internally eco_prime still uses bigmods and not > gf_elements, due to "historic reasons" and lack of free time). Now the > modulus is set first if not yet defined. Does this mean that after calling the point counting functions, all other bigmods I have been using in my code are invalid, unless I reset the modulus? Would it not be a reasonable option to directly use parameters of type bigmod in the function calls? I find it somehow weird to create new field and gf_element objects to transform my bigmods if they are transformed back to bigmods only a few lines of code later on. Well, if you are planning to extend the code, it may be understandable. A completely different question concerning the documentation. I personally prefer the html version, but runnning latex2html on the current docs first takes very long, second does not work properly. So I am still using the documentation of the previous version. (Here is the relation to the eco package, since it is new and I had to browse through the new dvi.) Would it be an option to replace the current latex files by precompiled documentation in, say, html, dvi and ps or pdf format? After all, all these formats are system independent, so there is no real need to have them created by the user on each machine where LiDIA is installed. Cheers, Andreas _______________________________________________________________________________ Andreas Enge Laboratoire d'Informatique (LIX) Ecole Polytechnique 91128 Palaiseau CEDEX France Phone: +33 1 69 33 34 79 Fax: +33 1 69 33 30 14 E-mail: enge@lix.polytechnique.fr URL: http://www.math.uni-augsburg.de/~enge From John.Cremona at nottingham.ac.uk Fri Sep 28 13:36:05 2001 From: John.Cremona at nottingham.ac.uk (John Cremona) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Eco il mondo References: Message-ID: <3BB460A5.B33BE743@nottingham.ac.uk> I would support Andreas's suggestion about documentation: I find latex2html very problematic to use, but html documentation the easiest for reference. John -- Prof. J. E. Cremona | University of Nottingham | Tel.: +44-115-9514920 School of Mathematical Sciences | Fax: +44-115-9514951 University Park | Email: John.Cremona@nottingham.ac.uk Nottingham NG7 2RD, UK | From vmueller at ukdw.ac.id Sat Sep 29 04:46:11 2001 From: vmueller at ukdw.ac.id (Volker Mueller) Date: Tue Nov 13 09:18:49 2007 Subject: [LiDIA] Eco il mondo In-Reply-To: Message-ID: Hi, > Does this mean that after calling the point counting functions, all other > bigmods I have been using in my code are invalid, unless I reset the > modulus? Would it not be a reasonable option to directly use parameters > of type bigmod in the function calls? I find it somehow weird to create > new field and gf_element objects to transform my bigmods if they are > transformed back to bigmods only a few lines of code later on. Well, > if you are planning to extend the code, it may be understandable. Yes, unfortunately it's that weired at the moment. The idea of using gf_element was to "almost automatically" extend the code to finite fields of reasonable large characteristic. But then we found out that the polynomial classes for gf_element are not well suited for prime fields (since no fft ist used, not as in Fp_polynomial). Therefore at the moment we just transform gf_elements to bigmods. In a old version of eco_prime, we used bigmods in the interfaces, but the former LiDIA administrator disliked and changed it. I personally agree with you that a bigmod Interface would be cleaner, but it's like it is. And as far as I see, there are currently no "resources" in Darmstadt available to significantly rearrange the code. Cheers, Volker