I've had a think, especially considering the 10's of thousands of people who will be using MPIR in Sage, not to mention the sponsor, and I think we need to write try tests for the mpn functions we use.
We could divide the work in half by one person writing the reference tests and the other writing the lt-try tests. I volunteer to write the reference tests. I may be able to start this tomorrow after I finish with converting the core 2 code to yasm. Bill. 2009/3/4 <ja...@njkfrudils.plus.com>: > > On Wednesday 04 March 2009 23:24:59 Bill Hart wrote: >> Is there a test for lshift1, rshift1, addlsh1, addrsh1, addadd, >> addsub, sumdiff, divebyff or redc_basecase? >> >> Do we need tests for these? >> >> I know we use addadd and addsub. Do we use any of the others yet? >> > > we use lshift1 rshift1 addlsh1 sublsh1 sumdiff redc_basecase > we dont use divebyff > make check run tests for all these , but nothing in ./try > - Show quoted text - > > >> Bill. >> >> 2009/3/4 Bill Hart <goodwillh...@googlemail.com>: >> > 2009/3/4 <ja...@njkfrudils.plus.com>: >> >> On Wednesday 04 March 2009 22:40:18 Bill Hart wrote: >> >>> I'd like to propose a code freeze on all K8/K10 assembly code, which I >> >>> have now converted to yasm format, unless serious bugs are uncovered. >> >>> >> >>> If we freeze the code then we can begin testing. I propose we wear out >> >>> each and every file with /tests/devel/try including many small >> >>> operands and as many different types of data as try can throw at it. >> >> >> >> There no point both of us running the same test on cuda1 say , so who >> >> does which machine? >> > >> > I am currently running tests on a K8. >> > >> > Do you want to do cuda? >> > >> > That will be enough. >> > >> > Let me just check that: >> > >> > wbh...@host-57-44:~/mpir-trunk/tests/devel$ ./try -s 1-50 -r 10 -S >> > 1-50 mpn_blah blah blah >> > >> > does something sensible according to you? >> > >> >>> On my machine the K8 code gets a bench of 15283 which is what it got >> >>> before the conversion. Also on K10 I did cycle timings of all the >> >>> functions we care about and they did not change (to within tolerances >> >>> due to variations between runs of course). >> >>> >> >>> I'm inclined to finish the core 2 code conversion tomorrow, do some >> >>> cleaning up of the C code (insert some whitespace :-)) and then >> >>> release 1.0.0. It's just about as much work as releasing 0.9.1. >> >> >> >> wasting precious bytes with whitespace :) >> > >> > Now we know what is causing that 2 Trillion dollar debt!! >> > >> >> I thought I ran my C-code thru indent first , to use the standard format >> >> , perhaps I missed some files. I really find difficult to believe that >> >> people read code formated with the standard amount of whitespace , I'm >> >> forever scrolling up and down to try to see the rest of the >> >> function.First thing I do when reading code now is to delete most >> >> whitespace. >> > >> > Maybe I won't have much to do. I did see some code the other day that >> > I would instinctively do some things to however. It's just a knee-jerk >> > reaction. >> > >> > I used to despise whitespace too. However I did change my mind after >> > certain other programmer told me my code was sending them crosseyed. >> > Now I like the sense of peace that one gets from the whitespace. It's >> > like having a spacious office as opposed to clutter. Obviously I >> > accept it is a matter of preference and irrelevant in the scheme of >> > things. However I have observed that the majority tend to go for >> > space. >> > >> >>> By the way, make check still runs the yasm tests. >> >> >> >> It was quite a job do disable all the tests , so I left it , as it >> >> doesn't effect the correctness >> >> - Show quoted text - >> > >> > That's fine. No problem by me. >> > >> > Bill. >> >> > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ 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://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
