That's a function of our growing arsenal of machines to test on, and the (unspecified) machines which sage developers test on.
The reason for specifying a moving wall dependent on some measurable metric is that: 1) It doesn't depend on us (what we test on does) 2) It gives a rationale for retiring assembly support which we can easily explain to people. I just want to avoid people saying, "oh, I wouldn't use MPIR, they don't test on lots of architectures and when they can't be bothered any more, they just remove support for them". I would prefer people to say that MPIR supports processors manufactured in the last 20 years. It sounds very reasonable and people can easily tell that it isn't going to affect them. Everyone knows they will upgrade their machine they just bought, within 20 years. Bill. 2009/3/25 Jason Moxham <ja...@njkfrudils.plus.com>: > > > How about we cut out the cpu's that haven't been tested for x years say. If we > are going to rewrite/reorganize the mpn layer , then only the modern cpus and > C version will be tested anyway. > > On Wednesday 25 March 2009 16:38:28 Bill Hart wrote: >> One thing we could do is remove support for chips with a "rolling >> wall". If the manufacturing date for that architecture is more than >> 10, 15 or 20 years ago, say, we could remove support for it. >> >> Funnily enough, this may not cut much out. The Intel 80386 for example >> ceased to be made in September 2007!! Perhaps if we take the 21 years >> of manufacture for this CPU as a benchmark, that would mean we cut out >> any CPU's which were first manufactured 21 years or more ago, i.e. >> before March 1988. >> >> Often military, aerospace and embedded applications see the lifespans >> of chips hyperextended. >> >> Perhaps, given that MPIR will still run on them, with C support only, >> we can afford to have a more recent wall, say 15 years ago. That would >> cut out all 80486's, some pentiums, but not pentium pros, etc. >> >> Bill. >> >> 2009/3/23 Jason Moxham <ja...@njkfrudils.plus.com>: >> > On Monday 23 March 2009 16:45:53 Bill Hart wrote: >> >> 2009/3/23 Jason Moxham <ja...@njkfrudils.plus.com>: >> >> > MPFR is based on mpn and mpz , not mpf . >> >> >> >> OK, I didn't seem to know that. I probably should have though. >> >> >> >> > I suppose we get remove mpf from the default MPIR build , and only >> >> > build mpf if we configure with --enable-gmp-compat which could switch >> >> > on all the other old stuff we would like to remove. >> >> >> >> Would that actually cut down the size of MPIR? >> > >> > No , it would be bigger and more complex >> > >> >> I also don't see how say switching off nails and mpbsd, etc, would >> >> actually save development effort. If someone types --enable-gmp-compat >> >> then all that is going to have to be there (and work) anyway. >> >> >> >> Bill. >> > >> > What about some of the old cpu archs , mpir would still run on them but >> > just in C >> > >> >> > On Monday 23 March 2009 16:18:56 Bill Hart wrote: >> >> >> Hi Mariah, >> >> >> >> >> >> This would make MPIR unusable in Sage as a drop in replacement for >> >> >> GMP, and it would prevent people from using MPIR instead of GMP as a >> >> >> base for MPFR. >> >> >> >> >> >> However, if MPFR becomes independent of the mpf layer in GMP, as I >> >> >> suspect it may in the future, then it is a possibility worth >> >> >> considering. Though I'd still be worried about packages which want to >> >> >> use the mpf layer from GMP and use MPIR as a drop-in replacement. >> >> >> >> >> >> Bill. >> >> >> >> >> >> 2009/3/23 Mariah <mariah.le...@gmail.com>: >> >> >> > Bill, >> >> >> > >> >> >> > As a suggestion on something that could be removed from >> >> >> > MPIR, had you considered removing the mpf code? I was >> >> >> > under the impression that MPIR was going to concentrate on >> >> >> > multiple-precision integers and rationals, and >> >> >> > leave multiple-precision floating-point to MPFR. >> >> >> > >> >> >> > Mariah >> >> >> > >> >> >> > On Mar 20, 11:30 pm, Gonzalo Tornaria <torna...@gmail.com> wrote: >> >> >> >> On Fri, Mar 20, 2009 at 11:46 PM, Bill Hart >> >> >> >> <goodwillh...@googlemail.com> >> >> > >> >> > wrote: >> >> >> >> > I suppose it's just aggregation. >> >> >> >> > >> >> >> >> > Maybe we need to get rid of the bit that says, "overall licensed >> >> >> >> > LGPL". Is that still permitted, when some component of the >> >> >> >> > distro is GPL? >> >> >> >> >> >> >> >> Sounds like a good idea. >> >> >> >> >> >> >> >> > Actually the reason for me wanting to perhaps get rid of the >> >> >> >> > demos was more to do with the fact that I don't know anyone who >> >> >> >> > uses them. Very clear examples in the documentation would >> >> >> >> > probably be much more useful. >> >> >> >> >> >> >> >> I haven't looked at the demos, but I did want to use the benchmark >> >> >> >> and I didn't get to it until your posted howto (not that it was >> >> >> >> that hard, but I was lazy). I expect more people will use it if >> >> >> >> "make bench" just works. >> >> >> >> >> >> >> >> I'm not arguing to keep the demos, nor I am saying that benchmark >> >> >> >> code should not be rewritten and expanded. But just not because of >> >> >> >> licensing. >> >> >> >> >> >> >> >> > Anyhow, it's no big deal. Just an idea. I suppose the thing that >> >> >> >> > set off that thought process for me was Brian saying it took >> >> >> >> > forever to check out MPIR via his internet connection. We are >> >> >> >> > carrying some fat. There's no reason to not have the demos on >> >> >> >> > the website. Can't come up with as clear a case for leaving them >> >> >> >> > in the library source. >> >> >> >> >> >> >> >> Sounds fair if demos are indeed big, I have no idea how much space >> >> >> >> they take (otoh, I think Brian was updating the root of the svn >> >> >> >> repo instead of just trunk). The benchmark code is about 6kb >> >> >> >> compressed... not too bad. >> >> >> >> >> >> >> >> Gonzalo >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
