On Sat, Feb 12, 2011 at 12:12 PM, Cactus <rieman...@gmail.com> wrote: > > > On Feb 12, 7:00 pm, Jason <ja...@njkfrudils.plus.com> wrote: >> One point I forgot to mention is that it's pretty certain that only 32 and 64 >> bit will work , there was some discussion about 10 years ago that even then >> 16 >> bit wouldn't work , nails worked but only for a very limited set of values , >> and even then there were dubious performance benefits. >> >> On Saturday 12 February 2011 18:44:39 Bill Hart wrote: >> >> >> >> >> >> > On 12 February 2011 18:14, Jason <ja...@njkfrudils.plus.com> wrote: >> > > Hi >> >> > > Some random thoughts. >> >> > > I think if we add new functions to the mpz layer , however it is done , >> > > then it's possible that GMP may choose to have a set of incompatible >> > > functions which will be a headache for everyone. >> >> > True. >> >> > > We have to remain compatible with GMP so the ui/si function must be >> > > long's , although larger type would work , C++ types would be different >> > > and so would C , function pointers, would DLL's be binary compatible? >> >> > Don't know. I know next to nothing about DLL's. My guess is they have >> > to work. But I can't be sure of this. >> >> I'm not at all sure either , I think C++ function name mangerling would be >> affected though. >> >> >> >> >> >> > > I think of mpz as a class that represents "the integers" , and so should >> > > be abstracted away from any thought of how it is represented in the >> > > computer. >> >> > 100% agree with that. >> >> > > Good software design , especially for big systems is information hiding , >> > > it promotes parallelism in coding , when I use a compiler I should not >> > > need to know how it works , it's a black box that turns source code into >> > > executable's. >> >> > Absolutely! >> >> > > How about a new class mpn_easy (I'm not serious about the name) which are >> > > just mpn's that have a sign and are memory managed.All the ease of use >> > > of mpz's , but efficient in the case when long!=limb >> >> > Dunno. Does this or any of the other solutions presented actually deal >> > with Brian's original problem or the problems reported on the Mersenne >> > forum? I doubt it. >> >> > It might help the discussion to make a list of actual real world >> > problems that led to the discussion in the first place. Then look at >> > all the currently supported arches and see specifically which arches >> > are affected. Then we can think about which solutions make the most >> > sense. >> >> Well!!! , I just answered the question I wanted to hear , what's that got to >> do with the real world :) >> >> >> >> >> >> > I seriously doubt having an uj/sj type for Win64 is going to stop >> > people accidentally getting screwed up by longs being a different size >> > to limbs when using ui functions. It's not that it's not a good idea, >> > it just doesn't actually solve the problem. >> >> > I *think* using a larger type always does fix the problem. But it >> > isn't completely without issues. >> >> > > Jason >> >> > > On Saturday 12 February 2011 13:35:11 Bill Hart wrote: >> > >> There's two other problems with what I suggest: >> >> > >> 1) If someone builds MPIR in the default manner and an ui happens to >> > >> be 2 limbs, the code may run slower in MPIR than GMP. >> >> > >> 2) flint2 has the convention that ui is an mp_limb_t and not a long. >> > >> So I'm not even consistent in my own code. >> >> > >> Lots of other libraries have a different convention again, e.g. GSL and >> > >> MPFR. >> >> > >> I will leave it up to you guys to decide what you want to do. I'm >> > >> merely giving my opinion based on what I've discovered from trying to >> > >> write interpreters, which may not be helpful. >> >> > >> Bill. >> >> > >> On 12 February 2011 13:19, Bill Hart <goodwillh...@googlemail.com> >> > >> wrote: >> > >> > 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 mpn_* functions should already be defined to use mp_limb_t. >> >> > >> >>> 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 >> >> ... >> >> read more »- Hide quoted text - >> >> - Show quoted text -- Hide quoted text - >> >> - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > Its probably only an issue on WIndows because of issues that arise in > moving open source code developed on *nix onto the Windows platform. > Most *nix developers are so confident that longs are 64-bits or more > in length on 64-bit systems that they even consider the possibility of > truncation when moving integers into the mp types using the ui/si > functions. > > Over the last several years I haave spent more time than I would like > in tracking down errors that result from this when I move programs > onto Windows. > > Probably the easiest solution on Windows is to simply to express the > integer parameters of ui/si functions (and some internal integers in > the functions themselves) as a new global integer type that is > (unsigned) long on 32-bit Windows systems and (unsigned) long long on > 64-bit Windows. > > Brian I think changing the signature of ui/si functions will cause problems. You should assume that code using MPIR will be written using long or long long. Forcing that code to use a new type will cause issues, too. Python has specific API calls for working with long vs long long. I'd like to be able to map the output of those API calls directly to the appropriate function. A parallel ull/sll API would be the easiest for use with gmpy. A parallel uj/sj would work also and matches the API in MPFR (both ui/si and uj/sj functions are supported). I think the high-level API should be be expressed in terms of standard C types. Just having the alternate API defined, either ull/sll and/or uj/sj, should make it easier for software authors to make the proper choice. Since the only interface functions are defined use long, it's not surprising that all code uses long. To avoid possible name collisions with GMP, you could prefix these functions with mpir_. The low-level mpn interface should remain defined in terms of mp_limb_t. Case > > > > > > > > > > > > > define global signed and unsigned > > > > > > an issue on Windows because there is a held belief that longs are 64- > bits on all 64-bit systems when in fact they 1re 32-bits on WIndows. > > -- > 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.
