May 2004 - GiNaC-devel

series and expansion.
by Chris Dams 20 Jun '04

20 Jun '04

Dear developers, Some time ago I sent a patch to prevent .series() to revert to .expand() internally. This was because in the case that one has polynomial^some_large_integer the expansion will be hopeless. However, I keep running into this kind of problems. To determine the real_ldegree in mul::pseries, still expansion is used with potentially the same problems. I think there are two possible solutions to this problem. (1) Tell your users (me included) that they should not be substituting polynomials into each others when they should have used power series from the start. (2) Create (or ask me to create) a patch that solves this particular case and hope that there will not be ten other instances where .series() is going to crash a program. (3) Forbid any occurance of .expand() in any method or function that may be called from .series(). Create a new method to determine the leading behaviour of any expression. Let .series() use this and let .series() work by calculating power series of subexpressions and combining these into the power series for the entire expression. I am in favour of (3). The only reason not to use (3) would be if someone in this mailing list could come up with an example where (3) clearly is horribly inefficient. What do other people think? Best, Chris Dams

2 3

Re: C++ module ordering (was: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP)
by Richard B. Kreckel 10 May '04

10 May '04

On 6 May 2004, Ian Lance Taylor wrote: > > Please see <http://www.ginac.de/lists/ginac-devel/msg00623.html>. > > Those bits are the end of my message weren't actually written by me. > They were written by some of the C++ compiler hackers at Cygnus. So it remains a mystery what was meant by "full runtime dependency analysis [...] with no linker mods"? Sad. > Are you familiar with the init_priority attribute supported by g++? > It seems to me that it handles most of the problems associated with > static object initialization order. > http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Attributes.html#C++%20Attri… Sure, but that is only pampering about the real problem: Who establishes the PRIORITY variables? The programmer would have to do it manually. Any programmer is likely to get it wrong if confronted with several hundreds or even thousands of modules. Working with an automated mechanism is much less prone to errors. Hence init_priority is not at all an acceptable solution, IMNSHO. A while ago, I've been debugging an industrial application where the linker line was basically rearranged automatically based on a self-made scheme: a script was extracting dependency ordering information scattered by the programmer. That solution is equivalant to GCC's init_priority. The lesson learned from that experience are: 1) Most professional C++ programmers are not aware of there being a problem. Really. :-( 2) Even if they are, they are unlikely to get it right. #-( 3) If they don't get it right, debugging code which hasn't even started running yet is intersting. :-/ Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

3 4

CLN 1.1.7 released
by Richard B. Kreckel 02 May '04

02 May '04

Hi! This is to announce the availability of CLN version 1.1.7. It is source and binary compatible to version 1.1.6. Noticeable features are fixes for a couple of corner case bugs and the inclusion of a workaroud for a miscompilation issue with GCC 3.1.0 - 3.3.4-prerelease. Cebix: Is my handling of the spec file finally okay? Qalculate-hackers: Oh, yes, that miscompilation issue is responsible for crashes you may see when typing into the number base conversion dialog. It was reported via the Debian BTS. Enjoy -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0