Bill Page wrote:
>
> Here is a more specific example from expr.spad.pamphlet:
>
> )abbrev package PAN2EXPR PolynomialAN2Expression
> ++ Author: Barry Trager
> ++ Date Created: 8 Oct 1991
> ++ Description: This package provides a coerce from polynomials over
> ++ algebraic numbers to \spadtype{Expression AlgebraicNumber}.
> PolynomialAN2Expression():Target == Implementation where
> EXPR ==> Expression(Integer)
> AN ==> AlgebraicNumber
> PAN ==> Polynomial AN
> SY ==> Symbol
> Target ==> with
> coerce: Polynomial AlgebraicNumber -> Expression(Integer)
> ++ coerce(p) converts the polynomial \spad{p} with algebraic number
> ++ coefficients to \spadtype{Expression Integer}.
> coerce: Fraction Polynomial AlgebraicNumber -> Expression(Integer)
> ++ coerce(rf) converts \spad{rf}, a fraction of polynomial \spad{p}
> with
> ++ algebraic number coefficients to \spadtype{Expression Integer}.
> Implementation ==> add
> coerce(p:PAN):EXPR ==
> - map(#1::EXPR, #1::EXPR, p)$PolynomialCategoryLifting(
> + map(coerce, coerce, p)$PolynomialCategoryLifting(
> IndexedExponents SY, SY, AN, PAN, EXPR)
>
> IndexedExponents SY, SY, AN, PAN, EXPR)
> coerce(rf:Fraction PAN):EXPR ==
> numer(rf)::EXPR / denom(rf)::EXPR
>
> ---
>
> The lisp generated for this is shown below:
>
> +++ /home/wspage/new-lambda-build/src/algebra/PAN2EXPR.NRLIB/PAN2EXPR.lsp
> 2009-03-22 2
> 3:29:39.000000000 -0400
> @@ -2,14 +2,7 @@
> (/VERSIONCHECK 2)
>
> (DEFUN |PAN2EXPR;coerce;PE;1| (|p| $)
> - (SPADCALL (CONS #'|PAN2EXPR;coerce;PE;1!0| $)
> - (CONS #'|PAN2EXPR;coerce;PE;1!1| $) |p| (QREFELT $ 15)))
> -
> -(DEFUN |PAN2EXPR;coerce;PE;1!1| (|#1| $)
> - (SPADCALL |#1| (QREFELT $ 10)))
> -
> -(DEFUN |PAN2EXPR;coerce;PE;1!0| (|#1| $)
> - (SPADCALL |#1| (QREFELT $ 8)))
> + (SPADCALL (ELT $ 8) (ELT $ 10) |p| (QREFELT $ 15)))
>
> (DEFUN |PAN2EXPR;coerce;FE;2| (|rf| $)
> (SPADCALL (SPADCALL (SPADCALL |rf| (QREFELT $ 18)) (QREFELT $ 16))
>
> ----
>
> Using 'coerce' directly instead of the trivial lambda expression seems
> to generate significantly better code. It seems unlikely to me that
> any Lisp compiler would be able to optimize this difference away.
> Should we also consider making this change?
Version using coerce here gives both smaller and faster code.
However, when making optimizations one question is if the
change matters. Without hard data from profiling reasonable
guess is that this change does not matter. So (unless we get
extra information) our criterion here should be code readability.
I must say that I find the first version (using lambda expressions)
more readable than the second one. First, the first version
contains target type. Given that coerce is highly overloaded
it makes a difference. Second, we typically use :: for coercions,
so it is not obvious why coerce is used this time.
So I would be (weakly) against such change.
Concerning compilers: yes, Lisp compiler has almost no chance
to optimize the resulting code. Such optimization is job
for Spad compiler. Our current compiler is organized in a
way which makes implementing this optimization hard. But
techniques for doing such optimization are standard, and
sooner or later we will implement them.
--
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
-~----------~----~----~----~------~----~------~--~---
