Oh, forgot the link:
http://github.com/bo198214/hyperops/raw/157fa46ca4439d0e022c1c6249c5862d1d2569c2/formal_powerseries.py
Grateful for any comments.
On Apr 6, 1:49 pm, Henryk Trappmann wrote:
> Now a new version is out, picklable, coerceable and 100% coverage,
> though not comletely complete
Now a new version is out, picklable, coerceable and 100% coverage,
though not comletely complete yet.
But getting it to pickle was really *some* effort, 60 inner functions
had to converted to "outer" classes, but now it works.
However some strange effects occured with coercing:
sage: RR.coerce_ma
On Tue, Mar 31, 2009 at 1:26 PM, Henryk Trappmann
wrote:
>
> On Mar 31, 4:35 pm, William Stein wrote:
>> Note that callable objects are fine as
>> attributes (e.g., objects with a __call__ method defined).
>
> Actually I dont see how to get it to work:
> I want to give a function as initializati
On Mar 31, 4:35 pm, William Stein wrote:
> Note that callable objects are fine as
> attributes (e.g., objects with a __call__ method defined).
Actually I dont see how to get it to work:
I want to give a function as initialization parameter to
FormalPowerSeries.
This function needs to be stored s
On Mar 31, 4:35 pm, William Stein wrote:
> (1) You can't pickle objects with attributes that are functions. If
> your code currently only works with attributes that are functions, it
> will need to be rewritten. Note that callable objects are fine as
> attributes (e.g., objects with a __call__
On Tue, Mar 31, 2009 at 12:55 AM, Robert Bradshaw
wrote:
>
> On Mar 30, 2009, at 6:36 AM, Henryk Trappmann wrote:
>
>>
>> Ok, here is a first shot that has 100% coverage (except dumps):
>> http://github.com/bo198214/hyperops/raw/
>> 09e1da3372d7b431cdf557ffe164df9f91c08e68/formal_powerseries.py
>
I don't think it should affect performance much. The difference between
calling a Python function and calling a Python class with a custom __call__
method shouldn't be very large. But you can time it and see.
David
On Tue, Mar 31, 2009 at 2:21 PM, Henryk Trappmann
wrote:
>
> On Mar 31, 12:34 pm
On Mar 31, 12:34 pm, David Roe wrote:
> Having written a lazy p-adics class, my guess is that your pickling errors
> have to do with the fact that you're storing a function. If you replace all
> of the local functions that you're storing with callable classes (ie a class
> that implements the __
If you're editing files in the sage library, you need to type
sage -br
from the command line in order for your changes to be incorporated into the
copy of sage that you're running (the -b builds, the -r means to start
sage).
Having written a lazy p-adics class, my guess is that your pickling error
On Mar 31, 10:49 am, Franco Saliola wrote:
> > I'd rather it were named the more verbose, but significantly more
> > explicit, FormalPowerSeriesRing. This fits better with the naming of
> > all the other rings, and we do have tab completion after all.
>
> I prefer FormalPowerSeriesRing, as well.
On Mar 31, 10:41 am, Franco Saliola wrote:
> On Sat, Mar 28, 2009 at 9:17 AM, Henryk Trappmann
> I would guess that you are probably just loading/attaching some local
> files to a Sage session. If that's correct, then that is the cause of
> this problem. When you merge your code into Sage, then t
On Mar 31, 9:55 am, Robert Bradshaw
wrote:
> There is also _rmul_ and _lmul_ which are used to implement
> multiplication by a scalar.
Thats great, I was wandering how to recognize scalar multplication.
Thank you Robert.
--~--~-~--~~~---~--~~
To post to this gr
On Tue, Mar 31, 2009 at 9:55 AM, Robert Bradshaw
wrote:
>
> On Mar 30, 2009, at 6:36 AM, Henryk Trappmann wrote:
>
>>
>> Ok, here is a first shot that has 100% coverage (except dumps):
>> http://github.com/bo198214/hyperops/raw/
>> 09e1da3372d7b431cdf557ffe164df9f91c08e68/formal_powerseries.py
>>
On Sat, Mar 28, 2009 at 9:17 AM, Henryk Trappmann
wrote:
>
> I reached 90% coverage and have some more questions:
>
> 1. What is pickling? Currently I get the following message if I try
> dumps:
> PicklingError: Can't pickle :
> attribute lookup __main__.FormalPowerSeries failed
I would guess th
> 3. I dont know what "sum_generator" and "product_generator" in Mike's
> implementation do.
Maybe you should look at the original...
http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu29.html#x44-770009.2.10
and corresponding tests
http://www.risc.uni-linz.ac.at/people/hem
On Mar 30, 2009, at 6:36 AM, Henryk Trappmann wrote:
>
> Ok, here is a first shot that has 100% coverage (except dumps):
> http://github.com/bo198214/hyperops/raw/
> 09e1da3372d7b431cdf557ffe164df9f91c08e68/formal_powerseries.py
>
> I finally decided to name it FPSRing, for Formal Power Series R
Dear Henryk, dear Mike,
On Mon, Mar 30, 2009 at 06:36:17AM -0700, Henryk Trappmann wrote:
>
> Ok, here is a first shot that has 100% coverage (except dumps):
> http://github.com/bo198214/hyperops/raw/09e1da3372d7b431cdf557ffe164df9f91c08e68/formal_powerseries.py
>
> I finally decided to
Ok, here is a first shot that has 100% coverage (except dumps):
http://github.com/bo198214/hyperops/raw/09e1da3372d7b431cdf557ffe164df9f91c08e68/formal_powerseries.py
I finally decided to name it FPSRing, for Formal Power Series Ring. It
resides in sage.rings.formal_powerseries
I hope Nicolas M.
On Sat, Mar 28, 2009 at 12:17 AM, Henryk Trappmann
wrote:
>
> I reached 90% coverage and have some more questions:
>
> 1. What is pickling?
http://docs.python.org/library/pickle.html
> Currently I get the following message if I try
> dumps:
> PicklingError: Can't pickle :
> attribute lookup __m
I reached 90% coverage and have some more questions:
1. What is pickling? Currently I get the following message if I try
dumps:
PicklingError: Can't pickle :
attribute lookup __main__.FormalPowerSeries failed
2. I currently work in my own repository, when is it time to switch to
the sage reposit
On Thu, Mar 26, 2009 at 05:58:17AM -0700, Henryk Trappmann wrote:
>
> On Mar 26, 5:07 am, mabshoff wrote:
> > Well, I will not merge a second implementation as long as there is no
> > clear roadmap for resolving the problem.
>
> The basic functionality of Mike's powerseries class is also contai
On Thu, Mar 26, 2009 at 8:44 AM, Henryk Trappmann
wrote:
>
> On Mar 26, 3:52 pm, William Stein wrote:
>> 2. Make sure your code has 100% doctest coverage.
>
> I have two questions here.
> 1. I work intensely with functions defined inside of methods (because
> one attribute of the power series is
On Mar 26, 3:52 pm, William Stein wrote:
> 2. Make sure your code has 100% doctest coverage.
I have two questions here.
1. I work intensely with functions defined inside of methods (because
one attribute of the power series is a function. It needs to be
defined whenever a method returns a power
On Thu, Mar 26, 2009 at 5:58 AM, Henryk Trappmann
wrote:
>
> On Mar 26, 5:07 am, mabshoff wrote:
>> Well, I will not merge a second implementation as long as there is no
>> clear roadmap for resolving the problem.
>
> The basic functionality of Mike's powerseries class is also contained
> in my
On Mar 26, 5:07 am, mabshoff wrote:
> Well, I will not merge a second implementation as long as there is no
> clear roadmap for resolving the problem.
The basic functionality of Mike's powerseries class is also contained
in my class.
That is add, multiply, power, composition, shift, differentiat
On Mar 25, 8:26 pm, "Nicolas M. Thiery"
wrote:
> Dear Henryk, dear Mike,
> Mike: could you plse answer this e-mail???
Right now it is spring break at UW, so I expect Mike to pop up soon
again.
> We really really really don't want two separate implementations.
Well, I will
Dear Henryk, dear Mike,
On Wed, Mar 25, 2009 at 12:31:46PM -0700, Henryk Trappmann wrote:
> On Mar 25, 8:08 pm, mabshoff wrote:
> > Why can't this code be patched into Mike's LazyPowerSeries class? I
> > really don't think we want the same thing implemented twice in Sage
> > with overlap
On Mar 25, 2009, at 11:26 AM, Henryk Trappmann wrote:
> Oh, then I have some questions.
>
> First how shall the class finally be named (the current name
> PowerSeriesI is rather a working title):
> LazyPowerSeries (conflict with Mike Hansen's package),
> InfinitePowerSeries, LIPS?
>
> and into wh
On Mar 25, 8:08 pm, mabshoff wrote:
> Why can't this code be patched into Mike's LazyPowerSeries class? I
> really don't think we want the same thing implemented twice in Sage
> with overlapping functionality.
For me its just too much effort to port all the functionality and to
retest.
My class
On Mar 25, 11:26 am, Henryk Trappmann wrote:
> Oh, then I have some questions.
>
> First how shall the class finally be named (the current name
> PowerSeriesI is rather a working title):
> LazyPowerSeries (conflict with Mike Hansen's package),
> InfinitePowerSeries, LIPS?
Why can't this code b
On Wed, Mar 25, 2009 at 11:26 AM, Henryk Trappmann
wrote:
>
> Oh, then I have some questions.
>
> First how shall the class finally be named (the current name
> PowerSeriesI is rather a working title):
> LazyPowerSeries (conflict with Mike Hansen's package),
> InfinitePowerSeries, LIPS?
(1) Came
Oh, then I have some questions.
First how shall the class finally be named (the current name
PowerSeriesI is rather a working title):
LazyPowerSeries (conflict with Mike Hansen's package),
InfinitePowerSeries, LIPS?
and into which package should it go: sage.rings ?
shall it inherit from Ring?
On Wed, Mar 25, 2009 at 9:13 AM, Henryk Trappmann
wrote:
>
> http://github.com/bo198214/hyperops/raw/a5b716d48751778ffccff6769a96d9bea428b4d1/powerseries.py
>
Your doctest coverage score on that file is currently 1% but has to be
100% before it could be included in Sage:
teragon:tmp wstein$ sag
http://github.com/bo198214/hyperops/raw/a5b716d48751778ffccff6769a96d9bea428b4d1/powerseries.py
On Mar 25, 4:58 pm, William Stein wrote:
> On Wed, Mar 25, 2009 at 6:14 AM, Henryk Trappmann
>
>
>
> wrote:
>
> > On Mar 9, 5:42 am, "Nicolas M. Thiery"
> > wrote:
> >> What's the status of the merg
On Wed, Mar 25, 2009 at 6:14 AM, Henryk Trappmann
wrote:
>
> On Mar 9, 5:42 am, "Nicolas M. Thiery"
> wrote:
>> What's the status of the merge of your implementations of power
>> series? I need a couple functionalities not yet in Mike's
>> implementation, and mainly:
>> - conversion from a poly
On Mar 9, 5:42 am, "Nicolas M. Thiery"
wrote:
> What's the status of the merge of your implementations of power
> series? I need a couple functionalities not yet in Mike's
> implementation, and mainly:
> - conversion from a polynomial
> - division
Actually I improved my powerseries package and
Dear Mike, dear Henryk,
What's the status of the merge of your implementations of power
series? I need a couple functionalities not yet in Mike's
implementation, and mainly:
- conversion from a polynomial
- division
On Thu, Oct 30, 2008 at 06:29:35AM -0700, Henryk Trappmann wrote:
> On
Maybe its a bit off topic but in the line of thought:
I wonder whether the subset of the reals generated by
+,-,*,/,x^y,log_x y from {1} (that means it contains at least Q)
is decidable (i.e. whether we can decide equality for two given
expressions in the operations and 1).
For a start we could
On Oct 31, 10:31 am, Jason Grout <[EMAIL PROTECTED]> wrote:
> mabshoff wrote:
>
> > On Oct 31, 2:05 am, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
> >>> Sage is full of "fields" that aren't actually fields mathematically.
> >>> Field in Sage means "object that models a mathematical field",
> >>> b
mabshoff wrote:
>
>
> On Oct 31, 2:05 am, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
>>> Sage is full of "fields" that aren't actually fields mathematically.
>>> Field in Sage means "object that models a mathematical field",
>>> but includes e.g., the "field of double precision floating point numb
On Oct 31, 2:05 am, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
> > Sage is full of "fields" that aren't actually fields mathematically.
> > Field in Sage means "object that models a mathematical field",
> > but includes e.g., the "field of double precision floating point numbers",
> > which isn't
> Sage is full of "fields" that aren't actually fields mathematically.
> Field in Sage means "object that models a mathematical field",
> but includes e.g., the "field of double precision floating point numbers",
> which isn't really a field (e.g., it is finite).
And + is not associative...
I gu
On Oct 30, 6:06 pm, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
> > Formal Laurent series would also form a field.
> > For example the formal Laurent series are a field.
>
> While this is certainly true mathematically, you might run into trouble
> computationally.
>
> In a (additive and commutative)
On Thu, Oct 30, 2008 at 10:06 AM, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
>
>> Formal Laurent series would also form a field.
>> For example the formal Laurent series are a field.
>
> While this is certainly true mathematically, you might run into trouble
> computationally.
>
> In a (additive and
> Formal Laurent series would also form a field.
> For example the formal Laurent series are a field.
While this is certainly true mathematically, you might run into trouble
computationally.
In a (additive and commutative) monoid M there is a (unique) x in M such
that for all m in M it holds:
On Oct 30, 1:14 pm, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> When I said recursively defined streams, I meant something a little
> more general. For example, if f is a power series and g is exp(f),
> then g satisfies g = \int g*f'. This translates to the following code
> for the exponential of
Hi,
On Thu, Oct 30, 2008 at 4:35 AM, Henryk Trappmann
<[EMAIL PROTECTED]> wrote:
> Yes thats true. Currently if I need cached recursion (and I need it in
> the code),
> I do
>
> s = PS() #uninitialized powerseries
> def f(n):
> #fibonacci example
> if n==0 or n==1:
>return 1
> #do somethin
On Oct 30, 9:44 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> One of the main features that I need is the ability to handle
> recursively/implicitly defined power series. This is currently not
> possible in your code base because the series aren't "lazy enough".
Yes thats true. Currently if I n
On Oct 30, 2:17 am, "John Cremona" <[EMAIL PROTECTED]> wrote:
> 2008/10/30 Robert Bradshaw <[EMAIL PROTECTED]>:
>
>
>
>
>
> >> Since we're working with trac and use mercurial from a Sage interface,
> >> I strongly recommend that you use our Sage interface to mercurial, not
> >> mercurial itself.
2008/10/30 Robert Bradshaw <[EMAIL PROTECTED]>:
>
>> Since we're working with trac and use mercurial from a Sage interface,
>> I strongly recommend that you use our Sage interface to mercurial, not
>> mercurial itself. That is, please use the family hg_sage.* of commands
>> for interfacing with me
Hello,
On Thu, Oct 30, 2008 at 12:49 AM, Henryk Trappmann
<[EMAIL PROTECTED]> wrote:
> Our lazy mechanism seems however very different.
> While you use somehow Stream, I just have a hash table for each power
> series.
Actually, they're doing pretty much the same thing. A stream models
an infini
On Oct 30, 2008, at 12:49 AM, Henryk Trappmann wrote:
> On Oct 30, 3:01 am, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> More on topic, much better merge the two and have the best of both
>> than have competing implementations. Shouldn't this belong in sage/
>> rings rather than in combinat?
>
On Oct 30, 2:07 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> Is your code posted anywhere? I'm sure we can come up with a way to
> merge the two implementations.
Yes you can see it here:
http://github.com/bo198214/hyperops/tree/master/powerseries.py
it was originally developed for a different
On Wed, 29 Oct 2008 at 07:01PM -0700, Robert Bradshaw wrote:
> This is somewhat OT, but just to clarify, I never use the hg_sage.*
> commands and I never have any issues. Nor do a many of the other
> developers I know. For example, lots of people find mercurial queues
> very useful and they are not
> By the way, I wish the queues *were* exposed via the hg_sage.*
> interface.
+1 to this, and that the documentation for it on the Wiki compared
things to action under the 'usual' commands, or that documentation for
it was under the Programmer's Guide.
- kcrisman
--~--~-~--~~
On Wed, Oct 29, 2008 at 7:01 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Oct 29, 2008, at 5:08 PM, Minh Nguyen wrote:
>
>> Hi Henryk,
>>
>> On Thu, Oct 30, 2008 at 7:34 AM, David Roe <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Great! This has been on my list of things I'd like to have
>>> imp
On Oct 29, 2008, at 5:08 PM, Minh Nguyen wrote:
> Hi Henryk,
>
> On Thu, Oct 30, 2008 at 7:34 AM, David Roe <[EMAIL PROTECTED]>
> wrote:
>>
>> Great! This has been on my list of things I'd like to have
>> implemented for a while.
>>
>> Presumably, much of this code will be incorporated into th
Hi Henryk,
On Wed, Oct 29, 2008 at 5:26 PM, Henryk Trappmann
<[EMAIL PROTECTED]> wrote:
> Ya, my code does that too. I even implemented formal Laurent-Series
> for some operations (negative lower bound).
>
> Many interesting things in power series manipulation are not
> implemented in your LazyPo
On Oct 30, 12:08 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 29, 2008 at 3:50 PM, Mike Hansen <[EMAIL PROTECTED]> wrote:
> > Hello,
>
> > On Wed, Oct 29, 2008 at 1:48 PM, Martin Rubey <[EMAIL PROTECTED]> wrote:
> >> As far as I know, Mike Hansen ported Ralf Hemmecke's lazy power s
Hi Henryk,
On Thu, Oct 30, 2008 at 7:34 AM, David Roe <[EMAIL PROTECTED]> wrote:
>
> Great! This has been on my list of things I'd like to have
> implemented for a while.
>
> Presumably, much of this code will be incorporated into the Sage
> library. So it's not really a "package" per se. Inst
On Wed, Oct 29, 2008 at 3:50 PM, Mike Hansen <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Wed, Oct 29, 2008 at 1:48 PM, Martin Rubey <[EMAIL PROTECTED]> wrote:
>> As far as I know, Mike Hansen ported Ralf Hemmecke's lazy power series, too,
>> to
>> python. They are not "exposed", however.
>
> In S
Hello,
On Wed, Oct 29, 2008 at 1:48 PM, Martin Rubey <[EMAIL PROTECTED]> wrote:
> As far as I know, Mike Hansen ported Ralf Hemmecke's lazy power series, too,
> to
> python. They are not "exposed", however.
In Sage 3.1.4, LazyPowerSeriesRing is exported to the global
namespace. You can find t
"David Roe" <[EMAIL PROTECTED]> writes:
> Great! This has been on my list of things I'd like to have
> implemented for a while.
>
> Presumably, much of this code will be incorporated into the Sage
> library. So it's not really a "package" per se. Instead, you should
> make a ticket on trac (h
Great! This has been on my list of things I'd like to have
implemented for a while.
Presumably, much of this code will be incorporated into the Sage
library. So it's not really a "package" per se. Instead, you should
make a ticket on trac (http://trac.sagemath.org/sage_trac), for which
you nee
64 matches
Mail list logo
