Bill Page wrote: > > On 5 August 2014 12:38, Waldek Hebisch <[email protected]> wrote: > > > > I wrote: > > > > > > If you mean support for derivatives of "jumpy" functions, this > > > is reasonable easy. Namely, we need to add 'signum' and > > > 'diracDelta' to standard operators and define new functions > > > (this is very much like current definition of 'abs'). Then > > > we need to define derivatives: > > > > > > D(abs(x), x) = signum(x) > > > D(signum(x), x) = diracDelta(x) > > > > > > and derivatives of 'diracDelta' would remain in symbolic > > > form. Such definitions are sound and cause no special > > > trouble. > > > > In the attachement there is a patch in this direction. > > Simple things work, but I did only very light testing. > > Up to now I have noticed two problem. First, I used > > name 'sign' to be consistent with other uses. > > I think that signum is not really consistent with other uses of sign. > > > But > > this means that 'sign' is heavily overloaded and > > interpreter has problems with choosing correct > > signature. In fact, there was also compilation > > problem: in DoubleFloat there is implementation > > of 'sign : % -> Integer'. But with the patch we > > also have 'sign : % -> %' and compiler was picking > > the second signature and report error. > > > > I prefer signum rather than sign. In particular sign(0)=0 but > signum(0) is undefined.
I do not think that such a small detail alone justifies introducing new name. Practial difficulties with overloading may force us to use two names, but morally we have single concept. It is debatable if sign/signum should be defined at 0, but in most cases having bigger domain is better. And do you mean that signum(0) should merely remain in symbolic form, or do you want error? Raising errors in Expression should be avoided in general and limited to situation that would otherwise lead to wrong results. > > Second problem is that after changing definition of > > derivative of 'abs' several integrals containing > > 'abs' which used to work now fail. In a sense this > > is trivial problem: our integrator can integrate > > only derivatives of a few simple forms containg 'abs' > > and changing derivative of 'abs' changed set of > > "integrable" functions. But still, this is not > > nice. > > I do not like to change the definition of the derivative of 'abs'. Or > rather I would really like to change it to > > derivative(opabs, (x : F) : F +-> x*inv(abs(x)) Why this form? Now we have 'abs(x)*inv(x)'. So, current form has 'abs' in numerator and 'x' in denominator. Your form puts 'abs(x)' in denominator. Normal practice when simplifying expressions is to remove complicated parts from denominator. In our case 'abs' is most complicated part and form with 'abs' in numerator is considered simpler. > And define signum by > > abs(x)*signum(x) = x > > > > > I am thinking about including (possibly improved) > > version of this patch. Comments? > > > > Although I do greatly appreciate your work on this, in general I do > not like this patch very much. It seems to me that it treats this > problem in only a superficial symbolic way (like Maple, Mathematica > and Maxima). Take into account that some of best people in symbolic computations work on Maple and Mathematica. If both do this in such a way and there are no reports in the literature about better computational approach, then there is good chance that there is no simple way to do this better. > I think it would be more in keeping with the algebraic > approach to choose some theory of distributions and extend FriCAS by > implementing it (or at least some parts of it) explicitly. > > In particular after reviewing what I could find on the subject I think > I like the ideas of Shirokov best: > > http://en.wikisource.org/wiki/Algebra_of_generalized_functions_%28Shirokov%29 > > http://en.wikipedia.org/wiki/Signum_function#Generalized_signum_function > > where signum and diracDelta are generalized functions. > > signum(x)^2 = 1 > diracDelta(x)^2 = 0 > signum(x)*diracDelta(x) + diracDelta(x)*signum(x) = 0 > > etc. > > In FriCAS signum(x) and diracDelta(x) would be singular > GeneralizedExpressions. An Expression could be coerced to a continuous > GeneralizedExpression while derivatives of GeneralizedExpressions > would in general also be GeneralizedExpressions having both a > continuous and possibly a singular part. > > In Expression we should have > > D(x/abs(x), x) = (abs(x)^2 - x^2 ) / abs(x)^3 > > but > > D(x/abs(x),x)$GeneralizedExpression(Integer) = 2*diracDelta(x) > > D(signum(x),x) = 2*diracDelta(x) > > Is anyone else interested in this sort of approach? Well certainly this is an interesting project. But I am affraid that you underestimate its scope. Above you have noncommutative ring with zero divisors. For such rings even simple concepts like fractions become complicated. Expression uses powerful algorithms from commutative algebra (Gaussion elimination, GCD, factorization, Groebner bases, etc.). You need to extend them (or find good replacements) to noncommutative case (and handle zero divisors). Also, our coercions normally are homomorphisms, that is they preserve relevant operatios. But AFAICS formulas for derivatives means that going from Expression to GeneralizedExpression is not a differential homomorphizm. Also, from GeneralizedExpression to Expression will kill noncommutative part (in particular map diracDelta to 0), so it seems that only homomorphizm is a trivial one. In other words, GeneralizedExpression will be a separate world only loosely connected to Expression, which will limit its usefulness. IIUC Shirokov approach is motivated by quantum physics and in this context noncommutativity is a virtue. It would be nice to have a domain implementing his ideas. But for general computations we need something more classical (in particular commutative). -- 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.
