True. Should be https://libntl.org
On Friday, March 5, 2021 at 5:00:17 PM UTC-5 jus...@mac.com wrote:
> Hi, Victor,
>
> It appears that the first link has a typo :-}
>
> > On Mar 5, 2021, at 13:35 , Victor Shoup wrote:
> >
> > Just posted a new version of NTL
Just posted a new version of NTL to https://libnlt.org
BTW, NTL is also hosted on github: https://github.com/libntl/ntl
Cheers
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
I uploaded NTL 11.4.3 to https://www.shoup.net/ntl/
This fixes an embarrassing build problem in 11.4.2.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel
I just uploaded NTL 11.4.2 to http://www.shoup.net/ntl
This fixes a few small, obscure bugs, including one that prevents using
the gf2x-1.3 library.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiv
I've just posted NTL 11.4.1, which fixes a bug introduced in NTL 11.4.0.
Details here: https://shoup.net/ntl/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sag
A new version of NTL is available. Details
here: https://www.shoup.net/ntl/doc/tour-changes.html
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsu
. If you want to use this as the build system
> for ntl going forward, then I can add support for the wizard as well.
>
> Isuru
>
>
> On Sat, Sep 7, 2019 at 10:56 AM Victor Shoup > wrote:
>
>> I just posted NTL 11.3.4.
>>
>> Details here [ https
I just posted NTL 11.3.4.
Details here [ https://www.shoup.net/ntl/ ].
This (I hope) fixes the "-lpthread underlinking issue" reported here [
https://trac.sagemath.org/ticket/28406 ] and discussed at excessive length
(mostly due to my own obstinance) here [
https://groups.google.com/forum/#!t
implementation
more than the buggy gcc/clang implementations.
On Thursday, September 5, 2019 at 6:57:36 PM UTC-4, Dima Pasechnik wrote:
>
> On Thu, Sep 5, 2019 at 11:43 PM Victor Shoup > wrote:
> >
> > So NTL's configure script already provides a work-around.
&g
ptember 5, 2019 at 6:57:36 PM UTC-4, Dima Pasechnik wrote:
>
> On Thu, Sep 5, 2019 at 11:43 PM Victor Shoup > wrote:
> >
> > So NTL's configure script already provides a work-around.
> > Just pass LIBTOOL_LINKER_FLAGS=-lpthread to NTL's configure script,
>
elf.
On Thursday, September 5, 2019 at 10:35:42 AM UTC-4, Antonio Rojas wrote:
>
>
>
> El jueves, 5 de septiembre de 2019, 15:51:34 (UTC+2), Victor Shoup
> escribió:
>>
>> We seem to be talking past each other.
>>
>
> Unfortunately it seems so.
>
> I
I updated my PGFFT (Pretty Good FFT) library.
Details here: https://www.shoup.net/PGFFT/
It is now almost as fast or faster than FFTW on transforms up to 100K or so,
at least on AVX or AVX2 machines. I've posted some more timings.
If anyone is curious, the only reason I did this is that for anot
ep the peace, I will patch my libbtool based on Dima's
suggestion.
Someday, I will make NTL's build system more conventional...maybe I can
find a student who can help me out.
On Thursday, September 5, 2019 at 10:35:42 AM UTC-4, Antonio Rojas wrote:
>
>
>
> El jueves, 5 de se
ool, then you can build NTL using a custom libtool
that supports your conventions.
That's probably where this ends.
On Thursday, September 5, 2019 at 2:48:58 AM UTC-4, Dima Pasechnik wrote:
>
>
>
> On Thu, 5 Sep 2019 at 05:07, Victor Shoup >
> wrote:
>
>> Please
Please see comments/questions below...
On Wednesday, September 4, 2019 at 6:04:42 AM UTC-4, Dima Pasechnik wrote:
>
> On Tue, Sep 3, 2019 at 2:21 PM Victor Shoup > wrote:
> >
>
> > When I compile a program that uses NTL, I always pass -pthread to g++.
> > Doesn&
-pthread:
again, the latter is supposed to add the necessary linker flags.
Thus, I'm still a bit hesitant to do this.
I guess I still don't entirely understand the model.
On Monday, September 2, 2019 at 6:24:00 PM UTC-4, Dima Pasechnik wrote:
>
> On Tue, Sep 3, 2019 at 1:05 AM Victor Sh
to do with libtool. libtool
> >> is robust if you let it handle the configuration. It will not try to
> >> fix a given one.
> >>
> >> In a libtool configure.ac script you would just have a directive
> >> AC_CHECK_LIB for pthread.
> >>
>
t;
> In short, I would suggest
>
> 3) Replace DoConfig by a configure.ac script
>
> Vincent
>
> Le 28/08/2019 à 15:15, Victor Shoup a écrit :
> > Thanks. I guess what I'm asking for is a solution. From what you say
> here,
> > and what is said in the
PGFFT is a "pretty good FFT" for double-precision complex numbers, written
in C++. It's main selling points are (1) it's not too slow, and (2) it's
available under a BSD license. Details here: https://www.shoup.net/PGFFT/
--
You received this message because you are subscribed to the Google G
I've uploaded a new version of NTL. Details on changes are
here: https://www.shoup.net/ntl/doc/tour-changes.html
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
:13 PM Victor Shoup > wrote:
> >
> > Thanks for all of the thoughtful replies.
> >
> > I don't have time to rewrite the config script any time soon.
> > According to the libtool documentation, it is supposed to be usable
> > without relying on automake.
Thanks for all of the thoughtful replies.
I don't have time to rewrite the config script any time soon.
According to the libtool documentation, it is supposed to be usable
without relying on automake.
NTL's config script allows you to override the default libtool with a
system libtool,
so that se
nt of libtool was to take care of all this nonsense,
and if it's not doing that, then
it seems kind of pointless.
On Tuesday, August 27, 2019 at 1:42:51 PM UTC-4, Antonio Rojas wrote:
>
>
>
> El martes, 27 de agosto de 2019, 16:25:12 (UTC+2), Victor Shoup escribió:
>>
>&
I reviewed some comments which mentioned a problem with ntl and threads. I’m
happy to fix that, but I don’t think I understand what the issue is. Can anyone
explain? Thanks.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from th
I just uploaded NTL 11.3.2 to https://www.shoup.net/ntl/
This fixes a performance issue in the ZZ PowerMod function (which also
affects the prime testing and generating function).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fr
I just posted NTL 11.3.2 to http://www.shoup.net/ntl
This fixes a performance issue related the ZZ PowerMod function (and by
implication primality testing and generating functions).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe
I just release NTL 11.3.1, which fixes a bug.
See http://www.shoup.net/ntl/doc/tour-changes.html
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsub
opposed to 60 (or 62) in the normal implementation. And because of CPU
throttling,
it can even slow down some computations.
On Tuesday, September 11, 2018 at 10:31:16 AM UTC-4, Erik Bray wrote:
>
> On Tue, Sep 11, 2018 at 4:14 PM Victor Shoup > wrote:
> >
> > I got cu
I got curious, so I collected some data. Here are timing results comparing
NTL's zz_pX multiplication
to zn_poly's zn_array_mul. For various values of n, I multiplied
polynomials of degree < n
modulo a 50 bit number. The values of n are powers of 2 and halfway
between powers of 2,
ranging bet
I just uploaded NTL 11.3.0 to https://www.shoup.net/ntl/
Brief summary of what's new:
- An AVX-based small-prime FFT
- For a variety of reasons, this is an experimental feature that is
not enabled by default.
- Works with both AVX2 and AVX512.
- It can give a 2-3x spee
I just uploaded NTL 11.2.1 to http://www.shoup.net
This fixes an embarrassing bug, which slipped into NTL 11.2.0.
Any installations of NTL 11.2.0 should be replaced as soon as possible with
NTL 11.2.1.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gr
making your code Open Source, so that we can all learn from it, and for the
> benchmarks you have been making available!
>
> Bill.
>
> On Saturday, 7 July 2018 20:39:59 UTC+2, Victor Shoup wrote:
>>
>> I just released NTL 11.2.0 at http://www.shoup.net/ntl
>>
>
I just released NTL 11.2.0 at http://www.shoup.net/ntl
The main change is a new and improved implementation of the
Schoenhage-Strassen FFT for multiplication of polynomials over the
integers. The new implementation includes a truncated FFT algorithm, the
"sqrt 2" trick, and better engineered lo
Just posted a new version of NTL, version 11.1.0. I've completely
re-written the low-level small-prime FFT to use a truncated FFT algorithm.
More details here:
http://www.shoup.net/ntl/doc/tour-changes.html
--
You received this message because you are subscribed to the Google Groups
"sage-d
w.shoup.net/ntl/benchmarks.pdf
Cheers!
-Victor Shoup
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group,
Go to http://shoup.net/ntl for full details.
Below is the latest entry in the change log.
I've also updated the NTL/FLINT comparison document:
http://shoup.net/ntl/benchmarks.pdf
The only significant change is to the ZZ_pX factoring benchmarks
(the new code in NTL speeds up mat_ZZ_p multiplication
Just posted a new version. In addition to a few performance improvements,
I've added new routines that give direct access to the underlying "limbs"
of a ZZ,
which is a feature that has been requested from time to time.
As usual, go to: http://www.shoup.net/ntl
The next thing I
Sure. Will do.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroup
I will anyway add routines to get and set the limbs of a ZZ.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to th
Good! But it should be determined if there is an interface that ntl could
provide so that this problem goes away
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
That said, I think the quickest fix is to replace static_cast with
(long*). But it's not a good long term solution.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
I see. I don't do it on purpose...
I looked at some singular source files, but I don't know if I have the most
recent. But it looks like they are trying to look inside ntl's ZZ
representation. That's a big no no. Right now, the only semi efficient way to
do this with the existing interface is
Interesting. Looks like the singular code is using internal, undocumented NTL
interfaces. I work very hard to keep the documented interfaces stable and
reliable, but I can't guarantee anything for undocumented interfaces. If
singular is going to do that, they will have to use ifdefs or somethin
I just uploaded NTL v10.1.0.
After much foot dragging, and with the help and encouragement of folks here
at sage-devel,
I've finally got around to making (nearly) all of the packaging/build
features that were requested.
The big ones are locally generated libtool and $(MAKE).
I did not implement
updates, too.
BTW, I also remember using paper tape...but that was mainly just
to backup my programs, if I recall correctly. Ahhh...those were the days
:-)
On Saturday, October 8, 2016 at 4:21:14 PM UTC-4, Victor Shoup wrote:
>
> I hope this is of some interest to the Sage community.
>
is a problem that should be fixed in singular, if it hasn't
been already.
On Saturday, October 8, 2016 at 4:21:14 PM UTC-4, Victor Shoup wrote:
>
> I hope this is of some interest to the Sage community.
> I've just released a new version of NTL at http://www.shoup.net/ntl
>
&
d have pestered you about make/$(MAKE) a lot more
> as it is a much bigger sin ;)
>
> François
>
> > On 11/10/2016, at 13:03, Victor Shoup >
> wrote:
> >
> > First, you are definitely wrong about punch cards. I started programming
> > with Fortran
I am almost done with everything!!
I have just a couple of remaining questions.
First, I am having a hard time understanding why singular is having a hard
time
with the definition of NTL_NEW_OP. It is defined that way for a reason,
and this
is completely standard C++ (standard, as in C++98).
Co
changes.
I will follow up with a couple of quick questions, though.
On Monday, October 10, 2016 at 5:09:48 PM UTC-4, Dima Pasechnik wrote:
>
>
>
> On Monday, October 10, 2016 at 9:09:38 PM UTC+1, François wrote:
>>
>> On 11/10/16 01:58, Victor Shoup wrote:
>> > Another
About the make variable... I can definitely see it's utility with make -j... I
would guess that's the main advantage, and that's easy enough to fix in the
makefile itself.
The other calls to make from other scripts are a bit more problematic. Would
you say they are a priority? And if so, woul
One more question, relating to $(MAKE). There are a number of scripts besides
the makefile that also invoke make. Should these also be modified? But then the
mechanism would have to be different (environment variable?). Before I can sort
that out, I would like to know what is the goal here? Is s
Let me get this straight...
You say that the tarball does not contain a libtool script, but rather,
contains a directory that contains files that will build a libtool script at
compile time. Is that right?
--
You received this message because you are subscribed to the Google Groups
"sage-devel
Ok, thanks. I will try to get this done this week. Your explanation was very
helpful. Hopefully, I can piece together a solution based on the scripts you
pointed to in your previous reply.
I admit, I've been quite a dinosaur when it comes to autotools stuff...when I
started, none of this really
Ok, I will start working on these issues. The one I understand the least is
libtool.
It looks like you are saying I should generate a libtool script on the machine
X on which
I create the NTL tarball. But this seems very strange. How could that script be
any better
than one generated/installed
Haha, yes, that was one reason to do it.
On Saturday, October 8, 2016 at 4:27:01 PM UTC-4, François wrote:
>
>
> > On 9/10/2016, at 09:21, Victor Shoup >
> wrote:
> >
> > • I've renamed all the ".c" files to ".cpp" files in the U
I hope this is of some interest to the Sage community.
I've just released a new version of NTL at http://www.shoup.net/ntl
Here is a summary of changes.
*New License: LGPLv2.1*
- With the permission of all relevant contributors, NTL is now licensed
under LGPLv2.1+ (the Lesser GNU Public
conclusive...
>
> By the way, I've forwarded all of our patches/hackery to Victor Shoup some
> monthes/years ago and he said he'll try to integrate them.
> Maybe it's time to politely ask once again about what has not been
> integrated (e.g. shipping its own libtool).
So I finally figured out a way to get NTL to work in thread-safe mode
on a much broader range of platforms, including Mac OSX (10.10 and above)
and Linux with somewhat older gcc's (gcc version 4.8 and above).
This new version of NTL still requires many C++11 features in
thread-safe mode, but it do
I uploaded a new NTL version (9.7.1) to
http://www.shoup.net/ntl
This version completes the implementation of faster matrix
arithmetic (mul, inv, gauss, etc) modulo small primes.
These new implementations are more cache friendly, and they
make more intelligent use of available hardware (e.g.,
sion of c++11 flags breaks the building of the
> singular version shipped in sage. I don’t know about singular 4
> but it wouldn’t surprise me if it did too.
>
> François
>
> > On 13/03/2016, at 10:32, Victor Shoup >
> wrote:
> >
> > Just released a new vers
Just released a new version of NTL!
In a nutshell: faster, better matrix arithmetic over zz_p (small moduli),
some improved thread pooling facilities,
and several other small improvements.
For more details, go here: http://shoup.net/ntl/doc/tour-changes.html
--
You received this message because
I implemented a simple thread pool, so threads are long lived and wake up when
there is work to do. The thread pool class is pretty easy to use.
Have not tried hyperthreading. The sys admins who are in charge of the machine
are not keen to turn it on.
All the code is available on my Web site.
Just in case anyone is interested...
I released a new version of NTL that offers a new "thread boosting" feature,
which utilizes multiple cores to speed up certain computations.
This is a work in progress...as of now, only basic operations in ZZ_pX
are thread boosted.
You can see a report on the
until that happens before diving in to all of the
current muck...
Hopefully, I won't be too old to write code :-)
On Monday, October 5, 2015 at 10:22:08 AM UTC-4, bluescarni wrote:
>
> On 5 October 2015 at 13:13, Victor Shoup >
> wrote:
>>
>> I hesitate somewhat to get
onday, October 5, 2015 at 7:13:23 AM UTC-4, Victor Shoup wrote:
>
> Yes, I saw a paper by the mathemagix people recently...I believe they use
> the floating point SIMD, and some
> tricks with "fused multiply and add" to very nice effect.
> They are basically implementing
ther hand, seems like a better
investment, especially since C++11 (and C11) now standardize many aspects
of it, so one can write portable
code now.
On Monday, October 5, 2015 at 5:33:29 AM UTC-4, Bill Hart wrote:
>
>
>
> On Monday, 5 October 2015 04:18:27 UTC+2, Victor Shoup wrote:
>
ks compared
> to some of the new code that is being presented at conferences these days.
>
> Bill.
>
> On Monday, 5 October 2015 01:35:09 UTC+2, Victor Shoup wrote:
>>
>> I've recently done some benchmarking to compare FLINT and NTL.
>> I've tried to be as fair as po
I've recently done some benchmarking to compare FLINT and NTL.
I've tried to be as fair as possible in the comparisons.
If anyone is interested, you can see the results here:
http://shoup.net/ntl/benchmarks.pdf
The upshot is: FLINT is faster for some things, and NTL is faster
for other things.
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
I finally transformed the internals of NTL to be exception safe and to throw
exceptions upon encountering an error (rather than the old "abort with
error message"
approach).
This required a major overhaul of a lot of NTL internals, but the high level
interfaces remain unchanged.
To enable except
ecember 15, 2014 5:31:21 PM UTC-5, Jeroen Demeyer wrote:
>
> On 2014-12-15 20:15, Victor Shoup wrote:
> > As I get closer to finishing this, I'm thinking more about gmp's lack of
> > proper error handling, which is just like NTL's currently: print error
> messa
I've just uploaded a bug-fix version of NTL (version 7.0.2) at
www.shoup.net/ntl.
Probably does not affect any Sage code, though.
Also, I'm getting closer to finish my quixotic quest to make NTL exception
safe.
It is an interesting experience, as I'm learning how to make use of "modern"
C++ idio
that is certainly a possibility, it would just be an
> >>> optimizer bug. All reasonable C++ compilers uses a zero-cost model so
> its at
> >>> least as fast as handling / returning some error flag. What _is_
> expensive
> >>> is when an exception occurs
Hi all,
I've joined this group, since I think the Sage developer group is probably
one of the biggest users of NTL, and so it might be useful to be in more
direct contact.
Anyway, I just release v7.0.1 of NTL, which fixes a bug in the polynomial
multiplication code in v7.0. You will only see the
74 matches
Mail list logo
