From jblazi@gmx.de  Fri Nov  1 13:41:48 2002
From: jblazi@gmx.de (jblazi)
Date: Fri, 1 Nov 2002 14:41:48 +0100
Subject: Installation problem on Cygwin (ABI=32)
Message-ID: <200211011441.48569.jblazi@gmx.de>

I am trying to install Core, that is a library for exact geometrical=20
compuations. Core needs gmp I should like to work work on *Cygwin*.
When I try to install gmp (I have to input make configure first) I get th=
e=20
error message that ABI=3D32 is not on the ABI list which seemingly only=20
contains 'standard'.
I do not know whether this is a gmp or a Core problem but I suspect that =
I am=20
having this problem with gmp.
Could anybody give me a hint?

TIA,
--=20
Janos Blazi




From md6nguyen@yahoo.com  Fri Nov  1 16:37:09 2002
From: md6nguyen@yahoo.com (Minh Nguyen)
Date: Fri, 1 Nov 2002 08:37:09 -0800 (PST)
Subject: Installation problem on Cygwin (ABI=32)
In-Reply-To: <200211011441.48569.jblazi@gmx.de>
Message-ID: <20021101163709.53669.qmail@web20108.mail.yahoo.com>

--0-1012541831-1036168629=:52677
Content-Type: text/plain; charset=us-ascii


I've had a lot of problems to install GMP on Cygwin. After that I tried to use Mingw and things goes on much more smoothly. More than that, Cygwin requires cygwin runtime library when you want to link your program with GMP but Mingw only requires the standard Windows libraries. So I would recommend using Mingw unless you have other reasons. 

Minh

 jblazi <jblazi@gmx.de> wrote:I am trying to install Core, that is a library for exact geometrical 
compuations. Core needs gmp I should like to work work on *Cygwin*.
When I try to install gmp (I have to input make configure first) I get the 
error message that ABI=32 is not on the ABI list which seemingly only 
contains 'standard'.
I do not know whether this is a gmp or a Core problem but I suspect that I am 
having this problem with gmp.
Could anybody give me a hint?

TIA,
-- 
Janos Blazi



_______________________________________________
gmp-discuss mailing list
gmp-discuss@swox.com
https://gmplib.org/mailman/listinfo/gmp-discuss




---------------------------------
Do you Yahoo!?
HotJobs - Search new jobs daily now
--0-1012541831-1036168629=:52677
Content-Type: text/html; charset=us-ascii

<P>I've had a lot of problems to install GMP on Cygwin. After that I tried&nbsp;to use Mingw and things&nbsp;goes on much&nbsp;more smoothly. More than that,&nbsp;Cygwin requires cygwin runtime library when you&nbsp;want to link your program with GMP but Mingw&nbsp;only requires the standard Windows libraries. So I would recommend using Mingw unless you have other reasons. </P>
<P>Minh</P>
<P>&nbsp;<B><I>jblazi &lt;jblazi@gmx.de&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">I am trying to install Core, that is a library for exact geometrical <BR>compuations. Core needs gmp I should like to work work on *Cygwin*.<BR>When I try to install gmp (I have to input make configure first) I get the <BR>error message that ABI=32 is not on the ABI list which seemingly only <BR>contains 'standard'.<BR>I do not know whether this is a gmp or a Core problem but I suspect that I am <BR>having this problem with gmp.<BR>Could anybody give me a hint?<BR><BR>TIA,<BR>-- <BR>Janos Blazi<BR><BR><BR><BR>_______________________________________________<BR>gmp-discuss mailing list<BR>gmp-discuss@swox.com<BR>https://gmplib.org/mailman/listinfo/gmp-discuss<BR><BR></BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://rd.yahoo.com/careers/mailsig/*http://www.hotjobs.com ">HotJobs</a> - Search new jobs daily now
--0-1012541831-1036168629=:52677--



From tege@swox.com  Fri Nov  1 18:45:42 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 01 Nov 2002 19:45:42 +0100
Subject: Division degeneration
Message-ID: <86n0otjfhl.fsf@king.swox.se>

When dividing a (3n-s)-limb number by a n-limbs number, for
a small s, GMP degenerates to quadratic behaviour.  This
problem was discovered by Kalle Hasselström, who works on
divison optimizations for GMP 4.2.

The result of this flaw is that a division of a number with 150000
limbs by a divisor of 100000 limbs runs fast at a few seconds,
while a division of a 149999 limb number by the same divisor
takes several minutes...

I just checked in a fix for GMP 4.2.  The silly code was in
mpn/generic/tdiv_qr.c.

-- 
Torbjörn



From user42@zip.com.au  Fri Nov  1 21:08:48 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Sat, 02 Nov 2002 07:08:48 +1000
Subject: Installation problem on Cygwin (ABI=32)
In-Reply-To: <200211011441.48569.jblazi@gmx.de> (jblazi's message of "Fri, 1
 Nov 2002 14:41:48 +0100")
References: <200211011441.48569.jblazi@gmx.de>
Message-ID: <87k7jxj8v3.fsf@zip.com.au>

jblazi <jblazi@gmx.de> writes:
>
> I am trying to install Core, that is a library for exact geometrical 
> compuations. Core needs gmp I should like to work work on *Cygwin*.
> When I try to install gmp (I have to input make configure first) I get the 
> error message that ABI=32 is not on the ABI list which seemingly only 
> contains 'standard'.

There's only one ABI on cygwin for gmp, you're best off not trying to
choose anything, ie. just use "./configure".

> I do not know whether this is a gmp or a Core problem but I suspect that I am 
> having this problem with gmp.

Are you running the gmp configure or does the Core stuff do so?  If
the latter then the problem is probably down to it.



From user42@zip.com.au  Fri Nov  1 21:17:34 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Sat, 02 Nov 2002 07:17:34 +1000
Subject: mpz_sizeinbase
In-Reply-To: <20021028201737.582.qmail@web20101.mail.yahoo.com> (Minh
 Nguyen's message of "Mon, 28 Oct 2002 12:17:37 -0800 (PST)")
References: <20021028201737.582.qmail@web20101.mail.yahoo.com>
Message-ID: <87fzulj8gh.fsf@zip.com.au>

Minh Nguyen <md6nguyen@yahoo.com> writes:
>
> Now, suppose the return value of mpz_sizeinbase(op, base) is numdigs and I want to know the *exact* number of digits. The most straightforward way is to compare op with base^(numdigs-1) and then reduce numdigs by 1 if op is less than              base^(numdigs-1). Is there a better way?

Not that I know of.

Per remarks under "Binary to Radix" in the manual, I think examining
some of the high bits of "op" could give an exact answer more often,
to the point of "almost always", but in general it's a bit tricky
because the difference between "op" being n or n-1 digits can be only
in the very last few bits.

> By the way, is it too expensive to *always* return the exact number of digits when base is not 2 ? 

It already does so. :-)  (And it always did I think, but it's has only
recently been documented.)



From J.L.Moxham@maths.soton.ac.uk  Fri Nov  1 22:02:17 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Fri, 1 Nov 2002 22:02:17 +0000
Subject: mpz_sizeinbase and mpz_root
Message-ID: <200211012202.17340.J.L.Moxham@maths.soton.ac.uk>

I notice that=20

int mpz_root (mpz_t x , mpz_t y , unsigned long k ) when k=3D2 does not c=
all the=20
sqrt fn's  which are much faster than general k'th root , I suppose this=20
could be added as small patch , if it was thought that the case k=3D2 is =
common=20
enough ?

same comment for mpz_sizeinbase(mpz_t x, unsigned long k) when k=3D2
by using count_leading_zeros and not the bases[] tables , I was suprised =
that=20
it was that much faster  , in the current code we have an useless divisio=
n by=20
1 , which the compiler doesn't recognize. The case k=3D2 must be fairly c=
ommon=20
as it can be used for log_base2 .

jason




From J.L.Moxham@maths.soton.ac.uk  Sat Nov  2 02:16:17 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Sat, 2 Nov 2002 02:16:17 +0000
Subject: Installation problem on Cygwin (ABI=32)
In-Reply-To: <87k7jxj8v3.fsf@zip.com.au>
References: <200211011441.48569.jblazi@gmx.de> <87k7jxj8v3.fsf@zip.com.au>
Message-ID: <200211020216.17623.J.L.Moxham@maths.soton.ac.uk>

On Friday 01 Nov 2002 9:08 pm, Kevin Ryde wrote:
> jblazi <jblazi@gmx.de> writes:
> > I am trying to install Core, that is a library for exact geometrical
> > compuations. Core needs gmp I should like to work work on *Cygwin*.
> > When I try to install gmp (I have to input make configure first) I ge=
t
> > the error message that ABI=3D32 is not on the ABI list which seemingl=
y only
> > contains 'standard'.
>
> There's only one ABI on cygwin for gmp, you're best off not trying to
> choose anything, ie. just use "./configure".
>

I use gmp under cygwin in two ways , for static gmp libs only,

for programs that need to use cygwin.dll , I just use the default configu=
re

and for programs that I want to run native , or must not use cygwin.dll ,=
 I=20
configure with

=2E/configure --build=3Dathlon-pc-mingw32 --host=3Di586-pc-mingw32 --disa=
ble-shared=20
CFLAGS=3D"-mno-cygwin"=20

effectivily just using cygwin as a build enviroment only , saves me havin=
g to=20
install both mingw32 and cygwin.

Although , I only use the mpz,mpn functions , none of the formatted outpu=
t=20
printf type stuff


> > I do not know whether this is a gmp or a Core problem but I suspect t=
hat
> > I am having this problem with gmp.
>
> Are you running the gmp configure or does the Core stuff do so?  If
> the latter then the problem is probably down to it.
>
>
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss@swox.com
> https://gmplib.org/mailman/listinfo/gmp-discuss




From J.L.Moxham@maths.soton.ac.uk  Sat Nov  2 02:52:30 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Sat, 2 Nov 2002 02:52:30 +0000
Subject: whats happening ?
In-Reply-To: <878z0qggp5.fsf@zip.com.au>
References: <200210220026.30226.J.L.Moxham@maths.soton.ac.uk> <878z0qggp5.fsf@zip.com.au>
Message-ID: <200211020252.30096.J.L.Moxham@maths.soton.ac.uk>

On Wednesday 23 Oct 2002 1:08 am, Kevin Ryde wrote:
> Jason Moxham <J.L.Moxham@maths.soton.ac.uk> writes:
> > mpz_rootexact (like mpz_divexact but for roots)  using varible precis=
ion
> > , division free p-adic newton method
>
> Not sure if there'd be much direct use for that.  When would one know
> a number is an exact power?
>

I have come across it a few times , but nothing springs to mind . If the=20
p-adics are faster (than real newton iterations)(and they should be) for=20
perfect_power testing then we can get the mpz_rootexact for free.

> > mpz_perfect_power_p using parts of the above fn's
>
> If it finds a use there then it'd be fine.
>
> > mpz_invert_2exp (like mpz_invert but 2^n modulas) again using above
> > p-adics
>

again this fn would come for free from a p-adic perfect power testing fn =
,=20
although I don't know of any uses besides redc-init

> I looked at that as part of the redc, since it wants such an inverse.
> The function would match mpz_invert nicely, but again I'm not sure
> quite how much use it would get.
>
> Paul Z had some ideas about efficiency which I've (still) yet to look
> at properly.  Efficiency isn't a big deal for the prospective mpm
> since the inverse is calculated just once at the start.
>

interesting , they could be usefull for the p-adic perfect power test






From user42@zip.com.au  Sat Nov  2 00:00:07 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Sat, 02 Nov 2002 10:00:07 +1000
Subject: mpz_sizeinbase and mpz_root
In-Reply-To: <200211012202.17340.J.L.Moxham@maths.soton.ac.uk> (Jason
 Moxham's message of "Fri, 1 Nov 2002 22:02:17 +0000")
References: <200211012202.17340.J.L.Moxham@maths.soton.ac.uk>
Message-ID: <87k7jwj0xk.fsf@zip.com.au>

Jason Moxham <J.L.Moxham@maths.soton.ac.uk> writes:
>
> int mpz_root (mpz_t x , mpz_t y , unsigned long k ) when k=2 does not call the 
> sqrt fn's  which are much faster than general k'th root , I suppose this 
> could be added as small patch , if it was thought that the case k=2 is common 
> enough ?

The general rule is that if an application expects a special case like
that very often it should call mpz_sqrt directly.  But a root like
this is pretty slow anyway so maybe a test could be justified.

> same comment for mpz_sizeinbase(mpz_t x, unsigned long k) when k=2
> by using count_leading_zeros and not the bases[] tables , I was suprised that 
> it was that much faster  , in the current code we have an useless division by 
> 1 , which the compiler doesn't recognize. The case k=2 must be fairly common 
> as it can be used for log_base2 .

If you mean mpz_sizeinbase(x,2) from an application, that can be
recognised for gcc, but not otherwise.

If you mean internally to mpz_sizeinbase, well perhaps an inverse for
the divisor would help, sometimes, if we could be bothered setting
that up.



From tege@swox.com  Mon Nov  4 14:49:44 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 04 Nov 2002 15:49:44 +0100
Subject: mpz_sizeinbase
In-Reply-To: <87fzulj8gh.fsf@zip.com.au>
References: <20021028201737.582.qmail@web20101.mail.yahoo.com>
 <87fzulj8gh.fsf@zip.com.au>
Message-ID: <86vg3dgzjr.fsf@king.swox.se>

  > Now, suppose the return value of mpz_sizeinbase(op, base) is
  > numdigs and I want to know the *exact* number of digits. The most
  > straightforward way is to compare op with base^(numdigs-1) and
  > then reduce numdigs by 1 if op is less than base^(numdigs-1). Is
  > there a better way?

  Not that I know of.

One could compute t=approx(base^n/2^m), where n is initially
chosen to a suitable value less than returned mpz_sizeinbase(op,
base).  During the computation of base^n, low limbs should be
truncated gradually,

Then, we compute op/t and op/(t+1) and convert these small number
to to base.  If they are the same number of digits, we're done.
Else, decrease m and try again...

On average, this should be very fast.

  > By the way, is it too expensive to *always* return the exact
  > number of digits when base is not 2 ?

  It already does so. :-) (And it always did I think, but it's
  has only recently been documented.)

No, the results are exact just for powers of 2.

--
Torbjörn



From gary@leads-west.com  Mon Nov  4 11:50:59 2002
From: gary@leads-west.com (Gary Bobel)
Date: Mon, 04 Nov 2002 11:50:59
Subject: Excess Mortgage Leads
Message-ID: <20021104195112.27BB523BB@b.swox.se>

Guys,

After 11 years in the business, we are running into an excess of mortgage leads.  An because of this I can sell them to you as low as $18 each, depending on what you can take.

Please call me.

voice: 702-334-2157
fax: 702-920-8874
gary@leads-west.com

if you have recieved this email in error, please send blank email to remove@leads-west.com. ;-)



From user42@zip.com.au  Mon Nov  4 22:08:54 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Tue, 05 Nov 2002 08:08:54 +1000
Subject: mpz_sizeinbase
In-Reply-To: <86vg3dgzjr.fsf@king.swox.se> (Torbjorn Granlund's message of
 "04 Nov 2002 15:49:44 +0100")
References: <20021028201737.582.qmail@web20101.mail.yahoo.com>
 <87fzulj8gh.fsf@zip.com.au> <86vg3dgzjr.fsf@king.swox.se>
Message-ID: <873cqhdm2x.fsf@zip.com.au>

Torbjorn Granlund <tege@swox.com> writes:
>
> No, the results are exact just for powers of 2.

Oops, I misread the question (answered about powers of 2).



From user42@zip.com.au  Mon Nov  4 22:21:45 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Tue, 05 Nov 2002 08:21:45 +1000
Subject: logarthim
References: <92456F6B84D1324C943905BEEAE0278E0134127F@RED-MSG-10.redmond.corp.microsoft.com>
 <001d01c27fc7$838758a0$5e4c5685@math.metrou.ac.jp>
Message-ID: <87pttlc6x2.fsf@zip.com.au>

"Hatem  Bahig" <hatem@comp.metro-u.ac.jp> writes:
>
> Unfortunately, I tried to use this concept "cast", but I didn't sucess. 

mpf_get_d can be used for such a conversion.

> Is there a function to calculate log for floating nu.?

Not in gmp currently.  But mpfr has mpfr_log2 (and others), see
www.mpfr.org.



From bagnara@cs.unipr.it  Tue Nov  5 14:18:46 2002
From: bagnara@cs.unipr.it (Roberto Bagnara)
Date: Tue, 05 Nov 2002 15:18:46 +0100
Subject: Problem (with fix) concerning GMP's C++ random number class
Message-ID: <3DC7D346.1050001@cs.unipr.it>

If you take the following code, that comes straight
from the manual of GMP 4.1, and try to compile it with
a strictly conforming C++ compiler, you will see that
it does not compile.

---------------------------------------------
#include <gmpxx.h>

void foo() {
   gmp_randclass rg(gmp_randinit_default);
}
---------------------------------------------

