Talk:Formal power series

From Rosetta Code
Revision as of 14:54, 18 February 2009 by rosettacode>Dmitry-kazakov (→‎About solving equations: Functional equations)

Is it possible for non-functional language?

As alway, I misunderstood the task, the sin & cos is not defined by Integral of each other, but by explicit series definition.
I just wondered if non-functional language can accomplish the task. Is my examples totally go the wrong way, or 1 step away from goal? -- badmadevil 02:49, 6 April 2008 (MDT)

You beat to me flagging it as incorrect :-) And the key is lazyness, which in principle should also work in a non-functional language. As D doesn't seem to support it directly, you'll have to emulate it: Each coefficient should be a class that either already has a concrete value (an infinite precision rational, if available), or contains a call to a generator that can calculate the value. The first time the value is required, the generator is called, the next time, the cached value is used ("call-by-need"). That will also get rid of the inefficiencies in your implementation when do e.g. multiply several series (which causes the same coefficients to be calculated many times). And you need an infinite list of coefficients, which can be done with the same trick for a cons-cell. Yes, it's much nicer if the language does this naturally, which is the point of this task :-) --Dirkt 03:09, 6 April 2008 (MDT)
I found it can be done lastly. I struck at how to define the two object at the same time, which is not need. Thanks -- badmadevil 03:30, 6 April 2008 (MDT)
I've seen you added an extra indirection, but I don't see how you handle "call-by-need", i.e. when you replace that indirection with the real value. So does it? But maybe my D guessing skills are not sufficient. --Dirkt 04:14, 6 April 2008 (MDT)
Is indirection mean the interface which called like a class? I think it is one of the D ways to do closure. Actually I am still wondering how it work. -- badmadevil 04:32, 6 April 2008 (MDT)
It's the extra member term of type UT. I don't understand D enough to say why you need an interface, or if you need one at all. I only understand that the usual way to implement lazyness is to use such an extra variable. And yes, it's related to closures -- the call to a generator mentioned above can also be a closure. As I said, I don't understand D well enough, but it still doesn't look like I would expect it. In particular, you still seem to have the efficiency problem (try multiplying three series, and insert some debugging code that shows you when a coefficient gets calculated. You should see that the same coefficient gets calculated multiple times, which means a lot of times at higher numbered coefficients. --Dirkt 05:36, 6 April 2008 (MDT)
The term is an interface, which as previously state, may think as a class object. In solving the efficiency problem, I think the interface can be expanded to a proper class object, which has at least 2 member function. One is the coefficient generator, other is cache function to access an cache array storage. The cache function will query the generator if the coefficient is not inside the cache array, and of course, after return from the generator, the cache array will be updated. It is a trade off of time and space. I will try to implement this structure later if not too complicated. -- badmadevil 06:35, 6 April 2008 (MDT)

BTW, I only mentioned the rationals as a "nice to have" feature (because then you can immediately see if the coefficients for sine and cosine are correct). If you need an extra module that implements the rationals from scratch, and if you don't have arbitrary precision anyway, I personally would prefer doubles. The task leaves this detail unspecified on purpose. --Dirkt 05:36, 6 April 2008 (MDT)

Yes, it is overkill to implement from scratch, it is strict forward though.-- badmadevil 06:35, 6 April 2008 (MDT)

Multiplication and division

Could someone post examples of correct multiplication and division of power series, and perhaps even an explanation of the correct algorithm? The Haskell code is invalid, and I just wrote a translation of the D/Java code, which gives wrong results: multiplying 2 by 1 yields 3 + 3x + 3x^2 + ... --Kevin Reid 00:04, 17 February 2009 (UTC)

About solving equations

The task seems incomplete without defining cos as:

assuming that d/dx denotes the differential operator. The task uses the integral operator instead and sinx as a temporal. Shouldn't it work with any operator defined defined in the task, in any combination of? --Dmitry-kazakov 10:32, 17 February 2009 (UTC)

But also ; and in fact any linear combination of sin and cos will satisfy that differential equation you gave. The basic reason why we don't use differentiation is that it loses information, so equations based on differentiation will not have unique solutions. --76.167.241.45 06:00, 18 February 2009 (UTC)
No, the actual problem is that the solutions proposed in the task (and lazy expressions in particular) do not solve what the task is supposed to require. It only happens so that formal integration of 1 plus an infinite self recursion occasionally gives Taylor series of cos:




. . .
But it is a wrong solution in other cases, which are mathematically equivalent. Strange if that would be otherwise. Because mathematically it is about solving equations (integral, differential, basically any).
I would suggest to remove laziness as irrelevant to Taylor series, as well as self-recursive and also incomputable task. Instead of this I would take some finite series and add, integrate them etc. --Dmitry-kazakov 10:38, 18 February 2009 (UTC)
Can you give any examples of equations with these integrals where it would be "wrong"? I don't see anything unusual with what you've shown. Maybe you are not appreciating the power of recursive definitions. When you try to break it down into steps it might seem weird but the process is correct. --76.167.241.45 11:03, 18 February 2009 (UTC)
These integrals are OK, the implementations of functions using Taylor series are not, provided they should serve the purpose of solving functional equations like , where x is a variable, are Taylor series and F is a combination of functional operators from the task (+, - etc). This is what makes me suggest. But that does not looks to me like a use case of the Taylor series representation. If it were a case, then for example: should work as well. Will it?