-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathtour-changes.html
2489 lines (2003 loc) · 63.5 KB
/
tour-changes.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html>
<head>
<title>
A Tour of NTL: Summary of Changes </title>
</head>
<center>
<a href="tour-roadmap.html"><img src="arrow1.gif" alt="[Previous]" align=bottom></a>
<a href="tour.html"><img src="arrow2.gif" alt="[Up]" align=bottom></a>
<a href="tour-ack.html"> <img src="arrow3.gif" alt="[Next]" align=bottom></a>
</center>
<h1>
<p align=center>
A Tour of NTL: Summary of Changes
</p>
</h1>
<p><hr><p>
<h3>
2015.11.13: Changes between NTL 9.6.1 and 9.6.2
</h3>
<ul>
<li>
More small tweaks and a new configuration variable:
<pre>
NTL_MAXIMIZE_SP_NBITS=off
# Allows for 62-bit single-precision moduli on 64-bit platforms.
# By default, such moduli are restricted to 60 bits, which
# usually gives *slightly* better performance across a range of
# of parameters.
</pre>
</ul>
<p><hr><p>
<h3>
2015.11.13: Changes between NTL 9.6.0 and 9.6.1
</h3>
<ul>
<li>
Streamlined some awkard code in <tt>g_lip_impl.h</tt>.
<li>
Made <tt>QuickTest</tt> a bit quicker.
<li>
Fixed some documentation/packaging problems.
</ul>
<p><hr><p>
<h3>
2015.11.10: Changes between NTL 9.5.0 and 9.6.0
</h3>
<ul>
<li>
More performance tuning for <tt>ZZ_pX</tt> arithmetic.
<li>
Added configuration variable <tt>CXXAUTOFLAGS</tt>,
which is dynamically (and heuristically) set by the configuration
script.
This way, <tt>CXXFLAGS</tt> is not modified by the script.
</ul>
<p><hr><p>
<h3>
2015.10.20: Changes between NTL 9.4.0 and 9.5.0
</h3>
<ul>
<li>
Added a new <i>thread boosting</i> feature.
With this feature, certain code within NTL will use available
threads to speed up certain computations on a multicore
machine.
This feature is enabled by setting <tt>NTL_THREAD_BOOST=on</tt>
during configuration.
See <a href="BasicThreadPool.cpp.html">BasicThreadPool.txt</a>
for more information.
<p>
This feature is a work in progress.
Currently, basic <tt>ZZ_pX</tt> arithmetic has been thread boosted.
More code will be boosted later.
<li>
A bit more perfomance tuning for <tt>ZZ_pX</tt> arithmetic,
and better crossovers for <tt>ZZX</tt> multiplcation.
</ul>
<p><hr><p>
<h3>
2015.9.22: Changes between NTL 9.3.0 and 9.4.0
</h3>
<ul>
<li>
Performance tuning: <tt>ZZ_pX</tt> and <tt>zz_pX</tt> keep
getting faster
<li>
Upgrade to pseudo-random number generation:
I replaced the underlying PRG with Chacha20 (replacing RC4)
and the underlying key-derivation function with a function
based on HMAC-SHA256 (replacing an MD5-based function).
The new routines are faster and more secure.
<p>
I also expanded the PRG interface a bit:
<a href="ZZ.cpp.html#prg">see here</a> for details.
<li>
Bug fixes: fixed a (mostly dormant) bug in the <tt>ZZFromBytes</tt>
routine (triggered only when <tt>n==0</tt>).
<li>
Added documentation for classes <tt>RRPush</tt> and
<tt>RROutputPush</tt>:
<a href="RR.cpp.html#push">see here</a> for details.
</ul>
<p><hr><p>
<h3>
2015.7.9: Changes between NTL 9.2.0 and 9.3.0
</h3>
<ul>
<li>
Fixed a compilation error that arose with <tt>NTL_LEGACY_SP_MULMOD=on</tt>.
<li>
Added a new call back routine <tt>ErrorMsgCallback</tt>.
See <a href="tools.cpp.html">tools.txt</a>.
This is mainly to help with NTL integration withing SAGE.
</ul>
<p><hr><p>
<h3>
2015.5.23: Changes between NTL 9.1.1 and 9.2.0
</h3>
<ul>
<li>
Completed the transition away from floating-point arithmetic
for the implementation of single-precision modular arithmetic.
The current implementation should allow 60-bit moduli on
64-bit platforms that support a 128-bit extended integer
type (this is the case for current gcc, clang, and icc
compilers).
<p>
One can still revert to the "classical" (pre-9.0) implementation
using double-precision arithmetic (which imposes a 50-bit limit),
or to the "long double" implementation introduced in v9.0 (60-bit limit).
<p>
Note that one must compile NTL with GMP to get any of these improvements.
It would have perhaps been better to use GMP's <tt>longlong.h</tt>
facility instead of relying on compiler support for extended
integer types.
However, at the moment, it is a bit inconvenient to use <tt>longlong.h</tt>
as a freestanding header file.
This might change in the future.
<p>
For details, see <a href="ZZ.cpp.html#modarith">here</a>,
including the comments entitled "Compatibility notes".
<p>
<i>Programming notes:</i> <tt>MulMod(a, b, n)</tt> is equivalent to
<tt>mulmod_t ninv = PrepMulMod(n);</tt> <tt>MulMod(a, b, n, ninv)</tt>.
Compared to the older, floating-point implementation, the
relative cost of computing <tt>ninv</tt> is higher in the new regime.
In a loop where <tt>n</tt> is invariant, the compiler should
"hoist" the computation of <tt>ninv</tt>, so it is only done once.
However, it is usually better to precompute and store <tt>ninv</tt>,
and use the second form of <tt>MulMod</tt>, with <tt>ninv</tt> passed
as a parameter (NTL does this internally quite consistently).
The performance of <tt>MulMod(a, b, n, ninv)</tt> is somewhat faster
in the new implementation.
Where possible, one should use <tt>MulModPrecon</tt>, which is faster still
(useful in situations where both <tt>n</tt> and <tt>b</tt> are invariant).
<p>
<li>
A number of general performance improvements.
</ul>
<p><hr><p>
<h3>
2015.5.16:
Changes between NTL 9.1.0 and 9.1.1
</h3>
<ul>
<li>
Fixed a bug introduced in 9.1.0 that prevented conversions
between <tt>Vec<GF2></tt> and <tt>Vec<T></tt>.
</ul>
<p><hr><p>
<h3>
2015.5.2:
Changes between NTL 9.0.2 and 9.1.0
</h3>
<ul>
<li>
Added a new configuration switch to enable
the <tt>PCLMUL</tt> instruction on x86 machines.
This can speed up <tt>GF2X</tt> arithmetic significantly
(by a factor of 4).
This is enabled by configuring with <tt>NTL_PCLMUL=on</tt>
(and the configuration
script automatically checks if it actually works on your platform).
<p>
Note that this is an alternative to building NTL against the <tt>gf2x</tt>
library (the latter is currently not thread or exception safe).
<p>
<li>
Performance improvements to <tt>zz_pX</tt> and <tt>Vec<zz_p></tt>.
<p>
<li>
Performance improvements to <tt>ZZX</tt>:
implemented asymptotically fast CRT code
for <tt>HomMul</tt> and more cache-friendly logic.
This routine is used for polynomials whose degree is
significantly larger than the bit-length of its coefficients.
This should make NTL's <tt>ZZX</tt> multiplication faster
across a broader range of parameters,
and at least be within a (hopefully not-too-large) constant factor
of optimal.
<p>
<li>
Some internal cleaning on the small-prime FFT code.
I've made David Harvey's lazy butterfly routine without
precomputed tables more competitive with the large-table
variant,
so now that large tables
are used for a smaller range of parameters (this should reduce
the overall memory footprint).
<p>
<li>
Laid the groundwork for some future changes;
namely, to allow 60-bit
modular arithmetic without relying on the esoteric x87 fmul
instruction.
This should be coming soon (probably v9.2).
<p>
</ul>
<p><hr><p>
<h3>
2015.3.29:
Changes between NTL 9.0.1 and 9.0.2
</h3>
<ul>
<li>
Made a small change to single-precison <tt>MulMod</tt>
that enables slightly better compiler optimizations
(compiler can "hoist" the computation of <tt>1/n</tt>
out of a loop, so the variant with extra <tt>mulmod_t</tt>
arg becomes somewhat less essential).
</ul>
<p><hr><p>
<h3>
2015.3.27:
Changes between NTL 9.0.0 and 9.0.1
</h3>
<ul>
<li>
Fixed a small bug that prevented compilation a certain platforms.
</ul>
<p><hr><p>
<h3>
2015.3.27:
Changes between NTL 8.1.2 and 9.0.0
</h3>
<ul>
<li>
With much trepidation, I have introduced a (hopefully minor)
backward incompatibility into NTL.
The interface to the single-precision modular arithmetic
routines has been modified slightly.
This interface change allows for more flexible and more
efficient implementation of these routines,
which play a crucial role at many levels in NTL.
<p>
Basically, these changes to the interface abstract away
some implementation details that arguably should never been there
in the first place.
By coding to the new interface, NTL clients will be able to
benefit from
the current and future improvements.
<p>
In particular, on 64-bit x86/GCC platforms, single precision
moduli can now be up to <i>60 bits</i>, rather than <i>50 bits</i>.
While some operations may in fact be a little slower, the most important
ones (like <tt>MulModPrecon</tt>) should not be.
Using larger moduli speeds up a number of things, like <tt>ZZ_pX</tt>
arithmetic, as fewer primes need to be used in Chinese Remaindering steps.
Other applications benefit from larger moduli as well.
<p>
It is expected that most NTL clients will not be affected at all.
Moreover, any code that needs to be updated will be detected
by the compiler, and the updates should be simple and mechanical.
There is also a configuration flag that will enable the legacy
interface (although this is not recommended practice).
<p>
For details, <a href="ZZ.cpp.html#modarith">see here</a>,
including the comments entitled "Compatibility notes".
<p>
<li>
Other changes:
<ul>
<li>
Previous versions of NTL relied (at least by default) on some
<i>undefined behavior</i> regarding integer arithemtic
(namely, that in a few key code sequences, signed integer
overflow just "wraps around").
All of this undefined behavior has been replaced by
(much more desirable) <i>implementation-defined behavior</i>
(namely, that conversion from unsigned to signed works as expected).
As in the past, the <tt>NTL_CLEAN_INT</tt> can be used to
avoid all of these issues (but with the new code, this should
truly be academic).
For details, look <a href="tour-impl.html">here</a>.
<li>
By request, added a function <tt>xdouble exp(const xdouble& x)</tt>,
which is equivalent to <tt>xexp(to_double(x))</tt>.
For details, look <a href="xdouble.cpp.html">here</a>.
</ul>
</ul>
<p><hr><p>
<h3>
2015.1.31:
Changes between NTL 8.1.1 and 8.1.2
</h3>
<ul>
<li>
Corrected a bug that could affect the <tt>log</tt>
function in a multi-threaded execution.
</ul>
<p><hr><p>
<h3>
2015.1.30:
Changes between NTL 8.1 and 8.1.1
</h3>
<ul>
<li>
Corrected a syntax error in <tt>SmartPtr.h</tt>,
which most compilers don't seem to complain about, but some
do.
<p>
<li>
Added <tt>--tag=CXX</tt> to the some lines
in the <tt>makefile</tt> to keep <tt>libtool</tt> happy.
</ul>
<p><hr><p>
<h3>
2015.1.9:
Changes between NTL 8.0 and 8.1
</h3>
<ul>
<li>
Corrected an oversight in the matrix template class.
With this new version, one may safely copy and assign
objects of type <tt>Mat<ZZ_p></tt>
and <tt>Mat<GF2E></tt> out of context (i.e.,
under a different or undefined modulus).
More generally, the copy constructor for <tt>Mat<T></tt>
now relies only on the copy constructor for <tt>Vec<T></tt>
and the assignment operator for <tt>Mat<T></tt>
relies only on the assignment operator and copy constructor
for <tt>Vec<T></tt>.
<p>
The goal since v6.2 has been to allow all modular types (<tt>ZZ_p</tt>, etc.)
and all types derived from them (vectors, polynomials, matrices, etc.)
to be safely copy constructed and assigned out of context.
Hopefully, this goal has now been reached.
</ul>
<p><hr><p>
<h3>
2014.12.24:
Changes between NTL 7.0.2 and 8.0
</h3>
<ul>
<p><li> <b> Exceptions! </b>
<p> This is another major milestone for NTL, and hence the big
version number bump (this will be the last of these big bumps
for a while).
<p>
Prior to this version, error handling consisted of "abort with an error message".
To enable exceptions in NTL, configure with <tt>NTL_EXCEPTIONS=on</tt>.
You will also need a <tt>C++11</tt> compiler for this to work properly
(and if you don't enable exceptions, any old <tt>C++98</tt> compiler will
work, as always).
<p>
With exceptions enabled, errors are reported by throwing an appropriate
exception.
Of course, this was the easy part.
The hard part was making NTL's code <i>exception safe</i>,
which (among other things) means that no resources (i.e., memory)
are leaked when an exception is thrown.
This required a very painful top-to-bottom scrub of the whole library.
<p>
Despite major changes to the code base and many internal
interfaces, the external (i.e., documented) interfaces remain
completely unchanged.
<p>
More details are available <a href="tour-struct.html#except">here.</a>
<p><li>
Improved performance of <tt>ZZ_pX</tt> arithmetic for both classic
and GMP-based long integer packages.
<p><li>
Made copy constructor and assignment operators
for <tt>fftRep</tt> and <tt>FFTRep</tt> safe "out of context",
which extends to the classes <tt>zz_pXModulus</tt> and <tt>ZZ_pXModulus</tt>.
<p><li>
Made mechanism for establishing "unique ID's" (used for temporary
file name generation and default pseudo-random number seeds)
more robust.
</ul>
<p> <hr> <p>
<h3>
2014.12.15:
Changes between NTL 7.0.1 and 7.0.2
</h3>
<ul>
<p><li>
Fixed bug introduced in v7.0 affecting <tt>RR</tt> and <tt>quad_float</tt> input routines,
which would leave the <tt>RR</tt> precision variable in an incorrect state.
<p><li>
Fixed a bug introduced in the v6.2 that affected the append routines
for <tt>ZZ_p</tt> and <tt>GF2E</tt>, which would lead to incorrect memory allocation
(which, if triggered, should just have led to an error message and abort, rather than
incorrect results).
This bug also affected the new <tt>Vec</tt> constructor introduced in v7.0
(and again, only for <tt>ZZ_p</tt> and <tt>GF2E</tt>).
</ul>
<p> <hr> <p>
<h3>
2014.11.14:
Changes between NTL 7.0.0 and 7.0.1
</h3>
<ul>
<li>
Fixed critical bug in new bit-reverse-copy routine.
Large degree polynomial multiplication code was buggy
in v7.0.
Now it's fixed and properly tested.
</ul>
<p> <hr> <p>
<h3>
2014.11.8:
Changes between NTL 6.2.1 and 7.0
</h3>
<ul>
<p> <li> <b>Thread safety!</b>
<p>
This is a major milestone for NTL (and hence a bump in the
major version number).
However, to actually use it, you will need a "bleeding edge"
<tt>C++</tt> that supports <tt>C++11</tt> concurrency features.
Most importantly, the <tt>C++11</tt> storage class <tt>thread_local</tt>
needs to be fully and correctly implemented.
Some compilers claim to support it, but are very buggy to the point of
being useless.
All I can say is, as of right now, I have been able to
successfully build and test a multi-threaded NTL program
using GCC 4.9.2 on a Red Hat Linux distribution.
I don't think any pre-4.9.x version of GCC will work.
And unfortunatly, I don't think any compiler (GCC or CLANG)
on any current Mac will work, but I haven't been able to directly
test this.
<p>
As time goes on, I expect <tt>C++</tt> compilers will provide the
necessary support.
In the meantime, you can try it out and see if it works for you.
Configure with the <tt>NTL_THREADS</tt> flag turned on and see
what happens.
The test program <tt>ThreadTest</tt> that runs as the last step
of <tt>make check</tt> will let you know if it works.
If not, you can try building GCC 4.9.2 yourself.
It is actually not that hard!
<p>
See the <a href="tour-impl.html">portability and implementation section</a>
for more information.
In any case, if threads don't work for you, just don't use them.
Everything still works as before using almost any compiler.
<p><li>
I changed the stream input behavior to conform to wider
<tt>C++</tt> practice (and with an eye towards am exception safe future).
Previously, if an attempt to read an NTL object failed, the
good old <tt>Error</tt> function was called, printing an error message,
and aborting your program.
Now, NTL just quietly sets the ``fail bit'' of the stream.
The second example <a href="tour-ex1.html">here</a> illustrates this.
Hopefully, this change will not cause too many problems,
but if it does, configure NTL with the <tt>NTL_LEGACY_INPUT_ERROR</tt>
flag on to get the old behavior back.
<p><li>
To further simplify future development, I've dropped support
for legacy <tt>C++</tt> standard header files.
That is, NTL always uses <tt><iostream></tt>
rather than <tt><iostream.h></tt>.
This shouldn't be a problem for anyone by now, as these
lagacy header files have been gone from standard <tt>C++</tt>
since 1998.
Also, by default, NTL components are still wrapped in the <tt>NTL</tt>
namespace, but for backward compatibility, you can still put
them in the global namespace by configuring NTL
with the <tt>NTL_LEGACY_NO_NAMESPACE</tt> flag.
<p><li>
Implemented a cache-friendy "bit reverse copy" routine for doing
FFT's. This is the COBRA algorithm from Cater and Gatlin, "Towards an
optimal bit-reversal permutation algorithm", FOCS 1998.
This does seem to help a bit.
Getting rid of "bit reverse copy" would be even better,
but this would take more work and break a number of interfaces.
<p><li>
Made some minor improvements to <tt>ZZX</tt> multiplication routines
to get better locality of reference.
Improvement is nominal.
<p><li>
Fixed a small issue in the left-shift <tt>ZZ</tt> routine:
it was allocating one word more than necessary in some cases.
<p> <li>
Added new <tt>Vec</tt> constructor, so
<!-- STARTPLAIN
T a;
Vec<T> v(INIT_SIZE, n, a);
ENDPLAIN -->
<!-- STARTPRETTY {{{ -->
<p><p><table cellPadding=10px><tr><td><font color="#000000">
<font face="monospace">
T a;<br>
Vec<T> v(INIT_SIZE, n, a);<br>
</font>
</font></td></tr></table><p><p>
<!-- }}} ENDPRETTY -->
is equivalent to
<!-- STARTPLAIN
T a;
Vec<T> v;
v.SetLength(n, a);
ENDPLAIN -->
<!-- STARTPRETTY {{{ -->
<p><p><table cellPadding=10px><tr><td><font color="#000000">
<font face="monospace">
T a;<br>
Vec<T> v;<br>
v.SetLength(n, a);<br>
</font>
</font></td></tr></table><p><p>
<!-- }}} ENDPRETTY -->
In both cases, the copy constructor for <tt>T</tt>
is used.
<p><li>
I've added some more documentation about what I plan on
doing with NTL in the future, as well as a "wish list"
of what I hope others might contribute.
See the <a href="tour-roadmap.html">roadmap section</a> for
more details.
</ul>
<p> <hr> <p>
<h3>
2014.8.26: Changes between NTL 6.2 and 6.2.1
</h3>
<ul>
<li>
Fixed syntax problem in <tt>NTL/vector.h</tt>
</ul>
<p> <hr> <p>
<h3>
2014.8.21: Changes between NTL 6.1 and 6.2
</h3>
<ul>
<p>
<li>
I added <i>explicit</i> constructors corresponding to promotions.
For example:
<!-- STARTPLAIN
ZZ w = ZZ(1); // legal
ZZ w(1); // legal
ZZ w{1}; // legal in C++11
ZZ w = 1; // not legal
ENDPLAIN -->
<!-- STARTPRETTY {{{ -->
<p><p><table cellPadding=10px><tr><td><font color="#000000">
<font face="monospace">
ZZ w = ZZ(<font color="#ff8c00">1</font>); <font color="#0000ee"><i>// legal</i></font><br>
ZZ w(<font color="#ff8c00">1</font>); <font color="#0000ee"><i>// legal</i></font><br>
ZZ w{<font color="#ff8c00">1</font>}; <font color="#0000ee"><i>// legal in C++11</i></font><br>
ZZ w = <font color="#ff8c00">1</font>; <font color="#0000ee"><i>// not legal</i></font><br>
</font>
</font></td></tr></table><p><p>
<!-- }}} ENDPRETTY -->
<p>
Also added new names for the "monomial constructors", e.g.,
<tt>ZZX(INIT_MONO, i, c)</tt> is now preferred to <tt>ZZX(i, c)</tt>,
although the old constructors are still there.
There are also new constructors like <tt>ZZX(INIT_MONO, i)</tt>
for making monic monomials.
<p>
<li>
An subtle but important change is that now objects from
classes that represent residue class rings with a
dynamically installed modulus, i.e.,
<pre>
ZZ_p, zz_p, ZZ_pE, lzz_pE, GF2E,
</pre>
may now be used a bit more flexibly.
<p>
It is critical that such objects created under one modulus are not used in
any non-trivial way "out of context", i.e., under a different (or undefined)
modulus. However, for ease-of-use, some operations may be safely
performed out of context. These safe operations now include: the default and copy
constructor, the destructor, and the assignment operator. In addition it is
generally safe to read any object out of context (i.e., printing it out, or
fetching its underlying representive using the rep() function).
(In the past, it was generally unsafe to use the the default and copy constructors
out of context, which also prevented vectors and polynomials
of such objects from being copied out of context.)
<p>
The implementations of <tt>Vec<ZZ_p></tt> and <tt>Vec<GF2E></tt>
are still specialized to manage memory more
efficiently than in the default implementation of <tt>Vec<T></tt>.
Contiguous elements in such an array are allocated in a contiguous region of
memory. This reduces the number of calls to the memory allocator, and
leads to greater locality of reference.
A consequence of
this implementation is that any calls to <tt>SetLength</tt> on such a vector will
need to use information about the current modulus, and so such calls should
only be done "in context". That said, it is still safe to construct a
such a vector using the default or copy contructor, and to assign or append one
to another "out of context".
<p>
<li>
For the classes <tt>ZZ_p</tt>, <tt>ZZ_pE</tt>, <tt>zz_pE</tt>,
and <tt>GF2E</tt>, added explicit "allocation" and "no allocation" contructors
(invoked with <tt>INIT_ALLOC</tt> and <tt>INIT_NO_ALLOC</tt>) and special member function
<tt>allocate()</tt>. This allows one to explicitly determine exactly when
space for such objects is allocated.
By default, no space is allocated (this is different from prior versions of NTL),
except for <tt>ZZ_p</tt>'s that are a part of a <tt>Vec<ZZ_p></tt>
and <tt>GF2E</tt>'s that are a part of a <tt>Vec<GF2E></tt>
<p>
<li>
Added new classes <tt>ZZ_pPush</tt>, <tt>ZZ_pEPush</tt>,
<tt>zz_pPush</tt>, <tt>zz_pEPush</tt>, <tt>GF2EPush</tt>.
These allow one to conveniently backup and optionally install
a new modulus in one step:
<!-- STARTPLAIN
{ ZZ_pPush push(p); ... }
ENDPLAIN -->
<!-- STARTPRETTY {{{ -->
<p><p><table cellPadding=10px><tr><td><font color="#000000">
<font face="monospace">
{ ZZ_pPush push(p); ... }<br>
</font>
</font></td></tr></table><p><p>
<!-- }}} ENDPRETTY -->
will save the current modulus and install <tt>p</tt> as the
new modulus; when the destructor for <tt>push</tt> is invoked,
the old modulus will be re-installed.
<p>
<li>
Made the one-arg constructors for all the various "context" classes
(e.g., <tt>ZZ_pContext</tt>) <i>explicit</i>.
<p>
<li>
As a general aid to generic programming, I've added a
bunch of typedef's using consistent naming conventions
to all of the main arithmetic classes.
E.g., <tt>ZZ_p::poly_type</tt> is a typedef for <tt>ZZ_pX</tt>.
There are a whole bunch of these.
See the documentation for the individual classes for details.
<p>
<li>
Got rid of a few esoteric compilation modes:
<ul>
<li>
All files are now <tt>C++</tt> files, and should be compiled
using a <tt>C++</tt> compiler. In older versions, some files
could be compiled either as <tt>C</tt> or <tt>C++</tt>.
<li>
The flag <tt>NTL_GMP_HACK</tt> is no longer supported.
GMP may still be used using the <tt>NTL_GMP_LIP</tt> flag,
which is still highly recommended for high-performance applcations.
<li>
The flags <tt>NTL_SINGLE_MUL</tt> and <tt>NTL_FAST_INT_MUL</tt>
are no longer recognized.
These were really outdated and esoteric.
</ul>
<p>
<li>
I have started working towards making NTL thread safe.
It is not as difficult as I thought it would be, but it is still
a work in progress.
So far I have identified all global variables, and either got
rid of them, or tagged them as "thread local".
So, although there are still some global variables, they will
all eventually be "thread local".
In particular, things like the current <tt>ZZ_p</tt> modulus
will be a thread-local global variable.
<p>
There are a few remaining trouble spots I've tagged:
these mostly involve lazy initialization of tables;
I have a plan for making this code thread safe using
nearly lock-free coding techniques.
<p>
I will hopefully get this done within the next 6-12 months.
One thing that is slowing me down is the lack of availibility
of <tt>C++11</tt> features that I need to do some of this,
but it will come.
<p>
The main reason for getting rid of the esoteric compilation modes
mentioned above is to make it easier to do this thread-safety work.
</ul>
<p> <hr> <p>
<h3>
2014.03.13: Changes between NTL 6.0 and 6.1
</h3>
<ul>
<li>
Added support for "user defined" FFT primes for <tt>zz_p</tt>.
See the functions
<!-- STARTPLAIN
static void zz_p::UserFFTInit(long p);
zz_pContext::zz_pContext(INIT_USER_FFT_TYPE, long p);
ENDPLAIN -->
<!-- STARTPRETTY {{{ -->
<p><p><table cellPadding=10px><tr><td><font color="#000000">
<font face="monospace">
<font color="#008b00"><b>static</b></font> <font color="#008b00"><b>void</b></font> zz_p::UserFFTInit(<font color="#008b00"><b>long</b></font> p);<br>
zz_pContext::zz_pContext(INIT_USER_FFT_TYPE, <font color="#008b00"><b>long</b></font> p);<br>
</font>
</font></td></tr></table><p><p>
<!-- }}} ENDPRETTY -->
in the <tt>lzz_p</tt> module.
</ul>
<p> <hr> <p>
<h3>
2013.02.15: Changes between NTL 5.5.2 and 6.0
</h3>
<ul>
<li>
Replaced the old template-like macros for vectors, matrices,
and pairs with true template classes: <tt>Vec<T></tt>,
<tt>Mat<T></tt>, and <tt>Pair<S,T></tt>.
<p>
For backwards compatibilty, all the names that were used
in previous versions (e.g., <tt>vec_ZZ_p</tt>, <tt>mat_ZZ_p</tt>)
have been replaced with appropriate typedefs.
<p>
For many years, I resisted the temptation of using templates,
because compiler support was very inconsistent.
But that no longer seems to be the case.
<p>
This change, while rather sweeping, should create very few,
if any, incompatibilities with existing software.
The biggest issue would be for software that uses the
old template-like macros: such macro invocations can simply be
replaced with appropriate typedefs.
<p>
<li>
Made the conversion interface more complete and uniform.
Also, using template notation, one can and should now write
<tt>conv<ZZ>(a)</tt> instead of <tt>to_ZZ(a)</tt>
(for backward compatibility, all the old names <tt>to_XXX</tt>
are still there, but many new conversions are not available
under these old names).
<p>
There are many new conversions provided.
Moreover, whenever there is a conversion from a ring <i>R</i>
to a ring <i>S</i>, there is a corresponding, coefficiet-wise
conversion from the polynomial ring <i>R[X]</i> to the
polynomial ring <i>S[X]</i>.
<p>
In addition, using the template mechanism, there are
generic conversions for vectors and matrices.
For example, if there is a conversion from <tt>S</tt> to <tt>T</tt>,
then there is automatically a corresponding component-wise
conversion from <tt>Vec<S></tt> to <tt>Vec<T></tt>.
<p>
<li>
Introduced a more general mechanism for accessing <tt>GF2</tt>'s
in packed structures via indexing (see the class
<tt>ref_GF2</tt> in the <tt>GF2</tt> module).
<p>
<li>
Employed ideas from David Harvey to make the single-precision
FFT faster (about twice as fast in many cases).
This speeds up many higher-level operations.
See: Faster arithmetic for number-theoretic transforms.
<i>J. Symb. Comp. 60</i> (2014) 113-119.
<p>
<li>
Fixed all known bugs.
</ul>
<p> <hr> <p>
<h3>
2009.08.14: Changes between NTL 5.5.1 and 5.5.2
</h3>
<ul>
<li>
New routines <tt>MulAddTo</tt> and <tt>MulSubFrom</tt>
for computing <tt>x += a*b</tt> and <tt>x -= a*b</tt>,
where <tt>x</tt> and <tt>a</tt> are <tt>ZZ</tt>'s and
<tt>b</tt> is a <tt>ZZ</tt> or a <tt>long</tt>.
In the case where <tt>b</tt> is a <tt>long</tt>,
this may be much faster than writing
<tt>mul(t, a, b); add(x, x, t)</tt>.
See <a href="ZZ.cpp.html">ZZ.txt</a> for details.
These new routines are used in a number of places in
NTL to get faster algorithms (for example, the <tt>LLL</tt> routine).
<li>
Fixed a relatively benign indexing bug in <tt>GF2EX</tt>
discovered by Berend-Benjamin Tams using the <tt>valgrind</tt> tool.
</ul>
<p> <hr> <p>
<h3>
2009.05.05: Changes between NTL 5.5 and 5.5.1
</h3>
<ul>
<li> If using GMP (via either <tt>NTL_GMP_LIP</tt>
or <tt>NTL_GMP_HACK</tt>), then the new version (4.3.0) of
GMP implements the <tt>XGCD</tt> functionality differently,
so that the coefficients do not always agree with those returned by
the classical extended Euclidean algorithm.
This version of NTL corrects the coefficients, so that the
"classical" coefficients are always produced, regardless
of GMP's implementation.
This version of NTL also works
around a bug in GMP 4.3.0's <tt>XGCD</tt> code
(although that bug should be fixed in GMP 4.3.1).
<li>
The <tt>configure</tt> script has been slightly modified:
there is a new configuration variable <tt>DEF_PREFIX</tt>,
whose value can be used to set <tt>PREFIX</tt>, <tt>GMP_PREFIX</tt>,
and <tt>GF2X_PREFIX</tt> in one stroke.
Also, the (somewhat esoteric) <tt>configure</tt> variables
<tt>GMP_LIBDIR</tt>, <tt>GMP_INCDIR</tt>,
<tt>GF2X_LIBDIR</tt>, and <tt>GF2X_INCDIR</tt>
have slightly different meanings now.
</ul>
</h3>
<p> <hr> <p>
<h3>