{"id":19183853,"url":"https://github.com/passagemath/lidia","last_synced_at":"2025-05-07T23:32:27.824Z","repository":{"id":21484754,"uuid":"24803554","full_name":"passagemath/LiDIA","owner":"passagemath","description":"LiDIA --- A library for computational number theory, developed 1994-2004 by Johannes Buchmann's group at TU Darmstadt, relicensed to GPL 2+ in 2006/2010. Not under active development. Minimal patches for using it within the LattE integrale project. ","archived":false,"fork":false,"pushed_at":"2019-08-01T00:51:12.000Z","size":22808,"stargazers_count":29,"open_issues_count":6,"forks_count":9,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-04-18T19:18:27.593Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/passagemath.png","metadata":{"files":{"readme":"README","changelog":"ChangeLog","contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-10-04T22:46:08.000Z","updated_at":"2025-03-24T14:30:55.000Z","dependencies_parsed_at":"2022-08-05T12:15:21.226Z","dependency_job_id":null,"html_url":"https://github.com/passagemath/LiDIA","commit_stats":null,"previous_names":["passagemath/lidia","mkoeppe/lidia"],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/passagemath%2FLiDIA","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/passagemath%2FLiDIA/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/passagemath%2FLiDIA/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/passagemath%2FLiDIA/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/passagemath","download_url":"https://codeload.github.com/passagemath/LiDIA/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249850093,"owners_count":21334423,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T11:02:11.454Z","updated_at":"2025-04-20T04:33:37.683Z","avatar_url":"https://github.com/passagemath.png","language":"C++","readme":"\n             LiDIA --- A library for computational number theory\n\nLiDIA was developed from 1994 to 2004 at TU Darmstadt. It is not under active development. \nThe authoritative repository for LiDIA used to reside at\n\n\thttp://www.informatik.tu-darmstadt.de/TI/LiDIA/ftp/LiDIA/\n\nThe present version, named 2.3.0+latte-patches-YYYY-MM-DD, \nis based on the last official release, 2.3.0, of the LiDIA library.\nIt has minimal patches for using LiDIA within the LattE integrale project\nwith newer compilers and other infrastructure.\nIt is maintained at https://github.com/mkoeppe/LiDIA\n\n\nLiDIA's build system has a mechanism to create two types of distribution archives:\nthe whole archive (LiDIA-2.3.0) or just packages (LiDIA-base-2.3.0,\nLiDIA-FF-2.3.0, LiDIA-LA-2.3.0, LiDIA-LT-2.3.0, LiDIA-NF-2.3.0,\nLiDIA-EC-2.3.0, LiDIA-ECO-2.3.0, and LiDIA-GEC-2.3.0).  All packages\nare provided in tar.gz format.  Everything unpacks into the directory\n./LiDIA-2.3.0. \n\nPackage dependencies:                                                   base\n * The FF (Finite Fields) package depends only on the base package.      |\n * The LA (Linear Algebra) package depends on the FF package.\t         FF\n * The LT (Lattice) package depends on the LA package.\t\t         |\n * The NF (Number Field) package depends on the LT package.\t         LA\n * The EC (Elliptic Curve) package depends on the LA package.\t        / \\\n * The ECO (Elliptic Curve Order) package depends on the EC package.   LT  EC\n * The GEC (Generate Elliptic Curves) package depends on both the NF   |   |\n   and the ECO package.\t\t\t\t\t\t       NF  ECO\n     \t\t\t\t\t\t\t\t        \\ /\n     \t\t\t\t\t\t\t\t         GEC\n     \nCHANGES\n\nSee the file NEWS for a list of major changes in the current release.\n\n\n\n\nC++ COMPILER REQUIREMENTS\n\nIn order to compile LiDIA, your C++ compiler MUST support some ISO C++\nfeatures.  These are:\n\n    - type bool\n    - inlining\n    - mutable class members\n    - explicit constructors\n    - C++ style casts (i.e. static_cast\u003c...\u003e and const_cast\u003c...\u003e)\n    - explicit template instantiation by ISO C++\n    - template specialization by ISO C++ (template \u003c\u003e)\n    - ISO C++ headers, such as \u003ciostream\u003e, \u003cfstream\u003e, \u003cstring\u003e, but also\n      \u003ccstdlib\u003e, \u003ccstdio\u003e, etc. \n\nMoreover, LiDIA makes use of some basic classes from the C++ standard\nlibrary, such as fstream, string.\n\nIf your compiler fails to support one of the above items, you should\nupgrade.  Sorry for the inconvenience, but that's what a standard is for.\n\nHowever, LiDIA still doesn't make use of exceptions and run-time type\ninformation if you don't want it to.\n\nAs of release 2.1pre6, only g++ has been tested.  The g++ versions 3.x and 4.x\ncompile LiDIA successfully, whereas g++ 2.95.3 and 2.96 are\nknown to fail when compiling LiDIA.  Note that this is not LiDIA's fault...\n\n\n\n\nDISK SPACE AND MAIN MEMORY REQUIREMENTS\n\nLiDIA is a quite large system which requires a remarkable amount of\nresources.  The full LiDIA distribution occupies about 70MByte when\nunpacked. Configuring and building all packages typically takes about 135MByte\ndisk space on an i386-linux-gnu platform with ELF object file format, plus\nabout 25MByte for temporaries.  Installing all packages can take additional\n90MByte. These amounts depend very much on the platform and on the configuration\noptions. You can easily consume more than 1.8GByte if you configure LiDIA with\n  configure --disable-shared CXXFLAGS='-O0 -g2'\nand run\n  make check\nOn the other hand, you can reduce the disk space requirements significantly by\nusing appropriate configuration options if you do not need all the features\nof the full LiDIA distribution and if you build only those test programs you\nare interested in.\n\nWith older versions of g++, 64MByte of RAM used to be sufficient for building\nLiDIA. Since recent g++ version have a much more heavy memory footprint, we\nrecommend you have at least 512MByte free RAM. This recommendation also\napplies to building LiDIA applications, particularly when\ninstantiating some of LiDIA's template classes.\n\n\n\nINSTALLATION (Unix-like systems, using configure)\n\nIf you used `git clone` to obtain the source code of LiDIA,\nyou will first have to generate the build scripts using:\n\n    ./bootstrap\n\nThen proceed using `./configure' to configure LiDIA, see the file INSTALL for\ncompilation and generic installation instructions.\n\nLiDIA-specific configure options:\n\n    --enable-inline\n\tIf set to `yes', the multi-precision arithmetic routines from the\n\tunderlying kernel are inlined, otherwise separate function calls are\n\tgenerated.  The default is `yes'.\n\n    --enable-exceptions\n        If set to `yes', then LiDIA is built with support for\n        exceptions and errors are reported by exceptions. \n        If set to `no', then LiDIA is built without support for\n        exceptions. (g++ compiler switch `-fno-exceptions'.) \n        Consult the description of class LiDIA::BasicError in the\n        LiDIA manual for details.\n        The default is `yes'.\n\n    --enable-namespaces\n\tIf set to `yes', then all of LiDIA's symbols will be defined in the\n\tname space LiDIA (your C++ compiler must support name spaces).  The\n\tdefault is `yes'.\n\n    --enable-assert\n\tIf set to `yes', the assert macros will be activated by not defining\n\t`NDEBUG'.  The default is `no'.\n\n    --enable-ff\n\tIf set to `yes', the finite-fields package will be built.  The\n\tdefault is `yes'.\n\n    --enable-la\n\tIf set to `yes', the linear-algebra package will be built.  Since\n\tthis package depends on the finite-fields package, the\n\tlinear-algebra package will be built only if the finite-fields\n\tpackage is built.  The default is `yes'.\n\n    --enable-lt\n\tIf set to `yes', the lattice package will be built.  Since this\n\tpackage depends on the linear-algebra package, the lattice package\n\twill be built only if the linear-algebra package is built.  The\n\tdefault is `yes'.\n\n    --enable-nf\n\tIf set to `yes', the number-fields package will be built.  Since\n\tthis package depends on the lattice package, the number-fields\n\tpackage will be built only if the lattice package is built.  The\n\tdefault is `yes'.\n\n    --enable-ec\n\tIf set to `yes', the elliptic-curves package will be built.  Since\n\tthis package depends on the lattice package, the elliptic-curves\n\tpackage will be built only if the lattice package is built.  The\n\tdefault is `yes'.\n\n    --enable-eco\n\tIf set to `yes', the elliptic-curve-order package will be built.\n\tSince this package depends on the elliptic-curves package, the\n\telliptic-curve-order package will be built only if the\n\telliptic-curves package is built.  The default is `yes'.\n\n    --enable-gec\n\tIf set to `yes', the elliptic curve generation package will be\n\tbuilt.  Since this package depends on the elliptic curve order\n\tpackage, the elliptic curve generation package will be built only\n\tif the elliptic curve order package is built.  The default is\n\t`yes'.\n\n    --with-arithmetic\n\tDetermines the multi-precision kernel for LiDIA.  Valid values are\n\t`gmp', `cln', `piologie', and `libI'.\n\n\tYOUR SYSTEM MUST PROVIDE THE LIBRARY OF YOUR CHOICE BEFORE\n\tCONFIGURING LiDIA!\n\n\tNote for Piologie users on Unix-like systems: For some reason the\n\tPiologie library is created as `piologie.a' instead of\n\t`libpiologie.a'.  Rename `piologie.a' to `libpiologie.a', or create\n\ta link, otherwise the configure script will not find the Piologie\n\tlibrary.\n\n    --with-extra-includes\n\tIf the headers of the multi-precision library reside in a directory\n\tthat is not searched by your C++ compiler, then add the path with\n\tthis option.\n\n    --with-extra-libs\n\tIf the multi-precision library resides in a directory that is not\n\tsearched by your linker, then add the path with this option.\n\nLiDIA's build procedure uses GNU Libtool, which adds the following \noptions to \"configure\":\n\n    --enable-shared\n    --enable-static\n\tThese options determine whether shared and/or static library\n\tversions will be built.  Only the latter option defaults to `yes'.\n\n    --with-pic\n    --without-pic\n\tNormally, shared libraries use position-independent code, and\n\tstatic libraries use direct jump instructions which need to be\n\tedited by the linker.  The --with-pic option enforces\n\tposition-independent code even for static libraries, whereas\n\t--without-pic does not demand position-independent code even when\n\tbuilding shared libraries.  Using one of these options can halven\n\tcompilation time and reduce disk space usage because they save\n\tthe source files from being compiled twice.  Note that only\n\tposition-independent code can be shared in main memory among\n\tapplications; using position-dependent code for dynamically linked\n\tlibraries just defers the linking step to program load time and\n\tthen requires private memory for the relocated library code.\n\n    --enable-fast-install\n\tLiDIA comes with some example applications, which you may want to\n\trun in the build tree without having installed the shared library.\n\tTo make this work, Libtool creates wrapper scripts for the actual\n\tbinaries.  With --enable-fast-install=yes, the (hidden) binaries\n\tare prepared for installation and must be run from the (visible)\n\twrapper scripts until the shared library is installed.  With\n\t--enable-fast-install=no, the binaries are linked with the\n\tuninstalled library, thus necessitating a relinking step when\n\tinstalling them.  As long as you do not run the hidden binaries\n\tdirectly and use the provided make targets for installing, you need\n\tnot care about these details.  However, note that installing the\n\texample applications without having installed the shared library in\n\tthe configured libdir will work only with the setting\n\t--enable-fast-install=yes, which is the default.  This can be\n\timportant when preparing binary installation images.\n\n\nCOMPILER FLAGS\n\nYou can provide any desired compiler flag by setting the variable CXXFLAGS\nin the environment or in the command line passed to `configure'.  For\nexample, type\n\n\t./configure CXXFLAGS=\"\u003cyour desired flags\u003e\"\n\nThe configure script presets CFLAGS and CXXFLAGS with -O2, if these are\nempty or unset. \n\nIf you have problems to build LiDIA due to memory exhaustion, it will\nprobably help to limit inlining (some packages contain quite large inlined\nfunctions).  If you are using GCC, the appropriate option to limit inlining\nis -finline-limit-N (GCC-2.x) resp. -finline-limit=N (GCC-3.x), where N\nshould be chosen to be between 300 and 1000 (GCC's default is 10000).  This\nwill also result in faster compilation times and smaller object files for\nsome source files.\n\nLikewise, the GNU g++ compiler flags -Wreturn-type might drastically\nincrease memory consumption (see the GCC FAQ, e.g. http://gcc.gnu.org/faq/).\nNote that -Wall implies -Wreturn-type.\n\n\nEXTENDED FEATURES\n\nLiDIA's Makefile suite provides all targets proposed in the GNU Makefile\nstandards, including `install-exec', `install-data', and `uninstall'.\nFurthermore, VPATH builds and staged installs (using DESTDIR) are supported.\n\n\nBUILDING AND INSTALLING THE EXAMPLES\n\nTo build the examples, type\n\n\tmake examples\n\nand to install the examples type\n\n\tmake install-examples\n\n\nBUILDING THE DOCUMENTATION\n\nTo run the documentation through LaTeX2e and produce the DVI file\ndoc/LiDIA.dvi, type\n\n\tmake dvi\n\nNote: As of release 2.1pre6, this also requires the \"texi2dvi\" script,\nwhich comes with the GNU texinfo tools, to be available on your system.\n\nYou can additionally convert the DVI file into Postscript, yielding\ndoc/LiDIA.ps, by running\n\n\tmake ps\n\nand generate compressed versions doc/LiDIA.ps.{gz,bz2} using\n\n\tmake psgz\n\tmake psbz2\n\nIf you have pdflatex, you can as well build doc/LiDIA.pdf.  Just type\n\n\tmake pdf\nor\n\tmake dsc\n\nThe latter produces doc/LiDIA.dsc in addition to doc/LiDIA.pdf.  The dsc\nfile is a Postscript wrapper providing access to LiDIA.pdf for PS tools\nlike psselect, Ghostview, and others.  Making the dsc file requires the\n\"pdf2dsc\" utility which comes with Ghostscript 6.x.  Note that the\ncombination of pdf+dsc is as compact as a compressed PS file.  However, you\nwill probably not be able to print doc/LiDIA.dsc because that file uses\npointers into LiDIA.pdf which will be dangling when copied into a spool\ndirectory.  For printing, better make doc/LiDIA.ps.\n\n\nBUILDING THE MANUAL\n\nYou can build the manual with \"make doc\" once the package is configured. Note\nthat you need a (PDF-)LaTeX installation for this to work.\n\nIf you do not have the EC and EM Type 1 fonts installed, then edit\ndoc/LiDIA.tex and uncomment the line that instructs LaTeX to use the package\nae.  Using package \"ae\" will produce better-looking postscript output for\non-screen viewing.\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpassagemath%2Flidia","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpassagemath%2Flidia","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpassagemath%2Flidia/lists"}