Gpc

gpc@gnu.de

5400 discussions

#466 ???
by 320017353451-0001＠t-online.de 16 Jan '02

16 Jan '02

Where do I find errorcodes in general and this one in particular ? I had a look into /usr/share/doc/packages/gpc etc witout finding anything ... : -) Thanks Douglas P.S. It s an error which is not really reproduceable ... so I would like to know where to look closer ?!

2 1

Re: Complex_SqRt bug
by da Silva, Joe 14 Jan '02

14 Jan '02

OK, if you're happy that the code is correct ... I guess I just don't understand what the "a := Abs(Im(z)) / (2 * b)" statement does ... More accurate results are always welcome, anyway. Anyway, although you might say the Clipped_SqRt solution is a kludge, it is certainly not second-guessing. It would only be applied where the minimum theoretical argument was zero, in which case it would avoid (and eliminate) rounding errors which produced a slightly negative "zero". Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, January 10, 2002 9:30 PM > To: gpc(a)gnu.de > Subject: Re: Complex_SqRt bug > > da Silva, Joe wrote: > > > To be honest, the revised Complex_SqRt function you present > > is a bit too complicated for me. <G> > > > > So, my thinking is that, instead of re-writing the algorithm of > > Complex_SqRt and similar routines, it would be simpler and > > less error-prone in these situations, to utilize a new, alternative > > SqRt function, eg. : > > > > Function Clipped_SqRt (x : double) : double; > > {Alternative SqRt : Clips negative arguments, returning zero} > > begin {Clipped_SqRt} > > if x > 0 > > then > > Clipped_SqRt := SqRt (x) > > else > > Clipped_SqRt := 0 > > end; {Clipped_SqRt} > > > > Of course, you would only apply this alternative to SqRt when > > the argument cannot theoretically be negative ... > > I don't think so. This seems more like a kludge to me (first compute > a wrong value, and then second-guess in a subroutine what it could > really be). Besides, it would only avoid the problem in the "< 0" > case -- as Emil noted, "the patch above gives more accurate results > (even for arguments which do not trigger the bug)." > > BTW, I checked his code carefully to make sure it's mathematically > correct. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

4 3

Problems with GtkUnit
by Klaus F. Østergaard 14 Jan '02

14 Jan '02

