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.

Reply via email to