On Wednesday, March 26, 2014 4:28:20 AM UTC-7, Bill Hart wrote:
> Hi all,
>
>
> We still don't have any tuning code on ARM or Atom for MPIR. Note MPIR will
> run extremely slowly without new tuning values due to recent changes.
>
>
> Please let us know on the mpir-devel list if you are willing
than if we
did it the "old" way due to the fact that cache lines are aligned to 16 bytes
anyway , so it's a Valgrind problem that only they can fix. To verify this you
can delete the relavant copyi.asm file and rebuild mpir and try it again.
Jason
--
You received this mes
I see, thank you for your help and for saving a lot of my time!
If my target nehalem, then would it be Ok to configure MPIR as :
--host=nehalem-unknown-linux
?
yep , although I always use --build=
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" g
which are the lowest common
denominators.The x86_64 build is really the lowest but the current way we
arrange the directory's means it's a slow build.
Jason
==
This is the whole point. I want to link MPIR statically into my share
Ah , it looks like your linking against libgmp.a not libgmp.so ?
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr..
disable all the clever bits that configure tries
to do (and the dumb bits it does)
Thanks
Jason
==
Dear Developers,
Thank you for your efforts creating and maintaining MPIR!
I am trying to build my application (shared library) which is
M but be seen by configure.
Brian
That what I thought the GLOBAL_FUNC was for :)
I can easily add this with a script
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To pos
On Sunday, 10 June 2012 17:15:09 UTC+1, Jason Moxham wrote:
>
>
> > Hi
> >
> > I figured out what going on here , basically configure is failing to
> > populate config.h with the required
> > #define HAVE_NATIVE_mpn_addmul_2 1
> > and all the other
On Sun, 10 Jun 2012 08:07:39 -0700 (PDT)
jason wrote:
> Hi
>
> I figured out what going on here , basically configure is failing to
> populate config.h with the required
> #define HAVE_NATIVE_mpn_addmul_2 1
> and all the others , it has always done this on mingw64 but because
delete the lines in the mpn/generic/redc_2.c file
where it trys to redefine addmul_2
I don't know why configure fails to populate config.h , it manages to
do the sym links
Jason
=
On May 14, 3:45 am, Pavel Holoborodko wrote:
&
Hi
Sorry for the delay.
I seem to remember that 64bit builds are limited to 2^37 bits (16GB) , I read
it somewhere on the GMP website ,I have no idea which part of MPIR has this
restriction.
Jason
---
MPIR-2.5.1 bug
#include
#include
Whoops , found this old email on my other computer :(
If there are any other emails that I should of have answered please repost them.
Thanks
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to
Sat, 9 Jun 2012 20:00:37 +0100
Jason Moxham wrote:
> I had a quick read of the license and it's nothing special , so
> mingw64 users probably wont have an objection , but I can imagine
> other (linux users for example)people who will object to downloading
> a package which co
h they won't be using it in
anyway. We can solve this by using are automated "make dist" system to build
two varients , one pure open source version for all system except mingw64 , and
a mingw64 version which contains jwasm.
Jason
--
You received this message because you are s
On Sat, 9 Jun 2012 18:30:31 +0100
Jason Moxham wrote:
> Hm , I just assumed yasm supported masm but it's nasm . What we
> need is a masm compatible free/open source program that I can get to
> work under mingw64 then. Getting it to work under mingw64 should be
> easy.We ca
t the time I had a working
computer :(
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@google
?asm? which we supply
under mingw64
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@google
ngw64 yasm will build them
anyway
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.c
, but we could preprocess our yasm we
supply with mpir(which we do at the moment to a small extant).
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscr
I'll change the website and tested the fallbacks for the broken debian gcc-4.3.2
Brian , is there any msvc changes needed for the mpir-2.5.2 branch?
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, sen
On Sat, 9 Jun 2012 09:14:51 +0100
Jason Moxham wrote:
> This is based on the 2.5.1 branch
Thanks Jason, I have just downloaded it and saw that it is a minor
evolution of 2.5.1.
I assume that when 2.5.1 was branched from trunk, it worked on MSVC.
So what matters are any post release patc
This is based on the 2.5.1 branch
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@google
I'll change the website and tested the fallbacks for the broken debian gcc-4.3.2
Brian , is there any msvc changes needed for the mpir-2.5.2 branch?
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, sen
Hi
I believe it's all 64bit cpu's , but I have a proper test now (from the gcc bug
tracker so we can just use that , rather than just exclude gcc-4.3.2 as some
gcc-4.3.2 have been patched
Jason
--
You received this message because you are subscribed to the Google Groups
"mp
Yeah , it was a buggy compiler , I'll send details to the mingw64 team
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send
On Fri, 1 Jun 2012 07:52:54 +0100
Jason Moxham wrote:
> Hi
>
> it was on a sandybridge but there is nothing specific about so it
> should run on a core2
I have just built and tested the x64 static library build for
sandybridge from the MPIR SVN trunk and all tests passed.
Br
Hi
it was on a sandybridge but there is nothing specific about so it should run on
a core2
I'll try some other arches
Jason
On Fri, 1 Jun 2012 07:12:33 +0100
Jason Moxham wrote:
> Hi
>
> we get errors in these te
Hi
we get errors in these tests on mingw64
mpz/t-set_si
mpz/t-mul_i
mpz/t-fits
mpz/t-cmp_si
I'm sure they passed before , and we have made no changes , Brian I assume they
pass in MSVC ?
perhaps a compiler bug
Jason
--
You received this message because you are subscribed to the G
. This way
./configure should work with the ABI option as well
Jason
=
Hi
I properly installed MinGW64 and built MPIR-2.5.0 and MPIR-2.5.1 , there were
two trivial corrections that were needed but otherwise all was fin
ith C++
I issue a 2.5.2-rc0 later , and run a full set of tests on sandybridge , I do
have code that will test all cpus , but the runtime is probably a week :)
thanks
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to th
Yep , it looks like I have installed msys+mingw64 wrong , and even my previous
installation was wrong which would explain some dll test errors , I'll install
properly tomorrow and make sure I can compile mpir-2.5.0 and then look at 2.5.1
Jason
--
You received this message because yo
a native compiler , see the second entry in
this thread
http://groups.google.com/group/mpir-devel/browse_thread/thread/3aafeb376e39fa99/e59b242c321af5ed?lnk=gst&q=mingw64+jason#e59b242c321af5ed
I know that the mingw64 people don't this (know idea why , it's the most
sensible thin
anges from 2.5.0 were
small , it will be some silly error that I made .
I now have a working box , so I can check it out
Jason
-
Hi Vlad,
Looking through your report, I'd say that the MinGW64/sandybridge
combination is not supported
It looks like its related to this thread
http://groups.google.com/group/mpir-devel/browse_thread/thread/b440111d4048c1ec/70dfdfeee241edb2?lnk=gst&q=get_ux#70dfdfeee241edb2
a compiler bug but note the gcc version is 4.1.3 on netbsd on the gccfarm gcc70
jason
--
You received this mes
make install
you can replace the "k8" with "core2" if you think its more common
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe f
On 22 May 2012 10:10, Jeroen Demeyer wrote:
> Within the Sage project, we discovered several issues with the
> CPU/CFLAGS/MPN_PATH configuration code in MPIR-2.4.0. The code mostly
> works well, but there are a few things I would like to change.
>
> I would also like to add a configuration option
lback to -O1 is best
Jason
-
I imagine the performance hit is minimal . We have a simple testcase
int __attribute__((noinline))
foo(int i)
{
int *p = __builtin_malloc (4 * sizeof(int));
*p = 0;
p[i] = 1;
retu
reject the bad debian gcc-4.3.2 only , but I'm not sure how to get it
to select no-strict-aliasing if it fails the test.
Jason
Thanks for the information. I am forwarding this to mpir-devel to see
what Jason thinks about possibly disabling '-fstrict-aliasing
e can't use the reuse test itself as
it needs MPIR to be built first. Note GMP is also broken on gcc-4.3.2
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To
r C++, I prefer Freebasic, so you
should have a look at.
I must say I like MPIR and I some times use for calculations of number
that are to big for Freebasic.
Regards
R. Liemburg
-
Thanks , this has already been corrected in the SVN
Jason
--
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http:
fluctuating cpu speeds like power saving and turbo boost , you could try
turning these off in the bios for tuning. The existing values should be fine.
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send ema
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http:
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http:
nd if the build fails again then can you send me the tmp-karasub.s file and
config.h and the output of running config.guess
Thanks
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@g
I don't know what cpu this was on , but it's good news :)
I'll be adding ecm-6.4.2 to our standard app tests.
Jason
---
---
Hi,
GMP-ECM 6.4.2 has been released. It
will be
reading mail from the old address as well.
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir
testing my new email address
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com
Hi
GAP-4.5 compiles and runs OK for me with MPIR-2.5.1 , I would need some more
details to track this down
Thanks
Jason
Hi MPIR devs
Do any of you know what Dima is alluding to below?
-- Forwarded message --
From: Dima Pasechnik
On 16 March 2012 09:18, leif wrote:
> Jason wrote:
>>
>> I added app tests for
>> mpfr-3.1.0
>> mpfi-1.5.1
>> ecm-6.4.1
>> flint-2.3
>> pari-2.5.1
>
>
> [Apparently Jeroen missed this.]
>
>
>
>
>> and the first mi
5.tar.bz2
mpc-0.9.tar.gz
ecm-6.3.tar.gz
flint-2.1.tgz
pari-2.3.5.tar.gz
on all the usual test machines. I can easily add gap and any other smallish
packages(sage itself is too big) and/or versions.
Jason
---
Probably GAP uses some of the GMP internals. As far as I know, we
We currently test against
mpfr-3.0.1.tar.bz2
mpfi-1.5.tar.bz2
mpc-0.9.tar.gz
ecm-6.3.tar.gz
flint-2.1.tgz
pari-2.3.5.tar.gz
on all the usual test machines. I can easily add gap and any other smallish
packages(sage itself is too big) and/or versions.
Jason
---
Probably
Hi
MPIR 2.5.1 was released on 11th March 2012.
* source tarballs: http://www.mpir.org/mpir-2.5.1.tar.bz2
http://www.mpir.org/mpir-2.5.1.tar.lzma
* documentation: http://www.mpir.org/mpir-2.5.1.pdf
See the MPIR website (www.mpir.org) for known issues and a list of s
ve , even on cygwin I wouldn't
advise it , but it seems to work.
I can add it to the svn probably monday/tuesday , if the new ecm requires it
then we have to add it anyway , shouldn't take me
more than an hour. Thanks for your report.
Jason
--
You received this message because you are
e any
additional information anyone would need so that we can track down and resolve
this issue? Thanks for your time.
-David C.
Hi
MPIR does not have redc_2 , we can easily add it for the next release , if you
know autotools you can give it a go yourself.
jason
--
You received this message becaus
ct_by3 warning is known , there's no easy way to
avoid it at the moment , but when we revamp the division code it will go away ,
it's just the current division code is a right old mismash :)
We can include these batch files in the next release if you want , they need to
be under t
dont know the text was empty last time
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For mo
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http:
On Saturday 21 January 2012 17:37:27 Jason wrote:
> On Saturday 21 January 2012 15:33:12 Cactus wrote:
> > The FFT tuning appears to work in Windows but if I turn on asserts I see
> > the same problem that Jason reported earlier.
> >
> > But I don'
On Saturday 21 January 2012 15:33:12 Cactus wrote:
> The FFT tuning appears to work in Windows but if I turn on asserts I see
> the same problem that Jason reported earlier.
>
> But I don't see the out of memory problem.
>
> Brian
>
>
with asserts on it fail
On Friday 20 January 2012 02:43:11 jason wrote:
>
> On Jan 20, 1:07 am, Jason wrote:
> > On Thursday 19 January 2012 09:42:35 Jason wrote:
> >
> > > On Thursday 19 January 2012 09:32:02 Cactus wrote:
> > > > Thanks for the testing. You are right - the
On Jan 20, 1:07 am, Jason wrote:
> On Thursday 19 January 2012 09:42:35 Jason wrote:
>
> > On Thursday 19 January 2012 09:32:02 Cactus wrote:
> > > Thanks for the testing. You are right - the t-locale.c test failure is
> > > not
> > > a major concern.
t; -David C.
>
>
thanks , but configure is a machine generated file from configure.in and
autotools , so this would
not be very useful , I think autotools will fix it soon , in the next mpir we
will be upgrading to the latest
autotools anyway. the script regen in the develop directory w
out it.
>
> This is not the first time the issue has arisen - Jason and I spent some
> time working out why I could not build with mingw64 some months ago and it
> was this issue that caused the problem. It's bizarre that tools doing
> native builds fail with native line
On Thursday 19 January 2012 09:42:35 Jason wrote:
> On Thursday 19 January 2012 09:32:02 Cactus wrote:
> > Thanks for the testing. You are right - the t-locale.c test failure is not
> > a major concern.
> >
> > Has anyone tested a Linux build for the mpir-exp branc
On Thursday 19 January 2012 10:36:49 Cactus wrote:
> Thanks Jason,
>
> Right now the source code files for the mpn_* routines provide the
> interface to the new FFT are in the fft subdirectory.
>
> Does this matter - should I move them to the mpn\generic subdirectory?
&
On Thursday 19 January 2012 09:32:02 Cactus wrote:
> Thanks for the testing. You are right - the t-locale.c test failure is not
> a major concern.
>
> Has anyone tested a Linux build for the mpir-exp branch?
This will need some configure work done first , I was just waiting for it to
settle do
On Tuesday 17 January 2012 01:55:45 Case Van Horsen wrote:
> Hi,
>
> I've compiled Brian's mpir-exp branch with the VS2008 SDK and a
> modified configure.bat/make.bat. I changed the warning level to /W3
> and examined some of the warnings. The first three warnings I examined
> are:
>
> 1) mpn_ad
in cache?
>
> Bill.
>
> On 10 January 2012 18:52, Jason wrote:
> > On Tuesday 10 January 2012 14:23:35 Bill Hart wrote:
> >> I just tried removing mpn_sumdiff_n references from my code, and this
> >> slowed it down substantially. So this function is really importa
erence in timings between sumdiff and an
> add + sub is on K10 when everything is in cache?
add+sub=3.0c and sumdiff is 2.75c
>
> Bill.
>
> On 10 January 2012 18:52, Jason wrote:
> > On Tuesday 10 January 2012 14:23:35 Bill Hart wrote:
> >> I just tried removing
t; Bill.
>
> On 9 January 2012 18:01, Bill Hart wrote:
> > I wouldn't worry about it. It is possible I overwrote my timings file
> > and that the times are not affected after all.
> >
> > On 9 January 2012 17:56, Jason wrote:
> >> On Sunday 08 Jan
On Sunday 08 January 2012 11:30:05 Bill Hart wrote:
> I decided to try the FFT without addsub_n and it seems to actually go
> consistently about 3% faster, which is totally mysterious. So I have
> removed it from the two files it is defined in:
Thats very strange , I assume this is on a K10 , wha
Hi
I've created a 2.5 branch in the svn so we can start working on trunk again
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this gr
its it into L1 sized chunks , I seem to think
that it was never very effective and probably slower than a separate add/sub
for most values
> What about addsub_n?
in mpir-2.4/2.5 only atom,netburst and sandybridge dont have it
>
> Bill.
>
> On 4 January 2012 23:23, jason wrote:
&g
Hi
MPIR 2.5.0 was released on 5th January 2012.
* source tarballs: http://www.mpir.org/mpir-2.5.0.tar.bz2
http://www.mpir.org/mpir-2.5.0.tar.lzma
* documentation: http://www.mpir.org/mpir-2.5.0.pdf
See the MPIR website (www.mpir.org) for known issues and a list of
I had forgotten this but mpir-2.5.0 does have a sumdiff for core2 :)
On Dec 27 2011, 5:27 pm, Bill Hart
wrote:
> In my FFT I make use of mpn_sumdiff_n and mpn_addsub_n. It seems these
> are not exported even though there are generic C versions.
>
> Also, I see there is no sumdiff_n.as on core2 st
On Wednesday 04 January 2012 09:19:01 Jason wrote:
>
> testing the command line builds under the directory win , this is
> specifically with nehalem , vista64 , VS2008
>
> 64bit static OK
> 32bit static OK
> 64bit shared OKish , make check fails the C++ tests
> 32
n
Besides docs , I believe we are good to go
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@g
The apptests all pass in the technical sense on the gcc farm except for a mpfr
error on loulou.esiee.fr which is nothing to do with mpir , it's a missing
symbol probably fixed in a later release of mpfr . The apptest script need to
be updated so that we have proper passes and not technical ones(
mingw32 and mingw64 both pass mpir tests , the apptest scripts wont
even run yet so I'll have to do that later , only MSVC to do
MINGW32_NT-6.0 NEHALEM 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
nehalem-pc-mingw32
gcc version 4.5.2 (GCC)
NEHALEM
PASSED configure CC=gcc.exe CXX=g++.exe
PASSED
Cygwin passes mpir tests
CYGWIN_NT-6.0-WOW64 nehalem 1.7.9(0.237/5/3) 2011-03-29 10:10 i686
Cygwin
nehalem-pc-cygwin
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
gcc version 4.5.3 (GCC)
nehalem
PASSED configure CC=cc-3.exe CXX=c++-3.exe
PASSED configure CC=cc-3.exe CXX=c++-
All mpir tests pass on the gcc farm , I'l try the apptests on the farm now
Linux gcc17 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux
k10-unknown-linux-gnu
gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)
gcc17
PASSED configure CC=gcc-4.1
PASSED configure CC=gcc
On Tuesday 03 January 2012 00:06:18 Jason wrote:
> mpir tests all pass on my home net , now to do the app tests
>
>
>
the apptests all pass , so I 'll start on cugwin and mingw* and MSVC , gccfarm
is nearly done
--
You received this message because you are subscribed to
mpir tests pass on skynet , or at least all that I can automate ( must extend
this) , but I dont think the rest will tell us much new , now to do the app
tests
Linux taurus 2.6.40.3-0.fc15.x86_64 #1 SMP Tue Aug 16 04:10:59 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
nehalem-unknown-linux-gnu
g
mpir tests all pass on my home net , now to do the app tests
Linux nehalem 2.6.33.4 #3 SMP Tue Sep 21 17:42:09 CDT 2010 x86_64 Intel(R)
Core(TM) i7 CPU 920 @ 2.67GHz GenuineIntel GNU/Linux
nehalem-unknown-linux-gnu
gcc version 4.4.4 (GCC)
nehalem
PASSED configure CC=cc CXX=c++
PA
Hi
MPIR-2.5.0-rc2 is released for testing here
http://www.mpir.org/mpir-2.5.0-rc2.tar.bz2
The changes from rc1 are threshold correction for powerpc64 and sparc32/v9
and minor MSVC build tweeks
The manual has not been updated to reflect the above yet and the news files etc
,hopefully I'll
Hi
MPIR-2.5.0-rc2 is released for testing here
http://www.mpir.org/mpir-2.5.0-rc2.tar.bz2
The changes from rc1 are threshold correction for powerpc64 and sparc32/v9
and minor MSVC build tweeks
The manual has not been updated to reflect the above yet and the news files etc
,hopefully I'll
ing for MPIR.
> It's trivial to tune this FFT.
>
> Obviously as two thirds of the time is spent in butterflies, any
> assembly optimisation of these will speed things up. I don't plan to
> do this myself.
>
I can give it go , starting this week and also the
fast naive acy
On Thursday 22 December 2011 09:35:50 Jason wrote:
> Hi
>
> I've tested and done a few minor tweeks and the current svn now passes tests
> on all the gcc farm , mingw64, cygwin and mingw32
> , I'll try and do a few MSVC tests tonight , and then we can release rc2
&
ay of missed a few cases
When I've tested them , I'll change all the branches to pointer swapping and
boolean logic
So we can have addadd on every machine , which would simplify quite a bit code
Jason
--
You received this message because you are subscribed to the Google Groups
&qu
t; done into temporary space then swapped. I use this strategy a lot and
> > it doesn't affect the FFT timings.
> >
> > Bill
> >
> > On 31 December 2011 18:22, Jason wrote:
> >> On Saturday 31 December 2011 17:47:03 Jason wrote:
> >>> On Tue
On Saturday 31 December 2011 17:47:03 Jason wrote:
> On Tuesday 27 December 2011 17:27:48 Bill Hart wrote:
> > In my FFT I make use of mpn_sumdiff_n and mpn_addsub_n. It seems these
> > are not exported even though there are generic C versions.
> >
> > Also, I see
On Tuesday 27 December 2011 17:27:48 Bill Hart wrote:
> In my FFT I make use of mpn_sumdiff_n and mpn_addsub_n. It seems these
> are not exported even though there are generic C versions.
>
> Also, I see there is no sumdiff_n.as on core2 style machines. Is it
> possible to include mpn_sumdiff_n.c
-- Forwarded Message --
Subject: binomial calculation wrong?
Date: Thursday 29 December 2011, 15:39:03
From: "Michael Dambmann"
To: thempirt...@gmail.com
Dear mpir team,
I have played around with the binomial calculation.
The attached .cpp file is created with vs2010 and win7
Hi
I've tested and done a few minor tweeks and the current svn now passes tests on
all the gcc farm , mingw64, cygwin and mingw32
, I'll try and do a few MSVC tests tonight , and then we can release rc2
Jason
--
You received this message because you are subscribed to the Google Gro
On Monday 05 December 2011 18:32:00 Jason wrote:
> Hi
>
> MPIR-2.5.0-rc1 is released for testing here
>
> http://www.mpir.org/mpir-2.5.0-rc1.tar.bz2
>
> The main changes are , very briefly and incomplete
>
> new assembly code
> fat builds more effiecent on x64
&g
> -David C.
Hi
Tuning under windows is very problematic and the difference between windows and
unix tuning values is minimal . Hopefully in the next MPIR release the tuning
will work correctly under all OS'es . And note the tuning for the above part
you
mention is slow on all system
Hi
MPIR-2.5.0-rc1 is released for testing here
http://www.mpir.org/mpir-2.5.0-rc1.tar.bz2
The main changes are , very briefly and incomplete
new assembly code
fat builds more effiecent on x64
removed ancient/obsolete stuff and cleanups
new python windows build script
faster GCD code (Than
On Monday 05 December 2011 02:47:33 Dima Pasechnik wrote:
> On Sunday, December 4, 2011 5:12:21 PM UTC+8, jason wrote:
> > On Sunday 04 December 2011 08:50:21 Volker Braun wrote:
> > > When I tracked down the yasm bug I made a trac ticket at
> > > http://trac.sagemath
is weird things like this
from gmp-in.h
/* __GMP_USHRT_MAX is not "~ (unsigned short) 0" because short is promoted
to int by "~". */
#define __GMP_UINT_MAX (~ (unsigned) 0)
#define __GMP_ULONG_MAX (~ (unsigned long) 0)
#define __GMP_USHRT_MAX ((unsigned short) ~0)
alt
1 - 100 of 1548 matches
Mail list logo
