Serge D. Mechveliani wrote:
>
> On Fri, Mar 02, 2012 at 12:35:14PM +0100, Ralf Hemmecke wrote:
>
> >> I am trying to find out whether the language allows, in principle, a clear
> >> and efficient dispatching for such operations which have a complex set of
> >> implementation cases overlapping non-trivially and having different
> >> generality levels.
> >
> > I think my previous mail should have shown you how dispatching can be
> > done on a domain level. The exports would simply list the function
> > unconditionally.
>
> Then, the next question is
> why the `factor' instances are not so nicely
> dispatched in the current FriCAS, Axiom ?
>
> For I am a bit confused.
> 1. Waldek wrote about the category of Explicit...,
> and of some performance problems related to dispatching `factor'.
> 2. I write in my testParse.spad :
> factor(f) $UnivariateFactorize(UP(x,INT))
> -- and this is by the advice read from e-mail.
> Could I happen to call `factor' in this case from other place, where
> its impementation is less efficient?
> 3. Waldek wrote, that it is not nicely dispatched -- if I understand
> correct.
> Is this by occasion or there are some fundamental reasons for this?
>
I would say that general dispatching features of Spad are adequate.
There are limitations, for example conditions in export lists have
restricted form (basically you can form boolean formula where
atomic tests are 'A is B' and 'A has C').
However, in case of factor:
- there are several places when dispatching would be needed
(minimally in SparseUnivariatePolynomial and
SparseMultivariatePolynomial, but there are other polynomial
domains).
- information needed for dispatching is not available in places
where we would like to dispatch.
- we also need appropriate conditions in export lists.
- besides dispatching we need actual code, at least code
which converts from one represetation to another
Original Axiom developers invented a clever scheme, where
only two conditions are used for dispatching, namely
PolynomialFactorisationExplicit and characteristic, the
rest is done by "generic" code. This scheme
involves more than 'factor', namely also gcd and
square-free factorisation. And it adds operations
to several domains: baseline cases to Integer and
finite fields, and recursive reductions to Fraction,
algebraic exensions and polynomial domains.
As I wrote problem with PolynomialFactorisationExplicit
is that supporting _implementation_ is too slow (slower
than current factoring and gcd routines). Of course
one could try to mix the two implementations. This
is doable, but not very attractive:
- there would be are several dispatching places and
messy conditions, so one would end up with maze of
conditionals
- besides adding conditionals one would have to propagate
information needed for dispatching
- the end result would be code which is is much slower
than what is possible -- simply because better algorithms
were invented after our current factoring routines and
PolynomialFactorisationExplicit were written.
In other words, after adding dispatching code we would
later have to throw it out because we want better
implementation (which needs _different_ conditions).
So I decided to work on new implementation. In other
words, if I thought that we really need dispatching
between implementations I would do it. But IMHO it
is too much work (and too little effect) to do it
knowing that it will be removed later.
--
Waldek Hebisch
[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.
