[GiNaC-devel] Polynomial arithmetics

[bernard.parisse]

>
>
>If the library does everything I need and is well maintained I don't care
>> about code ugliness either (but I haven't seen any well maintained ugly
>> code yet). But there are no such libraries in a real world. Typically some
>> necessary functions/features are missing and nobody (except myself) is
>> going to add them. The same applies to fixing bugs. That's why I avoid
>> ugly code.
>>
>  
>

Why do you believe I would not fix a bug, add a function or whatever is meaningfull?
The right question you should ask yourself is how much time you will spend to do it better/faster? Is that time really worth it?

>>> > What's wrong with giac error handling?
>>    
>>
>> 
>> giac always throws std::runtime_error. How do I distinguish what was
>> exactly the reason of error?
>> 
>  
>

The reason is somewhat described in the what() method.
Inside a call to gcd or factor with meaningfull arguments, if you get a std::runtime error, it will be a bug, that's why I don't see any reasons to  bother about a more complex error scheme.

>>> > I just find it stupid that people prefer to redevelop something already
>>> > working and C++-usable.
>>    
>>
>> 
>> \begin{sarcasm}
>> Why did you write giac then?
>> \end{sarcasm}
>> 
>  
>

Because there was no C++ CAS library available.
I mean not a symbolic library, like GiNaC, but also with gcd,
factorization, integration, calculus, etc.
The difference is the N between GiNaC and giac.

>>> > If you had some look at giac, then you have perhaps observed that 
>>> > giac::gen use hardware integers for smalls integers (_INT_)
>>    
>>
>> 
>> giac::gen wastes at least 16 bytes to store that _INT_
>> 
>  
>

sizeof(gen)=16, sizeof(int)=4. But you won't suffer from it for 
intermediate computation, since for example modular 1-d gcd is done with 
array of ints. The extra space is only required for initial and
final data, which is negligible for non trivial gcd and factorization.

>>> > , GMP is used for int largers than 231 (_ZINT).
>>    
>>
>> 
>> Wonderful! So giac::gen uses 16 bytes to store int8_t, and 24 bytes to
>> store int32_t. I think this is absolutely inacceptable.
>>
>  
>

It's a typo, 231 has no meaning, it is of course 2^31 (2**31).
Otherwise I could easily improve the timings you can see there
http://www-fourier.ujf-grenoble.fr/~parisse/giac/benchmarks/benchmarks.html
Unfortunately it won't be that easy:-)

>>> > Moreover most modular computations are done with int, not gen nor GMP.
>>    
>>
>> 
>> However public functions take gen as an input.
>> 
>  
>

I don't see why you would need to call functions that do not take
gen as input since GiNaC representation for polynomials is symbolic, 
but many polynomials functions are also exported, and, if not, I can just
add them to a header if someone needs it.

I keep thinking it could be interesting to have some complementarity between GiNaC and giac.