>> In fact, I am not so sure about SubDomain. Currently, it is only used to
>> implement NonNegativeInteger and PositiveInteger. Currently, SubDomain
>> is completely useless.
>>
>> We can also get rid of SubDomain, if, for example, one writes
>>
>> PositiveInteger: Join(OrderedAbelianSemiGroup, Monoid, CommutativeStar) with
>> gcd: (%,%) -> %
>> ++ gcd(a,b) computes the greatest common divisor of two
>> ++ positive integers \spad{a} and b.
>> == Integer add
>> --- appropriate implementation of functionality which is different
>> --- from the implementation in Integer (in particular bound checks).
>>
>> That would open the whole world for redesign of SubDomain.
> This may work, but has a disadvantage that after such change
> PositiveInteger integer would work as expected due to compiler
> magic. Currently source at least tries to say that
> PositiveInteger is a subdomain of NonNegativeInteger.
OK, but why would the compiler need to know about NNI and PI? That is
just another point to clean up sometime.
I might agree that the compiler knows about Integer, but NNI and PI can
be completely represented in library code. I don't see why this should
be less efficient.
The only problem might be the interpreter since then finding the closest
type is problematic without knowing that NNI and PI are actually in the
library.
In fact, I would be more happy if there were an infrastructure that
registers domains and their hierarchy with the interpreter and thus
decouple the library from the interpreter. As I said before, I'd like to
see an interpreter that is mathematically relatively stupid and becomes
smarter and smarter with more and more registered domains and categories.
Ralf
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
