Wish list

An NTL discussion forum

Wish list

Postby dthomson » Wed Jan 27, 2016 10:00 pm

Dear Victor, et al.,

Recently, I've mentioned your wish-list for NTL recently in a couple of different contexts: http://www.shoup.net/ntl/doc/tour-roadmap.html. I wanted to confirm that this wish-list is current (that is, the wishes are still current to the best of your knowledge).

This forum provides a good venue for a discussion about such a wishlist and roadmap for NTL: what are some pressing additions that the community-at-large is looking for in NTL? And conversely, have any wishlist items already been implemented (possibly in a stable but unpolished way).

If such a list takes off, I think it should focus on core functionality (such as Kronecker substitution for zz_pX arithmetic) or applications that are ubiquitous and guaranteed to be integrated into the library proper (such as EC arithmetic, point counting, etc.). There are other many other venues to solicit help on pet projects.

I'll begin a list by saying something of interest for me is natively supporting extensions of extensions (e.g., GF(2^8) over GF(2^4)) and, having done so, to have NTL understand the compatibility between extensions. I think there are many challenges to doing this: testing membership and knowing compatibility may end up being a 'hack' (or at least the lattice may need to be set up only when necessary). Clearly, I haven't worked out the implementation details, but I believe a lot of the legwork appears in the following paper:
W. Bosma, J. Cannon and A. Steel, Lattices of Compatibly Embedded Finite Fields, JSC (24), 351--369.

The recent improvements to NTL, especially thread safety, are very exciting and much appreciated. Many thanks for your efforts,

David Thomson
Posts: 1
Joined: Wed Jan 27, 2016 9:35 pm

Re: Wish list

Postby victorshoup » Wed Jan 27, 2016 11:12 pm

Hi David,

I'm glad to see that I didn't post into a void!!
Yes, I should work out in more detail a wish list, but I think it is best to have
people's interests dictate what is to be done. In any case, I will go back
over my documentation and notes, and extract a short list.

Suppose we wanted to do something like what you suggest, which I think is
a great idea, by the way!! There are a number of non-algorithmic issues
we would have to tackle.

One set of issues revolves around how we we want to structure the class
definitions. What new classes would be defined, and how would they
relate to the existing classes? And is it time to exploit C++ templates more
fully? I mean...there is already a lot of code replication in NTL, and this
would lead to much more, possibly... One has to be careful, though, with
templates...they can introduce a lot of surprises, especially when it comes to overload
resolution, and such. I would envision using them in some behind-the-scenes way
so that they would not even be visible from the documented interface.
And hopefully we can maintain and extend the current conventions
for conversions and promotions in a clean way. And would there be
parallel classes corresponding to GF2, zz_p, and ZZ_p? And is it best to
introduce towers of fields and bivariate polynomials at the same time?
Lot's of questions!

Another set of issues revolves around "software development management".
If we move forward on this or similar projects, what is the best way to manage
distributed development, in a way that maintains quality and consistency,
but encourages cooperation? I've obviously been a total control freak for a long time,
but I think it is time to slowly start getting away from that.

Site Admin
Posts: 32
Joined: Mon Jan 13, 2014 3:18 am

Return to NTL

Who is online

Users browsing this forum: No registered users and 1 guest