On Fri, 26 Feb 2016 09:04:23 +0100
FRIGN <dev_AT_frign.de> wrote:
> On Fri, 26 Feb 2016 07:54:26 +0100
> isabella parakiss <izaberina_AT_gmail.com> wrote:
>
> Hey izabera,
>
> > the problem with factor is that any naive
> > implementation will pale against the one in gnu
> > coreutils.
> >
> > (gnu)
> > $ time factor 1267650600228402790082356974917
> > 1267650600228402790082356974917: 1125899906842679
> > 1125899906842723 real: 0m1.576s, user: 0m1.570s, sys:
> > 0m0.003s
> >
> > (yours with gmp)
> > $ time ./factor 1267650600228402790082356974917
> > 1267650600228402790082356974917: 1125899906842723
> > 1125899906842679 real: 1m11.109s, user: 1m11.013s, sys:
> > 0m0.013s
> >
> > (yours with tommath)
> > $ time ./factor 1267650600228402790082356974917
> > ^C interrupted after 20 minutes
> >
> > from at least 50x to more than 1000x slower than the
> > gnu version. does this suck less?
>
> Just use matlab or wolfram alpha. I see no need for such
Well, that is pain in the ass.
> a tool in sbase. If we lool at the history of factor(1),
> some guy came up with it and through the years, there was
> no reason not to include it in the package, however, the
> use for this software is very low.
>
> Maybe we should go back to fixing real problems and
> improve tools that people actually use.
I'm actually using factor. And it is in base systems, so
I think it should be included, but I will be simplifying
it.
>
> Cheers
>
> FRIGN
>
Received on Fri Feb 26 2016 - 09:11:20 CET