On 12 February 2011 13:11, Cactus <rieman...@gmail.com> wrote: > > > On Feb 12, 12:50 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >> On 12 February 2011 10:07, Cactus <rieman...@gmail.com> wrote: >> >> >> >> >> >> >> >> >> >> >> >> > On Feb 9, 10:10 am, Cactus <rieman...@gmail.com> wrote: >> >> On Feb 8, 3:50 am, Case Vanhorsen <cas...@gmail.com> wrote: >> >> >> > On Mon, Feb 7, 2011 at 7:47 AM, Cactus <rieman...@gmail.com> wrote: >> >> >> > > On Feb 7, 3:09 pm, Case Vanhorsen <cas...@gmail.com> wrote: >> >> > >> On Mon, Feb 7, 2011 at 7:00 AM, Cactus <rieman...@gmail.com> wrote: >> >> >> > >> > This would also be a significant task but it would solve this >> >> > >> > problem >> >> > >> > once and for all. >> >> >> > >> It does keep the API from growing. I can see it working with >> >> > >> statically linked applications (like gmpy) but wouldn't there be DLL >> >> > >> issues if two dynamically linked applications assumed different >> >> > >> interfaces? >> >> >> > > Only the application that made the wrong assumption :-) >> >> >> > > Brian >> >> >> > > -- >> >> > > 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 >> >> > > athttp://groups.google.com/group/mpir-devel?hl=en. >> >> >> > What about following the API in MPFR and adding mpz_set_sj where j is >> >> > defined to be intmax_t? IIUC, this should allow us to pass any integer >> >> > type. (And _uj for uintmax_t, etc.) >> >> >> > This may be the most work, but it follows the precedent set in MPFR. >> >> >> > casevh >> >> >> Yes, that's a good solution. Its a lot of work but would be worthwhile >> >> in the long term. >> >> >> How many would volunteer some effort to do this though? I am not >> >> sure I would want to embark on this as the only contributor. >> >> >> On the plus side it should not be hard to draw up a small set of >> >> 'templates' for doing this, many of which already exist in the code. >> >> >> The get/set with limb and integer size relationships greater, equal >> >> and less would be fairly standard code. >> >> >> And others would involve faking up an appropriate GMP type from >> >> similar templates. >> >> >> Brian >> >> > Case and I have been discussing how this issue should be approached in >> > an 'off list' email exchange so I want to expose a couple of options >> > here in case others have any views on the way ahead. >> >> > One option is to duplicate (or even replace) all existing 'ui/si' >> > functions so that they all use either an mp_limb_t or an mp_slimb_t (a >> > new signed limb type) for their integer parameters. >> >> There is already a signed limb format. It is called mp_limb_signed_t >> >> >> >> > This would be manly a reuse of the existing source code but we would >> > need to check that the functions still work for all the limb/integer >> > size ratios that we might come across. >> >> An mp_limb_t can currently be a short int, long or long long depending >> on platform. As far as I know, an mp_limb_t is now always 32 or 64 >> bits. Odd sizes have all vanished since the big cleanup of old arches >> that Jason did. >> >> I think there are actually some old supported platforms on which long >> is *bigger* than the supported ABI, i.e. long is bigger than an >> mp_limb_t. Whether these machines are still supported and whether >> anyone but museums still owns such machines, I am unsure. But we must >> assume they still exist. >> >> The ui functions doubtlessly exist because most people write C code >> using either ints or longs or long longs. By having a set_ui function >> for example, one can pass either an int or a long or long long into an >> MPIR function without caring about what size a limb is. This is >> definitely how it should be. >> >> This highlights what should be the correct design principle, an ui >> should be larger than any type used commonly on that architecture. >> Then one can pass any size and automatic zero or sign extension will >> take care of everything for them. Thus on 64 bit Windows an ui should >> be a unsigned long long and an si should be a long long. >> >> Note a ui/si should *NOT* in general be the same thing as an mp_limb_t >> or mp_limb_signed_t. It might be that you have an ABI=32 bits machine >> on which an mp_limb_t is a long (because that is faster and has >> hardware support) but long long is 64 bits on that machine. The ui >> functions should still use long long and set two limbs. >> >> Now of course functions like mpn_addmul_1 would *NOT* use an ui/si. >> They would specifically use an mp_limb_t. This is for performance >> reasons. So in general mpz_set_ui would NOT do the same thing as >> mpn_set_ui. This is also how things should definitely be. >> >> The only problem with this approach is if someone wants a fast >> mpz_mul_ui and an ui is currently two limbs. In this case one might >> like to have an mpz_mul_1 function which multiplies by a limb instead >> of an ui. >> >> I definitely do not think it is a good idea to allow one to specify >> the size of an ui at compile time (of MPIR). >> >> As C is a compiled language, there is no chance to do this efficiently >> at run time. >> >> The only way to do it would be to allow it at compile time (of the >> application). >> >> In other words, one would have to do: >> >> #define MPIR_LIMB_UI >> #include "mpir.h" >> >> in the application being compiled against MPIR. This would set the >> size of an UI to the same size as a limb for efficiency. Thus when >> mpz_mul_ui is used, it would expect a limb sized ui instead of a long >> long or whatever the currently largest integer on that machine is. >> >> The reason I have an opinion on this issue is I've recently been >> fiddling a lot with compilers and interpreters, including coding some >> experimental ones, and the issue of different sized integers came up >> there. I finally had the revelation that if one supports the largest >> sized integer available, all the others are automatically supported >> (at the C level anyway) because of sign/zero extension, i.e. by C's >> automatic casting. >> >> >> >> >> >> >> >> >> >> > Another approach is to modify the existing 'ui/si' source code files >> > by using two defines: >> >> > #define INT_VAR_TYPE >> > #define FN_SUFFIX >> >> > internally for their integer types and their function suffixes and >> > then rename them to, say, function.inc. we can then use a source code >> > file function.c: >> >> > #define INT_VAR_TYPE unsigned int >> > #define FN_SUFFIX ui >> > #include "function.inc' >> > #undef INT_VAR_TYPE >> > #undef FN_SUFFIX >> >> > #define INT_VAR_TYPE unsigned long long >> > #define FN_SUFFIX ull >> > #include "function.inc' >> > #undef INT_VAR_TYPE >> > #undef FN_SUFFIX >> >> > #define INT_VAR_TYPE uintmax_t >> > #define FN_SUFFIX uj >> > #include "function.inc' >> > #undef INT_VAR_TYPE >> > #undef FN_SUFFIX >> >> > ....... >> >> > for as many integer types as we want (we again need to check the >> > generic code will work for all anticipated limb/integer size >> > ratios). >> >> > This is the 'C template' technique that the GNU Scientific Library >> > (GSL) uses to handle a similar issue. >> >> > But I recall that such techniques can play havoc with the *nix build >> > system so it might be only be possible on a windows specific version >> > of MPIR, which would be a pity given our eventual desire to have a >> > unified build system for *nix and Windows. >> >> > I would be interested in any views people might have on these issues >> > before we leap in and so any coding. >> >> > Brian >> >> > -- >> > 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 >> > athttp://groups.google.com/group/mpir-devel?hl=en. > > Can I hence assume that you favour redefining the _existing_ ui/si > functions to use intmax_t (signed) and uintmax_t (unsigned) for their > integer parameters?
Not necessarily. I just think that it is the right way to fix this problem. I don't think it will affect many *nix platforms anyway, and I definitely think using unsigned long for ui functions is wrong. The difficulty with my proposal would be strict compatibility with GMP. I don't personally care about this because if we use the bigger integer for ui/si then correctly written code for GMP should still work with MPIR. > > Case has suggested a parallel API for these operations (sj/uj), which > is a related but somewhat different approach. > > The 'C template' approach would allow us to do pretty well anything we > liked here. > > Brian > > -- > 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. > > -- 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.
