On Wednesday 25 March 2009 17:12:11 Bill Hart wrote: > 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". >
The support would still be there , just in C which we have tested. > 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 -~----------~----~----~----~------~----~------~--~---
