Here are the random functions now supported by mpir (not include obsolete 
ones)

u denotes uniform distribution
r denotes "random distribution" ie long strings :)
b denotes bits
m denotes modulus

mpz_urandomb (ROP, STATE, N)
mpz_urandomm (ROP, STATE, N)
mpz_rrandomb (ROP, STATE, N)

I suppose we are missing a mpz random fn with a random sign.

mpn_urandomb (RP, STATE,  unsigned long N)
mpn_urandomm (RP, STATE, const mp_limb_t *MP, mp_size_t N)
mpn_rrandom (RP, STATE, mp_size_t N)  // no b or m , so in limbs
mpn_randomb (RP, STATE, mp_size_t N)   // shouldn't have a b here but name 
allready taken by obsolete function


mpf_urandomb (ROP, STATE, unsigned long int NBITS)
mpf_rrandomb (ROP, STATE, mp_size_t MAX_SIZE, mp_exp_t EXP)

When we enable MT we can not have global variables so mpn_random will have to 
go , so perhaps we should junk it now? I'm thinking clean sweep now , rather 
than years of inconsistent interfaces. 
Thoughts?




On Monday 19 October 2009 09:41:10 Bill Hart wrote:
> We can fix this in either a service release or the next release, as it
> is clearly labelled as being a provisional interface which may change
> in a future release.
>
> Bill
>
> 2009/10/19 Bill Hart <[email protected]>:
> > The function described as mpn_randomb appears to be misnamed. The
> > documentation says it generates a random number of n limbs. But the
> > name suggests it generates a random number of n bits.
> >
> > Can we rename it before the release, are the docs wrong, or should we
> > fix this in a service release?
> >
> > Bill.
>
> 

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to