[Ecm-dev] ecm v6.0.1: library enhancement
Paul Leyland
paul at leyland.vispa.com
Dim 9 Avr 22:07:05 CEST 2006
Sounds like a very good idea to me, as long as unrealistic precision
isn't required. As long as it is understood (and documented!) that an
estimate is good only to a factor of, say, times/divide 1.5 or 1.3 or
whatever, such a function would be useful.
It should also be straightforward to gain an estimate of roughly how
many primitive operations (whether ECM addition or mulmods on integers
doesn't really matter) and how long each would be expected to take on
the cpu on which the program is running. From there, producing the
total run time is a simple multiplication.
Paul
On Sun, 2006-04-09 at 20:49, Paul Zimmermann wrote:
> Dear Thomas,
>
> I forward your suggestion to all GMP-ECM developers.
>
> Regards,
> Paul
>
> > Date: Sun, 09 Apr 2006 14:20:16 +0200
> > From: ThMO <thmo-13 at gmx.de>
> >
> > Hello Paul,
> >
> > I would like to make a suggestion in order to enhance the ECM library
> > for a function, which is able to determine the expected running time
> > for a given number to factor related to the given B1 parameter, like
> > your ecm program does already.
> >
> > Since I'm using my "general-purpose" factorization routines using
> > your ecm_factor() as the "working horse", in order to compute home-primes,
> > it would be a great benefit IMHO, if there would be a function present,
> > maybe realized as a 1st step for the stage-2 factorization of ecm_factor(),
> > which would return the estimated time needed, in order to find a factor
> > with the given B1 parameter.
> > If it could be realized as the 1st step of ecm_factor(), setting up the
> > parameters in the supplied parameter structure, another call to this
> > function could continue exactly, where the 1st call finished with e.g.
> > ECM_ECM_ESTIMATE_TIME, ECM_ECM_CONTINUE and analogous definitions for
> > ECM_PM1 and ECM_PP1...
> >
> > The problem is, if a specific composite needs to be factored, this could
> > be done using your ecm program directly and wait for the given timings.
> >
> > But this can't be done, if the program is running continously with ever
> > increasing numbers generated, so to be able to abort execution, if the
> > the processor the program is running on, will not find some factor in a
> > "reasonable" time...
> > This structure could look like:
> > struct estimated_time {
> > unsigned int years, days, seconds;
> > };
> > So if ( est.years > 0 || est.days >= 90) could abort execution in an early
> > stage, where it doesn't makes sense to continue computation (on this CPU).
> >
> > What do you think about it?
> >
> >
> > CU Tom.
> > (Thomas M.Ott)
> > Germany
> >
>
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: This is a digitally signed message part
Url: http://lists.gforge.inria.fr/pipermail/ecm-discuss/attachments/20060409/05c73180/attachment-0006.pgp
Plus d'informations sur la liste de diffusion Ecm-discuss