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.
