source: git/ntl/doc/tour-roadmap.html @ 6ce030f

spielwiese
Last change on this file since 6ce030f was 2cfffe, checked in by Hans Schönemann <hannes@…>, 21 years ago
This commit was generated by cvs2svn to compensate for changes in r6316, which included commits to RCS files with non-trunk default branches. git-svn-id: file:///usr/local/Singular/svn/trunk@6317 2c84dea3-7e68-4137-9b89-c4e89433aadc
  • Property mode set to 100644
File size: 4.4 KB
Line 
1<html>
2<head>
3<title>
4A Tour of NTL: NTL past, present, and future  </title>
5</head>
6
7<body bgcolor="#fff9e6">
8<center>
9<a href="tour-time.html"><img src="arrow1.gif" alt="[Previous]" align=bottom></a>
10 <a href="tour.html"><img src="arrow2.gif" alt="[Up]" align=bottom></a> 
11<a href="tour-changes.html"> <img src="arrow3.gif" alt="[Next]" align=bottom></a>
12</center>
13
14<h1> 
15<p align=center>
16A Tour of NTL: NTL past, present, and future
17</p>
18</h1>
19
20<p> <hr> <p>
21
22<h3>
23Some History
24</h3>
25
26<p>
27
28Work on NTL started around 1990, when I wanted to implement some new
29algorithms for factoring polynomials over finite fields.
30I found that none of the available software was adequate for
31this task, mainly because the code for polynomial arithmetic in
32the available software was too slow.
33So I wrote my own.
34My starting point was Arjen Lenstra's LIP package for long integer
35arithmetic, which was written in <tt>C</tt>.
36It soon became clear that using <tt>C++</tt> instead of <tt>C</tt>
37would be much more productive and less prone to errors,
38mainly because of <tt>C++</tt>'s constructors and destructors
39which allow memory management to be automated.
40Using <tt>C++</tt> has other benefits as well, like function
41and operator overloading, which makes for more readable code.
42
43<p>
44One of the basic design principles of LIP was portability.
45I adopted this principle for NTL as well, for a number of reasons,
46not the least of which was that my computing environment
47kept changing whenever I changed jobs.
48Achieving portability is getting easier as standards,
49like IEEE floating point, get widely adopted, and as the definition of
50and implementations of the
51<tt>C++</tt> language stabilize (which a few years ago was a huge headache,
52but is now only a big one, and in a few years will be a small one).
53
54
55<p>
56Since 1990, NTL has evolved in many ways,
57and it now provides a fairly polished and well-rounded programming interface.
58
59<p>
60When I started working on NTL, there really were not that many
61good, portable long integer packages around.
62Besides LIP, there was the BSD Unix MP library.
63The first version of GMP was released in the early 1990's.
64At that point in time, LIP seemed like the best starting point.
65LIP remains a reasonable long integer package, but in recent years,
66GMP has really become quite good:  it seems well supported on
67many platforms, and is typically much faster than LIP.
68
69<p>
70I've now re-structured NTL so that one can use
71either 'traditional' LIP or GMP as the <i>primary</i> long integer package.
72Doing this introduced some (minor) backward incompatabilies in
73the programming interface, so there is also a 'third way' -- you
74can use GMP as a <i>supplemental</i> long integer package, getting
75many (but not all) of the performance benefits of GMP, while
76maintaining <i>complete</i> backward compatability with the traditional
77long integer package.
78This 'third way' is not highly recommended -- it is only intended
79as backward compatabilty hack.
80
81<p>
82
83<h3>
84The Future of NTL
85</h3>
86
87<p>
88
89I hope that NTL remains stable in its current form.
90I plan to support NTL, fixing bugs and serious performance
91problems, but otherwise not to add significant new functionality or
92modify the programming interface.
93
94<p>
95I don't have time to add significant new functionality to NTL.
96However, there seems to be an ever-growing number of NTL users
97out there, and I encourage them to make their code available to
98others.
99These might be in the form of NTL "add ons", but there is the
100possibility of integrating new functionality or algorithmic improvements into NTL itself.
101One thing in particular  that would be nice is support for
102bivariate polynomial arithmetic, including GCDs, resultants,
103and factoring, and for integer and all the various finite field
104coefficient rings.
105Another nice thing would be code for elliptic curves,
106including an elliptic curve point counting algorithm.
107Another nice thing would be something for factoring integers.
108Any one of these projects would be a nice master's thesis project,
109I think.
110
111<p>
112As you can well imagine, there is potentially no end to algorithms one
113could implement.
114That is why I have to stop somewhere.
115I think NTL has reached a point where it provides a reasonably
116well-rounded suite of algorithms for basic problems.
117
118
119<p>
120
121<center>
122<a href="tour-time.html"><img src="arrow1.gif" alt="[Previous]" align=bottom></a>
123 <a href="tour.html"><img src="arrow2.gif" alt="[Up]" align=bottom></a> 
124<a href="tour-changes.html"> <img src="arrow3.gif" alt="[Next]" align=bottom></a>
125</center>
126
127</body>
128</html>
Note: See TracBrowser for help on using the repository browser.