[sage-devel] Re: Random elements
I want to add that however random's are changed, e.g., for the integers,
the current behavior MUST still be available. The reason is because most
benchmarks I know about for other systems use uniformly chosen random
numbers in an interval. Loosing this behavior would make it much much
more painful to do comparative benchmarks.
On 3/2/07, David Roe <[EMAIL PROTECTED]> wrote:
> I've been thinking about random elements a bit for p-adics. There are lots
> of good and reasonable ways to generate random elements of things. For
> example, in addition to Robert's suggestion, we could have a Gaussian
> distribution with a specified mean, or a Poisson distribution... It seems
> like a reasonable way to do it would be to have an algorithm = {uniform,
> gaussian,...} argument to the random element function and thus have lots
> available (ie however many we decide to write). Then if someone wants to
> know what kind of random distributions they can generate, they can just
> check the docstring for the function. Of course, this still leaves the
> question of which is the default...
>
> Anyway, I'm planning on doing this for p-adics. Thought I might throw the
> idea in for integers too.
> David
>
>
> >It's always bugged me that the default distribution for integers (and
> >rationals) is just a uniform distribution over some small range. What
> >if instead we chose the distribution ZZ.random_element() = floor(1/r)
> >where r is uniformly distributed in (-1,1). Then P(n) = 1 / (2 |n| (|
> >n| + 1)) for all n in Z-{0}. This gives mostly small numbers with the
> >occasional large ones thrown in at ever decreasing probabilities.
> >
> >A random rational could then be the ratio of two such integers.
> >
> >- Robert
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Random elements
Of course. I agree that there should be an algorithm parameter, but I
bet most people/functions will end up using the default which should
be something reasonable.
On Mar 3, 2007, at 8:25 AM, William Stein wrote:
> I want to add that however random's are changed, e.g., for the
> integers,
> the current behavior MUST still be available. The reason is because
> most
> benchmarks I know about for other systems use uniformly chosen random
> numbers in an interval. Loosing this behavior would make it much
> much
> more painful to do comparative benchmarks.
>
> On 3/2/07, David Roe <[EMAIL PROTECTED]> wrote:
>> I've been thinking about random elements a bit for p-adics. There
>> are lots
>> of good and reasonable ways to generate random elements of
>> things. For
>> example, in addition to Robert's suggestion, we could have a Gaussian
>> distribution with a specified mean, or a Poisson distribution...
>> It seems
>> like a reasonable way to do it would be to have an algorithm =
>> {uniform,
>> gaussian,...} argument to the random element function and thus
>> have lots
>> available (ie however many we decide to write). Then if someone
>> wants to
>> know what kind of random distributions they can generate, they can
>> just
>> check the docstring for the function. Of course, this still
>> leaves the
>> question of which is the default...
>>
>> Anyway, I'm planning on doing this for p-adics. Thought I might
>> throw the
>> idea in for integers too.
>> David
>>
>>
>>> It's always bugged me that the default distribution for integers
>>> (and
>>> rationals) is just a uniform distribution over some small range.
>>> What
>>> if instead we chose the distribution ZZ.random_element() = floor
>>> (1/r)
>>> where r is uniformly distributed in (-1,1). Then P(n) = 1 / (2 |
>>> n| (|
>>> n| + 1)) for all n in Z-{0}. This gives mostly small numbers with
>>> the
>>> occasional large ones thrown in at ever decreasing probabilities.
>>>
>>> A random rational could then be the ratio of two such integers.
>>>
>>> - Robert
>>
>>
>>>
>>
>
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
>
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] google summer of code
Hi, According to http://code.google.com/support/bin/answer.py?answer=60302&topic=10727 mentoring organizations can apply to mentor Google Summer of Code projects between March 5 and March 12. I think the chances Google will declare SAGE / Univ of Washington as a mentoring organization are slim, but it's worth trying. I tried last year to no avail. If anybody knows somebody at Google, or would like to help with an application, let me know. -- William Stein Associate Professor of Mathematics University of Washington --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] problems in the interface with gp
Hi, I was playing a little with sage, and I've found that there are some problems with the interface with gp when dealing with big numbers, due to the the fact that sage doesn not understand the gp exponential notation. One first example, is the following: a= factorial(100,'pari'); a works as expected and gives... 933262154439441526816992388562667004907159682643816214685929638952175322991 However, the follwoing example (that should be equivalent), except for the fact that we are calling the gp interpreter instead of using the pari library, does not: age: b=gp.factorial(100) sage: b 9.332621544394415268169923886 E157 sage: type(b) sage: int(b) --- Traceback (most recent call last) /hdc1/pablo.hdc1/mathsoft2/sage.new/ in () /hdc1/pablo.hdc1/mathsoft2/sage.new/local/lib/python2.5/site-packages/ sage/inte /in __int__(self) 870 871 def __int__(self): --> 872 return int(str(self)) 873 874 def bool(self): There are two problems there: * Python is confused in the conversion by exponential notation * precision is lost in a computation with integers (that should be exact!) This problem can be important for the functions in the pari library that does not have a direct wrapper (but are calling via gp.* version) best regards Pablo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problems in the interface with gp
On Saturday 03 March 2007 9:40 pm, pdenapo wrote:
> Hi,
>
> I was playing a little with sage, and I've found that there are some
> problems with the interface with gp when dealing with big numbers, due
> to
> the the fact that sage doesn not understand the gp exponential
> notation.
>
> One first example, is the following:
>
> a= factorial(100,'pari'); a
>
> works as expected and gives...
>
> 93326215443944152681699238856266700490715968264381621468592963895217532
>2991
>
> However, the follwoing example (that should be equivalent), except for
> the
> fact that we are calling the gp interpreter instead of using the pari
> library, does not:
>
> age: b=gp.factorial(100)
> sage: b
> 9.332621544394415268169923886 E157
You are unfortunately confused by GP/PARI being, well, confusing.
The command for integer factorial in PARI is "!", whereas "factorial"
gives the floating point factorial:
sage: gp('100!')
9332621544394415268169923885626670049071596826438162146859296389521753229915608941463976156518286253697920827223758251185210916864
sage: gp('factorial(100)')
9.332621544394415268169923886 E157
Thanks for your feedback, and for subscribing to sage-devel.
-- William
> sage: type(b)
>
> sage: int(b)
> ---
> Traceback (most recent call
> last)
>
> /hdc1/pablo.hdc1/mathsoft2/sage.new/ in ()
>
> /hdc1/pablo.hdc1/mathsoft2/sage.new/local/lib/python2.5/site-packages/
> sage/inte
> /in __int__(self)
> 870
> 871 def __int__(self):
> --> 872 return int(str(self))
> 873
> 874 def bool(self):
>
> There are two problems there:
>
> * Python is confused in the conversion by exponential notation
> * precision is lost in a computation with integers (that should be
> exact!)
>
> This problem can be important for the functions in the pari library
> that does not have a direct wrapper (but are calling via gp.* version)
>
> best regards
> Pablo
>
>
>
--
William Stein
Associate Professor of Mathematics
University of Washington
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
