Bill Page wrote:
>
> On 6 August 2014 21:13, Waldek Hebisch <[email protected]> wrote:
> > Bill Page wrote:
> >> I think that
> >>
> >> abs(x)/x ~= x/abs(x)
> >>
> >> If D(abs(x),x) = x/abs(x) then D(abs(x),[x,x]) = (abs(x)^2 - x^2 ) /
> >> abs(x)^3.
> >> This is zero only for x is real.
> >
> > But what D(abs(x),x) mean for non-real x? 'abs' considered
> > as function of complex variable is not differentiable. AFAICS
> > one reasonable interpretation of D(abs(x),x) is that it
> > automatically forces x to be real.
>
> Yes, D(abs(x),x) is not complex-differentiable. But D(abs(x),x) =
> x/abs(x) is nonetheless a derivative in the direction of the real
> axis.
No, derivative in the direction of the real axis is real(x)/abs(x).
z/abs(z) = \partial_x abs(z) + i*\partial_y abs(z) where
z = x + iy. Note that neither definition fits FriCAS. In
fact, once you try to use FriCAS to compute derivatives
of functions containig abs of complex argument you will
get nonsense regardless of what you take as D(abs(x), x).
More precisely, for a given function f you may be able to
tweak D(abs(x), x) so that D(f, x) will be sensible.
But for any value of D(abs(x), x) you will find some f
so that D(f, x) would be a nonsense. The reason is
that FriCAS assumes chain rule and Leibintz rule
and they are valid only for differentiable functions.
> My thinking is this: If we can "define" signum(x) as x/abs(x)
> then perhaps we can also "define" diracDelta(x) as (abs(x)^2 - x^2 ) /
> abs(x)^3 / 2 ? To do this the derivative D(abs(x),[x,x]) must not be
> zero. Of course these expressions are not actual distributions but
> perhaps we can also define integration of expressions involving abs so
> that we may use them to represent distributions in a consistent way.
You probably can use (abs(x)^2 - x^2 ) / abs(x)^3 / 2 to represent
delta distribution, but there are plenty of alternative
representations, so I do not see why you want this one.
Also, connection of this with D(abs(x),[x,x]) is still
unclear. Concerning integration: if you want to integrate
something on _real_ interval, then integrator should
simplify your expression to zero since x is real on
te interval. ATM integrator is not doing this, but
sensible handling of integrals containing abs will
do this. So your representation is really unsuitable
for purpose of integrating delta distribution.
Note that your expression probably would represent delta
via intagration along some complex contours. But we
do not want to use such contours in normal integration,
because results are discontinous and we would risk
wrong integrals for real function. Also, if delta
is represented explicitely, then integrating it
is quite easy. I do not remember formula by heart,
but it is relatively simple.
>
> > ...
> >>
> >> Maybe. Note that both Maple and Mathematica give
> >>
> >> D(abs(x),x) = x/abs(x)
> >> ...
> >> Perhaps you are right. To use and extend Shirokov's idea might not be easy.
> >>
> > ...
> > Note that you give different derivatives for the "same" function
> > x/abs(x) depending on domain. So you have
> >
> > D(f::GE, x) != D(f, x)::GE
> >
> > where f = x/abs(x) and GE is GeneralizedExpression(Integer).
> > This means that '::GE' can not be a differential homomorphism.
> >
>
> OK.
>
> > ...
> > Note that similar relation hold between PrimeField(p) and Integer.
> > Only mapping from bigger domain to smaller is called 'coerce' and
> > mapping from smaller to bigger 'convert'.
>
> This seems backward. We 'coerce' Integer to Fraction(Integer) and
> retract Fraction(Integer) to Integer. Fraction(Integer) is "bigger"
> domain than Integer, right? Coercion to Fraction(Integer) preserves
> addition, multiplication etc.
Well, 'coerce' should be a (global) homomorphizm. Integer and
Fraction(Integer) are very special example. Namely in this
case 'coerce' is one to one onto image and we can define
retraction. But not all homomorphizms are one to one onto
image, so in general you may have 'coerce' without 'retract'.
That is why PrimeField(p) and Integer is a better example.
Note that in general source and target may be uncomparable.
For example interpreter will happily synthetize
coercion form Integer to Polynomial(PrimeField(7)).
As I wrote above relation between your GeneralizedExpression
and Expression does not fit to Axiom/FriCAS concept
of coersion.
> test((1/3 + 1/4) = retract((1/3)::Float + (1/4)::Float))
>
> but the latter seems to produce an unexpected error message:
>
> >> Error detected within library code:
> Not an integer
Well, without target type interpreter tries to restract to
integer which fails.
> >> I think
> >> non-commutative is likely to be more useful. I guess that the subset
> >> that can be consistently expressed in a purely commutative function
> >> space is (mostly) trivial but I am not against a consistent
> >> implementation of this subset.
>
> Maybe I will change my mind about this. I agree that implementing as
> much as possible without resorting to generalized functions theory is
> a good idea. As a speculation I wonder if the non-commutativity of
> Shirokov's generalized functions could be represented with
> quaternion-valued expressions t + i dx + i dy + j dz, for real t, and
> arbitrarily small dx, dy, and dz? If so, the value of this is not
> immediately clear to me.
IIUC Shirokov has diracDelta(x)*diracDelta(y) = 0, so on "pure"
deltas multiplication is trivial. This is easy to implement if
all you want is addition and multiplication, but leads to
rather nasty algebraic properties.
> >> Could you give an example of a
> >> non-trivial computation that you would like to be able to perform
> >> in this manner? In particular I am interested in extending this
> >> to integration.
> >
> > We should be able to compute things like
> >
> > integrate(diracDelta(x^2+y^2), x)
>
> What value do you expect?
>
> Did you mean?
>
> integrate(diracDelta(x^2+y^2), x=%minusInfinity..%plusInfinity)
Well, that is easier, but we can manufacture indefinite integral
using step function (granted, when point lies at the end
of integration interval then value is somewhat arbitrary).
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
