On 11 Gen, 12:35, Bill Hart wrote:
> Nah, the discussion is over.
Ok, you chose the easiest way: to escape.
> Your suggestion of me donating code to the FSF shows you have totally
> missed the point.
It was too much, I realised while trying to write the 10 lines... too
easy for such a big price
Nah, the discussion is over.
Your suggestion of me donating code to the FSF shows you have totally
missed the point.
Why should I donate a few thousand lines of my own code to them
because you donate 10 lines to us?
Go away. You are just being rude. I can write the lines myself.
I personally th
> I am afraid that you are misusing my benchmark, which I provede as a
> way of monitoring aspects of MPIR development.
[...]
> It is NOT intended for use in comparing MPIR and GMP and, as you have
> quickly discovered, it is completely inappropriate for this.
I'm afraid you should explain this to
On Jan 11, 7:48 am, Gianrico Fini wrote:
> I missed this yesterday... (I was sleepy)
>
> On 11 Gen, 03:50, Bill Hart wrote:
>
> > > We finally agree! That function is a joke!
>
> > I'm talking about the real mpn_mulmod_2expp1 function in mpn/generic,
> > not the stupid alternative in the bench
I missed this yesterday... (I was sleepy)
On 11 Gen, 03:50, Bill Hart wrote:
> > We finally agree! That function is a joke!
>
> I'm talking about the real mpn_mulmod_2expp1 function in mpn/generic,
> not the stupid alternative in the benchmark.
You say the real function is a joke, and the alter
On 11 Gen, 04:44, Bill Hart wrote:
> Take as much time as you like. I think I would be quite impressed if
> it really works for all inputs and is relatively fast. I am not sure I
> could do it properly in 10 lines (unless they were exceptionally long
> lines). You have to do a bit shift and subtra
Take as much time as you like. I think I would be quite impressed if
it really works for all inputs and is relatively fast. I am not sure I
could do it properly in 10 lines (unless they were exceptionally long
lines). You have to do a bit shift and subtract, then deal with the
carries. Then there a
> What will you do if I win?
Ok... I'll know it tomorrow...
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@go
On 11 Gen, 04:09, Bill Hart wrote:
> That's all rubbish and you know it. My reply to you, which you keep
> quoting, was in reply to you where you are talking about Case's
> benchmarks. It was in that context.
>
> You lied. You cheated. And you know it.
>
> Still waiting on those 10 line patches.
That's all rubbish and you know it. My reply to you, which you keep
quoting, was in reply to you where you are talking about Case's
benchmarks. It was in that context.
You lied. You cheated. And you know it.
Still waiting on those 10 line patches. One to speed up nextprime and
one to implement a
> it wasn't a fake argument at all. Your claim was that these Core 2
> benchmarks of Case's show that MPIR is only faster for multiplication
> above 10 digits and nothing else. But that is completely *false*,
> (his benchmarks didn't show that at all - you lied, and his benchmarks
> only includ
2010/1/11 Gianrico Fini :
> Pardon?
>
>> Because it is not possible to come up with an efficient replacement
>> for mpn_mulmod_2expp1 using powm. The object of the benchmark was to
>> show what is possible using a new mpn function we had added and which
>> (at the time) was not available in GMP.
>
2010/1/11 Gianrico Fini :
> On 11 Gen, 03:14, Bill Hart wrote:
>> Ha ha, very funny cheater. Your function is only faster for full limbs!!
>
> Well, Fermat numbers with k>=5 use full limbs!
Yes, true. But that just illustrates that this particular test is not
a good one for showing off our functi
Pardon?
> Because it is not possible to come up with an efficient replacement
> for mpn_mulmod_2expp1 using powm. The object of the benchmark was to
> show what is possible using a new mpn function we had added and which
> (at the time) was not available in GMP.
I do really not follow you... let
On 11 Gen, 03:14, Bill Hart wrote:
> Ha ha, very funny cheater. Your function is only faster for full limbs!!
Well, Fermat numbers with k>=5 use full limbs!
> What do you think the other hundred or so lines of mpn/generic/mulmod_2expp1
> do?
I do not know, I did not read the function, nor I kn
2010/1/11 Gianrico Fini :
>> With all due respect, I think you are vastly underestimating the
>> difficulty of providing robust, efficient, well tested code for your
>> benefit. There's tens of thousands of lines of code been put into the
>> MPIR library, and to just dismiss it all as a joke becaus
> With all due respect, I think you are vastly underestimating the
> difficulty of providing robust, efficient, well tested code for your
> benefit. There's tens of thousands of lines of code been put into the
> MPIR library, and to just dismiss it all as a joke because you found
> something which
Ha ha, very funny cheater. Your function is only faster for full limbs!!
What do you think the other hundred or so lines of mpn/generic/mulmod_2expp1 do?
Everyone notice what a silly cheater gian is. Ha ha ha ha!!!
More seriously, what do you think you have just proved?
The powm idea was ok. Bu
2010/1/11 Gianrico Fini :
> It is not a matter of GMP5! on my laptop GMP4 is faster than MPIR, but
> your fake_bench_two claims it is slower!
> Why? Because it does not use the _documented_ (it is there from YEARS,
> not days) function mpz_powm!
> It does a _fake_ exponentiation using a _SL
When it will be stable and documented, it will make sense using it...
But now I'm playing with the stable version. Try this ten-lines patch:
--- mpir_bench_two/fermat_prime_p.c 2010-01-11 02:12:21.0
+0100
+++ mpir_bench_two/fermat_prime_p.c.orig2010-01-11 01:47:44.0
+01
It is not a matter of GMP5! on my laptop GMP4 is faster than MPIR, but
your fake_bench_two claims it is slower!
Why? Because it does not use the _documented_ (it is there from YEARS,
not days) function mpz_powm!
It does a _fake_ exponentiation using a _SLOOW_ stupid trick
instead of squ
21 matches
Mail list logo
