NTL 1v0.1.0

[Victor Shoup]

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 that Singular/NTL_NEW_OP patch --- that is a Singular problem

that should be fixed in Singular.

I also added a new TUNE variable to the configuration script.

TUNE=auto (the default) runs the performance-tuning wizard (as before).

TUNE=x86 skips the wizard, and sets things up so it should work well on any x86.

TUNE=generic skips the wizard, and sets things up so it should work not too badly on

  any not-too-old hardware (ARM, PowerPC).

Please see http://shoup.net/ntl/doc/tour-changes.html for more details.

I also polished up the installation documentation quite a bit.

Please see http://shoup.net/ntl/doc/tour-unix.html for more details.

Please let me know if there any issues with the packaging/build features.

Maybe some day I will get around to going fully autotools.

But that will take some tinkering to get right...hopefully, this new build

system will be pretty useful "as is".

Again...thanks for your help and encouragement!

[François Bissey]

On 15/10/16 03:28, Victor Shoup wrote:
> 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 that Singular/NTL_NEW_OP patch --- that is a
> Singular problem
> that should be fixed in Singular.
>

Hum, not sure it is fixed, but something that look new happened :)
NTLconvert.cc: In function ‘CanonicalForm convertZZ2CF(const NTL::ZZ&)’:
NTLconvert.cc:509:38: error: invalid static_cast from type ‘const
raw_ptr {aka _ntl_gbigint_body* const}’ to type ‘long int*’
static_cast<long *>( a.rep.rep ); // what about NTL7?
^
Makefile:1205: recipe for target 'NTLconvert.lo' failed

This is building singular 4.0.3p3. Haven't tried a build including
the old to see if that makes the problem go away.

Francois

[Victor Shoup]

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 something to work around the issue. Or ask me to provide an interface for some functionality that they need and that I can maintain. My guess is that this is related to changes I made in the transition to v10.

[Francois Bissey]

> On 18/10/2016, at 16:49, Victor Shoup <sh...@cs.nyu.edu> wrote:
>
> 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 something to work around the issue. Or ask me to provide an interface for some functionality that they need and that I can maintain. My guess is that this is related to changes I made in the transition to v10.
>

And you should make life difficult for abuser of undocumented
or internal interfaces. There is a special place for such people…

They already do ifdef, this is a larger extract than the
error message:
const long * rep =
#if NTL_MAJOR_VERSION <= 6
static_cast<long *>( a.rep );
#else

static_cast<long *>( a.rep.rep ); // what about NTL7?

#endif

François

[Victor Shoup]

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 to use ZZToBytes (or something like that). I could add some special routines for direct gmp bignum conversions, if there was a demand for that.

[Francois Bissey]

> On 18/10/2016, at 17:18, Victor Shoup <sh...@cs.nyu.edu> wrote:
>
> 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 to use ZZToBytes (or something like that). I could add some special routines for direct gmp bignum conversions, if there was a demand for that.

The code is not recent as far as I can tell. The stated purpose here:
////////////////////////////////////////////////////////////////////////////////
/// NAME: convertZZ2CF
///
/// DESCRIPTION:
/// Routine for conversion of integers represented in NTL as Type ZZ to
/// integers in Factory represented as canonicalform.
/// To guarantee the correct execution of the algorithm the characteristic
/// has to equal zero.
///
/// INPUT: The value coefficient of type ZZ that has to be converted
/// OUTPUT: The converted Factory-integer of type canonicalform
////////////////////////////////////////////////////////////////////////////////
And in some case they use the quoted snippet.
This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

[Victor Shoup]

That said, I think the quickest fix is to replace static_cast<long*> with (long*). But it's not a good long term solution.

[Bill Hart]

Hans does seem to fix most bugs that are reported unless they require extensive rewriting or aren't considered bugs. It looks like this code was written with the expectation that it would be maintained, so I'd just report it to him [1].

Bill.

[1] https://www.singular.uni-kl.de/index.php/singular-report-bugs.html

[Victor Shoup]

Good! But it should be determined if there is an interface that ntl could provide so that this problem goes away

[Jean-Pierre Flori]

On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup wrote:

Good! But it should be determined if there is an interface that ntl could provide so that this problem goes away

I think that what you suggested: extracting gmp bignums from NTL's ZZ (and the other way around) would be great.

[Francois Bissey]

Who is doing the reporting to singular upstream? Preferably someone
who already has an account on singular’s trac.

François

[Jean-Pierre Flori]

Usually I just post on the google group libsingular-devel and Hans read it and fixes the issue.
The singular trac server uses a high port and I can not reach it from some of my computers.

[Bill Hart]

Are you sure you need an account on the trac to report it? The http version at least seems to accept essentially anonymous input.

Alternatively, I guess JP's suggestion should work fine. It might be even better if some discussion is needed about what interface NTL should provide.

Bill.

[Francois Bissey]

I probably assumed too much. But it felt wrong to say
“there is a problem building ntl but ntl upstream is happy
to talk to you about your needs” (and doing that anonymously
feels like a prank call).
I prefer the mailing list option and I am actually subscribed.
Still have to get to it.

François

> --
> 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+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Victor Shoup]

I will anyway add routines to get and set the limbs of a ZZ.

[Francois Bissey]

And posted to libsingular-devel: https://groups.google.com/d/msg/libsingular-devel/u8-aHNMqf44/GNVvSYGEAQAJ

[Victor Shoup]

Sure. Will do.

[François Bissey]

On 19/10/16 23:57, Victor Shoup wrote:
> Sure. Will do.
>
For people not on libsingular-devel, Hannes' answer:
==========
The problem is a fast/convinient conversion between long integers in
factory of type CanonicalForm (which is in principle a mpz_t number)
and long integers in NTL of type ZZ (which is, if I understood it
correctly, analogue to the internal of a mpz_t).
(There are routines to access the mpz_t representation of a CanonicalForm in
factory and to construct a CanonicalForm from a mpz_t)

The current implementation uses a string representation in basis
16 (NTL->factory) resp. 10 (factory->NTL),
which is neither nice nor fast, but was easy to implement and works:

mpn_get_str converts the NTL-ZZ-number to a string
and mpz_init_set_str creates then the GMP-mpz_t-number (and then the
CanonicalForm number)

The reverse uses a string with basis 10: mpz_get_str from factory to
string and conv from string to NTL ZZ
=========

Francois