remove pomopo! and fmecg

[Qian Yun]

I suggest to remove pomopo! and fmecg from code base.

First, these are strange names. It is used nowhere else,
only in FriCAS. A more appropriate name would be "add_and_mul".

Second, it is not widely used inside FriCAS either.
And it is easily replaceable.

Third, these 2 functions are designed to have better performance,
to avoid extra allocation, I guess. But fmecg implementation
has O(n^2) list iteration, I doubt it performs better than alternative.

- Qian

[Waldek Hebisch]

Main point is performance for small inputs where big-O reasoning
may be misleading. Fusing operations _is_ important for
performace. In POLYVEC we have 'vector_combination', it
is logically redundant, having just multiplication by scalar
and addition would do. But fused operation means that
some time-critical operations in guessing package as
2 times faster than with simpler implementation, so IMO
it is worth the effort.

You may be able to re-arrage operations to make them faster
than current way, but simply replacing pomopo! and fmecg
by higher level operations is likely to give measurable
slowdown.

BTW: Our polynomial arithmetic is higly recursive and
pomopo! and fmecg serve as final points of recursion,
so any change here while not very tricky may be more
tricky than you think.

BTW2: pomopo! and fmecg are really internal things,
exported because they must be available in more than
1 domain/package. So it is reasonable to use somewhat
obscure names so that normal users are more likely to ignore
them.

--
Waldek Hebisch

[Qian Yun]

On 10/6/22 02:00, Waldek Hebisch wrote:
> On Wed, Oct 05, 2022 at 07:07:00PM +0800, Qian Yun wrote:
>> I suggest to remove pomopo! and fmecg from code base.
>>
>> First, these are strange names. It is used nowhere else,
>> only in FriCAS. A more appropriate name would be "add_and_mul".
>>
>> Second, it is not widely used inside FriCAS either.
>> And it is easily replaceable.
>>
>> Third, these 2 functions are designed to have better performance,
>> to avoid extra allocation, I guess. But fmecg implementation
>> has O(n^2) list iteration, I doubt it performs better than alternative.
>
> Main point is performance for small inputs where big-O reasoning
> may be misleading. Fusing operations _is_ important for
> performace. In POLYVEC we have 'vector_combination', it
> is logically redundant, having just multiplication by scalar
> and addition would do. But fused operation means that
> some time-critical operations in guessing package as
> 2 times faster than with simpler implementation, so IMO
> it is worth the effort.

If so, does it make sense to modify fmecg to look more like
pomopo!, which improves performance further for small inputs
and big inputs?

> You may be able to re-arrage operations to make them faster
> than current way, but simply replacing pomopo! and fmecg
> by higher level operations is likely to give measurable
> slowdown.
>
> BTW: Our polynomial arithmetic is higly recursive and
> pomopo! and fmecg serve as final points of recursion,
> so any change here while not very tricky may be more
> tricky than you think.

> BTW2: pomopo! and fmecg are really internal things,
> exported because they must be available in more than
> 1 domain/package. So it is reasonable to use somewhat
> obscure names so that normal users are more likely to ignore
> them.
>

pomopo! is only used in one place, "noKaratsuba". Which this
function should not exist in the first place, it should be
exported by PR and called something like "mul_classical".

- Qian