On Tue, Feb 21, 2012 at 05:16:50PM +0100, Ralf Hemmecke wrote:
>> det mM = 0
>
> Clearly, Haskell (being lazy) sees the full expression and thus can take
> short-cuts. Usually in computer algebra, the above means evaluation of
> det on mM before the result is handed over to the = function.
>
> Now, in FriCAS, one cannot even hope for a short-cut. = is a function
> like any other. So, if I have two functions
> det: X -> Z and =: (Z, Z)->Boolean
> then it is not actually clear what = actually is. One cannot decide just
> by the name. So the only way to get a proper result is to evaluate det
> for it's input and then apply =. That would probably be the same in a
> lazy language in which one has the freedom to define what = is.
>
In haskell, the user program does implement the operation (==). It is
an operation from the class Eq, and it is overloaded (like almost
everything in Haskell). DoCon defines f == g for polynomials as
f == g = (polMons f) == (polMons g)
-- comparing the monomial lists. And (==) is defined for lists by the
library instance as
(L):
(_ : _) == [] = False
[] == (_ : _) = False
(x : xs) == (y : ys) = x == y && xs == ys
(&& is computed lazily).
Now, the interpreter computes det mM == 0 -> (polMons (..)) == []
-->
(certainLeadingMonomial : (call for the rest of monomials)) == []
This matches the sample of the first equation in (I).
So, the interpeter stops, returning False.
The example was lucky in that certainLeadingMonomial has appeared fast.
For a lazy functional language, there are, may be, 1/4 of lucky examples
on average.
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.
