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 ./facto
True that, it's not useful for huge numbers.It could be optimized
(twofold) by not checking odd numbers. And around fivefold by taking
having a limit set as sqrt(n) after that. I think there's a better
solution for factor than to use gmp.
On Thu, Feb 25, 2016 at 7:41 PM, Mattias Andrée wrote:
> O
On Thu, 25 Feb 2016 19:26:52 -0300
Marc Collin wrote:
> 600851475143
That's just not fair.
I changed to 9223372036854775803 and ran.
Overflowed after 1:25.827 minutes. Will
take run now with unsigned long (long).
pgpHAeU_NJI5l.pgp
Description: OpenPGP digital signature
#include
int main(void)
{
int i = 2;
long n = 600851475143;
for (; n > 1; i++)
for (; n % i == 0; n /= i)
printf("%d\n", i);
return 0;
}
On Thu, Feb 25, 2016 at 7:15 PM, FRIGN wrote:
> On Thu, 25 Feb 2016 23:03:14 +0100
> Mattias Andrée wrote:
>
> Hey Mattias,
>
>> I ha
On Thu, 25 Feb 2016 23:15:46 +0100
FRIGN wrote:
> On Thu, 25 Feb 2016 23:03:14 +0100
> Mattias Andrée wrote:
>
> Hey Mattias,
>
> > I haven't spent too much time on it. But why don't we
> > need factor, it is in coreutils and is useful to have?
>
> why not just write a naive implementation,
On Thu, 25 Feb 2016 23:03:14 +0100
Mattias Andrée wrote:
Hey Mattias,
> I haven't spent too much time on it. But why don't we
> need factor, it is in coreutils and is useful to have?
why not just write a naive implementation, using no external libs.
I'm sure you can write a prime factorizer in
On Thu, 25 Feb 2016 21:58:32 +
Dimitris Papastamos wrote:
> We don't need a factor implementation in sbase. In the
> future, if you are unsure on whether a particular tool is
> needed or to avoid duplicated effort in case someone else
> is working on it, ask on the mailing list first.
>
I
On Thu, 25 Feb 2016 22:44:41 +0100
Mattias Andrée wrote:
> To GMP I assume.
To both.
--
FRIGN
We don't need a factor implementation in sbase. In the future, if you
are unsure on whether a particular tool is needed or to avoid duplicated
effort in case someone else is working on it, ask on the mailing list
first.
On Thu, 25 Feb 2016 22:54:17 +0100
FRIGN wrote:
> On Thu, 25 Feb 2016 22:44:41 +0100
> Mattias Andrée wrote:
>
> > To GMP I assume.
>
> To both.
>
pthreads too?
What should I use instead, or are you against threading?
pgppcFT8U0JPn.pgp
Description: OpenPGP digital signature
On Thu, 25 Feb 2016 22:41:45 +0100
FRIGN wrote:
> On Thu, 25 Feb 2016 21:48:52 +0100
> Mattias Andrée wrote:
>
> Hey Mattias,
>
> > +sbase: LDFLAGS += -lgmp -lpthread
> > +factor: LDFLAGS += -lgmp -lpthread
> > +++ b/factor.c
>
> No.
To GMP I assume.
>
> Cheers
>
> FRIGN
>
pgpkyuzQp
On Fri, 26 Feb 2016 10:09:58 +1300
David Phillips wrote:
> I am largely unfamiliar with sbase's codebase, but I
> wonder what the rest of the community will think of using
> GMP in an sbase tool.
Precisely why I included support for libtommath.
I think the significant problem with GMP is that
yo
On Thu, 25 Feb 2016 21:48:52 +0100
Mattias Andrée wrote:
Hey Mattias,
> +sbase: LDFLAGS += -lgmp -lpthread
> +factor: LDFLAGS += -lgmp -lpthread
> +++ b/factor.c
No.
Cheers
FRIGN
--
FRIGN
I am largely unfamiliar with sbase's codebase, but I wonder what the rest of
the community will think of using GMP in an sbase tool.
signature.asc
Description: PGP signature
Signed-off-by: Mattias Andrée
---
LICENSE | 1 +
Makefile | 4 +
README | 1 +
factor.1 | 62 ++
factor.c | 667 +++
5 files changed, 735 insertions(+)
create mode 100644 factor.1
create mode 100644 factor.c
diff --git a
On Thu, 25 Feb 2016 15:36:33 +0100
quinq wrote:
> Hi,
>
> > > > 2) Should it be able to do a dry run, would be
> > > > another flag that can be used independently of
> > > > -w?
> > >
> > > Yes it would be nice to support a dry run flag
> > > regardless of whether -w is specified or not.
Hi,
> > > 2) Should it be able to do a dry run, would be another flag
> > >that can be used independently of -w?
> >
> > Yes it would be nice to support a dry run flag regardless of
> > whether -w is specified or not.
>
> gnu patch supports --dry-run. It probably makes sense
> to support
On Thu, 25 Feb 2016 13:36:25 +
Dimitris Papastamos wrote:
> I don't see how this has to do with handholding users.
It's simple. Handholding for me is you offer things which purposely
allow the user not to do certain things.
This whitespace flag purpots that the user won't have to read patche
On Thu, 25 Feb 2016 13:45:58 +
Dimitris Papastamos wrote:
> On Thu, Feb 25, 2016 at 02:42:42PM +0100, Mattias Andrée
> wrote:
> > On Thu, 25 Feb 2016 14:11:05 +0100
> > FRIGN wrote:
> >
> > > On Thu, 25 Feb 2016 13:39:30 +0100
> > > Mattias Andrée wrote:
> > >
> > > Hey Matthias,
> > >
On Thu, Feb 25, 2016 at 02:42:42PM +0100, Mattias Andrée wrote:
> On Thu, 25 Feb 2016 14:11:05 +0100
> FRIGN wrote:
>
> > On Thu, 25 Feb 2016 13:39:30 +0100
> > Mattias Andrée wrote:
> >
> > Hey Matthias,
> >
> > > I think the documentation should be clear that it
> > > only to be relied upon
On Thu, 25 Feb 2016 14:11:05 +0100
FRIGN wrote:
> On Thu, 25 Feb 2016 13:39:30 +0100
> Mattias Andrée wrote:
>
> Hey Matthias,
>
> > I think the documentation should be clear that it
> > only to be relied upon if whitespace changes do
> > not have any affects. Perhaps it should not allow
> > i
On Thu, Feb 25, 2016 at 02:11:05PM +0100, FRIGN wrote:
> On Thu, 25 Feb 2016 13:39:30 +0100
> Mattias Andrée wrote:
>
> Hey Matthias,
>
> > I think the documentation should be clear that it
> > only to be relied upon if whitespace changes do
> > not have any affects. Perhaps it should not allow
On Thu, 25 Feb 2016 13:39:30 +0100
Mattias Andrée wrote:
Hey Matthias,
> I think the documentation should be clear that it
> only to be relied upon if whitespace changes do
> not have any affects. Perhaps it should not allow
> introducing whitespace where there was none,
>
>-helloworld
>
On Thu, 25 Feb 2016 13:29:07 +0100
v4hn wrote:
> On Thu, Feb 25, 2016 at 11:24:25AM +, Dimitris
> Papastamos wrote:
> > On Wed, Feb 24, 2016 at 08:54:13PM +0100, Mattias
> > Andrée wrote:
> > > I'm thinking about introducing an extension to the
> > > standard: -w. When this flag is used, pa
On Thu, 25 Feb 2016 13:29:07 +0100
v4hn wrote:
> On Thu, Feb 25, 2016 at 11:24:25AM +, Dimitris
> Papastamos wrote:
> > On Wed, Feb 24, 2016 at 08:54:13PM +0100, Mattias
> > Andrée wrote:
> > > I'm thinking about introducing an extension to the
> > > standard: -w. When this flag is used, pa
On Thu, 25 Feb 2016 13:29:07 +0100
v4hn wrote:
Hey v4hn,
> Sounds useless to me. What counts as whitespace change?
> `if(x){ \n` -> `if(x){\n`, ok,
> `\tif(x){\n` -> ` if(x){\n`, in python and haskell probably not,
> `if(x){\n` -> `if(x) {\n`, seems simple enough,
> `printf("%d",x);\n` -> `pr
On Thu, Feb 25, 2016 at 11:24:25AM +, Dimitris Papastamos wrote:
> On Wed, Feb 24, 2016 at 08:54:13PM +0100, Mattias Andrée wrote:
> > I'm thinking about introducing an extension to the standard: -w.
> > When this flag is used, patch will verify that the patchfile
> > only changes whitespace in
On Wed, Feb 24, 2016 at 08:54:13PM +0100, Mattias Andrée wrote:
> Hi!
>
> I'm working on implementing patch(1). I'm thinking about
> introducing an extension to the standard: -w. When this
> flag is used, patch will verify that the patchfile only
> changes whitespace in the file.
>
> So I have 2
28 matches
Mail list logo
