Re: [sage-devel] Re: Extend a real function's valid input types in Sage

2010-09-04 Thread ross kyprianou
Thanks for the advice William - will take everything on board On Sun, Sep 5, 2010 at 1:58 PM, William Stein wrote: > On Sat, Sep 4, 2010 at 7:27 PM, Ross Kyprianou wrote: > > +10 Certainly agree that the module is relevant and my work should be > > interwoven into it > > It was very timely that

Re: [sage-devel] Re: Extend a real function's valid input types in Sage

2010-09-04 Thread William Stein
On Sat, Sep 4, 2010 at 7:27 PM, Ross Kyprianou wrote: > +10 Certainly agree that the module is relevant and my work should be > interwoven into it > It was very timely that you drew my attention to this. > I think I should draw up an initial design for the functionality Im > aiming for and possibl

Re: [sage-devel] unpickling fast_float objects

2010-09-04 Thread Robert Bradshaw
On Sat, Sep 4, 2010 at 7:33 PM, Jason Grout wrote: > In improving fast_callable, I'm working on removing fast_float so we don't > have to maintain it.  Of course, the pickle jar complains that, with the > fast_float code gone, a pickle in the pickle jar doesn't unpickle. > > So... > > 1. Do people

[sage-devel] unpickling fast_float objects

2010-09-04 Thread Jason Grout
In improving fast_callable, I'm working on removing fast_float so we don't have to maintain it. Of course, the pickle jar complains that, with the fast_float code gone, a pickle in the pickle jar doesn't unpickle. So... 1. Do people care if we can't unpickle fast_float objects? (that would

[sage-devel] Re: Extend a real function's valid input types in Sage

2010-09-04 Thread Ross Kyprianou
+10 Certainly agree that the module is relevant and my work should be interwoven into it It was very timely that you drew my attention to this. I think I should draw up an initial design for the functionality Im aiming for and possibly put it in a new thread for comment. Im happy to do the most of

[sage-devel] Re: Extend a real function's valid input types in Sage

2010-09-04 Thread kcrisman
> (If youre into Probability and Statistics: Ive defined a Random > Variable class and for any instance X, the expressions exp(X) or > log(X) (or F(X) for any real function F) are well-defined random > variables and should be returned as new instances defined in terms of > X - but ignore this if y

Re: [sage-devel] Re: wiki.sagemath.org

2010-09-04 Thread William Stein
On Sat, Sep 4, 2010 at 8:21 AM, Jason Grout wrote: > On 9/4/10 9:35 AM, kcrisman wrote: >> >> >> On Sep 3, 11:55 pm, William Stein  wrote: >>> >>> Hi, >>> >>> I've changed thehttp://sagemath.orgwiki password phrase from "Number >>> of primes up to 100?" to "Number of primes up to 1000?"    The ans

[sage-devel] Re: wiki.sagemath.org

2010-09-04 Thread Jason Grout
On 9/4/10 9:35 AM, kcrisman wrote: On Sep 3, 11:55 pm, William Stein wrote: Hi, I've changed thehttp://sagemath.orgwiki password phrase from "Number of primes up to 100?" to "Number of primes up to 1000?"The answer is 168. Does the Wiki software allow for dynamically changing the ques

[sage-devel] problem in hashing Cython HMM prob function

2010-09-04 Thread Jason Grout
I've been working more on a lot of improvements to the fast_callable framework, but I've run into a point that is stumping me: Why is P.prob not hashable below? It's a cpdef function inside of a cdef class. sage: P = hmm.GaussianMixtureDistribution([(.2,-10,.5),(.6,1,1),(.2,20,.5)]) sage: ha

[sage-devel] Re: wiki.sagemath.org

2010-09-04 Thread kcrisman
On Sep 3, 11:55 pm, William Stein wrote: > Hi, > > I've changed thehttp://sagemath.orgwiki password phrase from "Number > of primes up to 100?" to "Number of primes up to 1000?"    The answer > is 168. > Does the Wiki software allow for dynamically changing the question each time to "Number of

[sage-devel] Re: Sphinx forgets variables between doctests

2010-09-04 Thread Nathann Cohen
> It would be good if you could update that bit of the documentation > that tells one how to load the optional GPLK package, when GLPK is now > a standard package. If you have not created a ticket for that, I think > it would be wise to do so. Patch #9836 completely removes this old file, and the

[sage-devel] Re: Extend a real function's valid input types in Sage

2010-09-04 Thread Jason Grout
On 9/4/10 1:35 AM, ross kyprianou wrote: Thanks guys exp, log, sqrt etc covers well over 50% of the requirement so Im really ahead - Once again - THANKS! It seems functional.py is definitely the place to be looking at. Whats needed is a "catch-all/anonymous" function in functional.py so that X.