On Mon, Feb 27, 2012 at 10:38:05PM +0100, Ralf Hemmecke wrote:
>>> It's not so
>>> totally obvious how one would for example make the representation of
>>> Fraction(SUP(INT)) canonical.
>>
>> I thought, there is a natural way. For example, canInv (x:INT)
>> (the canonical invertible factor) is defined as signum x (for x /= 0).
>> canInv(f : SUP INT) == canInv(lc(f)) :: SUP INT;
>> and cancelling the fraction of num and den in Fraction(SUP(INT)) is
>> by
>> c := canInv den; (num/c, den/c).
>> [..]
>
> Well, yes. That would probably every mathematicians way. I admit that
> FRAC(SUP(INT)) was not the best example, but I guess you understood what
> I meant, namely that there may be several good choices for a canonical
> form and without proper documentation, you cannot rely that the
> programmer of the Algebra library has chosen the same as you in DoCon.
Yes, probably, there exist difficult examples for defining any correct
canInv method. Anyway, it is desirable for documentation to explain what
is canInv as notion, and what method is chosen -- at least for easy cases.
>>>> I suggest fraction(m, num, den),
>>>> a) where m may be MtPrime or Generic,
>>>> b) this operation to be implemented by the Axiom library, not by the user,
>>>
>>> Sorry, but we are not in a situation like in Maple or Mathematica. User
>>> code is indistinguishable and treated in exactly the same way as the
>>> library that comes with FriCAS. In Maple or Mathematica, they have a
>>> kernel and then there are (interpreted) user functions. That's not the
>>> case for SPAD files. Domains/Categories/Packages in user defined .spad
>>> files are compile in the same way as library functions just like in any
>>> other ordinary programming language.
>
>> I do not understand why does this matter.
>
> You seemed to make a distiction (in (b)) between the Axiom library code
> and the user code. If *you* write code and it enters the "official"
> repository. Will you count that as user code, because you are just a
> user or as library code? If your code enters FriCAS, you will probably
> be asked to help maintaining it. Otherwise it faces the chance of
> becoming dead.
(b) is due to that this requires to deal with the internal representation,
this cannot be written correctly in Spad, and, I think, this is for the
official developers
(but I wrote later that the practical need of fraction-MtPrime is small).
> In Aldor one would even have the "extend" keyword and so could add new
> properties/functions to already existing domains.
>
This is the most suspicious thing which I observe in Axiom.
So far, I hope that I have missed some point. But you are the second
why mention the feature.
It is difficult to imagine how can an user behave without adding his
category instances to the standard library domains.
For example, in DoCon, I introduce a category (class), say (contrived)
class Sized a where size :: a -> Integer
And usually the first instances for such a category are like this:
instance Sized Integer where size = abs
instance Sized a => Sized [a] where size = sum . map size
instance (Sized a, Sized b) => Sized (a, b)
where
where size (x, y)= (size x) + (size y)
Here Integer, [] := List, and (,) := Pair
are type constructors from the standard library. And this helps a lot
the furher usage of Sized.
For example, when an user defines a category Foo, very often, Integer
must be a member of this category, that is mathematics itself strongly
requires this. This way things are explained in textbooks.
Hence an instance of Foo must be defined for Integer.
If Spad does not allow this, then this is extremely strange.
Because the very claim of the Axiom/Spad project was just following
mathematics in defining algorthms in a generic way.
Now, if one needs to use this Sized for Integer in Spad, one has to
define a copy domain Integer2 and add an implemantation of Sized to
Integer2 ??
And to write almost everywhere in the program Integer2 instead of
Integer ??
And if the program uses 50 library domains in a simialr way, one needs
to create 50 more domains or constructors and use 50 different names for
them ??
MyList, MyProduct, MyInteger, MyFraction, MyUP, MyPOLY, MyMatrix ... ?
Am I missing something?
>> The difference between the FriCAS developers and user is greater than
>> the difference between GHC team and GHC users.
>
> Unfortunately true. I would like more users to speak up on the mailing
> list and slowly become involved in FriCAS development. Dream, dream.
I meant a different thing. I meant that the FriCAS developers deal more
often with a language other than Spad, with internals
(which is almost impossible for users, and not needed for users),
the compiler messages look lispy, and so on,
while the Haskell team writes just in Haskell (except certain very
particular libraries).
This is only my impression, may be wrong.
Regards,
------
Sergei
[email protected]
--
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.
