I will check it out.
On Fri, 26 Feb 2016 11:40:51 -0300
Marc Collin wrote:
> A contributor already started working on a suckless
> bignum library[0] to use on his bc(1) candidate for
> sbase[1]. Mattias maybe you want to work on that instead
> of starting from scratch. Duplicating efforts is usu
A contributor already started working on a suckless bignum library[0]
to use on his bc(1) candidate for sbase[1].
Mattias maybe you want to work on that instead of starting from
scratch. Duplicating efforts is usually not good when all have the
same goal (suckless bignum, dc and bc).
[0] https://g
On Fri, 26 Feb 2016 11:55:12 +
Dimitris Papastamos wrote:
> On Fri, Feb 26, 2016 at 12:45:27PM +0100, Mattias Andrée
> wrote:
> > On Fri, 26 Feb 2016 11:39:07 +
> > Dimitris Papastamos wrote:
> >
> > > On Fri, Feb 26, 2016 at 12:33:37PM +0100, Mattias
> > > Andrée wrote:
> > > > On
On Fri, Feb 26, 2016 at 12:48:09PM +0100, Jens Staal wrote:
> On 2016 M02 26, Fri 09:11:20 CET Mattias Andrée wrote:
> > I'm actually using factor. And it is in base systems, so
> > I think it should be included, but I will be simplifying
> > it.
>
> What about including it in ubase instead?
That
On Fri, Feb 26, 2016 at 12:45:27PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 11:39:07 +
> Dimitris Papastamos wrote:
>
> > On Fri, Feb 26, 2016 at 12:33:37PM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 11:31:31 +
> > > Dimitris Papastamos wrote:
> > >
> > > > O
On Fri, 26 Feb 2016 12:48:09 +0100
Jens Staal wrote:
> On 2016 M02 26, Fri 09:11:20 CET Mattias Andrée wrote:
> > I'm actually using factor. And it is in base systems, so
> > I think it should be included, but I will be simplifying
> > it.
>
> What about including it in ubase instead?
>
Why
On 2016 M02 26, Fri 09:11:20 CET Mattias Andrée wrote:
> I'm actually using factor. And it is in base systems, so
> I think it should be included, but I will be simplifying
> it.
What about including it in ubase instead?
On Fri, 26 Feb 2016 11:39:07 +
Dimitris Papastamos wrote:
> On Fri, Feb 26, 2016 at 12:33:37PM +0100, Mattias Andrée
> wrote:
> > On Fri, 26 Feb 2016 11:31:31 +
> > Dimitris Papastamos wrote:
> >
> > > On Fri, Feb 26, 2016 at 12:28:32PM +0100, Mattias
> > > Andrée wrote:
> > > > On
On Fri, Feb 26, 2016 at 12:33:37PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 11:31:31 +
> Dimitris Papastamos wrote:
>
> > On Fri, Feb 26, 2016 at 12:28:32PM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 11:26:15 +
> > > Dimitris Papastamos wrote:
> > >
> > > > O
On Fri, 26 Feb 2016 11:31:31 +
Dimitris Papastamos wrote:
> On Fri, Feb 26, 2016 at 12:28:32PM +0100, Mattias Andrée
> wrote:
> > On Fri, 26 Feb 2016 11:26:15 +
> > Dimitris Papastamos wrote:
> >
> > > On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias
> > > Andrée wrote:
> > > > On
On Fri, Feb 26, 2016 at 12:28:32PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 11:26:15 +
> Dimitris Papastamos wrote:
>
> > On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 10:07:31 +
> > > Dimitris Papastamos wrote:
> > >
> > > > O
On Fri, 26 Feb 2016 11:26:15 +
Dimitris Papastamos wrote:
> On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias Andrée
> wrote:
> > On Fri, 26 Feb 2016 10:07:31 +
> > Dimitris Papastamos wrote:
> >
> > > On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias
> > > Andrée wrote:
> > > > On
On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 10:07:31 +
> Dimitris Papastamos wrote:
>
> > On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 09:43:02 +0100
> > > FRIGN wrote:
> > >
> > > > On Fri, 26 Feb
On Fri, 26 Feb 2016 10:07:31 +
Dimitris Papastamos wrote:
> On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias Andrée
> wrote:
> > On Fri, 26 Feb 2016 09:43:02 +0100
> > FRIGN wrote:
> >
> > > On Fri, 26 Feb 2016 09:37:12 +0100
> > > Mattias Andrée wrote:
> > >
> > > Hey Mattias,
> > >
On Fri, 26 Feb 2016 10:07:32 +0100
hiro <23h...@gmail.com> wrote:
> simple doesn't say anything about size.
>
I know. But what is this in reference too?
pgpHr7pRYVnIG.pgp
Description: OpenPGP digital signature
On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 09:43:02 +0100
> FRIGN wrote:
>
> > On Fri, 26 Feb 2016 09:37:12 +0100
> > Mattias Andrée wrote:
> >
> > Hey Mattias,
> >
> > > Mostly random things, but regularly when I correct maths
> > > tests.
> >
> >
simple doesn't say anything about size.
On Fri, 26 Feb 2016 09:45:41 +0100
isabella parakiss wrote:
> On 2/26/16, Mattias Andrée wrote:
> > Performance is not really something suckless
> > concerns itself about. They favour solutions
> > that are simpler to implement and maintain
> > but asymptotically slower. But in the case of
>
On 26 February 2016 at 09:42, FRIGN wrote:
> On Fri, 26 Feb 2016 09:18:20 +0100
> Anselm R Garbe wrote:
> I agree with you, but sadly with numerical algorithms, the case is a
> different (it's my area of work).
I know.
> Implementing an Euler-iteration for first order separable ODE's is the
> s
On Fri, 26 Feb 2016 09:43:02 +0100
FRIGN wrote:
> On Fri, 26 Feb 2016 09:37:12 +0100
> Mattias Andrée wrote:
>
> Hey Mattias,
>
> > Mostly random things, but regularly when I correct maths
> > tests.
>
> do the primes you ask your students to study fit in 64
> bits?
>
Yes. But sometimes t
On 2/26/16, Mattias Andrée wrote:
> Performance is not really something suckless
> concerns itself about. They favour solutions
> that are simpler to implement and maintain
> but asymptotically slower. But in the case of
^^
this is awful.
i don't understand this whole approach t
On Fri, 26 Feb 2016 09:18:20 +0100
Anselm R Garbe wrote:
Hey Anselm,
I agree with you, but sadly with numerical algorithms, the case is a
different (it's my area of work).
> Of course the discussion about numeric algorithms is a bit different,
> though still a simple implementation should not i
On Fri, 26 Feb 2016 09:37:12 +0100
Mattias Andrée wrote:
Hey Mattias,
> Mostly random things, but regularly when I correct maths
> tests.
do the primes you ask your students to study fit in 64 bits?
--
FRIGN
On Fri, 26 Feb 2016 09:20:58 +0100
FRIGN wrote:
> On Fri, 26 Feb 2016 09:11:20 +0100
> Mattias Andrée wrote:
>
> Hey Mattias,
>
> > Well, that is pain in the ass.
>
> I know Matlab is a pain in the ass, but it's going to be
> academia mostly who would be "eligible" to use factor(1)
> for so
On Fri, 26 Feb 2016 09:18:20 +0100
Anselm R Garbe wrote:
> On 26 February 2016 at 09:01, Mattias Andrée
> wrote:
> > Performance is not really something suckless
> > concerns itself about. They favour solutions
> > that are simpler to implement and maintain
> > but asymptotically slower. But in
On Fri, 26 Feb 2016 09:11:20 +0100
Mattias Andrée wrote:
Hey Mattias,
> Well, that is pain in the ass.
I know Matlab is a pain in the ass, but it's going to be
academia mostly who would be "eligible" to use factor(1)
for something.
What I could live with is having a naive implementation,
so Joh
On 26 February 2016 at 09:01, Mattias Andrée wrote:
> Performance is not really something suckless
> concerns itself about. They favour solutions
> that are simpler to implement and maintain
> but asymptotically slower. But in the case of
I have to object here. It is correct that performance is n
On Fri, 26 Feb 2016 09:04:23 +0100
FRIGN wrote:
> On Fri, 26 Feb 2016 07:54:26 +0100
> isabella parakiss wrote:
>
> Hey izabera,
>
> > the problem with factor is that any naive
> > implementation will pale against the one in gnu
> > coreutils.
> >
> > (gnu)
> > $ time factor 12676506002284027
On Fri, 26 Feb 2016 07:54:26 +0100
isabella parakiss 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 1125899
On Fri, 26 Feb 2016 07:54:26 +0100
isabella parakiss wrote:
> the problem with factor is that any naive implementation
> will pale against the one in gnu coreutils.
>
> (gnu)
> $ time factor 1267650600228402790082356974917
> 1267650600228402790082356974917: 1125899906842679
> 1125899906842723 re
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
45 matches
Mail list logo
