CLN/ginac: factoring announce, questions

[Ralf Stephan]

Richard,
thanks for the detailed reply. Const correctness is noted for my next
submission (which will be to you), as well as testing. I understand from 
your comments that, while factor() will go into CLN, divisors() won't.

> Now I do have two questions: What do you mean by adapting CLN's memory
> scheme to STL?

As far as I understand, CLN doesn't use new/delete and its objects are
allocated using malloc_hook. OTOH, it may not be sufficient to malloc_hook
sizeof(std::vector<...>) and give that to the caller since STL might
itself allocate space using its own (default) allocator in the process.
If that is really of concern, the solution could be to write an allocator
(STL object) using malloc_hook for that and other cases. That was what
I meant. 

Meanwhile, I favor moving the burden of space allocation to the caller
via working on a referenced vector of pairs of cl_Is.

> The user-visible side of the bridge constitute perfectly
> copyable objects with value semantics and are hence suited for STL, right?

CLN's objects are suited for STL, of course, since STL uses the object's 
interface. I was sceptical about the reverse, i.e., if STL deletes 
everything(!) it creates with its normal malloc. The user relies on
garbage collection of an STL container with CLN objects that is returned
by CLN. But the point is moot, anyway, with factor having the interface

int factor (const cl_I& n, std::vector<std::pair<cl_I,cl_I> >& pv);

> Just have a look at the Bernoulli number cache in GiNaC.  Second, is
> std::list< factor_exponent_pair_or_whatever > really a wise decision?

I used the word 'list' not careful enough, sorry. I meant 'container'.

>     Well, sorry for the late answer.

I would have waited for it but nothing in CLN indicates who is its 
maintainer, so I was unsure if I mailed to the right address.

Regards,
ralf