The reason is that, while the constructors for `gmp_randclass'
have all been declared to take a C++ function pointer, the
invocation above passes a C function pointer.  This is not allowed
by the C++ standard.  One possibility to rectify things is the patch
below, which changes the declarations of the constructors.
Of course, the dual change is also possible, the point being
that C linkage and C++ linkage are incompatible.
All the best

      Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it


*** /usr/local/distrib/gmp-4.1/gmpxx.h	2002-05-08 01:09:50.000000000 +0200
--- gmpxx.h	2002-11-05 15:03:05.000000000 +0100
***************
*** 4968,4973 ****
--- 4968,4981 ----
     }
   };

+ extern "C" typedef void GMP_RANDINIT_DEFAULT(gmp_randstate_t);
+ extern "C" typedef void GMP_RANDINIT_LC_2EXP(gmp_randstate_t,
+ 					     mpz_srcptr,
+ 					     unsigned long int,
+ 					     unsigned long int);
+ extern "C" typedef void GMP_RANDINIT_LC_2EXP_SIZE(gmp_randstate_t,
+ 						  unsigned long int);
+
   class gmp_randclass
   {
   private:
***************
*** 4988,5004 ****
     }

     // gmp_randinit_default
!   gmp_randclass(void (*f)(gmp_randstate_t))
     { f(state); }

     // gmp_randinit_lc_2exp
!   gmp_randclass(void (*f)(gmp_randstate_t, mpz_srcptr,
! 			  unsigned long int, unsigned long int),
   		mpz_class z, unsigned long int l1, unsigned long int l2)
     { f(state, z.get_mpz_t(), l1, l2); }

     // gmp_randinit_lc_2exp_size
!   gmp_randclass(int (*f)(gmp_randstate_t, unsigned long int),
   		unsigned long int size)
     { f(state, size); }

--- 4996,5011 ----
     }

     // gmp_randinit_default
!   gmp_randclass(GMP_RANDINIT_DEFAULT* f)
     { f(state); }

     // gmp_randinit_lc_2exp
!   gmp_randclass(GMP_RANDINIT_LC_2EXP* f,
   		mpz_class z, unsigned long int l1, unsigned long int l2)
     { f(state, z.get_mpz_t(), l1, l2); }

     // gmp_randinit_lc_2exp_size
!   gmp_randclass(GMP_RANDINIT_LC_2EXP_SIZE* f,
   		unsigned long int size)
     { f(state, size); }





From J.L.Moxham@maths.soton.ac.uk  Wed Nov  6 20:59:06 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Wed, 6 Nov 2002 20:59:06 +0000
Subject: gmp prime testing
In-Reply-To: <nn1y5yk4z5.fsf@fafner.lysator.liu.se>
References: <8765vr76ov.fsf@zip.com.au> <864raxif4t.fsf@king.swox.se> <nn1y5yk4z5.fsf@fafner.lysator.liu.se>
Message-ID: <200211062059.06942.J.L.Moxham@maths.soton.ac.uk>

On Wednesday 06 Nov 2002 5:01 pm, Niels M=F6ller wrote:
> Torbjorn Granlund <tege@swox.com> writes:
> >   > > ul=09mpz_trial_div(mpz_srcptr N , ul start , ul stop)
> >   >
> >   > Sounds fair to me, if Torbjorn likes it.
> >
> > Might make sense.  What is it supposed to return?
> > Any factor, or 1 (or 0?) if no factor is found.
>
> If any reasonable implementation will compute a factor, I'd say return
> that factor or 0 if none was found. I think the trivial factors, i.e.
> 1 and N, should never be returned.
>
> If it's easy to make some additional guarantees (say, that if ul =3D=3D=
 2,
> then the returned factor will be a multiple of the smallest prime
> factor) then that would be nice too, but I don't know if a
> smallest-primefactor-of function is really useful.
>
> /Niels

The users of GMP should have a say , so this is going to gmp-discuss

I proposed the following user visible function

unsigned long mpz_trial_div(mpz_srcptr N , unsigned long start , unsigned=
 long=20
stop)

Precondition is that N has no divisors less than start (excude 1)

mpz_trial_div returns the smallest prime divisor of N that is greater tha=
n or=20
equal to start and less than or equal to stop.If there does not exist a=20
divisor in this range then 0 is returned.

"Returning the divisors in size order" make this function much easier to =
use =20
than if the divisors were returned out of order. The improvement in speed=
 you=20
get from returning the divisors out of order is not a lot (perhaps <5%). =
The=20
precondition is also not a great restriction , and it enables the functio=
n to=20
guarentee primality.

I already have a effiecent implementation of this , and also a possible=20

unsigned long ui_trial_div(unsigned long N , unsigned long start , unsign=
ed=20
long stop)

Note : In the definition above , and in my implementation , if N <stop^2 =
 or=20
N<stop then the "obvious" optimizations apply . So N can be returned if i=
f=20
fits the exact definition above.

jason






From user42@zip.com.au  Wed Nov  6 22:34:14 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Thu, 07 Nov 2002 08:34:14 +1000
Subject: Problem (with fix) concerning GMP's C++ random number class
In-Reply-To: <3DC7D346.1050001@cs.unipr.it> (Roberto Bagnara's message of
 "Tue, 05 Nov 2002 15:18:46 +0100")
References: <3DC7D346.1050001@cs.unipr.it>
Message-ID: <873cqe72ft.fsf@zip.com.au>

Roberto Bagnara <bagnara@cs.unipr.it> writes:
>
> a strictly conforming C++ compiler,

For instance?  g++ 3.2 -pedantic has no objections to the current
code.

> + extern "C" typedef void GMP_RANDINIT_DEFAULT(gmp_randstate_t);

Can this be private to gmp_randclass, or given within the definitions
of the constructors?  If not then they'll want to be prefixed like
__gmp_randinit_default_t, or some such.



From bagnara@cs.unipr.it  Thu Nov  7 06:25:50 2002
From: bagnara@cs.unipr.it (Roberto Bagnara)
Date: Thu, 07 Nov 2002 07:25:50 +0100
Subject: Problem (with fix) concerning GMP's C++ random number class
References: <3DC7D346.1050001@cs.unipr.it> <873cqe72ft.fsf@zip.com.au>
Message-ID: <3DCA076E.80709@cs.unipr.it>

Kevin Ryde wrote:
> Roberto Bagnara <bagnara@cs.unipr.it> writes:
> 
>>a strictly conforming C++ compiler,
> 
> 
> For instance?  g++ 3.2 -pedantic has no objections to the current
> code.

For instance Comeau C++ compiler with option --strict and (IIRC,
but I don't have it handy at the moment) Intel's icc compiler
with the -Xc option (select strict ANSI C/C++ conformance dialect).
However, the point is that the code I have indicated violates the
standard;  as C++ compiler are moving more and more towards standard
conformance the problem may show up at any time with any compiler.

>>+ extern "C" typedef void GMP_RANDINIT_DEFAULT(gmp_randstate_t);
> 
> 
> Can this be private to gmp_randclass, or given within the definitions
> of the constructors?  If not then they'll want to be prefixed like
> __gmp_randinit_default_t, or some such.

You are right of course (indeed I was expecting Gerardo, as the father,
of the C++ interface, would elaborate on the idea so as to suit his taste).
I will provide a better patch at the soonest (since I really hope it could
be incorporated in the next GMP's release).
All the best

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it




From nisse@lysator.liu.se  Thu Nov  7 11:43:50 2002
From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=)
Date: 07 Nov 2002 12:43:50 +0100
Subject: gmp prime testing
In-Reply-To: <200211062059.06942.J.L.Moxham@maths.soton.ac.uk>
References: <8765vr76ov.fsf@zip.com.au> <864raxif4t.fsf@king.swox.se>
 <nn1y5yk4z5.fsf@fafner.lysator.liu.se>
 <200211062059.06942.J.L.Moxham@maths.soton.ac.uk>
Message-ID: <nnptthiozt.fsf@fafner.lysator.liu.se>

Jason Moxham <J.L.Moxham@maths.soton.ac.uk> writes:

> I proposed the following user visible function
> 
> unsigned long mpz_trial_div(mpz_srcptr N , unsigned long start , unsigned long 
> stop)
> 
> Precondition is that N has no divisors less than start (excude 1)

That's too tough for my taste. It's fine if any guarantees on
returning the smallest prime divisor applies only if there are no
divosors smaller than start, but you should be able to call the
function with random start and end (start <= end), and get a well
defined answer back.

Exactly what you should get, I don't know, but it could be a number
between start and end that divides N, or a muber between start and end
that has some non-trivial factor comon with N. I don't know which is
most useful.

> "Returning the divisors in size order" make this function much easier to use  
> than if the divisors were returned out of order. The improvement in speed you 
> get from returning the divisors out of order is not a lot (perhaps <5%). The 
> precondition is also not a great restriction , and it enables the function to 
> guarentee primality.
> 
> I already have a effiecent implementation of this,

If I understood Torbjörn's concern, he want an implementation to be
able to do things like

  d = gcd(N, start * (start+1) * (start+2))

  if (d != 1)
    /* We have a factor. Done. */
    return something.

The problem is that d is not necessarily prime, so in order to return
the smallest factor you'd need to factorize d. It's small, so it's
probably not much work, but it is work that is totally unnecessary in
many cases, e.g. if all the caller really wants to know is if N is
prime or not.

Is it the facorization of d (or something similar) that give you the
5% slowdown?

That's why I proposed the compromise that the function, under certain
restrictions, should be specified to return a *multiple* of the
smallest factor.

Then callers that only want to know the existence of a factor get the
answer as quickly as possible, and callers that really want the
smallest factor can call some other function to get the smallest
factor of the returned value.

Finally, even my compromise may be too strict, as it rules out
implementations that compute gcd:s like

  d = gcd(N, start * (start + 1) * (end - 1) * end)

> Note : In the definition above , and in my implementation , if N <stop^2  or 
> N<stop then the "obvious" optimizations apply . So N can be returned if if 
> fits the exact definition above.

I'm thinking primarily of primetest applications (that's the only
things I've used trial division for, so far), and then it's quite
useless to return N. So I'd prefer that any "smallest prime factor of
N (in a given set)" is specified as returning either a *non-trivial*
factor of N, i.e. different from 1 and from N, or zero.

Are there any other applications where N is a useful answer?

/Niels



From pleyland@microsoft.com  Fri Nov  8 11:05:27 2002
From: pleyland@microsoft.com (Paul Leyland)
Date: Fri, 8 Nov 2002 03:05:27 -0800
Subject: gmp prime testing
Message-ID: <92456F6B84D1324C943905BEEAE0278E013412B1@RED-MSG-10.redmond.corp.microsoft.com>

> From: Niels M=F6ller [mailto:nisse@lysator.liu.se]=20
> Jason Moxham <J.L.Moxham@maths.soton.ac.uk> writes:
>=20
> > I proposed the following user visible function
> >=20
> > unsigned long mpz_trial_div(mpz_srcptr N , unsigned long=20
> start , unsigned long=20
> > stop)
> >=20
> > Precondition is that N has no divisors less than start (excude 1)
>=20
> That's too tough for my taste. It's fine if any guarantees on

I concur: too restrictive.

> returning the smallest prime divisor applies only if there are no
> divosors smaller than start, but you should be able to call the
> function with random start and end (start <=3D end), and get a well
> defined answer back.

Agreed.

>=20
> Exactly what you should get, I don't know, but it could be a number
> between start and end that divides N, or a muber between start and end
> that has some non-trivial factor comon with N. I don't know which is
> most useful.

I would say that it should return the smallest prime factor of N, if =
any, in the given range, and 0 otherwise.  Note that if N is prime, and =
start <=3D N <=3Dend it should return N.

I would argue that it should have a "unsigned long *expt" argument which =
returns the multiplicity of the factor returned.

> > "Returning the divisors in size order" make this function=20
> > much easier to use than if the divisors were returned out
> > of order. The=20

Strongly agree...

> > precondition is also not a great restriction , and it=20
> > enables the function to guarentee primality.

... mostly for this reason.

> That's why I proposed the compromise that the function, under certain
> restrictions, should be specified to return a *multiple* of the
> smallest factor.
>=20
> Then callers that only want to know the existence of a factor get the
> answer as quickly as possible, and callers that really want the
> smallest factor can call some other function to get the smallest
> factor of the returned value.

Almost all the time when I want to find small factors (and by =
definition, anything that fits into an unsigned long is small) I want =
all the factors, I want them to be prime and I want them in order.  =
Having to write complicated control structures to find them all, test =
for primality and sort them into order is a real PITA.   If I have to go =
to all that trouble, I may just as well code the trial division myself =
and avoid all the complexity.  It's likely to runs faster as well, just =
because I don't have to go through all the post-processing.  The whole =
point of a library is to remove the need to rewrite frequently used =
code.

> I'm thinking primarily of primetest applications (that's the only
> things I've used trial division for, so far), and then it's quite
> useless to return N. So I'd prefer that any "smallest prime factor of
> N (in a given set)" is specified as returning either a *non-trivial*
> factor of N, i.e. different from 1 and from N, or zero.

My application has been almost exclusively integer factorization.  Given =
an integer, or class of integers, I first filter out all the small prime =
factors with trial division, then run a few thousand iterations of =
Pollard rho or squfof.  That flushes out everything up to 8 digits or so =
and I can turn to ECM, QS or NFS as appropriate.  Trial division is a =
good candidate for a library and the other two possibly so.  QS and NFS =
are very likely not candidates.  ECM is borderline but I'd put it =
outside the border.

> Are there any other applications where N is a useful answer?

N, if prime, is useful in the factorization scenario given above.  It =
gives a simple test to see whether factorization is complete.


Paul



From Roseanndc@pancevo.com  Fri Nov  8 09:14:49 2002
From: Roseanndc@pancevo.com (Filomena Capobianco)
Date: Fri, 08 Nov 2002 04:14:49 -0500
Subject: Propel Your Job Future gmp
Message-ID: <ysosgnwdwkkw@pancevo.com>

YOUR DEGREE MAY BE CLOSER THAN YOU THINK
We remove the obstacles that cause adults to abandon hope.
DID YOU KNOW that you could earn your legitimate Associate's, Bachelor's, Master's or even Doctorate degree, utilizing your already existing professional or academic expertise? 

Prepare for the professional advancement you deserve
If you are an adult with a high school diploma and have a minimum of three years of experience in the field you are seeking a degree in, YOU QUALIFY.

As you know, employers continually hire, promote and give raises to new employees that have ZERO skills or experience, just because they have that piece of paper.
Take part in the wealth now!   Within days you can apply for that unreachable job, or show your degree to your employer and demand the raise and promotion that your knowledge and skills deserve.
How does this work?  You graduate without attending classes, or taking a leave of absence from your current job.  You receive you degree based on life and work experience!
The degree earned by our students enables them to qualify for career advancement and personal growth, while breaking down the wall that prevents them from receiving big money.

Degree verification and official transcripts will be provided in writing when requested by employers and others authorized by the graduate. Our college & University transcripts meet the highest academic standards. Our University issues a degree printed on premium diploma paper, bearing an official gold raised college seal.
 
No one is turned down.

Confidentiality assured.

CALL 1-602-230-4252

Call 24 hours a day, 7 days a week, including
Sundays and holidays.


To be taken off our list reply with off as the subject.



From bagnara@cs.unipr.it  Fri Nov  8 14:13:43 2002
From: bagnara@cs.unipr.it (Roberto Bagnara)
Date: Fri, 08 Nov 2002 15:13:43 +0100
Subject: Revised patch fixing a problem with GMP's C++ random number class
References: <3DC7D346.1050001@cs.unipr.it> <873cqe72ft.fsf@zip.com.au>
Message-ID: <3DCBC697.8020305@cs.unipr.it>

Kevin Ryde wrote:
>>+ extern "C" typedef void GMP_RANDINIT_DEFAULT(gmp_randstate_t);
> 
> 
> Can this be private to gmp_randclass, or given within the definitions
> of the constructors?

No, unfortunately it cannot.

> If not then they'll want to be prefixed like
> __gmp_randinit_default_t, or some such.

The patch below implements this idea.
Tested with G++ 3.2, Comeau C/C++ 4.3.0.1
(both with and without --strict) and
Intel(R) C++ Compiler for 32-bit applications, Version 6.0.1,
Build 20020822Z (the latest version, both with and without -Xc).
All the best

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it


*** gmpxx.h.orig	Mon Nov  4 10:00:43 2002
--- gmpxx.h	Fri Nov  8 16:08:23 2002
***************
*** 4968,4973 ****
--- 4968,4981 ----
     }
   };

+ extern "C" typedef void __gmp_randinit_default_t(gmp_randstate_t);
+ extern "C" typedef void __gmp_randinit_lc_2exp_t(gmp_randstate_t,
+ 						 mpz_srcptr,
+ 						 unsigned long int,
+ 						 unsigned long int);
+ extern "C" typedef void __gmp_randinit_lc_2exp_size_t(gmp_randstate_t,
+ 						      unsigned long int);
+
   class gmp_randclass
   {
   private:
***************
*** 4988,5004 ****
     }

     // gmp_randinit_default
!   gmp_randclass(void (*f)(gmp_randstate_t))
     { f(state); }

     // gmp_randinit_lc_2exp
!   gmp_randclass(void (*f)(gmp_randstate_t, mpz_srcptr,
! 			  unsigned long int, unsigned long int),
   		mpz_class z, unsigned long int l1, unsigned long int l2)
     { f(state, z.get_mpz_t(), l1, l2); }

     // gmp_randinit_lc_2exp_size
!   gmp_randclass(int (*f)(gmp_randstate_t, unsigned long int),
   		unsigned long int size)
     { f(state, size); }

--- 4996,5011 ----
     }

     // gmp_randinit_default
!   gmp_randclass(__gmp_randinit_default_t* f)
     { f(state); }

     // gmp_randinit_lc_2exp
!   gmp_randclass(__gmp_randinit_lc_2exp_t* f,
   		mpz_class z, unsigned long int l1, unsigned long int l2)
     { f(state, z.get_mpz_t(), l1, l2); }

     // gmp_randinit_lc_2exp_size
!   gmp_randclass(__gmp_randinit_lc_2exp_size_t* f,
   		unsigned long int size)
     { f(state, size); }





From md6nguyen@yahoo.com  Fri Nov  8 19:37:58 2002
From: md6nguyen@yahoo.com (Minh Nguyen)
Date: Fri, 8 Nov 2002 11:37:58 -0800 (PST)
Subject: mpz_sizeinbase
In-Reply-To: <86vg3dgzjr.fsf@king.swox.se>
Message-ID: <20021108193758.65942.qmail@web20110.mail.yahoo.com>

--0-1416131209-1036784278=:65788
Content-Type: text/plain; charset=us-ascii


 
 Torbjorn Granlund <tege@swox.com> wrote:
> Now, suppose the return value of mpz_sizeinbase(op, base) is
> numdigs and I want to know the *exact* number of digits. The most
> straightforward way is to compare op with base^(numdigs-1) and
> then reduce numdigs by 1 if op is less than base^(numdigs-1). Is
> there a better way?

Not that I know of.

One could compute t=approx(base^n/2^m), where n is initially
chosen to a suitable value less than returned mpz_sizeinbase(op,
base). During the computation of base^n, low limbs should be
truncated gradually,

Then, we compute op/t and op/(t+1) and convert these small number
to to base. If they are the same number of digits, we're done.
Else, decrease m and try again...

On average, this should be very fast.


If it is fast, is there any reason not to put it in mpz_sizeinbase?

Minh



---------------------------------
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
--0-1416131209-1036784278=:65788
Content-Type: text/html; charset=us-ascii

<P>&nbsp;
<P>&nbsp;<B><I>Torbjorn Granlund &lt;tege@swox.com&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>&gt; Now, suppose the return value of mpz_sizeinbase(op, base) is<BR>&gt; numdigs and I want to know the *exact* number of digits. The most<BR>&gt; straightforward way is to compare op with base^(numdigs-1) and<BR>&gt; then reduce numdigs by 1 if op is less than base^(numdigs-1). Is<BR>&gt; there a better way?<BR><BR>Not that I know of.<BR><BR>One could compute t=approx(base^n/2^m), where n is initially<BR>chosen to a suitable value less than returned mpz_sizeinbase(op,<BR>base). During the computation of base^n, low limbs should be<BR>truncated gradually,<BR><BR>Then, we compute op/t and op/(t+1) and convert these small number<BR>to to base. If they are the same number of digits, we're done.<BR>Else, decrease m and try again...<BR><BR>On average, this should be very fast.<BR></P>
<P>If it is fast, is there any reason not to put it in mpz_sizeinbase?</P>
<P>Minh</P></BLOCKQUOTE><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://autos.yahoo.com/">Yahoo! Autos</a> - Get free new car price quotes
--0-1416131209-1036784278=:65788--



From J.L.Moxham@maths.soton.ac.uk  Fri Nov  8 20:05:12 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Fri, 8 Nov 2002 20:05:12 +0000
Subject: mpz_trial_div
Message-ID: <200211082005.12965.J.L.Moxham@maths.soton.ac.uk>

The name of fn mpz_trial_div implies a specific algorithm , which in futu=
re=20
could restrict the optimization possibilitys. Perhaps it should be called=
=20
mpz_find_small_prime_factors ? or some such .

At present my code uses a prime table and/or a wheel to reduce the number=
 of=20
possible divisors and groups these divisors together to increase the spee=
d.=20
So it really is trial division.
I know of two ways to use gcd to increase speed (possibly ?)

1)
After we group together a small number of our trial divisors , then we ta=
ke=20
the gcd of this product (which is small) with N , and see if we get a=20
non-unit gcd. This would still be trial division.

2)
We multiply together lots of trial divisors mod N  and then take GCD with=
 N.
( this may require sub-quadratic gcd) . This is really nothing like trial=
=20
division. It could take the same time to discover that 23 is a divisor th=
an=20
it take to discover 100093 is a divisor.

I have yet to try either of these methods to see if they offer any=20
improvements.


> I proposed the following user visible function
>=20
> unsigned long mpz_trial_div(mpz_srcptr N , unsigned long start , unsign=
ed=20
long=20
> stop)
>=20
> Precondition is that N has no divisors less than start (excude 1)

I originally didn't have this precondition , but added it later to simpli=
fy=20
things. Some reasons why I changed it are

1) With this precondition it is easy to guarentee that the returned divis=
ors=20
are prime , without this precondition , any divisor found may be prime or=
=20
composite and you would still have to run trial_div again to split the=20
returned divisor up further.

2) Without insisting that the returned divisors are prime you can not red=
uce=20
the number of trial divisors by using a prime table.

eg
let N=3D3.5.7.11.(2^31-1)
d=3Dmpz_trial_div(N,1000,10000)
which implies d=3D3.5.7.11=3D1155
so our set of trial divisors must include non-primes

3)
I couldn't think of any situation where this is in any way a serious prob=
lem.


Uses for mpz_trial_div
-------------------------

1)To prove that N has no factor less than 10000
2)To find easy factors of N , before more expensive tests like probable p=
rime=20
tests or factoring
3) to factorize N

Why would anyone want to call mpz_trial_div (as proposed) with random sta=
rt=20
and end ?

When I say the function is undefined , I mean that it returns garbage in =
a=20
resonable time , it does not crash or loop forever , or format you hard d=
isk=20
:) . Technically the answer returned is well defined , just not useful.

consider mpz_divexact which will return garbage with random parameters.

All the uses to which I have put my mpz_trial_div , do not require the=20
divisors in order or to be prime or even what that divisor is. All I have=
=20
needed to know (so far) is that , does a divisor exist or not .

The problem with these GCD methods is that smaller divisors are found no=20
quicker than larger ones . So prove existence or not they are great (assu=
ming=20
they are faster) . But for eliminating common composites before a probabl=
e=20
prime test , they are much slower on average (because small divisors are =
very=20
common)

Perhaps a seperate fn (internal?) for this type of existence of divisors =
fn.
mpz_exist_div(N,start,stop) ?


> I would argue that it should have a "unsigned long *expt" argument whic=
h=20
> returns the multiplicity of the factor returned.

Possible , although I think it is unneccessairy (as we have the mpz fn=20
mpz_remove_ui) , consider

d=3Dmpz_trial_div(N,1,10000);
m=3Dmpz_remove_ui(N,N,d);

to cover the multiplicity case

=46rom Paul
----------------
> Almost all the time when I want to find small factors (and by definitio=
n,=20
>anything that fits into an unsigned long is small) I want all the factor=
s, I=20
>want them to be prime and I want them in order.  Having to write complic=
ated=20
>control structures to find them all, test for primality and sort them in=
to=20
>order is a real PITA.   If I have to go to all that trouble, I may just =
as=20
>well code the trial division myself and avoid all the complexity.  It's=20
>likely to runs faster as well, just because I don't have to go through a=
ll=20
>the post-processing.  The whole point of a library is to remove the need=
 to=20
>rewrite frequently used code.
>
>

I couldn't agree more , What is PITA ?

I don't what to count the number of times I have writen various trial div=
ision=20
routines , because I never had one that was general enough.

mpz_trial_div is also a very low-level fn , perfectly suited to gmp's man=
y cpu=20
optimizations (far more so than mpz_powm , say ) .

>
>> I'm thinking primarily of primetest applications (that's the only
>> things I've used trial division for, so far), and then it's quite
>> useless to return N. So I'd prefer that any "smallest prime factor of
>> N (in a given set)" is specified as returning either a *non-trivial*
>>
>My application has been almost exclusively integer factorization.  Given=
 an=20
>integer, or class of integers, I first filter out all the small prime=20
>factors with trial division, then run a few thousand iterations of Polla=
rd=20
>rho or squfof.  That flushes out everything up to 8 digits or so and I c=
an=20
>turn to ECM, QS or NFS as appropriate.  Trial division is a good candida=
te=20
>for a library and the other two possibly so.  QS and NFS are very likely=
 not=20
>candidates.  ECM is borderline but I'd put it outside the border.
>
>> Are there any other applications where N is a useful answer?
>
>N, if prime, is useful in the factorization scenario given above.  It gi=
ves a=20
>simple test to see whether factorization is complete.
>
>


I hope this answers all your objections ?
If not let me know=20
It was/is the best way I could think of to do this generally

jason




From user42@zip.com.au  Fri Nov  8 20:57:07 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Sat, 09 Nov 2002 06:57:07 +1000
Subject: mpz_sizeinbase
In-Reply-To: <20021108193758.65942.qmail@web20110.mail.yahoo.com> (Minh
 Nguyen's message of "Fri, 8 Nov 2002 11:37:58 -0800 (PST)")
References: <20021108193758.65942.qmail@web20110.mail.yahoo.com>
Message-ID: <87lm43bx0c.fsf@zip.com.au>

Minh Nguyen <md6nguyen@yahoo.com> writes:
>
> If it is fast, is there any reason not to put it in mpz_sizeinbase?

For mpz_get_str (which is where mpz_sizeinbase started) the current
situation is adequate, it makes a pass over the result digits to
convert to ascii and moves them down by one byte at the same time if
that's necessary.



From Jaideep Lamba" <jaideep@student.utdallas.edu  Fri Nov  8 22:55:08 2002
From: Jaideep Lamba" <jaideep@student.utdallas.edu (Jaideep Lamba)
Date: Fri, 8 Nov 2002 16:55:08 -0600
Subject: Doubt
Message-ID: <016401c28779$e2b069c0$ef7a6e81@campus.ad.utdallas.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_0161_01C28747.980509D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Friends,

I have a peculiar doubt. I want to define a bit array but its length is =
so long that it cannot fit into long int. What I want to do is basically =
define a bit array and then be able to access it via mpz_t value. Is it =
possible ?.
If you think there can be a better alternative way to do this, please =
feel free to tell me so.

Thanks,
Jaideep


------=_NextPart_000_0161_01C28747.980509D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear Friends,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have a peculiar doubt. I want to =
define a bit=20
array but its length is so long that it cannot fit into long int. What I =
want to=20
do is basically define a bit array and then be able to access it via =
mpz_t=20
value. Is it possible ?.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If you think there can be a better =
alternative way=20
to do this, please feel free to tell me so.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Jaideep</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0161_01C28747.980509D0--




From Jon F Federhenn" <sales@rockwelldatacorp.com  Sat Nov  9 13:08:20 2002
From: Jon F Federhenn" <sales@rockwelldatacorp.com (Jon F Federhenn)
Date: Sat, 9 Nov 2002 14:08:20 +0100
Subject: Java C++ developers needed in Switzerland
Message-ID: <20021109130928.83D4117EE7@rot13.romab.com>

Hello

I colleague of mine is in need of several Java or C++ developers for a
couple of projects in Switzerland and has asked for 
my help.

With the relaxation of permit issues in CH, he tells me that they will not
require swiss permits to qualify.

He speciafically needs people in the J2EE Corba arena, but is interested
to see any people with a good Java or C++ 
background, especially German speakers.

He may also need some German speaking support (2ND AND 3RD LINE) people
for the project as well.

Please drop me a mail which I will forward to him if of interest.

Kind regards

Jon



From frznclouds@hotmail.com  Sat Nov  9 21:38:21 2002
From: frznclouds@hotmail.com (brandon s)
Date: Sat, 09 Nov 2002 15:38:21 -0600
Subject: (no subject)
Message-ID: <F120h8dKsC4on0YkKlM0000389b@hotmail.com>



How many significant figures can GMP calculate out to?

Larry Smith


_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail




From gmp-discuss@swox.com  Sat Nov  9 22:19:01 2002
From: gmp-discuss@swox.com (Kevin Ryde)
Date: Sun, 10 Nov 2002 08:19:01 +1000
Subject: (no subject)
In-Reply-To: <F120h8dKsC4on0YkKlM0000389b@hotmail.com> ("brandon s"'s
 message of "Sat, 09 Nov 2002 15:38:21 -0600")
References: <F120h8dKsC4on0YkKlM0000389b@hotmail.com>
Message-ID: <87smya5qui.fsf@zip.com.au>

"brandon s" <frznclouds@hotmail.com> writes:
>
> How many significant figures can GMP calculate out to?

Generally you're limited only by available memory and stack space,
meaning in practice many thousands of digits, even millions.



From diegosancheznavarro@hotmail.com  Mon Nov 11 04:59:57 2002
From: diegosancheznavarro@hotmail.com (Diego Sanchez Navarro)
Date: Sun, 10 Nov 2002 23:59:57 -0500
Subject: mpz_invert function
Message-ID: <OE13PEhGD1XyCTr9rf300000c09@hotmail.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01C28915.45BA48F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Greetings everyone.
I am writing a paper investigating different alternatives of calculating =
inverses of large numbers modulo a similarly large number (several =
thousand bits long). I did not find details on the GMP manual about the =
workings of the mpz_invert function. What algorithm does it use? Is =
using it the same as using the mpz_gcdext algorithm to calculate the =
inverse, or is it optimized in any way?
Thank you very much in advance for your help.

Diego S=E1nchez Navarro
diegosancheznavarro@hotmail.com
d.sancheznavarro@umiami.edu

------=_NextPart_000_0021_01C28915.45BA48F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DVerdana size=3D2>Greetings everyone.</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D2>I am writing a paper investigating =
different=20
alternatives of calculating inverses of large numbers modulo a similarly =
large=20
number (several thousand bits long). I did not find details on the GMP =
manual=20
about the workings of the mpz_invert function. What algorithm does it =
use? Is=20
using it the same as using the mpz_gcdext algorithm to calculate the =
inverse, or=20
is it optimized in any way?</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D2>Thank you very much in advance for =
your=20
help.</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D2><BR>Diego S=E1nchez Navarro<BR><A=20
href=3D"mailto:diegosancheznavarro@hotmail.com">diegosancheznavarro@hotma=
il.com</A><BR><A=20
href=3D"mailto:d.sancheznavarro@umiami.edu">d.sancheznavarro@umiami.edu</=
A><BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0021_01C28915.45BA48F0--



From gmp@swox.com  Mon Nov 11 19:08:32 2002
From: gmp@swox.com (Invest your money Right)
Date: Mon, 11 Nov 2002 14:08:32 -0500
Subject: Best Chance to make millions
Message-ID: <200211111908.OAA26950@nachomail.com>


Dear Friends 



From user42@zip.com.au  Mon Nov 11 22:14:57 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Tue, 12 Nov 2002 08:14:57 +1000
Subject: mpz_invert function
In-Reply-To: <OE13PEhGD1XyCTr9rf300000c09@hotmail.com> ("Diego Sanchez
 Navarro"'s message of "Sun, 10 Nov 2002 23:59:57 -0500")
References: <OE13PEhGD1XyCTr9rf300000c09@hotmail.com>
Message-ID: <87isz3ycri.fsf@zip.com.au>

"Diego Sanchez Navarro" <diegosancheznavarro@hotmail.com> writes:
>
> I am writing a paper investigating different alternatives of
> calculating inverses of large numbers modulo a similarly large
> number (several thousand bits long). I did not find details on the
> GMP manual about the workings of the mpz_invert function. What
> algorithm does it use? Is using it the same as using the mpz_gcdext
> algorithm to calculate the inverse,

Yes, there's some notes on that in the algorithms chapter of the
manual.



From diegosancheznavarro@hotmail.com  Tue Nov 12 03:30:03 2002
From: diegosancheznavarro@hotmail.com (Diego Sanchez Navarro)
Date: Mon, 11 Nov 2002 22:30:03 -0500
Subject: mpz_invert function
In-Reply-To: <87isz3ycri.fsf@zip.com.au>
Message-ID: <000c01c289fb$c9c431b0$8601a8c0@kenny>

Thank you very much for your quick response. I found a description of
the inner workings of the mpz_gcdext function, but not of the mpz_invert
function. I derive from your answer that using either function would be
essentially the same, then. Though my tests using the same sample data
show a slightly better performance by the mpz_invert function, this must
probably be due to abnormalities in my testing process.
Regards,
	Diego Sanchez Navarro

-----Mensaje original-----
De: Kevin Ryde [mailto:user42@zip.com.au] 
Enviado el: Monday, November 11, 2002 5:15 PM
Para: gmp-discuss@swox.com
CC: Diego Sanchez Navarro
Asunto: Re: mpz_invert function

"Diego Sanchez Navarro" <diegosancheznavarro@hotmail.com> writes:
>
> I am writing a paper investigating different alternatives of
> calculating inverses of large numbers modulo a similarly large
> number (several thousand bits long). I did not find details on the
> GMP manual about the workings of the mpz_invert function. What
> algorithm does it use? Is using it the same as using the mpz_gcdext
> algorithm to calculate the inverse,

Yes, there's some notes on that in the algorithms chapter of the
manual.



From tege@swox.com  Tue Nov 12 08:39:55 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 12 Nov 2002 09:39:55 +0100
Subject: mpz_invert function
In-Reply-To: <OE13PEhGD1XyCTr9rf300000c09@hotmail.com>
References: <OE13PEhGD1XyCTr9rf300000c09@hotmail.com>
Message-ID: <864ranqizo.fsf@king.swox.se>

"Diego Sanchez Navarro" <diegosancheznavarro@hotmail.com> writes:

  Greetings everyone.

  I am writing a paper investigating different alternatives of
  calculating inverses of large numbers modulo a similarly large
  number (several thousand bits long). I did not find details on the
  GMP manual about the workings of the mpz_invert function. What
  algorithm does it use? Is using it the same as using the mpz_gcdext
  algorithm to calculate the inverse, or is it optimized in any way?
  Thank you very much in advance for your help.

It uses Lehmer's algorithm just like mpz_gcdext.
The execution time is O(n^2).

It saves a little time compared to mpz_gcdext by not
computing both s and t in gcd(u,v) = u*s+v*t.

-- 
Torbjörn



From keith.briggs@bt.com  Tue Nov 12 11:51:35 2002
From: keith.briggs@bt.com (keith.briggs@bt.com)
Date: Tue, 12 Nov 2002 11:51:35 -0000
Subject: mpz_size
Message-ID: <92D69A614ED4924A9071EA488631787833E425@i2km11-ukbr.domain1.systemhost.net>

Dear gmp-discuss,

Does mpz_size count the number of limbs allocated, or used?

Thank you,
Keith

	Dr. Keith M. Briggs
	Senior Mathematician, Complexity Research, BTexact Technologies

	email: Keith.Briggs@bt.com
	phone: +44(0)1473  work: 641 911 home: 610 517  fax: 647 410
        profile:  http://www.btexact.com/ideas/profiles?doc=42493
        web:  (work)     http://more.btexact.com/people/briggsk2/ 
        web:  (private) http://members.lycos.co.uk/keithmbriggs/
	mail: Keith Briggs, Antares 2pp5, Adastral Park, Martlesham, Suffolk
IP5 3RE, UK

	BTexact Technologies is a trademark of British Telecommunications
plc
	Registered office: 81 Newgate Street London EC1A 7AJ
	Registered in England no. 1800000

	This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or email (to the numbers or address above)
immediately.





From user42@zip.com.au  Wed Nov 13 19:51:54 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Thu, 14 Nov 2002 05:51:54 +1000
Subject: mingw __dllexport__
Message-ID: <87fzu5s0x1.fsf@zip.com.au>

For gcc I'm going to change the windows DLL function declarations in
gmp.h from "__declspec(dllexport)" to "__declspec(__dllexport__)", in
order to keep out of what is, strictly speaking, application
namespace.

Does the same or similar work for Microsoft C?  What about Borland C?



From user42@zip.com.au  Wed Nov 13 19:52:56 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Thu, 14 Nov 2002 05:52:56 +1000
Subject: mpz_size
In-Reply-To: <92D69A614ED4924A9071EA488631787833E425@i2km11-ukbr.domain1.systemhost.net> (keith.briggs@bt.com's
 message of "Tue, 12 Nov 2002 11:51:35 -0000")
References: <92D69A614ED4924A9071EA488631787833E425@i2km11-ukbr.domain1.systemhost.net>
Message-ID: <87bs4ts0vb.fsf@zip.com.au>

keith.briggs@bt.com writes:
>
> Does mpz_size count the number of limbs allocated, or used?

Used.



From deltatrinity@hotmail.com  Wed Nov 13 21:44:14 2002
From: deltatrinity@hotmail.com (delta trinity)
Date: Wed, 13 Nov 2002 16:44:14 -0500
Subject: mingw __dllexport__
Message-ID: <F535BQLHbsiofSY2O2Z000005c9@hotmail.com>

Borland C doens't recognize "__declspec(__dllexport__)"
You get:
<<[C++ Error] GMP.H(438): E2494 Unrecognized __declspec modifier>>
for every lines where the declaration is declared.

Maybe a conditional could let it like it already is, for Borland.

Note, Borland also support "__export".
Here is an extract from the Borland help file.

__export void f(void);                      // illegal
void __export f(void)                       // correct
void __declspec(dllexport) f(void);         // correct
__declspec(dllexport)void f(void);          // correct
class __declspec(dllexport) ClassName { }   // correct

I don't know if this answer the question or if this help...

>From: Kevin Ryde <user42@zip.com.au>
>To: gmp-discuss@swox.com
>Subject: mingw __dllexport__
>Date: Thu, 14 Nov 2002 05:51:54 +1000
>
>For gcc I'm going to change the windows DLL function declarations in
>gmp.h from "__declspec(dllexport)" to "__declspec(__dllexport__)", in
>order to keep out of what is, strictly speaking, application
>namespace.
>
>Does the same or similar work for Microsoft C?  What about Borland C?
>
>
>_______________________________________________
>gmp-discuss mailing list
>gmp-discuss@swox.com
>https://gmplib.org/mailman/listinfo/gmp-discuss


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail




From user42@zip.com.au  Wed Nov 13 22:02:23 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Thu, 14 Nov 2002 08:02:23 +1000
Subject: mingw __dllexport__
In-Reply-To: <F535BQLHbsiofSY2O2Z000005c9@hotmail.com> ("delta trinity"'s
 message of "Wed, 13 Nov 2002 16:44:14 -0500")
References: <F535BQLHbsiofSY2O2Z000005c9@hotmail.com>
Message-ID: <87isz1qgb4.fsf@zip.com.au>

"delta trinity" <deltatrinity@hotmail.com> writes:
>
> Maybe a conditional could let it like it already is, for Borland.

Yep.

> Note, Borland also support "__export".

Should move to that at some stage I guess.

> __export void f(void);                      // illegal
> void __export f(void)                       // correct

Have to change the way __GMP_DECLSPEC is arranged.

Does a global pointer variable look like

	extern const char * __export gmp_version;
?



From deltatrinity@hotmail.com  Thu Nov 14 01:03:58 2002
From: deltatrinity@hotmail.com (delta trinity)
Date: Wed, 13 Nov 2002 20:03:58 -0500
Subject: mingw __dllexport__
Message-ID: <F111Hd9ZO8jR5zt60Or000083b0@hotmail.com>

In Borland, just typing

extern const char * gmp_version;

work.

Although, the version you typed also work.

I don't know which one is prefferable or if there's side effect or 
limitations to the first or second form.

The external constant have to be defined in another module.  For DLL, I 
assume it have to be defined in the export table of the dll.


>From: Kevin Ryde <user42@zip.com.au>
>To: gmp-discuss@swox.com
>Subject: Re: mingw __dllexport__
>Date: Thu, 14 Nov 2002 08:02:23 +1000
>
>"delta trinity" <deltatrinity@hotmail.com> writes:
> >
> > Maybe a conditional could let it like it already is, for Borland.
>
>Yep.
>
> > Note, Borland also support "__export".
>
>Should move to that at some stage I guess.
>
> > __export void f(void);                      // illegal
> > void __export f(void)                       // correct
>
>Have to change the way __GMP_DECLSPEC is arranged.
>
>Does a global pointer variable look like
>
>	extern const char * __export gmp_version;
>?
>
>
>_______________________________________________
>gmp-discuss mailing list
>gmp-discuss@swox.com
>https://gmplib.org/mailman/listinfo/gmp-discuss


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus




From Jaideep Lamba" <jaideep@student.utdallas.edu  Thu Nov 14 04:28:59 2002
From: Jaideep Lamba" <jaideep@student.utdallas.edu (Jaideep Lamba)
Date: Wed, 13 Nov 2002 22:28:59 -0600
Subject: Factors
Message-ID: <001f01c28b96$5a5461f0$ef7a6e81@campus.ad.utdallas.edu>

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01C28B64.0FAC3650
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Readers,

I am interested in implementation of various factor finding algorithms. =
May I request to please redirect me to papers / sources where I can find =
the best factor finding algorithm for large numbers and their time =
complexity.

Thanks,
Jaideep

------=_NextPart_000_001C_01C28B64.0FAC3650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear Readers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am interested in implementation of =
various factor=20
finding algorithms. May I request to please redirect me to papers / =
sources=20
where I can find the best factor finding algorithm for large numbers and =
their=20
time complexity.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Jaideep</FONT></DIV></BODY></HTML>

------=_NextPart_000_001C_01C28B64.0FAC3650--




From hamdy@math.ucalgary.ca  Thu Nov 14 06:08:24 2002
From: hamdy@math.ucalgary.ca (Safuat Hamdy)
Date: Wed, 13 Nov 2002 22:08:24 -0800
Subject: Factors
In-Reply-To: <001f01c28b96$5a5461f0$ef7a6e81@campus.ad.utdallas.edu>
References: <001f01c28b96$5a5461f0$ef7a6e81@campus.ad.utdallas.edu>
Message-ID: <200211132208.33364.hamdy@math.ucalgary.ca>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 13 November 2002 20:28, Jaideep Lamba wrote:
> Dear Readers,
>
> I am interested in implementation of various factor finding algorithms.=
 May
> I request to please redirect me to papers / sources where I can find th=
e
> best factor finding algorithm for large numbers and their time complexi=
ty.

<FLAMES>
Your request is actually an impudence.  Searching google would give you=20
probably more answers than asking innocent and busy readers.
</FLAMES>

Having said this, you should go and obtain the following book

R.Crandall, C.Pomerance: Prime Numbers --- A Computational Perspective,=20
Springer Verlag

This book is fairly well written and reveals a lot of internal details of=
=20
various factoring algorithms.  Since you ask your question so naively, I=20
would discourage you strongly from going to real research papers, for thi=
s=20
matter is really not trivial and requires knowledge on algebraic and anal=
ytic=20
number theory in order to get all the details.

As for ready to go implementations, try Paul Zimmermanns ECM-Implementati=
ons=20
(exercise: use google or whatever to find it on the web), my own libiq co=
mes=20
with a Schnorr-Lenstra factorizer, LiDIA contains ECM, p-1, p+1, as well =
as=20
the MPQS (LiDIA's code is not suitable for learning algorithms, though), =
and=20
other readers such as Paul Leyland might give you pointers to NFS=20
implementations.


Best

- --=20

S. Hamdy                                |  All primes are odd except 2,
Dept. of Mathematics & Statistics       |  which is the oddest of all.
University of Calgary                   |
                                        |
unsolicited commercial e-mail           |
is strictly not welcome                 |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE90z3fwjuT2UdHuKURAk2aAJ9X0D2TjcM1DUE1IHPxxS8AG9tKZgCgi1mB
+iP3cWEI1aKxwOboTKM3yuI=3D
=3D2IJz
-----END PGP SIGNATURE-----



From dtashley@esrg.org  Thu Nov 14 05:11:48 2002
From: dtashley@esrg.org (David T. Ashley)
Date: Thu, 14 Nov 2002 00:11:48 -0500
Subject: Factors
In-Reply-To: <200211132208.33364.hamdy@math.ucalgary.ca>
Message-ID: <HFEIIMEHDLLIFKBFOAJLCENBCBAA.dtashley@esrg.org>

Also, if you run into notions you don't understand, try Wolfram's Mathworld,
i.e. for the definition of a prime number, try:

http://mathworld.wolfram.com/PrimeNumber.html

You might also pick up the Penguin Dictionary Of Mathematics.

Happy studying!

Dave.

> -----Original Message-----
> From: gmp-discuss-admin@swox.com [mailto:gmp-discuss-admin@swox.com]On
> Behalf Of Safuat Hamdy
> Sent: Thursday, November 14, 2002 1:08 AM
> To: gmp-discuss@swox.com
> Subject: Re: Factors
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 13 November 2002 20:28, Jaideep Lamba wrote:
> > Dear Readers,
> >
> > I am interested in implementation of various factor finding
> algorithms. May
> > I request to please redirect me to papers / sources where I can find the
> > best factor finding algorithm for large numbers and their time
> complexity.
>
> <FLAMES>
> Your request is actually an impudence.  Searching google would give you
> probably more answers than asking innocent and busy readers.
> </FLAMES>
>
> Having said this, you should go and obtain the following book
>
> R.Crandall, C.Pomerance: Prime Numbers --- A Computational Perspective,
> Springer Verlag
>
> This book is fairly well written and reveals a lot of internal details of
> various factoring algorithms.  Since you ask your question so naively, I
> would discourage you strongly from going to real research papers,
> for this
> matter is really not trivial and requires knowledge on algebraic
> and analytic
> number theory in order to get all the details.
>
> As for ready to go implementations, try Paul Zimmermanns
> ECM-Implementations
> (exercise: use google or whatever to find it on the web), my own
> libiq comes
> with a Schnorr-Lenstra factorizer, LiDIA contains ECM, p-1, p+1,
> as well as
> the MPQS (LiDIA's code is not suitable for learning algorithms,
> though), and
> other readers such as Paul Leyland might give you pointers to NFS
> implementations.
>
>
> Best
>
> - --
>
> S. Hamdy                                |  All primes are odd except 2,
> Dept. of Mathematics & Statistics       |  which is the oddest of all.
> University of Calgary                   |
>                                         |
> unsolicited commercial e-mail           |
> is strictly not welcome                 |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE90z3fwjuT2UdHuKURAk2aAJ9X0D2TjcM1DUE1IHPxxS8AG9tKZgCgi1mB
> +iP3cWEI1aKxwOboTKM3yuI=
> =2IJz
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss@swox.com
> https://gmplib.org/mailman/listinfo/gmp-discuss
>
>
>




From bagnara@cs.unipr.it  Thu Nov 14 06:21:09 2002
From: bagnara@cs.unipr.it (Roberto Bagnara)
Date: Thu, 14 Nov 2002 07:21:09 +0100
Subject: Reserved names in C++ [Was: Re: mingw __dllexport__]
References: <F535BQLHbsiofSY2O2Z000005c9@hotmail.com> <87isz1qgb4.fsf@zip.com.au>
Message-ID: <3DD340D5.8070208@cs.unipr.it>

Kevin Ryde wrote:
> Have to change the way __GMP_DECLSPEC is arranged.

I don't know if strict conformance to standards is one of GMP's goals.
If it is, it would be better to avoid using names that are reserved
to the language's implementation.  I enclose below an excerpt from the
C++ standard.
All the best

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it


17.4.3.1.2 Global names                           [lib.global.names]

  1 Certain sets of names and function signatures are always reserved
    to the implementation:

   - Each name that contains a double underscore (__) or begins with
     an underscore followed by an upper-case letter (2.11) is reserved
     to the implementation for any use.
   - Each name that begins with an underscore is reserved to the
     implementation for use as a name in the global namespace. 165)

-------- Footnotes
165) Such names are also reserved in namespace ::std (17.4.3.1).




From pleyland@microsoft.com  Thu Nov 14 11:20:49 2002
From: pleyland@microsoft.com (Paul Leyland)
Date: Thu, 14 Nov 2002 03:20:49 -0800
Subject: Factors
Message-ID: <92456F6B84D1324C943905BEEAE0278E013412BA@RED-MSG-10.redmond.corp.microsoft.com>

> From: Safuat Hamdy [mailto:hamdy@math.ucalgary.ca]=20

> On Wednesday 13 November 2002 20:28, Jaideep Lamba wrote:

>> I am interested in implementation of various factor finding=20
>> algorithms. May I request to please redirect me to papers /
>> sources where I can find the best factor finding algorithm
>> for large numbers and their time complexity.

> Having said this, you should go and obtain the following book
>=20
> R.Crandall, C.Pomerance: Prime Numbers --- A Computational=20
> Perspective,=20
> Springer Verlag

I also recommend Riesel's book --- full publication details deliberately =
omitted.  If you can't be bothered to search amazon.com, you're probably =
not that interested anyway ;-)

> As for ready to go implementations, try Paul Zimmermanns=20
> ECM-Implementations (exercise: use google or whatever to find
> it on the web), my own libiq comes with a Schnorr-Lenstra
> factorizer,

Thanks Safuat, I wasn't aware of that resource.  I will go chase it.

> LiDIA contains ECM, p-1, p+1, as well as=20
> the MPQS (LiDIA's code is not suitable for learning=20
> algorithms, though), and other readers such as Paul Leyland
> might give you pointers to NFS implementations.

Indeed, and thanks for the opportunity to plug http://www.nfsnet.org.  =
Don Leclair, Richard Wackerbarth and I are re-implementing a distributed =
NFS engine.  We're still at the beta-test stage so things are *very* =
rough around the edges but we've code that works well enough to complete =
a SNFS factorization of Woodall(668), which is a number with 204 digits, =
and have started 6^257-1.

For personal use (i.e. if you don't want to run a massive distributed =
computation) I found the NFSX packacke for UBASIC quite effective.  It's =
really only suitable for SNFS on numbers up to 120 digits, say, and then =
only if you can find an odd-degree poynomial (the sqrt algorithm =
employed doesn't allow even-degree polynomials).  Take a look in =
ftp://rkmath.rikkyo.ac.jp./pub/ubtest/ for the distribution.


I apologise for my contribution having essentially nothing to do with =
GMP per se.  Nonetheless, I hope that some list members find it useful.


Paul



From pleyland@microsoft.com  Thu Nov 14 11:48:20 2002
From: pleyland@microsoft.com (Paul Leyland)
Date: Thu, 14 Nov 2002 03:48:20 -0800
Subject: mpz_trial_div
Message-ID: <92456F6B84D1324C943905BEEAE0278E013412BB@RED-MSG-10.redmond.corp.microsoft.com>

> From: Jason Moxham [mailto:J.L.Moxham@maths.soton.ac.uk]=20

Many lines of goood stuff deleted.

Quoting me:=20

>> I would argue that it should have a "unsigned long *expt"=20
>> argument which returns the multiplicity of the factor
>> returned.
>=20
> Possible , although I think it is unneccessairy (as we have=20
> the mpz fn mpz_remove_ui) , consider
>=20
> d=3Dmpz_trial_div(N,1,10000);
> m=3Dmpz_remove_ui(N,N,d);
>=20
> to cover the multiplicity case

Fair point.  Thanks.

> From Paul
> ----------------
...
>> order is a real PITA.   If I have to go to all that trouble,=20
>> I may just as well code the trial division myself and avoid
>> all the complexity.  It's likely to runs faster as well,
>> just because I don't have to go through all the post-processing.
>> The whole point of a library is to remove the need to=20
>> rewrite frequently used code.
=20
> I couldn't agree more , What is PITA ?

Sorry.  I thought it was a reasonably well-known acronym for acute
rectal discomfort.

> I hope this answers all your objections ?

I believe so.


Paul



From tege@swox.com  Thu Nov 14 15:32:29 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 14 Nov 2002 16:32:29 +0100
Subject: mpz_trial_div
In-Reply-To: <92456F6B84D1324C943905BEEAE0278E013412BB@RED-MSG-10.redmond.corp.microsoft.com>
References: <92456F6B84D1324C943905BEEAE0278E013412BB@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <86bs4s88vm.fsf@king.swox.se>

"Paul Leyland" <pleyland@microsoft.com> writes:

  > Possible , although I think it is unneccessairy (as we have 
  > the mpz fn mpz_remove_ui) , consider
  > 
  > d=mpz_trial_div(N,1,10000);
  > m=mpz_remove_ui(N,N,d);
  > 
  > to cover the multiplicity case
  
  Fair point.  Thanks.

Not sure that would work.  Assume our number has the factor 3^2*5.
mpz_trial_div might find 3*5 and return that.  mpz_remove_ui
would then typically leave one factor 3.

Since some usages of mpz_trial_div will only care if any factor is
found, we don't want to slow it down by having it figure out any
factor multiplicity.

-- 
Torbjörn



From pleyland@microsoft.com  Thu Nov 14 15:58:38 2002
From: pleyland@microsoft.com (Paul Leyland)
Date: Thu, 14 Nov 2002 07:58:38 -0800
Subject: mpz_trial_div
Message-ID: <92456F6B84D1324C943905BEEAE0278E013C26CF@RED-MSG-10.redmond.corp.microsoft.com>

> From: Torbjorn Granlund [mailto:tege@swox.com]=20
> "Paul Leyland" <pleyland@microsoft.com> writes:
>=20
>   > Possible , although I think it is unneccessairy (as we have=20
>   > the mpz fn mpz_remove_ui) , consider
>   >=20
>   > d=3Dmpz_trial_div(N,1,10000);
>   > m=3Dmpz_remove_ui(N,N,d);
>   >=20
>   > to cover the multiplicity case
>  =20
>   Fair point.  Thanks.
>=20
> Not sure that would work.  Assume our number has the factor 3^2*5.
> mpz_trial_div might find 3*5 and return that.  mpz_remove_ui
> would then typically leave one factor 3.
>=20
> Since some usages of mpz_trial_div will only care if any factor is
> found, we don't want to slow it down by having it figure out any
> factor multiplicity.

I thought we'd agreed, wrongly it appears, that mpz_trial_div would =
return only prime factors and would always return the smallest such =
(perhaps in the range start--end if those arguments are present).


Paul



From tege@swox.com  Thu Nov 14 16:12:22 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 14 Nov 2002 17:12:22 +0100
Subject: mpz_trial_div
In-Reply-To: <92456F6B84D1324C943905BEEAE0278E013C26CF@RED-MSG-10.redmond.corp.microsoft.com>
References: <92456F6B84D1324C943905BEEAE0278E013C26CF@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <86wung6sgp.fsf@king.swox.se>

"Paul Leyland" <pleyland@microsoft.com> writes:

  > From: Torbjorn Granlund [mailto:tege@swox.com] 
  > "Paul Leyland" <pleyland@microsoft.com> writes:
  > 
  >   > Possible , although I think it is unneccessairy (as we have 
  >   > the mpz fn mpz_remove_ui) , consider
  >   > 
  >   > d=mpz_trial_div(N,1,10000);
  >   > m=mpz_remove_ui(N,N,d);
  >   > 
  >   > to cover the multiplicity case
  >   
  >   Fair point.  Thanks.
  > 
  > Not sure that would work.  Assume our number has the factor 3^2*5.
  > mpz_trial_div might find 3*5 and return that.  mpz_remove_ui
  > would then typically leave one factor 3.
  > 
  > Since some usages of mpz_trial_div will only care if any factor is
  > found, we don't want to slow it down by having it figure out any
  > factor multiplicity.
  
  I thought we'd agreed, wrongly it appears, that mpz_trial_div would
  return only prime factors and would always return the smallest such
  (perhaps in the range start--end if those arguments are present).

I haven't yet had time to read all messages in this thread (so I
suppose I should actually keep quiet...).

Is returning just prime factors worth making it slower?
I wrote code for this, for GMP 4.2, about half a year ago
(not yet committed to the cvs repo).

I found that accumulating groups of divisors mod m before
trying trial division (by means of gcd) was an efficient way
of implementing mpz_trial_div.  But of course we may return
non-prime factors.

-- 
Torbjörn



From J.L.Moxham@maths.soton.ac.uk  Thu Nov 14 16:14:16 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Thu, 14 Nov 2002 16:14:16 +0000
Subject: mpz_trial_div
In-Reply-To: <92456F6B84D1324C943905BEEAE0278E013C26CF@RED-MSG-10.redmond.corp.microsoft.com>
References: <92456F6B84D1324C943905BEEAE0278E013C26CF@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <200211141614.16694.J.L.Moxham@maths.soton.ac.uk>

On Thursday 14 Nov 2002 3:58 pm, Paul Leyland wrote:
> > From: Torbjorn Granlund [mailto:tege@swox.com]
> >
> > "Paul Leyland" <pleyland@microsoft.com> writes:
> >   > Possible , although I think it is unneccessairy (as we have
> >   > the mpz fn mpz_remove_ui) , consider
> >   >
> >   > d=3Dmpz_trial_div(N,1,10000);
> >   > m=3Dmpz_remove_ui(N,N,d);
> >   >
> >   > to cover the multiplicity case
> >
> >   Fair point.  Thanks.
> >
> > Not sure that would work.  Assume our number has the factor 3^2*5.
> > mpz_trial_div might find 3*5 and return that.  mpz_remove_ui
> > would then typically leave one factor 3.
> >
> > Since some usages of mpz_trial_div will only care if any factor is
> > found, we don't want to slow it down by having it figure out any
> > factor multiplicity.
>
> I thought we'd agreed, wrongly it appears, that mpz_trial_div would ret=
urn
> only prime factors and would always return the smallest such (perhaps i=
n
> the range start--end if those arguments are present).
>
>

if mpz_trial_div can return 3*5 say , then it gets very complicated (and =
SLOW)=20
, see my previous email on it , I recomend only returning prime factors i=
n=20
order .







From pleyland@microsoft.com  Thu Nov 14 16:44:55 2002
From: pleyland@microsoft.com (Paul Leyland)
Date: Thu, 14 Nov 2002 08:44:55 -0800
Subject: mpz_trial_div
Message-ID: <92456F6B84D1324C943905BEEAE0278E013C26D0@RED-MSG-10.redmond.corp.microsoft.com>

> From: Jason Moxham [mailto:J.L.Moxham@maths.soton.ac.uk]=20
...
> > > Not sure that would work.  Assume our number has the factor 3^2*5.
> > > mpz_trial_div might find 3*5 and return that.  mpz_remove_ui
> > > would then typically leave one factor 3.
> > >
> > > Since some usages of mpz_trial_div will only care if any factor is
> > > found, we don't want to slow it down by having it figure out any
> > > factor multiplicity.
> >
> > I thought we'd agreed, wrongly it appears, that mpz_trial_div would
> > return only prime factors and would always return the smallest=20
> > such (perhaps in the range start--end if those arguments are =
present).
>=20
> if mpz_trial_div can return 3*5 say , then it gets very=20
> complicated (and SLOW), see my previous email on it , I
> recomend only returning prime factors in order .

Strongly agree.   If it really does turn out to be much faster to return =
composite factors, then please provide an interface that does return =
them prime and in order.  Whether that's another function or a flag =
argument to a single function doesn't much matter --- testing a flag =
surely doesn't take long compared with a gcd.


Paul



From nisse@lysator.liu.se  Thu Nov 14 19:49:48 2002
From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=)
Date: 14 Nov 2002 20:49:48 +0100
Subject: mpz_trial_div
In-Reply-To: <200211141614.16694.J.L.Moxham@maths.soton.ac.uk>
References: <92456F6B84D1324C943905BEEAE0278E013C26CF@RED-MSG-10.redmond.corp.microsoft.com>
 <200211141614.16694.J.L.Moxham@maths.soton.ac.uk>
Message-ID: <nnfzu4exsz.fsf@fafner.lysator.liu.se>

Jason Moxham <J.L.Moxham@maths.soton.ac.uk> writes:

> if mpz_trial_div can return 3*5 say , then it gets very complicated
> (and SLOW) , see my previous email on it , I recomend only returning
> prime factors in order .

I'm not sure what it is that will be slow. There are several ways to
use the small trial division function:

1. Testing if a number has a small factor. Here's 3*5 is a perfectly
   good way of answering "yes".

2. Dividing out all small factors. For this, 3*5 is *also* a perfectly
   good answer. Given n, do as follows:

     A. Find a small factor of n, say d = 3*5.

     B. Divide n = dq + r. While r == 0, set n = q and divide again.

     C. Compute d = gcd(r,d) (= gcd(n,d)). (In our example, d will now
        be 1, 3 or 5). If d > 1, go back to B. 

     D. Go back to A to find a new small factor. Here we need an
	interface to the trial division function so that it can
	continue without repeating the work done during the previous
	call.

3. Enumerate all small prime factors.

   Do as in B, and keep track of the factors divided out. Furthermore,
   you need a factorization algorithm in order to split all d:s
   occuring above into prime factors (note that you'll get some
   splitting for free in step C).

   I'm assuming d will always be bounded by 2^32 or some such. I don't
   know how much work it is to factor numbers of that size. You may
   get some help from knowing more about the order in which you get
   factors from the trial division routine.

I'd say 2 is fairly trivial. 3 seems a little hairy to do efficiently.
I'd suggest writing some separate gmp function for that specific task,
and build it upon the trial division routine.

Regards,
/Niels



From librik@panix.com  Thu Nov 14 20:11:06 2002
From: librik@panix.com (librik@panix.com)
Date: Thu, 14 Nov 2002 15:11:06 -0500 (EST)
Subject: mingw __dllexport__
Message-ID: <200211142011.gAEKB6306626@panix1.panix.com>

> For gcc I'm going to change the windows DLL function declarations in
> gmp.h from "__declspec(dllexport)" to "__declspec(__dllexport__)", in
> order to keep out of what is, strictly speaking, application
> namespace.
> 
> Does the same or similar work for Microsoft C?  What about Borland C?


No.  Microsoft Visual C requires __declspec(dllexport).  Unlike
in Borland C, the _export keyword is no longer a legal synonym.

For Microsoft Visual C, the current use of __GMP_DECLSPEC in
gmp-h.in is correct.  (Remember that it was wrong in the original
GMP 4.0, and you moved it to the beginning of the declaration to
make it right.)  Also, the form that you use is correct for _MSC_VER:
   #if defined (__GNUC__) || defined (_MSC_VER) || defined (__BORLANDC__)
   #define __GMP_DECLSPEC_EXPORT  __declspec(dllexport)
   #define __GMP_DECLSPEC_IMPORT  __declspec(dllimport)
   #endif

The syntax of __declspec(dllexport) requires that it go at the
beginning of the declaration.  Here's an extract from the MSDN
documentation:

   __declspec ( extended-attribute ) declarator

   extended-attribute
   allocate(segname)
   dllimport
   dllexport
   naked
   noreturn
   nothrow
   novtable
   property({get=get_func_name|, put=put_func_name})
   selectany
   thread
   uuid(ComObjectGUID)

   ....<snip>....
   The __declspec keywords should be placed at the beginning of a
   simple declaration. THe compiler ignores, without warning, any
   __declspec keywords placed after * or & and in front of the
   variable identifier in a declaration.

   A __declspec attribute specified in the beginning of a user-defined
   type declaration applies to the variable of that type. For example:

       __declspec(dllimport) class X {} varX;

   In this case, the attribute applies to varX. A __declspec
   attribute placed after the class or struct keyword applies to
   the user-defined type. For example:

       class __declspec(dllimport) X {};

   In this case, the attribute applies to X.

   The general guideline for using the __declspec attribute for
   simple declarations is as follows:

       decl-specifier-seq init-declarator-list;

   The decl-specifier-seq should contain, among other things,
   a base type (e.g. int, float, a typedef, or a class name),
   a storage class (e.g. static, extern), or the __declspec
   extension. The init-declarator-list should contain, among
   other things, the pointer part of declarations. For example:

       __declspec(selectany) int * pi1 = 0;
                    //OK, selectany & int both part of decl-specifier
       int __declspec(selectany) * pi2 = 0;
                    //OK, selectany & int both part of decl-specifier
       int * __declspec(selectany) pi3 = 0;
                    //ERROR, selectany is not part of a declarator

   Example

   The following code declares an integer thread local variable
   and initializes it with a value:

   // Example of the __declspec keyword
   __declspec( thread ) int tls_i = 1;


In short, for Microsoft Visual C++, don't change __declspec(dllexport).

- David Librik
librik@panix.com



From larryhundle@northeasternleadandmarketinggroup.com  Thu Nov 14 19:11:04 2002
From: larryhundle@northeasternleadandmarketinggroup.com (Larry Hundle)
Date: Thu, 14 Nov 2002 19:11:04
Subject: Refinancing Help
Message-ID: <20021115031109.3E64021C4@b.swox.se>

Northeastern Marketing provides comprehensive and high quality leads you can trust. Our guaranteed leads save you both time and money.  Our mortgage leads are twenty four hours fresh and exclusive. Northeastern employs a network of extensively marketed and branded web sites designed to engender trust, enthusiasm and loyalty from consumers desiring to receive specific information and services.  Leads West is able to provide a high volume of high quality leads on a consistent basis.The prices on our leads, range from 25.00 to 38.00 a lead, depending on amount and the filters you require. We can give you any  LTVs, loan amounts, interest rates and type of credit. They are sorted by zip codes or area codes so your specific area can be targeted. The close rate for clients last month was between 27% to 33%.

4:06PM - In fact, a new client of mine in Illinois just contacted me and told me he closed 5 of the first 12 leads he got from me and that that was the best money he ever spent.  Even offered to put in writing.
 

Thank you,
Larry Hundle
E-mail: larryhundle@northeasternleadandmarketinggroup.com
Phone: (702) 334-2157
Fax: (702) 920-8874

*
Business Opp
Insurance
Debt
New Cars
Credit Card
targeted email marketing

friends, if for some reason you have been reached in error, please email my mailto:remove@northeasternleadandmarketinggroup.com account.



From hatem@comp.metro-u.ac.jp  Sat Nov 16 03:10:09 2002
From: hatem@comp.metro-u.ac.jp (Hatem  Bahig)
Date: Sat, 16 Nov 2002 12:10:09 +0900
Subject: Extended memory
References: <OE13PEhGD1XyCTr9rf300000c09@hotmail.com>
Message-ID: <005c01c28d1d$abed0340$5e4c5685@math.metrou.ac.jp>

This is a multi-part message in MIME format.

------=_NextPart_000_0059_01C28D69.1BCB8380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I would be thankful if someone tell me the command to see the extended =
memory.



------=_NextPart_000_0059_01C28D69.1BCB8380
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.100" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I would be thankful if someone tell me =
the command=20
to see the extended memory.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0059_01C28D69.1BCB8380--




From J.L.Moxham@maths.soton.ac.uk  Sat Nov 16 10:16:04 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Sat, 16 Nov 2002 10:16:04 +0000
Subject: New mpz_trial_division
Message-ID: <200211161016.04864.J.L.Moxham@maths.soton.ac.uk>


How about these two new functions , this should satisfy everyone ?


unsigned long=20
mpz_exist_small_factor(mpz_srcptr N, unsigned long start, unsigned long s=
top)

returns r which is a factor of N between start and stop inclusive and not=
=20
trivial . or returns 0 if no such factor exists.


unsigned long=20
mpz_trial_div(mpz_srcptr N, unsigned long start, unsigned long stop)

returns r which is the smallest prime factor of N between start and stop=20
inclusive , or returns 0 if no such factor exists.
Precondition is that N is not divisible by any number from 2 to start-1





From J.L.Moxham@maths.soton.ac.uk  Sat Nov 16 10:26:27 2002
From: J.L.Moxham@maths.soton.ac.uk (Jason Moxham)
Date: Sat, 16 Nov 2002 10:26:27 +0000
Subject: New mpz_trial_division
In-Reply-To: <200211161016.04864.J.L.Moxham@maths.soton.ac.uk>
References: <200211161016.04864.J.L.Moxham@maths.soton.ac.uk>
Message-ID: <200211161026.27878.J.L.Moxham@maths.soton.ac.uk>

On Saturday 16 Nov 2002 10:16 am, Jason Moxham wrote:

Correction


> How about these two new functions , this should satisfy everyone ?
>
>
> unsigned long
> mpz_exist_small_factor(mpz_srcptr N, unsigned long start, unsigned long
> stop)
>
> returns r which is a factor of N between start and stop inclusive and n=
ot
> trivial . or returns 0 if no such factor exists.
Precondition is that N is not divisible by any number from 2 to start-1
>
>
> unsigned long
> mpz_trial_div(mpz_srcptr N, unsigned long start, unsigned long stop)
>
> returns r which is the smallest prime factor of N between start and sto=
p
> inclusive , or returns 0 if no such factor exists.
> Precondition is that N is not divisible by any number from 2 to start-1
>
>
>
>
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss@swox.com
> https://gmplib.org/mailman/listinfo/gmp-discuss




From info@espydergroup.com  Sun Nov 17 10:59:34 2002
From: info@espydergroup.com (Renee Helton)
Date: Sun, 17 Nov 2002 10:59:34
Subject: CGI, PHP, FLASH, Programming, Design Help!!
Message-ID: <200211171603.gAHG3MI03450@spyderwebdesigngroup.com>

Hello,

My name is Renee Helton and I came across your domain today. We are Freelance Internet Programmers and Designers that specialize in searchable databases, member log-ins, chat rooms, message boards, shopping carts, Flash, and other dynamic web content. (bilingual)  Whether you require a Flash Design, Programming, Eng/Spanish translation for an existing site, or a complete web site design, we are happy to work with you!!

We offer any one of our services at affordable and competitive rates.

We do not compromise quality and can assure you responsible, and dependable work product. 

Thank you for your time and PLEASE feel free to contact me for more information and a portfolio of our work.

Renee Helton
info@espydergroup.com
http://www.espydergroup.com

This is a one-time message. Thank you.




From user42@zip.com.au  Sun Nov 17 20:34:05 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Mon, 18 Nov 2002 06:34:05 +1000
Subject: Reserved names in C++ [Was: Re: mingw __dllexport__]
References: <F535BQLHbsiofSY2O2Z000005c9@hotmail.com>
 <87isz1qgb4.fsf@zip.com.au> <3DD340D5.8070208@cs.unipr.it>
Message-ID: <87of8oaqbm.fsf@zip.com.au>

Roberto Bagnara <bagnara@cs.unipr.it> writes:
>
> I don't know if strict conformance to standards is one of GMP's goals.
> If it is, it would be better to avoid using names that are reserved
> to the language's implementation.

The rule we're working to is that _foo belongs to the compiler and
libc, and __foo is for third party libraries, or something like that.

For practical purposes annexing __gmp* at the symbol level and gmp*
and some mp* in gmp.h shouldn't be in too much danger of clashing with
unrelated stuff.

I guess in the libgmpxx routines we've ended up with __mpz_struct
getting into the mangling, where __gmpz_struct might have been better.
Alas doing anything about that would break binary compatibility.



From bagnara@cs.unipr.it  Sun Nov 17 21:57:32 2002
From: bagnara@cs.unipr.it (Roberto Bagnara)
Date: Sun, 17 Nov 2002 22:57:32 +0100
Subject: Reserved names in C++ [Was: Re: mingw __dllexport__]
References: <F535BQLHbsiofSY2O2Z000005c9@hotmail.com>	<87isz1qgb4.fsf@zip.com.au> <3DD340D5.8070208@cs.unipr.it> <87of8oaqbm.fsf@zip.com.au>
Message-ID: <3DD810CC.9080808@cs.unipr.it>

Kevin Ryde wrote:
> I guess in the libgmpxx routines we've ended up with __mpz_struct
> getting into the mangling, where __gmpz_struct might have been better.
> Alas doing anything about that would break binary compatibility.

In my humble opinion, there is no issue of binary compatibility
today, as far as libgmpxx is concerned (no C++ compiler/version
has been binary compatible with any other, no distribution I know
of has shipped precompiled versions of libgmpxx and so forth).
That is why I believe the very right thing should be done today
in order to be able to guarantee binary compatibility tomorrow,
when it will be an issue.  In other words, I believe the C++
standard should be followed to the last bit so as to decrease
the probability binary compatibility has to be broken later.
Just my opinion, of course.

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it




From Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de  Mon Nov 18 16:17:35 2002
From: Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de (Hermann Mahr)
Date: Mon, 18 Nov 2002 17:17:35 +0100 (MEZ)
Subject: GMP-3.1.1
Message-ID: <200211181620.RAA27674@sun14.hrz.tu-darmstadt.de>

Hello,

I have downloaded gmp-3.1.1 from hobbes.nmsu.edu.
One could read that gmp-3.1.1 runs under OS/2.
(GNU MP (MultiPrecision) math library for OS/2, v.3.1.1)

So far, so good.

First of all I tried to run a demo, for example  
factorize.exe.
A message was written, that GCC2952M(.DLL ?)
could not be found.

I use Eberhard Mattes' emx 09d for OS/2 with emxfix04. 
As far as I know this is the latest version of Eberhard
Mattes's emx! This version has no GCC2952M.DLL !

Is it necessary to use a gcc compiler Version 2952 ?
I do not know another GNU gcc for OS/2 than emx by
Ebergard Matthes.

What is to do?

I have gmp version 202 for OS/2 which works fine.

Do exist later versions of GNU GMP
(version later than 202 and earlier than 3.1.1) for OS/2 
which works with emx 09.d ?

Regards

Hermann Mahr













From erik_johnson1980@hotmail.com  Mon Nov 18 21:29:20 2002
From: erik_johnson1980@hotmail.com (Erik Johnson)
Date: Mon, 18 Nov 2002 15:29:20 -0600
Subject: (no subject)
Message-ID: <F86Ee4zadTMVwVn20lb000162cb@hotmail.com>

I'm using the GMP library for a demonstration of various cryptographic 
algorithms for an independent study project. I seem to have a problem, 
however, with the integer import and export functions. Basically, I am 
reading in binary data, using the import function to convert it to the GMP 
multi-precision number format, performing the algorithm, and then using the 
export function to convert the data back to binary and write it out to the 
destination file.

I have no problems with text files, the algorithms encrypt and decrypt 
perfectly.  The problem is this: when using characters with an ANSI value 
higher than 127, the program will not work.  The decrypted result does not 
match the original file. So, binary files don't work, and text files with 
special characters (accented letters, etc.) also do not. Since these 
characters do not work, but regular text does, I figure it is likely a 
problem with the conversion function not properly converting the unsigned 
char data to the GMP format.  Like it treats everything as a signed char or 
something when converting.  My buffer is an unsigned char array, so I know 
that the buffer is not the problem.

Can anyone else that has used GMP offer any insight into this problem?

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus




From tege@swox.com  Mon Nov 18 21:34:36 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 18 Nov 2002 22:34:36 +0100
Subject: (no subject)
In-Reply-To: <F86Ee4zadTMVwVn20lb000162cb@hotmail.com>
References: <F86Ee4zadTMVwVn20lb000162cb@hotmail.com>
Message-ID: <86smxy7eab.fsf@king.swox.se>

"Erik Johnson" <erik_johnson1980@hotmail.com> writes:

  Can anyone else that has used GMP offer any insight into this problem?
  
Please always include a test case when reporting problems with
GMP.  We cannot fix bugs by proof reading code given a vague
problem description.

-- 
Torbjörn



From erik_johnson1980@hotmail.com  Mon Nov 18 21:53:05 2002
From: erik_johnson1980@hotmail.com (Erik Johnson)
Date: Mon, 18 Nov 2002 15:53:05 -0600
Subject: GMP - integer import and export
Message-ID: <F455Qy2LfHxwgxSc6pT00004379@hotmail.com>

I'm using the GMP library for an demonstration of various cryptographic 
algorithms for an independent study project. I seem to have a problem, 
however, with the integer import and export functions. Basically, I am 
reading in binary data, using the import function to convert it to the GMP 
multi-precision number format, performing the algorithm, and then using the 
export function to convert the data back to binary and write it out to the 
destination file.

I have no problems with text files, the algorithms encrypt and decrypt them 
perfectly. The problem is this: when using characters with an ANSI value 
higher than 127, the decrypted result does not match the original file. So, 
binary files like wav files, PDFs, etc. don't work, and text files with 
special characters (accented letters, etc.) also do not. Since these 
characters do not work, but regular text does, I figure it is likely a 
problem with the conversion function not properly converting the unsigned 
char data to the GMP format.  Like it treats everything as a signed char or 
something when converting.  My buffer is an unsigned char array, so I know 
that the buffer is not the problem.

Can anyone else that has used GMP offer any insight into this problem?

Code sample is below.

--------------------------------------

FYI:
  BUFFER_SIZE is a const int.
  padding is an integer value calculated earlier in the program.

.
.
.
.
    unsigned char buffer[BUFFER_SIZE];

    for(int i=1; i<=num_blocks; i++)
    {
        if(a == 'E' && i == num_blocks)
            // If the algorithm is encrypting, and this is the last block,
            // Read the last bytes from the input file.
            inp.read((char *)&buffer,(BUFFER_SIZE-padding));
        else
            // Read a full block.
            inp.read((char *)&buffer,BUFFER_SIZE);

        // Convert to MP int.
        mpz_import(m,1,1,BUFFER_SIZE,0,0,buffer);

        // Encrypt or decrypt the block.
        mpz_powm(m,m,x,n);

        // Convert the block back to binary.
        mpz_export(buffer,&count,1,BUFFER_SIZE,0,0,m);

        if(a == 'D' && i == num_blocks)
            // If the algorithm is decrypting, and this is the last block,
            // then disregard the padding when writing.
            out.write((char *)&buffer,(BUFFER_SIZE-padding));
        else
            // Write the data out to the destination file.
            out.write((char *)&buffer,BUFFER_SIZE);
    }
.
.
.
.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail




From tege@swox.com  Mon Nov 18 21:58:09 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 18 Nov 2002 22:58:09 +0100
Subject: GMP - integer import and export
In-Reply-To: <F455Qy2LfHxwgxSc6pT00004379@hotmail.com>
References: <F455Qy2LfHxwgxSc6pT00004379@hotmail.com>
Message-ID: <86k7jalevi.fsf@king.swox.se>

  Can anyone else that has used GMP offer any insight into this problem?
  
  Code sample is below.
  
That test case doesn't compile.  Please check the GMP manual on how to
report bugs:

<http://swox.com/gmp/manual/Reporting-Bugs.html#Reporting%20Bugs>

(If you don't have time to read that, don't expect us to have time to
check if there is a biug in GMP.)

-- 
Torbjörn



From Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de  Tue Nov 19 16:35:06 2002
From: Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de (Hermann Mahr)
Date: Tue, 19 Nov 2002 17:35:06 +0100 (MEZ)
Subject: libgmp.a
Message-ID: <200211191637.RAA11757@sun14.hrz.tu-darmstadt.de>

Hello, GMP Experts,

please let me know where to get the library

libgmp.a,

suitable tu be used with the GNU MP gmp-3.1.1.zip for OS/2.

I have tried Google but I was not able to find by Google an 
URL to download  libgmp.a   .

My question is where to get  libgmp.a  ?

Thanks for every answer.

Regards,
Hermann Mahr. 


 





From user42@zip.com.au  Tue Nov 19 20:31:52 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Wed, 20 Nov 2002 06:31:52 +1000
Subject: GMP-3.1.1
In-Reply-To: <200211181620.RAA27674@sun14.hrz.tu-darmstadt.de> ("Hermann
 Mahr"'s message of "Mon, 18 Nov 2002 17:17:35 +0100 (MEZ)")
References: <200211181620.RAA27674@sun14.hrz.tu-darmstadt.de>
Message-ID: <87d6p1xpvr.fsf@zip.com.au>

"Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de> writes:
>
> First of all I tried to run a demo, for example  
> factorize.exe.
> A message was written, that GCC2952M(.DLL ?)
> could not be found.

We only distribute sources, perhaps whoever put together that binary
package can tell you.  Perhaps it's simply just the gcc runtime
(libgcc on other systems).

> Do exist later versions of GNU GMP
> (version later than 202 and earlier than 3.1.1) for OS/2 
> which works with emx 09.d ?

The version of libtool we're using in gmp has a mention of emx, but I
don't know if it's been tried recently.

From user42@zip.com.au  Tue Nov 19 23:05:16 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Wed, 20 Nov 2002 09:05:16 +1000
Subject: Reserved names in C++
In-Reply-To: <3DD810CC.9080808@cs.unipr.it> (Roberto Bagnara's message of
 "Sun, 17 Nov 2002 22:57:32 +0100")
References: <F535BQLHbsiofSY2O2Z000005c9@hotmail.com>
 <87isz1qgb4.fsf@zip.com.au> <3DD340D5.8070208@cs.unipr.it>
 <87of8oaqbm.fsf@zip.com.au> <3DD810CC.9080808@cs.unipr.it>
Message-ID: <87of8lw47n.fsf@zip.com.au>

Roberto Bagnara <bagnara@cs.unipr.it> writes:
>
> (no C++ compiler/version
> has been binary compatible with any other,

True, but outside our scope.

> no distribution I know
> of has shipped precompiled versions of libgmpxx and so forth).

Oh, well, the rules apply irrespective how you get libgmpxx, either
from a package or by building your own.

And as far as __mpz_struct in the mangling goes, of course it's also
in application and third party library object files directly, not just
in libgmpxx, and that dates right back to gmp 3.0.


If one day we have a big compatibility break for whatever reason then
yes we should certainly address such things.  But breaking
compatibility in a library like gmp which is used by other libraries
causes lots of pain so we'd want good reasons for doing so.

From user42@zip.com.au  Tue Nov 19 23:07:08 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Wed, 20 Nov 2002 09:07:08 +1000
Subject: mingw __dllexport__
In-Reply-To: <200211142011.gAEKB6306626@panix1.panix.com> (<librik@panix.com>'s
 message of "Thu, 14 Nov 2002 15:11:06 -0500 (EST)")
References: <200211142011.gAEKB6306626@panix1.panix.com>
Message-ID: <87lm3pw44j.fsf@zip.com.au>

<librik@panix.com> writes:
>
> No.  Microsoft Visual C requires __declspec(dllexport).  Unlike
> in Borland C, the _export keyword is no longer a legal synonym.

Thanks, I'll leave it alone.

From kalinabears@hdc.com.au  Wed Nov 20 03:17:54 2002
From: kalinabears@hdc.com.au (Sisyphus)
Date: Wed, 20 Nov 2002 14:17:54 +1100
Subject: Building on Win2k
Message-ID: <00ea01c29043$6bf8c7f0$7531ddcb@sisyphusii330h>

Hi,
Seems that some people have built gmp on Windows - though it's not apparent
to me (from the docs and the list archive) how this is achieved.

My problem is that './configure' won't work from my (cmd.exe) shell. It
simply produces the error message:
'.' is not recognized as an internal or external command,
operable program or batch file.

Any pointers (or links to info) on what needs to be done to overcome this
would be gratefully accepted.

I have both msvc++ and gcc(mingw32) compilers.

Cheers,
Rob


From chris.saunders@sympatico.ca  Wed Nov 20 07:24:29 2002
From: chris.saunders@sympatico.ca (Chris Saunders)
Date: Wed, 20 Nov 2002 02:24:29 -0500
Subject: Building on Win2k
References: <00ea01c29043$6bf8c7f0$7531ddcb@sisyphusii330h>
Message-ID: <000c01c29065$dddd4e00$ef1e5c41@mycomputer>

I have built this without problems using MingW but I also
have a thing called "msys" that I downloaded from the MingW
site.  I don't see how ./configure could work from the windows
shell.  Without this "msys" I think the only other way for this
to work is through Cygwin. I could be wrong as I do not have
a lot of experience with these tools.

Regards
Chris Saunders
chris.saunders.@sympatico.ca

----- Original Message -----
From: "Sisyphus" <kalinabears@hdc.com.au>
To: "GMP" <gmp-discuss@swox.com>
Sent: Tuesday, November 19, 2002 10:17 PM
Subject: Building on Win2k


> Hi,
> Seems that some people have built gmp on Windows - though it's not
apparent
> to me (from the docs and the list archive) how this is achieved.
>
> My problem is that './configure' won't work from my (cmd.exe) shell. It
> simply produces the error message:
> '.' is not recognized as an internal or external command,
> operable program or batch file.
>
> Any pointers (or links to info) on what needs to be done to overcome this
> would be gratefully accepted.
>
> I have both msvc++ and gcc(mingw32) compilers.
>
> Cheers,
> Rob
>
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss@swox.com
> https://gmplib.org/mailman/listinfo/gmp-discuss


From Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de  Wed Nov 20 11:38:29 2002
From: Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de (Hermann Mahr)
Date: Wed, 20 Nov 2002 12:38:29 +0100 (MEZ)
Subject: Addition
Message-ID: <200211201141.MAA24311@sun14.hrz.tu-darmstadt.de>

Hello Mr. Sobotka,

in addition to my last e-mail I should write the following
effect:

If I make mpz_out_str(stdout, 10, p);  ineffective
by setting it between /* and */ Example.exe does not print 
the result but no runtime error occurs.

May be that this fact can help you to give me a hint how to 
change the source code of example.c.

Thank you already in this moment for your help.

Regards, 
Hermann Mahr.





From brg@gladman.plus.com  Wed Nov 20 15:45:31 2002
From: brg@gladman.plus.com (Brian Gladman)
Date: Wed, 20 Nov 2002 15:45:31 -0000
Subject: Building on Win2K
Message-ID: <000501c290ab$ddd42370$f87e38d4@fortyfour>

I build a native version of GMP 4.1 on Windows XP without any mingw/cygwin
support uisng VC++ with a hand edited version of config.h.

I have also converted a lot of the pentium assembler stuff to Intel format
so that NASM can be used to add these faster routines (it is easy to add
NASM to VC++).

I don't see any reason why this would not work on WIn2K.  Details are
available here:

http://fp.gladman.plus.com/computing/gmp4win.htm

   Brian Gladman



From endersgame99@yahoo.com  Wed Nov 20 17:53:42 2002
From: endersgame99@yahoo.com (enders game)
Date: Wed, 20 Nov 2002 09:53:42 -0800 (PST)
Subject: GMP - integer import and export
In-Reply-To: <F455Qy2LfHxwgxSc6pT00004379@hotmail.com>
Message-ID: <20021120175342.92775.qmail@web13303.mail.yahoo.com>

--- Erik Johnson <erik_johnson1980@hotmail.com> wrote:
> I'm using the GMP library for an demonstration of
> various cryptographic 
> algorithms for an independent study project. I seem
> to have a problem, 
> however, with the integer import and export
> functions. Basically, I am 
> reading in binary data, using the import function to
> convert it to the GMP 
> multi-precision number format, performing the
> algorithm, and then using the 
> export function to convert the data back to binary
> and write it out to the 
> destination file.
> 
> I have no problems with text files, the algorithms
> encrypt and decrypt them 
> perfectly. The problem is this: when using
> characters with an ANSI value 
> higher than 127, the decrypted result does not match
> the original file. So, 
> binary files like wav files, PDFs, etc. don't work,
> and text files with 
> special characters (accented letters, etc.) also do
> not. Since these 
> characters do not work, but regular text does, I
> figure it is likely a 
> problem with the conversion function not properly
> converting the unsigned 
> char data to the GMP format.  Like it treats
> everything as a signed char or 
> something when converting.  My buffer is an unsigned
> char array, so I know 
> that the buffer is not the problem.
> 
> Can anyone else that has used GMP offer any insight
> into this problem?
> 
> Code sample is below.
> 
> --------------------------------------
> 
> FYI:
>   BUFFER_SIZE is a const int.
>   padding is an integer value calculated earlier in
> the program.
> 
> .
> .
> .
> .
>     unsigned char buffer[BUFFER_SIZE];
> 
>     for(int i=1; i<=num_blocks; i++)
>     {
>         if(a == 'E' && i == num_blocks)
>             // If the algorithm is encrypting, and
> this is the last block,
>             // Read the last bytes from the input
> file.
>             inp.read((char
> *)&buffer,(BUFFER_SIZE-padding));
>         else
>             // Read a full block.
>             inp.read((char *)&buffer,BUFFER_SIZE);
> 
>         // Convert to MP int.
>         mpz_import(m,1,1,BUFFER_SIZE,0,0,buffer);
> 
>         // Encrypt or decrypt the block.
>         mpz_powm(m,m,x,n);
> 
>         // Convert the block back to binary.
>        
> mpz_export(buffer,&count,1,BUFFER_SIZE,0,0,m);
> 
>         if(a == 'D' && i == num_blocks)
>             // If the algorithm is decrypting, and
> this is the last block,
>             // then disregard the padding when
> writing.
>             out.write((char
> *)&buffer,(BUFFER_SIZE-padding));
>         else
>             // Write the data out to the destination
> file.
>             out.write((char *)&buffer,BUFFER_SIZE);
>     }
> .
> .
> .
> .
> 

I might be wrong, im not sure, so im just going to
tell you my idea of what could be happening for you. 
If you read NULLs from the file before other
characters, then you will import from "000005622342"
for example.  But when you do any math (POWM) on the
number, you'll lose the leading zeroes, and wont be
able to decrypt them.  What I did was when decrypting,
exported to a zeroed array of the size each mpz-sized
block.

~Andrew


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

From chris.saunders@sympatico.ca  Thu Nov 21 19:25:24 2002
From: chris.saunders@sympatico.ca (Chris Saunders)
Date: Thu, 21 Nov 2002 14:25:24 -0500
Subject: mpz_cdiv_q_2exp
Message-ID: <002501c29193$be1e1de0$ef1e5c41@mycomputer>

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01C29169.D490D3D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am working on an Eiffel interface to GMP and am
trying to document the code as I go along.  I didn't
feel that I understood what the function mpz_cdiv_q_2exp
does and hope that someone might provide me with
a better explanation than I found in the provided
documentation.

Regards
Chris Saunders
chris.saunders.@sympatico.ca
------=_NextPart_000_0022_01C29169.D490D3D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>I am working on an Eiffel interface to GMP and am<BR>trying to =
document the=20
code as I go along.&nbsp; I didn't<BR>feel that I understood what the =
function=20
mpz_cdiv_q_2exp<BR>does and hope that someone might provide me with<BR>a =
better=20
explanation than I found in the=20
provided<BR>documentation.<BR><BR>Regards<BR>Chris Saunders<BR><A=20
href=3D"mailto:chris.saunders.@sympatico.ca">chris.saunders.@sympatico.ca=
</A></DIV></BODY></HTML>

------=_NextPart_000_0022_01C29169.D490D3D0--


From deltatrinity@hotmail.com  Thu Nov 21 20:43:42 2002
From: deltatrinity@hotmail.com (delta trinity)
Date: Thu, 21 Nov 2002 15:43:42 -0500
Subject: mpz_cdiv_q_2exp
Message-ID: <F126u757ygQX7iVhXmV00014ce3@hotmail.com>

The function divide a number by a power of two.  The 'q' in the expression 
meen that you want the quotient.  Some variations include 'r' to return 
remainder and 'qr' to return both.

Ex: X/2^Y

This is much faster than doing the regular division algorithm as only 
logical shifts are involved.

the fdiv round to lowest integer value while the cdiv to highest integer 
value.

ex, if you have 100/2^3 (equivalent to 100/8), you get 12.5.  fdiv would 
return 12 while cdiv would return 13.  In case of negative numbers, ex: 
-100/2^3, giving -12.5, fdiv would return -13 and cdiv would return -12.  
You can also specify 'tdiv', 't' for trunc.  In then round the number to the 
next value toware zero.  In the last example, they would give 12 and -12.

100/2^2 (or 100/4), giving exactly 25, would return, in both cases, 25.

If you already know that the denominator is a power of two, use the ..._2exp 
function.

ex, 100/2^2.
In binary, 100 is:
01100100.

Shift right by to, you get:
00011001 (or, in decimal, 25)

>From: "Chris Saunders" <chris.saunders@sympatico.ca>
>To: "GMP" <gmp-discuss@swox.com>
>Subject: mpz_cdiv_q_2exp
>Date: Thu, 21 Nov 2002 14:25:24 -0500
>
>I am working on an Eiffel interface to GMP and am
>trying to document the code as I go along.  I didn't
>feel that I understood what the function mpz_cdiv_q_2exp
>does and hope that someone might provide me with
>a better explanation than I found in the provided
>documentation.
>
>Regards
>Chris Saunders
>chris.saunders.@sympatico.ca


_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail


From user42@zip.com.au  Thu Nov 21 23:54:34 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Fri, 22 Nov 2002 09:54:34 +1000
Subject: Building on Win2K
In-Reply-To: <000501c290ab$ddd42370$f87e38d4@fortyfour> ("Brian Gladman"'s
 message of "Wed, 20 Nov 2002 15:45:31 -0000")
References: <000501c290ab$ddd42370$f87e38d4@fortyfour>
Message-ID: <877kf6zdfp.fsf@zip.com.au>

"Brian Gladman" <brg@gladman.plus.com> writes:
>
> I have also converted a lot of the pentium assembler stuff to Intel format
> so that NASM can be used to add these faster routines (it is easy to add
> NASM to VC++).

I wonder if it's possible to build a version of gas that spits out
.obj (intel OMF) and which would work with msvc.

Or maybe the mingw objcopy can convert coff (or whatever it is mingw
uses) to the right form.

Might be troublesome to get going, but could save some manual editing.

From brg@gladman.plus.com  Fri Nov 22 12:38:35 2002
From: brg@gladman.plus.com (Brian Gladman)
Date: Fri, 22 Nov 2002 12:38:35 -0000
Subject: Building on WIn2K
Message-ID: <000501c29224$1325fd90$f87e38d4@fortyfour>

Thanks for the input Kevin.  I appreciate the idea since this would
certainly save some time for me.

While I did download gas with this in mind, I quickly found that I needed m4
and then quite a few other 'unix style' tools that would have made my
development environemnt still more complex than it is now.

Moreover, gas is really only a backend for gcc and does not have the
facilities that are really needed for doing decent assembler code
development work. In contrast NASM is a good assembler with all the
facilities needed for this.

Hence although the conversion is a bit of a chore, once I have done this I
do at least have code that is much easier to work with and improve.

Nevertheless it is a chore so I only convert what I need even though I get
emails asking me to do the rest.

    Brian Gladman



From tege@swox.com  Fri Nov 22 13:03:45 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 22 Nov 2002 14:03:45 +0100
Subject: Building on WIn2K
In-Reply-To: <000501c29224$1325fd90$f87e38d4@fortyfour>
References: <000501c29224$1325fd90$f87e38d4@fortyfour>
Message-ID: <86ptsx3gem.fsf@king.swox.se>

"Brian Gladman" <brg@gladman.plus.com> writes:

  Moreover, gas is really only a backend for gcc and does not
  have the facilities that are really needed for doing decent
  assembler code development work. In contrast NASM is a good
  assembler with all the facilities needed for this.

Clearly, NASM does not have "all the facilities needed for this",
i.e., assembling GMP's code.  :-)

  Hence although the conversion is a bit of a chore, once I have
  done this I do at least have code that is much easier to work
  with and improve.

Well, working with the m4 unrolled output should be a nightmare,
I think.

  Nevertheless it is a chore so I only convert what I need even though I get
  emails asking me to do the rest.

I think it is always a mistake to duplicate lots of code.  The
.asm files in GMP, and the filtering using m4, are designed with
portability in mind, without creating redundancy.

I am afraid we will never accept translated code that can be fed
into some ever so good MS assembly.  If people feel a strong urge
to use that assembler for GMP's code, then somebody should write
a tool taking m4 output and rearranging the operands.  Such a
tool could perhaps be integrated in GMP.

--
Torbjörn

From nisse@lysator.liu.se  Fri Nov 22 21:31:01 2002
From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=)
Date: 22 Nov 2002 22:31:01 +0100
Subject: Building on WIn2K
In-Reply-To: <86ptsx3gem.fsf@king.swox.se>
References: <000501c29224$1325fd90$f87e38d4@fortyfour>
 <86ptsx3gem.fsf@king.swox.se>
Message-ID: <nnisype1gq.fsf@fafner.lysator.liu.se>

Torbjorn Granlund <tege@swox.com> writes:

> If people feel a strong urge to use that assembler for GMP's code,
> then somebody should write a tool taking m4 output and rearranging
> the operands. Such a tool could perhaps be integrated in GMP.

That shouldn't be terribly hard. I remember writing som elisp for
converting between Motorola and Sun syntax for m68k some ten years
ago.

But what's the real problem here? There's no object file format that
is supported by both gas and M$ compilers? If so it's probably a
better solution to either improve gas/bfd, or write some separate tool
to convert the object files.

/Niels

From user42@zip.com.au  Fri Nov 22 22:03:05 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Sat, 23 Nov 2002 08:03:05 +1000
Subject: Building on WIn2K
In-Reply-To: <nnisype1gq.fsf@fafner.lysator.liu.se> (nisse@lysator.liu.se's
 message of "22 Nov 2002 22:31:01 +0100")
References: <000501c29224$1325fd90$f87e38d4@fortyfour>
 <86ptsx3gem.fsf@king.swox.se> <nnisype1gq.fsf@fafner.lysator.liu.se>
Message-ID: <87of8hp8iu.fsf@zip.com.au>

nisse@lysator.liu.se (Niels M=F6ller) writes:
>
> That shouldn't be terribly hard. I remember writing som elisp for
> converting between Motorola and Sun syntax for m68k some ten years
> ago.

The djgpp faq mentions an att2intel program, but the link is dead.
Another I had for at&t to nasm is also dead.

> If so it's probably a better solution to either improve gas/bfd,

bfd knows pe-i386 and a pei-i386 (whatever the difference is), which
sounds likely.

From user42@zip.com.au  Fri Nov 22 22:14:30 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Sat, 23 Nov 2002 08:14:30 +1000
Subject: Building on WIn2K
In-Reply-To: <000501c29224$1325fd90$f87e38d4@fortyfour> ("Brian Gladman"'s
 message of "Fri, 22 Nov 2002 12:38:35 -0000")
References: <000501c29224$1325fd90$f87e38d4@fortyfour>
Message-ID: <87lm3lp7zt.fsf@zip.com.au>

"Brian Gladman" <brg@gladman.plus.com> writes:
>
> While I did download gas with this in mind, I quickly found that I needed m4
> and then quite a few other 'unix style' tools that would have made my
> development environemnt still more complex than it is now.

m4 and gas should be all you need, as far as the asm code goes.

> Moreover, gas is really only a backend for gcc and does not have the
> facilities that are really needed for doing decent assembler code
> development work. In contrast NASM is a good assembler with all the
> facilities needed for this.

It's true a typical unix "as" is pretty primative, but with m4 helping
it becomes fairly usable. :)

From brg@gladman.plus.com  Fri Nov 22 22:29:55 2002
From: brg@gladman.plus.com (Brian Gladman)
Date: Fri, 22 Nov 2002 22:29:55 -0000
Subject: Building on WIn2K
Message-ID: <000901c29276$af2e0460$f87e38d4@fortyfour>

I have tried several of the AT&T to Intel convertors and none seems very
comfortable with the output of M4.

There are also quite a few relatively quirky things that need accurate
conversion - for example, where instuctions must assemble to definite
lengths so that they are suitable for jumps into partially unrolled loops.
None of the convertors I tried handled this properly.

I have not put a lot of effort into this but from what I can see these
convertors are all now out of date and don't cope with code on the new x86
systems.  This would not be hard to put right but I decided that for my
limited purposes it was easier to do most of the conversion with Perl and do
the rest by hand.

    Brian Gladman



From Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de  Sun Nov 24 09:19:31 2002
From: Hermann Mahr" <h_mahr@hrzPUB.tu-darmstadt.de (Hermann Mahr)
Date: Sun, 24 Nov 2002 10:19:31 +0100 (MEZ)
Subject: ThankYou
Message-ID: <200211240922.KAA03715@sun14.hrz.tu-darmstadt.de>

Hello Mr. Sobotka,

thank you for your effort to help me.

But, the string

gcc -Zmt(d) example.c -I. -lgmp

does not work. It produces an error message

D:\emx\bin\ld.exe: No such file or directory for gmp.a  

At this time I had copied all files (mentioned in the 
following lines) in the working directory wich contains the 
example.c!

The error message

D:\emx\bin\ld.exe: No such file or directory for gmp.a

produces the idea in me to copy the files

gmp.a, gmp.lib, gmp_s.a  and the files
 mp.a,  mp.lib,  mp_s.a  in the directory D:\emx\lib,

and the files

gmp.dll, mp.dll in the directory D:\emx\dll,

and the file

gmp.h  in the directory  D:\emx\include.

Now the string

gcc -ZMT(or -Zmt) example.c -I. -lgmp

works fine.

Are these steps correct?????

If Yes, I recommend that the authors of  GNU MP  should 
give an hint to copy such files in the corresponding 
directories of the used gcc because the path entries in the 
config.sys are related to the emx configuration. My be that 
this is an elementary step, but.... 

My next step will be to compile a file to calculate 
rational numbers. If there are new difficulties I hope
that you give me suitable answers again.

Tanks again and Regards,
Hermann Mahr.

Postscriptum:

As I got the gmp-3.1.1 first of all I tried to use the
example file "factorize.exe" and an error message occurs
rhat the file "gcc2952m" could not be found. Therefore
I got this file with the help of GOOGLE. This file also I 
have copied to D:\emx\dll. Then  "factorize.ese" works 
fine.
What's about this gcc2952m.DLL? 







From coulouri@ncbi.nlm.nih.gov  Tue Nov 26 15:41:30 2002
From: coulouri@ncbi.nlm.nih.gov (George Coulouris)
Date: Tue, 26 Nov 2002 10:41:30 -0500
Subject: find position of most significant bit ?
Message-ID: <3DE3962A.6080701@ncbi.nlm.nih.gov>

Hello,

Is there an efficient way to compute the position of the most 
significant bit in a multiprecision integer? Basically, like 
mpz_scan1(), but instead of scanning from LSB to MSB, the other way around.

mpz_sizeinbase(op, 2) would do it, but I don't know if there is a more 
efficent way to accomplish this.

Regards,
George Coulouris


From tege@swox.com  Tue Nov 26 18:04:06 2002
From: tege@swox.com (Torbjorn Granlund)
Date: 26 Nov 2002 19:04:06 +0100
Subject: find position of most significant bit ?
In-Reply-To: <3DE3962A.6080701@ncbi.nlm.nih.gov>
References: <3DE3962A.6080701@ncbi.nlm.nih.gov>
Message-ID: <86el98xl61.fsf@king.swox.se>

George Coulouris <coulouri@ncbi.nlm.nih.gov> writes:

  mpz_sizeinbase(op, 2) would do it, but I don't know if there is a more
  efficent way to accomplish this.

mpz_sizeinbase(op,2) should need just a few cycles.
Is that not efficient enough?  ;-)

-- 
Torbjörn

From dtashley@esrg.org  Tue Nov 26 21:25:18 2002
From: dtashley@esrg.org (David T. Ashley)
Date: Tue, 26 Nov 2002 16:25:18 -0500
Subject: find position of most significant bit ?
In-Reply-To: <86el98xl61.fsf@king.swox.se>
Message-ID: <KGEGILEPOOMJFEDADOHHKEMLCEAA.dtashley@esrg.org>

I assume one knows from the data structure of an arbitrary integer where the
limb containing the most significant bit is.

Then the problem reduces to the problem of finding the most significant
within a limb (a machine word).

I would tend to hardcode and bsearch it, i.e.

if (word & 0x0000FFFF)
   {
   if (word & 0x000000FF)
      {
      }
   else
      {
      }
   }
else
   {
   if (word & 0x00FF0000)
      {
      }
   else
      {
      }
   }

You could just roll and test, but I'm not sure how that would compare
against a hardcoded BSEARCH.

Dave.

> -----Original Message-----
> From: gmp-discuss-admin@swox.com [mailto:gmp-discuss-admin@swox.com]On
> Behalf Of Torbjorn Granlund
> Sent: Tuesday, November 26, 2002 1:04 PM
> To: George Coulouris
> Cc: gmp-discuss@swox.com
> Subject: Re: find position of most significant bit ?
>
>
> George Coulouris <coulouri@ncbi.nlm.nih.gov> writes:
>
>   mpz_sizeinbase(op, 2) would do it, but I don't know if there is a more
>   efficent way to accomplish this.
>
> mpz_sizeinbase(op,2) should need just a few cycles.
> Is that not efficient enough?  ;-)
>
> --
> Torbjörn
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss@swox.com
> https://gmplib.org/mailman/listinfo/gmp-discuss
>


From user42@zip.com.au  Wed Nov 27 00:24:02 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Wed, 27 Nov 2002 10:24:02 +1000
Subject: Building on Win2K
In-Reply-To: <877kf6zdfp.fsf@zip.com.au> (Kevin Ryde's message of "Fri, 22
 Nov 2002 09:54:34 +1000")
References: <000501c290ab$ddd42370$f87e38d4@fortyfour>
 <877kf6zdfp.fsf@zip.com.au>
Message-ID: <87smxnkggt.fsf@zip.com.au>

I wrote:
>
> I wonder if it's possible to build a version of gas that spits out
> .obj (intel OMF) and which would work with msvc.

Which just goes to show how little I know about msvc.  Supposedly it's
coff not omf already, but maybe with gratuitous differences from what
everyone else calls coff.

I guess another way to convert would be assemble with gas then get the
disassembly and make a masm file with ".byte" directives, or .long's
maybe for the few external symbol references.  Sounds a bit silly, but
it'd ensure the instruction encodings were what's needed. :)

From brg@gladman.plus.com  Wed Nov 27 08:42:22 2002
From: brg@gladman.plus.com (Brian Gladman)
Date: Wed, 27 Nov 2002 08:42:22 -0000
Subject: Building on WIn2K
Message-ID: <000201c295f0$fcb5ae90$f87e38d4@fortyfour>

Kevin Ryde wrote:

> Which just goes to show how little I know about msvc.  Supposedly it's
> coff not omf already, but maybe with gratuitous differences from what
> everyone else calls coff.
>
> I guess another way to convert would be assemble with gas then get the
> disassembly and make a masm file with ".byte" directives, or .long's
> maybe for the few external symbol references.  Sounds a bit silly, but
> it'd ensure the instruction encodings were what's needed. :)
Has anyone tried to use gas output files with the MS linker?  If anyone
would be prepared to send me a few typical gas output files, I will
willingly try these and report on the results.   Brian Gladman



From kha@treskal.com  Wed Nov 27 08:51:17 2002
From: kha@treskal.com (Karl =?iso-8859-1?Q?Hasselstr=F6m?=)
Date: Wed, 27 Nov 2002 09:51:17 +0100
Subject: find position of most significant bit ?
In-Reply-To: <KGEGILEPOOMJFEDADOHHKEMLCEAA.dtashley@esrg.org>
References: <86el98xl61.fsf@king.swox.se> <KGEGILEPOOMJFEDADOHHKEMLCEAA.dtashley@esrg.org>
Message-ID: <20021127085117.GA22998@treskal.com>

On 2002-11-26 16:25:18 -0500, David T. Ashley wrote:
>
> I assume one knows from the data structure of an arbitrary integer
> where the limb containing the most significant bit is.

Yes. If A is an mpz_t, then A->_mp_d[ABS(A->_mp_size) - 1] is the most
significant limb, since ABS(A->_mp_size) is the number of limbs and
the most significant limb is always nonzero. I'm not exactly sure what
happens when A is zero, but I think that ABS(A->_mp_size) is zero
then, so there are no limbs. (Someone correct me if I'm wrong!)

> Then the problem reduces to the problem of finding the most
> significant within a limb (a machine word).

In longlong.h there is a macro called count_leading_zeros that does
this.

-- 
Kalle Hasselström, kha@treskal.com
      www.treskal.com/kalle

From deltatrinity@hotmail.com  Wed Nov 27 16:22:00 2002
From: deltatrinity@hotmail.com (delta trinity)
Date: Wed, 27 Nov 2002 11:22:00 -0500
Subject: find position of most significant bit ?
Message-ID: <F143XPvePX4e4yStuxn000183c3@hotmail.com>

> > I assume one knows from the data structure of an arbitrary integer
> > where the limb containing the most significant bit is.
>
>Yes. If A is an mpz_t, then A->_mp_d[ABS(A->_mp_size) - 1] is the most
>significant limb, since ABS(A->_mp_size) is the number of limbs and
>the most significant limb is always nonzero. I'm not exactly sure what
>happens when A is zero, but I think that ABS(A->_mp_size) is zero
>then, so there are no limbs. (Someone correct me if I'm wrong!)

I think this is right.  First check if A->_mp_size==0.  If so, then the 
value of A is zero.

If not, then, take the absolute value of _mp_size because negatives numbers 
are stored as positive integers inside the structure.  The sign of the 
number is stored in _mp_size (two-complement).

Then, I guess the fastest way to check, if you have a x86 class processor, 
is to use the 'bsr' assembly instruction (bit scan reverse):

(Assuming you've put the A->_mp_d[ABS(A->_mp_size)] value into edx.  You 
could also use a memory refference)

bsr   eax,edx

Then, eax contain index of most significant bit.

>
> > Then the problem reduces to the problem of finding the most
> > significant within a limb (a machine word).
>
>In longlong.h there is a macro called count_leading_zeros that does
>this.


_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail


From kha@treskal.com  Wed Nov 27 18:18:37 2002
From: kha@treskal.com (Karl =?iso-8859-1?Q?Hasselstr=F6m?=)
Date: Wed, 27 Nov 2002 19:18:37 +0100
Subject: find position of most significant bit ?
In-Reply-To: <F143XPvePX4e4yStuxn000183c3@hotmail.com>
References: <F143XPvePX4e4yStuxn000183c3@hotmail.com>
Message-ID: <20021127181837.GA6682@treskal.com>

On 2002-11-27 11:22:00 -0500, delta trinity wrote:
> 
> Then, I guess the fastest way to check, if you have a x86 class processor, 
> is to use the 'bsr' assembly instruction (bit scan reverse):
> 
> (Assuming you've put the A->_mp_d[ABS(A->_mp_size)] value into edx.  You 
> could also use a memory refference)
> 
> bsr   eax,edx
> 
> Then, eax contain index of most significant bit.

Use the count_leading_zeros macro. It is defined in terms of some
inline assembly something for lots of processors. It seems to use the
bsrl instruction for at least some x86 variants.

-- 
Kalle Hasselström, kha@treskal.com
      www.treskal.com/kalle

From librik@panix.com  Wed Nov 27 23:04:21 2002
From: librik@panix.com (librik@panix.com)
Date: Wed, 27 Nov 2002 18:04:21 -0500 (EST)
Subject: Building on Win2K
Message-ID: <200211272304.gARN4LP25796@panix2.panix.com>

> > I wonder if it's possible to build a version of gas that spits out
> > .obj (intel OMF) and which would work with msvc.
> 
> Which just goes to show how little I know about msvc.  Supposedly it's
> coff not omf already, but maybe with gratuitous differences from what
> everyone else calls coff.

I have no problem using the output from gas ("as" under Cygwin)
in the Microsoft linker.  This is how I build GMP from unmodified
sources using the standard configure system.  (I wrote wrapper
scripts around the MSVC compiler and linker to make them "look"
more like Unix-style compilers.  Modulo a major bug in libtool,
everything works perfectly.  I should probably release this as
it would save people's porting time, but it's kind of clumsy
due to the libtool bug workarounds.)

What problems are you having, and what versions of as and link
are you using?

- David Librik

From user42@zip.com.au  Wed Nov 27 23:29:17 2002
From: user42@zip.com.au (Kevin Ryde)
Date: Thu, 28 Nov 2002 09:29:17 +1000
Subject: Building on Win2K
In-Reply-To: <200211272304.gARN4LP25796@panix2.panix.com> (<librik@panix.com>'s
 message of "Wed, 27 Nov 2002 18:04:21 -0500 (EST)")
References: <200211272304.gARN4LP25796@panix2.panix.com>
Message-ID: <87znruh9rm.fsf@zip.com.au>

<librik@panix.com> writes:
>
> I have no problem using the output from gas ("as" under Cygwin)
> in the Microsoft linker.  This is how I build GMP from unmodified
> sources using the standard configure system.

Ah right.

> (I wrote wrapper
> scripts around the MSVC compiler and linker to make them "look"
> more like Unix-style compilers.

That'd be the way to go.

> Modulo a major bug in libtool,
> everything works perfectly.  I should probably release this as
> it would save people's porting time, but it's kind of clumsy
> due to the libtool bug workarounds.)

Something like that is probably good value because in theory it helps
all gnu software.  Maintaining something specific in gmp is a bit too
much like hard work.

> What problems are you having, and what versions of as and link
> are you using?

Me?  No, I was just speculating.  My normal w32 setup, such as it is,
is the debian mingw32 cross compiler plus wine.

It's a bit hard to be motivated about an egregiously non-free
environment like w32+msvc, but people ask for it, having apparently
not yet had their eyes opened to the benefits of a gnu or bsd system.

From pleyland@microsoft.com  Thu Nov 28 11:12:50 2002
From: pleyland@microsoft.com (Paul Leyland)
Date: Thu, 28 Nov 2002 03:12:50 -0800
Subject: Building on Win2K
Message-ID: <92456F6B84D1324C943905BEEAE0278E013412E2@RED-MSG-10.redmond.corp.microsoft.com>

> It's a bit hard to be motivated about an egregiously non-free
> environment like w32+msvc, but people ask for it, having apparently
> not yet had their eyes opened to the benefits of a gnu or bsd system.

I am self-evidently biased (look at my email address) and self-evidently =
bizarre in that I run BSD and gnu systems (look at my email address) so =
perhaps anything I say should be treated with suspicion.  In any event, =
anything I say should be treated as entirely my own personal ramblings =
and are in no way speaking for what my employer (look at my email =
address) may or may not think of the subject.

Disclaimer aside, my personal view is that GMP is an excellent package =
for number theoretical computations and should be ported widely, =
including to systems that may not be used by a number of its authors.  =
It is entirely understandable that it installs and runs most easily on =
the authors' systems.  It is also entirely desirable that it installs =
and runs easily on other systems.  The saying about sauces and genders =
of geese comes to mind when contemplating the similarities in difficulty =
of getting some systems' software to work in other systems' =
environments.

Philosophical meanderings aside, a more practical observation is that =
Microsoft's Services for Unix, currently at V3.0, makes porting =
GMP-using software to a Win32 environment extremely easy.  It just works =
straight out of the box.  The Unix-like tools you need, and most of the =
ones you expect, are present and the "./configure; make; make check; =
make install" idiom does The Right Thing.  You do have to install the =
gcc portion of SFU and it doesn't then use MSVC, but it does work =
nicely.  (And yes, MS does openly redistribute some (L)GPL software and =
it does, of course, abide by the relevant licenses: a state of affairs =
some find surprising for some reason.)

Personally I prefer the MSVC development environment to the gcc command =
line, though Emacs makes gcc tolerable, but after a lifetime of typing =
escape-meta-alt-control-shift chords I'm forever having to correct typos =
in my code because I let my subconscious do too much of my fingerwork.

Paul


From nisse@lysator.liu.se  Thu Nov 28 11:42:10 2002
From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=)
Date: 28 Nov 2002 12:42:10 +0100
Subject: Building on Win2K
In-Reply-To: <92456F6B84D1324C943905BEEAE0278E013412E2@RED-MSG-10.redmond.corp.microsoft.com>
References: <92456F6B84D1324C943905BEEAE0278E013412E2@RED-MSG-10.redmond.corp.microsoft.com>
Message-ID: <nnof899azx.fsf@fafner.lysator.liu.se>

"Paul Leyland" <pleyland@microsoft.com> writes:

> Philosophical meanderings aside, a more practical observation is
> that Microsoft's Services for Unix, currently at V3.0, makes porting
> GMP-using software to a Win32 environment extremely easy. It just
> works straight out of the box.

Can you compile GMP into a dll using this "SFU" package, and use the
resulting library with programs written using MSVC? I library that can
be used with MSVC-projects seems to be what most of the windows folks
in this list want.

How do you get the Services for Unix package? A few years ago I used
windows at work, and I stumbled upon the documentation for the M$ gcc,
but I didn't have it installed and I don't think our IT staff had ever
heard of it.

Out of curiosity, if you get the source code of the SFU package (or
the parts thereof that are (L)GPL:ed), does it compile out of the box
with MSVC?

/Niels

From pleyland@microsoft.com  Thu Nov 28 11:59:03 2002
From: pleyland@microsoft.com (Paul Leyland)
Date: Thu, 28 Nov 2002 03:59:03 -0800
Subject: Building on Win2K
Message-ID: <92456F6B84D1324C943905BEEAE0278E013412E3@RED-MSG-10.redmond.corp.microsoft.com>

#include <disclaimer.h>

> Can you compile GMP into a dll using this "SFU" package, and use the
> resulting library with programs written using MSVC? I library that can
> be used with MSVC-projects seems to be what most of the windows folks
> in this list want.

I don't know because I haven't tried.  I reported only what I did and
what I found.  What I found was satisfactory for me.

> How do you get the Services for Unix package? A few years ago I used
> windows at work, and I stumbled upon the documentation for the M$ gcc,
> but I didn't have it installed and I don't think our IT staff had ever
> heard of it.

http://www.microsoft.com/windows/sfu/default.asp

> Out of curiosity, if you get the source code of the SFU package (or
> the parts thereof that are (L)GPL:ed), does it compile out of the box
> with MSVC?

Don't know, sorry, again because I haven't tried.

Paul

From brg@gladman.plus.com  Thu Nov 28 12:03:59 2002
From: brg@gladman.plus.com (Brian Gladman)
Date: Thu, 28 Nov 2002 12:03:59 -0000
Subject: Building on WIn2K
Message-ID: <000501c296d6$3cc36000$f87e38d4@fortyfour>

Paul Leyland wrote:

> Personally I prefer the MSVC development environment to the gcc command =
> line, though Emacs makes gcc tolerable, but after a lifetime of typing =
> escape-meta-alt-control-shift chords I'm forever having to correct typos =
> in my code because I let my subconscious do too much of my fingerwork.

I also prefer the MSVC development environment.

And this is not because I have 'not yet had my eyes opened' since I have
used both environments and do find some aspects of the gcc toolset
impressive.

   Brian Gladman