Hi, I have a small problem with the GtkUnit. I have the unit installed, using make every thing just worked. All the tutorial programs compiled and they are ready to use. But when I try to compile the simple helloworld.pas with this: gpc -O2 -Wall --automake helloworld.pas -o ../../../pascal/bin/helloworld I get this error: In file included from helloworld.pas:5: ../units/gtk.inc:23: module/unit `gtkmarshal' could not be compiled In the helloworld I have changed the path from '../units' to '/home/klaus/temp/gtk/units' Am I missing something on the command line when I call the compiler, or is there a bug in the unit? Kind regards, Klaus F. Oestergaard

3 4

Complex_SqRt bug
by Emil Jerabek 14 Jan '02

14 Jan '02

The complex square root function crashes with a funny error message on some arguments close to the real line: [pas]% cat sqrt.pas program SqrtTest (Output); var C: Complex; begin C := Sqrt (Cmplx (4.2, 1e-8)); WriteLn ('OK') end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc sqrt.pas [pas]% ./a.out ./a.out: argument to `SqRt' is < 0 (error #708 at 805d837) [pas]% The square root is computed as \sqrt{X+iY} = \sqrt{(A+X)/2} + i \sqrt{(A-X)/2} sgn(Y), where A=|X+iY|. It seems that due to inaccuracies etc., A may turn out to be _less_ than |X|, if |Y| << |X|, which means that SqRt((A+-X)/2) gets a negative argument. I suggest the following patch. --------------------------------------------------- diff -U3 orig/p/rts/math.pas p/rts/math.pas --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 +++ p/rts/math.pas Mon Jan 7 21:34:43 2002 @@ -192,8 +192,7 @@ function Complex_SqRt (z: Complex): Complex; var - a: Double; - Sign: Integer; + a, b: Double; begin { SqRt (x + yi) = +/- (SqRt ((a + x) / 2) +/- i * SqRt ((a - x) / 2)) @@ -203,10 +202,15 @@ Principal value defined in the Extended Pascal standard: Exp (0.5 * Ln (z)), i.e. Sign (Re (SqRt (z)) := 1, Sign (Im (SqRt (z))) := Sign (Im (z)) } a := Abs (z); - if Im (z) < 0 then Sign := -1 else Sign := 1; - if a <> 0 - then Complex_SqRt := Cmplx (SqRt ((a + Re (z)) / 2), Sign * SqRt ((a - Re (z)) / 2)) - else Complex_SqRt := 0 + if a = 0 then Complex_SqRt := 0 + else begin + b := SqRt ((a + Abs (Re (z))) / 2); + if Abs (Im (z)) > Abs (Re (z)) then a := SqRt ((a - Abs (Re (z))) / 2) + else a := Abs (Im (z)) / (2 * b); + if Re (z) < 0 then begin var c: Double = a; a := b; b := c end; + if Im (z) < 0 then Complex_SqRt := Cmplx (b, -a) + else Complex_SqRt := Cmplx (b, a) + end end; function Complex_Ln (z: Complex): Complex; ---------------------------------------------------- It would also work to simply insert if Abs (Re (z)) > a then a := Abs (Re (z)); into the original version, but the patch above gives more accurate results (even for arguments which do not trigger the bug). When talking about math.pas, I also suggest a little optimization to the complex logarithm function; \log \sqrt x = (\log x)/2, but the RHS is (I guess) computed faster and more precisely: --------------------------------------------------- diff -U3 orig/p/rts/math.pas p/rts/math.pas --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 +++ p/rts/math.pas Mon Jan 7 22:10:08 2002 @@ -211,7 +211,8 @@ function Complex_Ln (z: Complex): Complex; begin - Complex_Ln := Cmplx (Ln (Abs (z)), ArcTan2 (Im (z), Re (z))) + Complex_Ln := Cmplx (Ln (Sqr (Re (z)) + Sqr (Im (z))) /2, + ArcTan2 (Im (z), Re (z))) end; function Complex_Exp (z: Complex): Complex; ----------------------------------------------------- Emil Jerabek

4 8

packed arrays again
by Emil Jerabek 14 Jan '02

14 Jan '02

