Kurt Pagani wrote: > > > > Am 25.11.2014 um 20:05 schrieb Waldek Hebisch: > > > Let me add that assumptions like "exements of Expression(Integer) > > are real" are in general unsound. > > Indeed. > > In case of log the assumption > > is frequently true and not making it would stop useful > > simplifications. However, I would rather move in direction > > of removing unsoudness than adding mor of it. > > By all means. The 'unsoundness' propagates in various directions. That's > why I've been trying to extract the 'Real' and 'Complex' field from > Expression space (as sketched below) and add/remove functions which > preserve/enforce 'soundness'. It's not as easy as I've thought because > some of the inherited items are even more 'unsound'. Moreover, there is > a strange behavior, similar to "Bug? Type specification changes result" > reported by Ralf. However, only the first assignment makes problems, > subsequent ones work properly. > <snip> > > )abbrev domain RR Real > ++ Description: The field of "real numbers" modelled as > ++ domain Expression(Integer) + some extensions. > Real : Exports == Implementation where <snip> > Exports ==> FunctionSpace R with
<snip> > > Implementation ==> Expression(R) add > > Rep := Expression(R) > dummy(x:R):R == x::R > Sorry to say this, but your definition has serious fundamental problem: Kernel(Real) is different domain than Kernel(Expression(R)) Inherited functions from expression will produce kernels form Kernel(Expression(R)). If you call 'kernel' inside your domain or call some function inherited from categories which call 'kernel' you will get kernels from Kernel(Real). Kernel(Expression(R)) and Kernel(Real) have representations that "look the same" and for any other domain this would work (which is probably the reason why type system allows such construction). But Kernel has special properties, in particular it has a cache which stores all kernels, each kernels has an integer field which stores its position in the cache and comparisons between kernels only look at position field (otherwise comparisons would be horribly expensive). The effect of this is that 'x' in Kernel(Real) may has position different than 'x' in Kernel(Expression(R)) and when mixing them we will get essentially random result of comparison. This lead to strange bugs, for example "the same" expression computed in two different way may compare unequal. > >>> > (2) -> x:Real:='x > > (2) x > Type: > Real > (3) -> x > > (3) x > Type: > Real > (4) -> sin(x) > > (4) 0 > Type: > Real Without deeper checking I can not say for sure, but this looks like typical bugs due to mixing kernels. Basically, inheriting from Expression is unsafe. Currently AlgebraicNumber inherits from kernel. ATM I do not have any examples of wrong result which conclusily can be attributed to this. But some "obviously correct" changes did trigger the bug (I wanted to commit a change, so I tested it and tests showed the problem...). Ideally either our code should be modified to make inheritance from Expression safe, or we should completely forbid such inheritance. Currently I do not see how to make inheritance form Expression safe. I have several ideas, but I had to reject a few promising ones when I discovered flaws in them, so ATM I do not know if any of the other ideas will work. Alternative would require some unpleasent rewrite, so it will not happen quickly. -- Waldek Hebisch hebi...@math.uni.wroc.pl -- 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.