On Mon, Feb 27, 2012 at 12:15:08PM +0100, Ralf Hemmecke wrote:
>> 2. Canonic fraction
>> -------------------
>
>> For a mutually prime n, d : (D : IntegralDomain),
>> how to set fraction of n/d in Spad with avoiding gcd and also
>> obtaining a correct fraction?
>
> Simplest answer is: use pretend.
>
?
For example, CONS(-2, 3 ::INT)$Lisp pretend Fraction INT (I)
avoids gcd. (-2)/3 over INT is defined as canonical in DoCon.
But it may occure not canonical in Axiom.
Suppose that in the next version of FriCAS its canonical form becomes
CONS(2, -3)$Lisp (II)
-- FriCAS is free to choose a different canonical form method, a matter
of internal representation etc.
In this case, it will occur (I) ~= (II), and this `pretend' usage will
occur incorrect. Right?
Moreover, this CONS-pretend is not safe because Axiom's idea of
canonizing a fraction may differ from DoCon's one.
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.
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').
MtPrime means that num and den are mutually prime,
that is Ideal(num) + Ideal(den) = (1).
Example:
D = POLY([x,y,z], INT), and gcd(f:D, g) = 1
is found in previous computation (done for a need other than Fraction).
This is a good point to write
(1) fr : Fraction D := fraction(MtPrime, f, g)
instead of (2) fr := (f/g) :: Fraction D
and instead of (3) fr := CONS(f, g)$Lisp pretend Fraction D.
Because (2) is often more expensive than (1), and (3) is not safe.
Generally, this `fraction MtPrime'
a) gives a hope for optimized computation,
b) guarantees correctness, because it is a part of the standard library,
it is implemented by the Axiom developers,
the user does not need to look into the Fraction representation.
It is a matter of the Axiom implementation of how to use the knowledge
given by m = MtPrime.
This `fraction' may also become an operation from the
QuotientFieldCategory.
Am I missig something?
In the first letter I wrote `m = NoGCD'.
But now I improve it to MtPrime, because it has more sense, because
probably, Axiom canonizes fraction not only for a GcdRing (and MtPrime
talks generally, of the sum of ideals).
> So the only way you can do what you want is "pretend" or provide a patch
> that adds a function constructFractionWithoutCancelling:(S,S)->%.
>
> But I will probably argue a lot that this function is basically like
> pretend and should better be avoided.
No. constructFractionWithoutCancelling and `pretend' (for canonic)
is the same. And they both are incorrect, depend on a particular
representation.
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,
c) in simple cases (D = INT, POLY(vars, INT), POLY(vars, Rational), and
such) it will hopefully lead to optimization,
d) which usage is totally safe.
>> When DoCon puts a string to Axiom, fractions are in their canonical form
>> by "gi". And it is desirable to avoid gcd when parsing (by dParse)
>> of such a fraction to Axiom.
>
> OK, this is a situation where your parsing framework should know about
> the internal structure of FriCAS domains and Fraction in particular,
> i.e. "pretend" should be the way to go.
>
> You should, however, mark such "pretend" places in big bold red letters
> [..]
In this case I will need to change dParse each time when FriCAS changes
treating of Fraction.
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.
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.
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.
