Updates to the MPIR-EXP branch

[Cactus]

I have corrected a minor bug and made several cosmetic updates to the MPIR-EXP branch.

If Case can let me have the updates needed for the mpir-exp command line build, I will add these to the SVN.

The only major outstanding issue (apart from as much application level testing as possible) is to check that the changes do not impact on MPIR using GCC/Linux/Unix.

     Brian

[Case Van Horsen]

On Thu, Jan 19, 2012 at 2:00 AM, Cactus <riem...@gmail.com> wrote:
> I have corrected a minor bug and made several cosmetic updates to the
> MPIR-EXP branch.
>
> If Case can let me have the updates needed for the mpir-exp command line
> build, I will add these to the SVN.

I will send my updates this evening.

Case

>
> The only major outstanding issue (apart from as much application level
> testing as possible) is to check that the changes do not impact on MPIR
> using GCC/Linux/Unix.
>
>      Brian
>

> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mpir-devel/-/EoIrDsNS3XgJ.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.

[Case Van Horsen]

On Thu, Jan 19, 2012 at 8:16 AM, Case Van Horsen <cas...@gmail.com> wrote:
> On Thu, Jan 19, 2012 at 2:00 AM, Cactus <riem...@gmail.com> wrote:
>> I have corrected a minor bug and made several cosmetic updates to the
>> MPIR-EXP branch.
>>
>> If Case can let me have the updates needed for the mpir-exp command line
>> build, I will add these to the SVN.
> I will send my updates this evening.
>
> Case

Updated configure.bat and make.bat files are attached. Files were
renamed with a .txt extension.

[Case Van Horsen]

On Thu, Jan 19, 2012 at 5:31 PM, Case Van Horsen <cas...@gmail.com> wrote:
> On Thu, Jan 19, 2012 at 8:16 AM, Case Van Horsen <cas...@gmail.com> wrote:
>> On Thu, Jan 19, 2012 at 2:00 AM, Cactus <riem...@gmail.com> wrote:
>>> I have corrected a minor bug and made several cosmetic updates to the
>>> MPIR-EXP branch.
>>>
>>> If Case can let me have the updates needed for the mpir-exp command line
>>> build, I will add these to the SVN.
>> I will send my updates this evening.
>>
>> Case
> Updated configure.bat and make.bat files are attached. Files were
> renamed with a .txt extension.

The latest version SVN version of gmpy2 now uses gmp_si/gmp_si. The
required changes were straight-forward.

I've made more modifications to configure.bat and make.bat. I added
support for a "CC" option to specify a specific compiler. The current
options are SDK70, SDK71, VS2008, and VS2010. Is there interest in
these new versions?

Is the mpir-exp compatible with MPFR and MPC? I want to create
configure/make files for MPFR and MPC and I want to be sure it is
expected to work (or not).

Case

[Cactus]

Hi Case,

I think the ability to build using any of the compilers you mention would be a good addition.   Jason maintains the command line build so the changes would need to go to him.

MPFR builds with mpir-exp and all tests pass.  MPC also builds with mpir-exp but one test currently fails due to what is probably an FFT bug that still has to be tracked down.

The major problem with both MPFR and MPC is that all the ui/si functions will have the 32 bit integer length problems on Windows x64.   

To solve this we either have to persuade the MPFR and MPC teams to adopt the gmp_ui/gmp_si solution in their releases or we will have to fork both MPFR and MPC.  

I doubt that they will be keen on the former and I don't think we have the resource needed to do the latter.  

Any thoughts on the issue will be much appreciated.   Is this facility still useful in MPIR evn if we cannot adopt it in MPFR and MPC?

     Brian

[Case Van Horsen]

On Tue, Jan 24, 2012 at 1:43 AM, Cactus <riem...@gmail.com> wrote:
> Hi Case,
>
> I think the ability to build using any of the compilers you mention would be
> a good addition.   Jason maintains the command line build so the changes
> would need to go to him.

I'll send copies to Jason when I'm finished with them.

>
> MPFR builds with mpir-exp and all tests pass.  MPC also builds with mpir-exp
> but one test currently fails due to what is probably an FFT bug that still
> has to be tracked down.

Okay.

>
> The major problem with both MPFR and MPC is that all the ui/si functions
> will have the 32 bit integer length problems on Windows x64.
>

I don't think that is a big issue. MPFR and MPC both support intmax_t
and uintmax_t for assignment and conversion. Only the combined
mpfr_t/long and mpc_t/long functions would not support 64-bit
integers.

> To solve this we either have to persuade the MPFR and MPC teams to adopt the
> gmp_ui/gmp_si solution in their releases or we will have to fork both MPFR
> and MPC.

To reinforce that these new types are MPIR specific, should they be
called mpir_ui/mpir_si?

>
> I doubt that they will be keen on the former and I don't think we have the
> resource needed to do the latter.
>
> Any thoughts on the issue will be much appreciated.   Is this facility still
> useful in MPIR evn if we cannot adopt it in MPFR and MPC?

Yes.

Case

>
>      Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/mpir-devel/-/VyWAw45uYVcJ.

[Cactus]

> To reinforce that these new types are MPIR specific, should they be called mpir_ui/mpir_si?