There are still some problems with packed arrays of subrange types. (1) Initializers don't work properly. [pas]% cat packed1.pas program P (Output); type T = packed array [0 .. 2] of 0 .. 1000; var A: T value (1, 2, 0); begin if (A[0] = 1) and (A[1] = 2) and (A[2] = 0) then WriteLn ('OK') else WriteLn ('Failed: ', A[0] : 4, A[1] : 4, A[2] : 4) end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc packed1.pas packed1.pas:9: warning: too few initializers for array [pas]% ./a.out Failed: 1 0 0 [pas]% (2) In certain situations, assignment statements work incorrectly when the same subscribed packed array variable is accessed on both sides of the assignment. [pas]% cat packed2.pas program P (Output); var A: packed array [0 .. 2] of 0 .. 1000; function F (N: Integer): Integer; begin if N = 0 then F := 0 else begin A[N] := F (A[N]); F := A[N] + 1 end end; begin A[0] := 1; A[1] := 2; A[2] := 0; A[0] := F (A[0]); if A[0] = 2 then WriteLn ('OK') else WriteLn ('Failed: ', A[0]) end. [pas]% gpc packed2.pas [pas]% ./a.out Failed: 1 [pas]% The problem is in the statement "A[N] := F (A[N]);" in the body of F. During its execution, A[N] is _cleared_ before the function call, in particular the argument passed to F is always 0. The debugger session below illustrates this behavior. (gdb 5.0 doesn't understand packed arrays; I used a type-cast to Integer as a workaround. Integer(A)=A[0]+1024*A[1]+1048576*A[2], i.e. 2049=(1,2,0) and 1=(1,0,0).) [pas]% gpc -g packed2.pas [pas]% gdb a.out GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) break F Breakpoint 1 at 0x8049c2c: file packed2.pas, line 8. (gdb) run Starting program: /home/emil/pascal/pas/a.out Breakpoint 1, F (N=1) at packed2.pas:8 8 if N = 0 then F := 0 Current language: auto; currently pascal (gdb) watch Integer(A) Hardware watchpoint 2: (Integer) A (gdb) step 10 A[N] := F (A[N]); (gdb) step Hardware watchpoint 2: (Integer) A Old value = 2049 New value = 1 $08049cb4 in F (N=1) at packed2.pas:10 10 A[N] := F (A[N]); (gdb) bt #0 $08049cb4 in F (N=1) at packed2.pas:10 #1 $0804a1a9 in pascal_main_program () at packed2.pas:19 #2 $0804a2bb in main (argc=1, argv=$bffffacc, envp=$bffffad4) at <implicit code>:21 #3 $40064e5e in __libc_start_main (main=$804a294 <main>, argc=1, ubp_av=$bffffacc, init=$80494c8 <_init>, fini=$8066b50 <_fini>, rtld_fini=$4000d3c4 <_dl_fini>, stack_end=$bffffabc) at ../sysdeps/generic/libc-start.c:129 (gdb) step Breakpoint 1, F (N=0) at packed2.pas:8 8 if N = 0 then F := 0 (gdb) Emil Jerabek

2 1

Re: Complex_SqRt bug
by da Silva, Joe 14 Jan '02

14 Jan '02

Well, I haven't seen the computations, but if you are happy that they are "sound" and that they will be more accurate than the existing algorithm, then I agree that you should use them. The advantage of the Clipped_SqRt solution was simplicity and clarity (and certainty;-). However, it does not change the accuracy. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Friday, January 11, 2002 12:43 PM > To: gpc(a)gnu.de > Subject: Re: Complex_SqRt bug > > da Silva, Joe wrote: > > > OK, if you're happy that the code is correct ... I guess I just don't > > understand what the "a := Abs(Im(z)) / (2 * b)" statement does ... > > I could write down the computations if you like (unless Emil has > them readily available already) ... > > > Anyway, although you might say the Clipped_SqRt solution is a > > kludge, it is certainly not second-guessing. It would only be applied > > where the minimum theoretical argument was zero, in which case > > it would avoid (and eliminate) rounding errors which produced a > > slightly negative "zero". > > As I said, I'm no expert on numeric algorithms, but I think if an > algorithm can produce such wrong results, it might also be > inaccurate for other values and should be improved (such as > Complex_Sqrt). After all, normal rounding doesn't easily make a > positive value (even very close to 0) negative. So it might be > better if the programmer sees the problem clearly with an error > message. If it really turns out that an algorithm is as good as > possible (numerically) and still prone to this kind of problem, > something like Clipped_SqRt might be in order. But I guess this is > rather an exceptional situation, so Clipped_SqRt does not seem a > good candidate for a general library routine. > > But perhaps Emil can comment better on these matters ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

List of successful GPC ports
by Prof. A Olowofoyeku (The African Chief) 12 Jan '02

12 Jan '02

Hi all Do we have a canonical list of successful GPC builds? If not, can we try to create one please? Thanks all. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

3 4

Speading up GPC [2] ...
by Mirsad Todorovac 12 Jan '02

12 Jan '02

