@kcrisman:
Sorry to fall off the earth there for awhile. Have to do the mechanical
crap to get an ordinary job while I keep studying. The idea of working in
a coffee shop when I could be learning python is stupid. But it needs to
be done. Anyway, I think I might be... um... getting ahead of the problem,
but could you take a peek at
http://poppersdreamland.blogspot.com/2012/08/the-dirac-delta-discrete-time.html
and let me know if everything appears to be in order?
I tend to picture problems whole, and have difficulty compartmentalizing
them. For the Delta, my problem is that
if it is defined in sage
then it is operable according to that definition
But I see no limit on the range of operability. As defined, it should work
everywhere the ordinary Algebra and Differential and Integral Calculus
are, symbolically and numerically.
In my textbook, Alan Oppenheim just leaves it out of his calculations, and
then slaps a u(t) on the end of a solution when it "fixes" everything.
Hindsight is not a property I am prepared to suggest be integrated into a
CAS. :)
More unfortunate is that he employs a definition of "causal" which does not
formally define a relationship to the Delta; he skirts the question, and I
do not think he knows. I could be wrong. This is problematic. I think what
he means --and does not properly formalize in a way a computer can accept--
is that we will USE the Delta and u(t) to manipulate systems and obtain the
properties we want. What he *says*, however, is that u(t) and the Delta *
render* the systems causal, which is not true.
I will be posting an elementary example on my blog to illustrate the
mistake. It is straightforward. He has a differential system:
y' + 2y = x(t)
Let x(t) =
0, t < -1
1, t > -1
but his trial solutions are of the form y_p = C
Which is impossible because the input is not constant. There is no such
system.
But assertions like this are fundamental to signal processing literature.
He then proves the system is non-causal by trying to force a solution
which is NOT a linear combination of x(t) and its linearly independent
derivatives, to provide a solution. Which of course, it cannot. The error
is multiple. Firstly, he says the *constant *solution is "anticipative"
which is false.
This is highly problematic. The *problem* with the linear differential
equation is that it *cannot* be anticipative. He inadevertently changes
his own definition of causality. He says a system is "causal" if the
output at time t depends only on the input at that same time or in the
past. In other words, he says, the system is *nonanticipative.*
*
*
Faced with the linear differential equation, he offers me some made up and
fallacious prose about how, since the output does not *in general* depend
on the input at the same time or in the past, *therefore *it must "in some
sense" be anticipative.
But this is also false.
He has forgotten to include time in his definition of anticipative. In any
linear differential equation of order n, the output y(t) depends *uniquely*
upon
(the input + the characteristic equation) at time *t*, and exactly time *
t.* Anticipation is impossible.
You see the accidental change in definition, right? "Anticipative" depends
on time, not the input. He has confused the two, and carries this
confusion forward as a structural assumption.
So I went to the literature looking for the answers about how to properly
define the operation of the delta and establish associated mathematical
terms in their proper context, and I am finding that I need to do this work
myself because it has not been done properly.
Advice?
back to the example.
In this example, the input is x(t) = u(t+1), not a constant. But he never
solves that system. He slaps u(t+1) on at the end, after solving it as if
it is a constant system. I don't think I will have any problem figuring
out, for a particular example, where I am supposed to rush in a flip the
switches to make it all work out. I am concerned that there is a threshold
of complexity past which the pure calculus manipulations will escape me,
and I won't be able to tell if what I'm saying the Delta can "do" is true.
Are these problems? I mean, it seems to me that u(t) and x(t) are
differentiable and integrable, according to the ordinary definition of the
calculus. But is it true? Globally?
:)
Anyway, I know I can read other books. But that's not really the problem.
There must be a way to insure global algebraic consistency of the Delta.
That is the problem, right? It's just a symbol, but it IS a symbol.
I know this doesn't have to be solved all-at-once. I will get used to
breaking up problems. It will get through to me eventually.
Oh. THe output of Delta?? does not alleviate my concerns. In a way, I am
more concerned about symbolic manipulation. But I will do the rest of what
you suggested and plow forward, as soon as I get work stabilized. I wish I
had infinte time in a day. It is maddening.
On Monday, July 2, 2012 6:17:59 AM UTC-7, kcrisman wrote:
>
>
>
> On Sunday, July 1, 2012 3:39:15 AM UTC-4, Slumberland wrote:
>>
>> Thanks for all the help!
>>
>> One last concern, then *ticket*:
>>
>> {Yes! I will move all future questions of this kind to the devel/ group!}
>>
>>
>> In a series of symbolic calculations, if I can redefine the answers to
>>
>>
>> -is the current representation of a system piecewise?
>>
>> -is the variable discrete or continuous?
>>
>> -how do I plan on integrating each part?
>>
>> -what monotonic function am I using to integrate?
>>
>>
>> ...without changing the structure of the system, I call that cheating.
>> Signal processing books call it the dirac_delta. I have no problem with
>> this. It's clever, and it works.
>>
>> In the context of a particular problem, even a purely mathematical one,
>> we say its width is zero, and we usually mean it is a pulse of the minimum
>> width and maximum height for the system in question, and with area 1. Or
>> maybe I mean it is the derivative of the unit step. I'll probably open the
>> width beyond zero; I might even change the impulse shape.
>>
>>
>> Q4) Should the dirac_delta wait until such manipulations are *in
>> general* defined to your satisfaction, across the packages; and then
>> inherit these methods directly? For example, Piecewise() should be updated
>> however it best suits SAGE, and the dirac_delta abstracted from it (among
>> others).
>>
>>>
>>>
>
> Not sure of the answers to all your questions, but I would go minimalist
> for now. Look at the output of
>
> dirac_delta??
>
> and note that it's defined in sage/functions/generalized.py as a symbolic
> function already, and compare the code of other functions in the functions
> module to see how to add the sympy method etc. I'm not sure what to do
> about the Maxima issue, given that Maxima doesn't actually recognize delta
> properly. But figuring these very basic things out would be a great way to
> learn how the symbolics and calculus code works in Sage; don't worry about
> piecewise functions in general at this stage. Good luck!
>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
Visit this group at http://groups.google.com/group/sage-support?hl=en.