I had exactly the same idea a few days ago - I am inclined to do this.

    Brian

[Case Van Horsen]

A couple more ideas...

Can we define a macro (HAVE_MPIR_SI ?) to unambiguously detect if
mpir_si/mpir_ui is available?

For better backwards compatibility, should mpir_si/mpir_ui always
default to long unless USE_MPIR_SI (or some other descriptive name) is
defined before mpir.h/gmp.h is included?

The only compatibility issue I encounterd was trying to explicitely
get a long on 64-bit Windows. I had to downcast the results of
gmp_get_si(). Would it make sense to add
mpir_get_slong/mpri_get_ulong?

Case
>
>     Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/mpir-devel/-/w3ZXpLZGZgcJ.

[Cactus]

On Tue, 24 Jan 2012 07:37:09 -0800

Case Van Horsen

> On Tue, Jan 24, 2012 at 5:59 AM, Cactus wrote:  

> >> To reinforce that these new types are MPIR specific, should they

> >> be called mpir_ui/mpir_si?  

> >

> > I had exactly the same idea a few days ago - I am inclined to do

> > this.  

> A couple more ideas...

> 

> Can we define a macro (HAVE_MPIR_SI ?) to unambiguously detect if

> mpir_si/mpir_ui is available?  

I can put HAVE_MPIR_UI and HAVE_MPIR_SI into mpir.h if this

would do the trick.

> For better backwards compatibility, should mpir_si/mpir_ui always

> default to long unless USE_MPIR_SI (or some other descriptive name) is

> defined before mpir.h/gmp.h is included?  

Right now these types are always long with only one exception - Windows

x64, which is detected with the define _WIN64.  I am not that keen on

removing the default of using 64-bit integers on Windows x64 but we

could allow this to be turned off by defining, say, NO_MPIR_INTS:

#if defined( _WIN64 ) && !defined( NO_MPIR_INTS )

  ....

#else

  ....

#endif

> The only compatibility issue I encounterd was trying to explicitely

> get a long on 64-bit Windows. I had to downcast the results of

> gmp_get_si(). Would it make sense to add

> mpir_get_slong/mpri_get_ulong?  

Yes, I can add:

#ifdef _WIN64

#define mpz_get_ulong(x) ((unsigned long)mpz_get_ui(x))

#define mpz_get_slong(x) ((long)mpz_get_si(x))

#endif

to solve this.

   Brian

[Brian Gladman]

TEST - Please ignore.

[Case Van Horsen]

On Tue, Jan 24, 2012 at 9:26 AM, Cactus <riem...@gmail.com> wrote:
> On Tue, 24 Jan 2012 07:37:09 -0800
> Case Van Horsen
>
>> On Tue, Jan 24, 2012 at 5:59 AM, Cactus wrote:
>> >> To reinforce that these new types are MPIR specific, should they
>> >> be called mpir_ui/mpir_si?
>> >
>> > I had exactly the same idea a few days ago - I am inclined to do
>> > this.
>> A couple more ideas...
>>
>> Can we define a macro (HAVE_MPIR_SI ?) to unambiguously detect if
>> mpir_si/mpir_ui is available?
>
> I can put HAVE_MPIR_UI and HAVE_MPIR_SI into mpir.h if this
> would do the trick.

A single define, say HAVE_MPIR_INTS, would be cleaner. I don't think
we coud have the SI and UI versions independantly.

>
>> For better backwards compatibility, should mpir_si/mpir_ui always
>> default to long unless USE_MPIR_SI (or some other descriptive name) is
>> defined before mpir.h/gmp.h is included?
>
> Right now these types are always long with only one exception - Windows
> x64, which is detected with the define _WIN64.  I am not that keen on
> removing the default of using 64-bit integers on Windows x64 but we
> could allow this to be turned off by defining, say, NO_MPIR_INTS:
>
> #if defined( _WIN64 ) && !defined( NO_MPIR_INTS )
>   ....
> #else
>   ....
> #endif
>

That would work, too.

>> The only compatibility issue I encounterd was trying to explicitely
>> get a long on 64-bit Windows. I had to downcast the results of
>> gmp_get_si(). Would it make sense to add
>> mpir_get_slong/mpri_get_ulong?
>
> Yes, I can add:
>
> #ifdef _WIN64
> #define mpz_get_ulong(x) ((unsigned long)mpz_get_ui(x))
> #define mpz_get_slong(x) ((long)mpz_get_si(x))
> #endif
>

Okay.

Case
> to solve this.

>
>    Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/mpir-devel/-/IRQHAeL7MukJ.

[Brian Gladman]

On Tue, 24 Jan 2012 09:57:36 -0800

Case Van Horsen <cas...@gmail.com> wrote:

> >> Can we define a macro (HAVE_MPIR_SI ?) to unambiguously detect if
> >> mpir_si/mpir_ui is available?
> >
> > I can put HAVE_MPIR_UI and HAVE_MPIR_SI into mpir.h if this
> > would do the trick.
> A single define, say HAVE_MPIR_INTS, would be cleaner. I don't think
> we coud have the SI and UI versions independantly.

The other issue is that we need a name that will not be misleading
since we are not switching off these types, just switching off
their definition as long longs on Windows x64

Brian