[GiNaC-devel] Polynomial arithmetics

Alexei Sheplyakov varg at theor.jinr.ru
Tue Sep 23 11:39:33 CEST 2008


Hello,

On Mon, Sep 22, 2008 at 10:34:00PM +0200, Bernard Parisse wrote:

> when I'm using a library, like GMP or NTL or whatever, I don't look at
> the coding style,

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.

> What's wrong with giac error handling?

giac always throws std::runtime_error. How do I distinguish what was
exactly the reason of error?

> 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}

> 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_

class gen {
  public:
    short int subtype;
		// 2 bytes
    short int type;
		// yet another 2 bytes
    int * ref_count; 
		// yet another 8 bytes to store the pointer, and extra 4 to store
		// the value.
    union {
      // atomic types
      int val; // immediate int (type _INT_)
      double _DOUBLE_val; // immediate float (type _DOUBLE_)
      mpz_t * _ZINTptr; // long int (type _ZINT)

			// So the union is aligned at 8 bytes, but only 1 of them is used

[skipped the rest because it's way too ugly]
	
> , 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.

> Moreover most modular computations are done with int, not gen nor GMP.

However public functions take gen as an input.

Best regards,
	Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20080923/fbf3f016/attachment.sig 


More information about the GiNaC-devel mailing list