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.
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.
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 at
http://groups.google.com/group/mpir-devel?hl=en.
