Talk:Formal power series: Difference between revisions

From Rosetta Code
Content added Content deleted
Line 21: Line 21:


assuming that d/d''x'' denotes the differential operator. The task uses the integral operator instead and sin''x'' as a temporal. Shouldn't it work with '''any''' operator defined defined in the task, in any combination of? --[[User:Dmitry-kazakov|Dmitry-kazakov]] 10:32, 17 February 2009 (UTC)
assuming that d/d''x'' denotes the differential operator. The task uses the integral operator instead and sin''x'' as a temporal. Shouldn't it work with '''any''' operator defined defined in the task, in any combination of? --[[User:Dmitry-kazakov|Dmitry-kazakov]] 10:32, 17 February 2009 (UTC)
:But also <math>\sin x = \frac{-d^2}{dx^2} \sin x</math>; and in fact any linear combination of sin and cos will satisfy that differential equation you gave. --[[Special:Contributions/76.167.241.45|76.167.241.45]] 06:00, 18 February 2009 (UTC)
:But also <math>\sin x = \frac{-d^2}{dx^2} \sin x</math>; 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. --[[Special:Contributions/76.167.241.45|76.167.241.45]] 06:00, 18 February 2009 (UTC)

Revision as of 06:09, 18 February 2009

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)