Am 01.12.2014 um 03:46 schrieb Waldek Hebisch: > <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).
I see. This might explain why the 'inherited' version above does not behave in the same way as in http://axiom-wiki.newsynthesis.org/SandBoxRealSpace. > > 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). That's good to know. How is the 'cache' managed? I suppose it's entirely transparent to the user. 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 > <snip> > Ideally > either our code should be modified to make inheritance > from Expression safe, or we should completely forbid > such inheritance. Difficult to say. IMO, intheritance from EXPR isn't a good idea anyway, but I've just tried it out of curiosity. 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. > It's not really a problem to me, everything works fine when omitting 'Real', i.e RealSpace(n) is a 'vector space' over EXPR(INT): http://axiom-wiki.newsynthesis.org/SandBoxGeom1 This way no 'unsound' properties can propagate upwards. Last, I'd be afraid that changes in EXPR could break a lot of existing code, so I'd vote for new creations. > Many thanks for the helpful explanations. Kurt -- 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.
