On Mon, Feb 27, 2012 at 07:13:11PM +0100, Ralf Hemmecke wrote:
>>> Simplest answer is: use pretend.
>
>> For example, CONS(-2, 3 ::INT)$Lisp pretend Fraction INT (I)
>
> No!!! If ever possible avoid Lisp in your program. That's in my eyes
> even worse than using pretend. As for Fraction(...) you track the
> representation down along the "add" inheritance. Since SPAD doesn't
> allow multiple inheritance in the "add" line, that should be easy.
>
> [..]
> Anyway, if ever you use "pretend" for your purpose in Fraction(Integer),
> you should do something like
>
> ([n,d]$Record(num:Integer,den:Integer)) pretend Fraction(Integer)
>
> That is expressing everything in terms of the SPAD language without ever
> saying that the underlying assembly language is LISP.
>
> It's important for the future. Maybe some day, we change from LISP to
> Forth or to C or LLVM or whatever.
I see. Thank you.
> if S has Canonical and S has GcdDomain and S has canonicalUnitNormal
> then Canonical
Sounds like GCDRing sS in DoCon.
>
>> Currently, DoCon can form Fraction D only for a GCDRing D.
>> But even in this restricted case Axiom's method may differ from DoCon's
>> for some instances of such D.
>
> I guess, currently, it doesn't. At least not for Fraction(Integer). But
> Fraction as a generic domain constructor is quite general. 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).
I am sorry if I have forgotten something.
Does this look natural?
>> This is why I suggest for an Axiom (FriCAS) library to provide
>>
>> package ... (D : IntegralDomain)
>> ...
>> fraction(m : FooMode, num : D, den : D) : Fraction D == ...
>>
>> in which m may be MtPrime or Generic
>> (may be, to provide the second format for `fraction', with skipped `m').
>
> But the maintenance effort is the same if it lives in your package or in
> a separate package in the Algebra library. This "fraction" function has
> to know the internal representation of Fraction. And the only place
> where the representation should be known is Fraction itself. So one
> would have to introduce this function into the Fraction code and *trust*
> the programmer that the input is as required. But since that cannot (and
> by design should not) be checked, the only place for a good
> specification of that function would be the documentation.
>
>> MtPrime means that num and den are mutually prime,
>> that is Ideal(num) + Ideal(den) = (1).
Please, see the improvement in another my letter!
>> 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.
For example, the Glasgow Haskell (GHC) library has the module Data.Map
for operations with finite maps. They are programmed in Haskell and
are compiled similarly as user programs.
I can write my own code for Data.Map, and overload it.
Another way is to rely on GHC.
Because the GHC team announces that it is going to support Data.Map, as
other GHC library. Each new version is going to support union of maps,
etc. If I find a bug there I report them.
This software is free, and they are not oblidged.
But this team somehow announces:
we are going to support at least this set of
functions and operations and language extesion features.
And this has a name: "ghc-ext (language) + GHC library"
(in addition to the standard Haskell-2010 and its library).
Each impementation announces whether it supports the standard of
Haskell-2010. This is very important for users.
If GHC stops supporting some needed thing in ghc-ext, then I'll
either remain with an old GHC version or re-implement the thing in
Haskell.
The most dangerous thing there is Overlapping Instances in the Language.
If they stop their support, I'll need to remain with old version.
What is the notion of standard in Axiom and FriCAS community?
The difference between the FriCAS developers and user is greater than
the difference between GHC team and GHC users.
Because in GHC more part is programmed in Haskell than the part of
Axiom programmed in Spad. Haskell anf GHC have a library, but most of
this libarary is _not built-in_, it is just a prelude witten in Haskell,
and even can be overloaded by the user.
>> Also I would need to study just now all the details of treating Fraction
>> in Axiom -- for the case of D : GcdRing.
>> This way does not look safe nor nice.
>
> But there are not too many people who would do the job for you. It's
> open source and unfortunately, FriCAS is not that wide-spread yet.
>
>> So, if Axiom(FriCAS) rejects my above suggestion of joining
>>
>> fraction(m : Mode, num : D, den : D) : Fraction D,
>>
>> then I would be forced to apply (num/den) :: Fraction D,
>> and this will lead to an unneeded gcd computation during the interface.
>
> Well yes that should be the first way to go. I think you should first
> program in a typesafe way and only then look for bottlenecks that slow
> down your code.
I fear, my noise was greater than the real need (see another my letter).
> and only then look for bottlenecks that slow down your code.
Currently it is so slow that without a real speed up the interface
project hardly ever has sense. That is the matter.
For INT, Fraction INT, UP(x, Fraction INT):
a) parse*interptet of FriCAS is 10 times slower than my special dParse
written in Spad,
b) dParse is 90 times slower than addition (+) of the these data to
itself in a Spad program.
And before using SBCL, this all was slower even 3 times more.
I do not understand, so far, what is the cost of this domain evaluation
in dParse.
May be, I need profiling.
I have FriCAS-1.1.6 built from source under SBCL-1.0.55, and may be,
could set profiling in this Lisp.
For example, what time takes lexLots (initial breaking to lexemes),
and so on.
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.
