On 6 August 2014 06:43, Waldek Hebisch <[email protected]> wrote: >... > > Bill Page wrote: >> >> 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.
I think it is not a small detail. > Practical difficulties with > overloading may force us to use two names, but morally > we have single concept. To me, overloading is only a small detail. > It is debatable if sign/signum > should be defined at 0, but in most cases having > bigger domain is better. The problem is in limits. limit(signum(x),x=0,"left") = -1 limit(signum(x),x=0,"right") = 1 but limit(sign(x),x=0,"left") = limit(sign(x),x=0,"right") = 0 > And do you mean that signum(0) > should merely remain in symbolic form, Yes. > or do you want error? No. > Raising errors in Expression should be avoided > in general and limited to situation that would otherwise > lead to wrong results. > Agreed. >> ... >> 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. Because I do not want D(abs(x),[x,x]) = 0 > 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. 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. >> ... >> 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. Maybe. Note that both Maple and Mathematica give D(abs(x),x) = x/abs(x) Mathematica and Maple do not treat signum in exactly the same way. Results in Maple in particular depend strongly on assumptions placed on variable x. In FriCAS we have no explicit way to do this, on the other hand we do have a much stronger emphasis on algebra and less on the purely symbolic. > >> 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 >> ... >> Is anyone else interested in this sort of approach? > > Well certainly this is an interesting project. But I am > afraid that you underestimate its scope. Perhaps you are right. To use and extend Shirokov's idea might not be easy. > 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). Yes. I think that the domain of GeneralizedExpressions must necessarily be weaker than Expression in some specific ways. > Also, our coercions normally are > homomorphisms, that is they preserve relevant operations. > But AFAICS formulas for derivatives means that going > from Expression to GeneralizedExpression is not a > differential homomorphism. Could you give an example? Note that in my email I wrote: > 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) but maybe we really should have D(x/abs(x),x)$GeneralizedExpression(Integer) = (abs(x)^2 - x^2 ) / abs(x)^3 + 2*diracDelta(x) Of course the first term is zero if x is real. > 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. >From GeneralizedExpression to Expression would be a retraction. My intention was that the coercion from Expression to GeneralizedExpression, performing some operation, followed by retraction would be identical to that operation in Expression - in that sense homomorphic. > > In other words, GeneralizedExpression will be a separate > world only loosely connected to Expression, which will > limit its usefulness. > I do not want this. > IIUC Shirokov approach is motivated by quantum physics > and in this context non-commutativity is a virtue. Yes, but there are subjects other than quantum physics where non-commutativity is also important. > It > would be nice to have a domain implementing his ideas. > But for general computations we need something more > classical (in particular commutative). > My admittedly limited understanding of the available approaches to the theory of distributions and generalized functions is that we may choose between non-commutative or non-associative algebras. 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. 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. Regards, Bill Page. -- 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.
