On Wed, Jan 18, 2012 at 1:25 PM, Waldek Hebisch wrote:
> Bill Page wrote:
>>
>> I have a similar "lack of respect" for macro usage. SPAD should
>> consistently be a high level language. Macros belong (perhaps) at a
>> lower level in Boot and in Lisp. If there is something that you think
>> requires a macro in SPAD I would take that as a criticism of the
>> language. It seems to me that even the use of the ... where clause
>> should not encourage us to think in terms of macros but rather as a
>> way of locally defining a context.
>
> Look at DoubleFloatEllipticIntegrals and FloatEllipticFunctions,
> both in special2.spad.pamphlet. The real and complex versions
> are very similar.
When I see the prefix DoubleFloat and Float in the names of these
packages I think immediately that something must be wrong with this
design. DoubleFloat and Float are names of domains. Somehow here the
programmer expects to make an implicit association with this domains.
In fact it seems like this must be a post facto extension of these
domains. Why are these functions on exported by the domains?
I realize that this is not your original design but most probably
patterned after the older code in special.spad.pamphlet. Perhaps this
design had some advantages when it took a long time to re-compile
Axiom and memory space was limited but it does not seem like that to
me today.
If there really is some advantage to be gained from having this code
in a separate package then why not write them in a generic manner
something like this:
EllipticIntegrals(F:Join(Field, TranscendentalFunctionCategory) ): with
ellipticRC : (F, F) -> F
...
if F has arbitraryPrecision then -- Float
...
else -- DoubleFloat
if F has ComplexCategory(F) then -- Complex
...
Of given the often adhoc seeming design of some other parts of the
library this might not be quite so straight forward but it seems
sensible to me to work towards this.
Would this sort of code really be significantly slower than your
performance optimized version?
> In DoubleFloat case we want to use fast
> version of square root for real version (it leads to much faster
> code) but regular square root for complex version. In Float
> case we need to raise errors in real version for arguments that
> are legal in complex version, OTOH complex version needs more
> tricky handling of periods. So I have parts which are exactly
> the same and parts that differ. I use macros to use single
> definition for common part of code. In principle I could
> create a common generic package for shared parts, but:
>
> - code is not generic, there are just two versions (real and
> complex)
That some parts of the code is common seems like a reasonable
definition of "generic" to me.
> - I prefer to keep code together (shared parts are strongly
> related to no-shared ones)
It might also make sense for something like SpecialFunctionCategory to
provide default code for many of these function? Where there are some
domain specific optimizations only these would then be given in the
domain to override the generic versions.
> - there is little gain in efficiency from using non-generic code.
>
Perhaps you meant to claim that there is little to gain from generic code?
Using a macro is seems like sort of the ultimate in generic code -
arbitrary text with textual substitutions. I think the goal is not so
much to be generic as it is to express the formal abstract structure
of the mathematics.
> Or look at 'addm!' in poly.spad.pamphlet. This routine is
> performance critical -- speed of polynomial multiplication
> (and conseqently of most our symbolic operations) depend on
> it. There are two versions of code, one that uses machine
> integers, the other general ones. Machine integers can
> be used in most cases and this version is much faster than
> the other one (using generic operations), but we want
> correctly handle general case. I use macro to
> share most of body of 'addm!', so the versions just
> differ in declarations and few operations which explicitly
> involve types.
I don't much like looking at ADDM_BODY. It seems to me that very
little is gained by factoring it out.
>
> I do not think there is other way n Spad to have fast
> specialized versions and share code...
>
I am tempted to spend some time trying to compare a more generic
version of the code in special2 to the "optimized" version. I am not
convinced that there must be such a great difference. But I must
admit that you do obviously have a great deal more experience than I
do in this matters.
> Of course, for each specific use case one can find a
> language feature which handles such case. But the point
> is that macros form a simple and general mechanism.
> I do not see way should we reject them when they
> solve real problems.
>
Assembler language (or for that matter Lisp) also solves very real
problems but we discourage it's use in the Axiom library for what I
think are some very good reasons.
Regards,
Bill Page.
--
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 fricas-devel@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
