On 16 April 2010 17:02, Sergey Bochkanov <[email protected]> wrote: > Hello, Bill. > > You wrote 16 апреля 2010 г., 15:07:18: > >> The things wrong with LGPL: >> * the number of contributors is too small even after two years of >> working on this project >> * companies are suspicious of it - worried the license will be changed >> to GPL (I know this for a fact, I'm not surmising) >> * if we use version 2.1 we can't use code from GMP and contributors >> who refuse to use v3+ only (of which there are numerous) >> It's BSD or v3+. We don't have any other viable options. And we've >> demonstrated that. If MPIR was going to get piles of regular >> contributors, we would have done by now. > > Thanks for the clarification. One more question: what's with interface > of the new library? Will it be close to the GMP's one? That would make > porting existing applications much more easier. > > Of course, there are things that are just source of confusion. It > would be good to drop them from new library. For example: > * inconsistent sizes of mp_exp_t/mp_bitcnt_t/... Sometimes they are 4, > sometimes they are 8 (depending on compiler, OS and CPU). It makes > writing cross-platform programs harder. Using GMP from another > languages becomes harder too. Many modern languages aim to be > platform-agnostic, i.e. program should work independently of the > 32/64 bit issues. But it is hard to achieve when underlying GPM > API changes when moving to another platform. C# program, for > example, works as 32-bit under x86, but it works as 64-bit under > x86_64.
This is, in my opinion, difficult to do anything about. The efficiency of arithmetic heavily depends on whether you use 32 or 64 bit, and GMP and MPIR aim to be efficient. However, I also believe it is becoming less important. Most Windows users have finally heard that 64 bit machines exist and some of them are actually buying them. So soon, everyone will have a 64 bit machine and 32 bit machines will not exist. In my opinion, 128 bit machines will never become useful for mp arithmetic, if they are ever built. So the situation seems to be normalising somewhat (other issues are becoming more important, such as parallelism). > * lack of normal error handling (out of memory, division by zero, > mpf_t underflow) I'm not sufficiently expert at floating point arithmetic to comment on this. The experts tell me that the mpf stuff in MPIR could be dropped without anyone caring. That suits me fine. I think MPFR should be used for such things as it is much better. As for future directions of the library. I think it is too early to set any long term objectives. The key to success will be to get something up and running as soon as possible, and so this means limiting the goals. For my money, that means 64 bit only, from the start, and concentrate on implementing the GMP mpn level only (albeit renamed). In 6 to 12 months we can re-evaluate and see how successful we've been. I've had more off list support for a BSD library today. See that never happened for MPIR. I had completely underestimated how much support there would be for a BSD licensed library. We'll see how much the enthusiasm turns into code. That is something we will have to evaluate over time. The next steps will be to get a website and devel list up and running. The latter is trivial and I will do it as soon as we have a website up. Watch this space.... Bill. > > -- > With best regards, > Sergey mailto:[email protected] > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
