Hello list,

as my fractal-drawing program was not working for a long time, after digging deeper and deeper I discovered a bug in ucomplex.h. Actually the cln() implementation is wrong, which I noticed after comparing to other source code available on the web. I attach the patch fixing it.

Given the chance, I would like also to ask some things about this unit. It is not documented or even mentioned anywhere, so it was pretty hard to find it in the first place. So is this unit considered an official part of fpc?

Moreover, why are functions named in a C-like manner (cpow, cmod, csin)? Since we have function overloading, wouldn't it be nicer if they were named after math's unit functions (power, abs, sin)?

Finally, after reading the fpc sources for the first time, I noticed a lot of preprocessor stuff inside the implementation part, which reminds of ugly C code! In particular the following construct is seen all over the place, making the code harder to read:

  {$ifdef TEST_INLINE}
  inline;
  {$endif TEST_INLINE}

I understand the importance of these constructs, but it would be nice if somehow they were not there. Could they be moved to other files? Could they be only in the interface part? Any other ideas?

Thanks in advance,
Dimitris

P.S. Ofcourse I can send patches fixing some of the stuff I mentioned. My purpose is only to raise discussion to see if such changes are desirable. Sorry if I'm being offensive.

Applied, thx.

Given the chance, I would like also to ask some things about this unit. It is not documented or even mentioned anywhere, so it was pretty hard to find it in the first place. So is this unit considered an official part of fpc?

It is else it wouldn't be in the distro ;) I guess more documenting it was forgotten so far. Fill a bug report and I assign it to Michael :)

Moreover, why are functions named in a C-like manner (cpow, cmod, csin)? Since we have function overloading, wouldn't it be nicer if they were named after math's unit functions (power, abs, sin)?

Cross unit overloading wasn't available when this unit was written though I consider it a little bit dangerous in this case.

Sorry I haven't filed that bug report yet. It's just that I'm always bored of creating new accounts and of strange web interfaces, that is all. I'd appreciate if someone with a bugzilla account and an interest on this issue files the bug report, or else I'll do it myself sometime, just don't hold your breath. :-)

Could you please explain me the reasons? I am not at all experienced with function/operator overloading and I have some doubts myself (especially when combining function overloading with implicit type conversions because of := overloading). It's just that I presumed overloading would be safe enough, since they are a long time feature of freepascal.

Thanks,
Dimitris

Here is another uComplex bug, which showed as a dark dot at the center of my fractal! (Please tell me if I can attach binary images in this list) I attach a patch, which is not a resolution, but a warning calling for discussion on how to resolve this...

In a few words, when performing complex number division, an internal variable can overflow to inf, making the division result 0! This is incorrect implementation (since the final result fits in the given precision) and there are various algorithms to avoid it. Unfortunately those algorithms require more CPU cycles. Please read more at the following references.

Example:
-8.205959956708821E+231-1.772371481991416E+230i / -1.023033304562047E+199+4.128416533132317E+199i = 0.000000000000000E+000

References:
http://gcc.gnu.org/ml/fortran/2004-05/msg00029.html http://gcc.gnu.org/ml/gcc-bugs/2004-12/msg00820.html http://perso.ens-lyon.fr/jean-michel.muller/EMAsap03.pdf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902

Thanks in advance,
Dimitris

P.S. Something more seems wrong in uComplex but could be related to this. If not, expect another bug report soon

patch attached to show where the problem lies...

Dimitris

P.S. Something more seems wrong in uComplex but could be related to this. If not, expect another bug report soon

OK, I conclude. My symptoms are:
z**3-2= NanNani
z*z*z-2= -2.000000000000000E+000

After digging a bit I realized that this is not a problem of uComplex, but a problem of math unit. In particular exp(-Inf) returns NaN, where it should return 0. Unfortunately I got really lost when studying the fpc_exp_real implementation, and when I saw that the actually used version is in assembly I just gave up!

Any ideas of how it can be fixed?

Thanks in advance,
Dimitris

Dimitrios Apostolou wrote

OK, I conclude. My symptoms are:

I forgot to mention here that z=0

Hasn't anybody else the same problem? Who wrote the initial implementation for fpc_exp_real?

Which one :)? E.g. which platform?

> Unfortunately I got really lost when studying the > fpc_exp_real implementation, and when I saw that the actually used version > is in assembly I just gave up!

i386?

yes, i386. Sorry for not mentioning it.