Hi, all, (Well, former message had a typing error in it's title as you must have noticed - which shows what quirks might occur when being eager to speed things up ;-) There's more space for speed/efficiency improvements. The second issue (I thank my friend Dvae who pointed similar issue years ago) is reading of input files. When done with open(2)/read(2) interface, it's correct, but mapping it into memory with mmap(2) is only slightly different, but much more efficient. This is because kernel does things for you. I can't give you a direct estimation about how switch to mmap(2) interface would speed-up GPC, but I remember an application (oops, I forgot to add it to my CV) when we had to read complete registry of Croatian companies in order to do a search. In this simplistic case with one big file, mmap(2)-ing it instead of open(2)/read(2)-ing it has shown _50%_drop!!!!_ in use of 'system time'. 'User time' also dropped, because interface routines didn't have to copy records to memory locations allocated with malloc - they were already mmap(2)-ed in, I only needed to re-link pointers to them. Off course, several routines had to be modified to be read-only to avoid copy-on-write overhead over input file, and to remove dependencies from '\0' trailing byte. At the time, it seemed as an acceptable price. I can't estimate the amount fo work required to attempt to implement mmap(2) interface to read files (on platforms where available) seemlesly. But from 'Internals', since parser calls lexer, mostly only lexer would have to be modified - and have two versions (one for platforms with MMAP and one for others, selected etiher with -DUSE_MMAP compile directive when compiling GPC, or even at runtime). The change would, however, significantly decrease copying overhead when dealing with large files. Also this could be applied to generating GPI files, but that area I'm not certain about yet. Please give your valuable opinions - thanks, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 1

{Max,Min,Eps}Real
by Emil Jerabek 12 Jan '02

12 Jan '02

The Extended Pascal real constants have strange values, namely MaxReal=MinReal=EpsReal=NaN. [pas]% cat const.pas program EPRealConstants (Output); uses GPC; var R : Real; OK: Boolean value True; procedure Bomb (I: Integer); begin WriteLn ('Failed ', I : 2, ': ', R); OK := False end; begin R := MinReal; if IsNotANumber (R) then Bomb (1); if IsInfinity (R) then Bomb (2); if R <= 0 then Bomb (3); { Simple `if R / 2 <> 0' doesn't work (at least on IA32), since it is internally computed with bigger precision. The same holds for tests # 8 and 13. } R := R / 2; if R <> 0 then Bomb (4); R := MaxReal; if IsNotANumber (R) then Bomb (5); if IsInfinity (R) then Bomb (6); if R <= 0 then Bomb (7); R := R + R; if not (IsInfinity (R) or (R <= MaxReal)) { `not IsInfinity (R)' alone probably can't work on non-IEEE hardware } then Bomb (8); R := EpsReal; if IsNotANumber (R) then Bomb (9); if IsInfinity (R) then Bomb (10); if R <= 0 then Bomb (11); R := R + 1; if R <= 1 then Bomb (12); R := EpsReal / 2 + 1; if R <> 1 then Bomb (13); if OK then WriteLn ('OK') end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc const.pas [pas]% ./a.out Failed 1: NaN Failed 4: NaN Failed 5: NaN Failed 8: NaN Failed 9: NaN Failed 13: NaN [pas]% I'm not quite sure if the testing program above is robust enough, but it passed on my machine when I replaced manually the constants with their correct (IMHO) values (1.7976931348623157e+308, 4.9406564584124654e-324, 2.2204460492503131e-16). Emil Jerabek

2 4

boolean function return value wrong
by Martin G C Davies 12 Jan '02

12 Jan '02

Hi, gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 20011222, based on gcc-2.8.1 I have to use gcc-2.8.1 because later versions have a bug with goto out multiple levels (as discussed in this forum before). My new problem is with source:- program Hello ; function covers( var p1 , p2 : integer ) : boolean ; begin if ( p1 = p2 ) then begin covers := false ; writeln( 'mgcd covers returns false 1' ) ; return ; end ; covers := true ; writeln( 'mgcd covers returns true' ) ; end ; var i1, i2 : integer ; begin i1 := 1 ; i2 := 1 ; writeln( 'covers=' , covers( i1 , i2 ) ) ; end. When I run it I get:- mgcd covers returns false 1 covers=True I could not find a reference to this problem. The problem was not introduced in 20011222 because 20010924 shows the same problem. Can anyone help? Cheers, Martin.

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc