Do you think the tests in make check are sufficient to test every branch of each of those functions?
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 -~----------~----~----~----~------~----~------~--~---
