Gpc October 1997

gpc@gnu.de

31 participants
158 discussions

Re: Portable random numbers
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > >IMHO, this code is still broken. On a non-DOS platform it tries to > >pass an integer to a function expecting a cardinal and always returns a > >type check error and doesn't compile. Is there some advanced switch > >that should be used in situations like this to turn off type-checking > >(I've never really looked at all of the directives and didn't see where > >they were in the docs after a quick look) and the type-casting section > >is empty. > > > >The code in question: > >FUNCTION Rand:Integer; C; > >PROCEDURE SRand(Seed:Cardinal); C; > >FUNCTION GetPID:Integer; C; > > > > Regarding portability: in my DJGPP C library, there is no `srand' function, > but a `srandom' function which expects an int (=Integer) as parameter. Hold it, please! The code fragment you're quoting is inside an $ifdef. It's not used in DJGPP. Please refer to the complete unit. I posted it here recently, and I'll make it available under the following URL tomorrow or so: http://home.pages.de/~fjf/rand.pas > I don't see how this should emulate the Randomize procedure in Borland > Pascal. The DJGPP code does so, and that's all I claimed. On non-Dos systems, it's almost impossible to emulate BP's behaviour since it depends on the internal system timer format used by Dos. I now added a comment to the unit making this clear. > According the info docs for my C library, getpid returns the unique > process number for the program running on the system. If you call getpid > twice in the same program, you get the same integer. (* This can happen (with Randomize) in BP, too, if within the same 1/18.2 seconds interval. Therefore, doing so is not recommended! *) > Why not compute a seed > from the system time (somehow), as Borland Pascal does? If you tell me how to do it, I'd like to! To do it "good", we'd need more than 1 second resolution, and getting this was the original problem here... > That is, if we need a Randomize procedure at all? My C library (DJGPP) > doesn't have such a beast. Ok, there is Borland compatibility .... Well, there must be any way to seed the Random randomly... :-) Otherwise, the program would produce the same sequence of random numbers in each run. AFAIK, the usual way to do so in C under Unix is GetPID, therefore I did it like that. A better general way would be most welcome. > I use random numbers a great deal in my work (statistical simulations), and > in most cases (if not all) I specify the seed myself, since this is the only > way of gettting reproducible results. There'd be no problem doing so with my unit (though it should not be used here, because it's only for BP compatibility). OTOH, I'd guess, most game programmers wouldn't like this behaviour... ;-) > When I was programming in Turbo Pascal (the pre-GPC era), I *never* used the > Random function in the system unit because I did not have source code and > thus couldn't see how the pseudo-random sequence was generated. There are a > lot of bad (= non-random) random number generators out there! True. BTW, my unit uses the same algorithm (though, of course, completely different code) as BP (7.0 at least). Now you can check if it's a good algorithm. The main formula is: RandSeed := $8088405 * RandSeed + 1 {mod 2^32} > The following piece of code represents a widely used procedure for generating > uniform random numbers (reals between 0.0 and 1.0), but it could easily be > changed to generating integers between 0 and 2^31-1 (just modify the last > line in RanUni). > > The routine is portable to all systems with a 32-bit integer type. It does > not rely on controlled overflow which may not be portable. The technically > inclined can consult the reference given in the comments. BTW, GPC users > familiar with the book(s) `Numerical Recipes' may be interested in knowing > that the `ran04 routine in the latest (2nd) edition (C only; not Pascal) > corresponds to the algorithm below. Thanks for the code! If it's not copyrighted/patented, we can perhaps use it for a built-it Random function in GPC. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: rand unit (was: us_Timer in TimeStamp)
by Frank Heckenbach 28 Oct '97

28 Oct '97

Kevin A. Foss wrote: > On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: > > >On 21 September, Frank Heckenbach posted a Unit `Rand' to this list > >which implements a `random' and a `randomize' function just this > >way. You can extract it from the GPC mailing list archives (see > >http://home.pages.de/~GNU-Pascal/support.html) or download it from > >ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/rand.pas. > > IMHO, this code is still broken. True, to some extent. See my previous mail. > On a non-DOS platform it tries to > pass an integer to a function expecting a cardinal and always returns a > type check error and doesn't compile. Assigning an integer to a cardinal is *NOT* a type check error, since the different integer types are assignment compatible. It could cause a range check error -- as soon as range checking will be implemented in GPC. The fact that GPC does report an "incompatible type" here (it didn't in earlier versions, otherwise I'd have noted when I wrote the unit), is indeed a bug in GPC. I'll add it to the bugs section of the To-Do list. Thanks for the (accidental ;-) bug report! Here is a short example program for this bug. This program should compile, but currently doesn't (it works, however, when I replace the functions v and w by variables): program x; procedure a(v:integer;w:cardinal); begin writeln(v,' ',w) end; function v:cardinal; begin v:=1 end; function w:integer; begin w:=2 end; begin a(v,w) end. > Is there some advanced switch > that should be used in situations like this to turn off type-checking > (I've never really looked at all of the directives and didn't see where > they were in the docs after a quick look) and the type-casting section > is empty. Turning off type checking in general would be a bit much, but type casting is indeed the right thing to do. Type casting works like - variable type casting: TypeName ( Variable or reference expression {"lvalue"} ) - value type casting (for ordinal and real type values): TypeName ( expression ) > SRand(GetPID); So change this line to: SRand(Cardinal(GetPID)); -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: String types in future GPC versions
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > >According to Extended Pascal, strings are written with parentheses > >("Str255 = String ( 255 )"), but GPC also accepts UCSD/Borland syntax > >("Str255 = String [ 255 ]"). In the future we *might* change this such > >that GPC produces an Extended Pascal string (unlimited length, 8 bytes > >overhead) with "(...)" but a Borland Pascal string (limited to 255 chars, > >1 byte overhead) with "[...]". > > > > Wouldn't that feature (choosing between two memory allocation/outline schemes > for strings) create a lot of problems Yes. > for relatively little benefit? I don't think so. > First, if I have a procedure with a var string type, > > procedure foo (var s : string) > > can I pass variables of either string type (Borland or Extended)? No. But we're discussing something like "AnyString" parameters for which you will be able to pass any string type. First of all, there are already now three different string types in GPC, namely the (EP) string schema, the (SP/BP) arrays of char and the "CStrings" (necessary for interfacing with C functions, esp. system functions). These string types are already handled in some places (e.g. the Read/Write functions), and will have to be handled in other places, too. So what we're talking about here is actually the introduction of a fourth string type... Since the distinction between the string types is a lot of work, and often a bit chaotic, we're looking for ways to simplify things. I hope, the AnyString parameters will be such a way. If things go as I hope, the distinction will only have to be done at a few places in the compiler rather than in each procedure operating on strings. When we aachive this for the three existing string types, adding a fourth one should not be so much work. So, we're not overly keen on doing this work, but it seems inevitable. > Second, a string variable in Borland Pascal does not contain information > about the maximum length (like the capacity field in GPC), so for procedures > that need this information (like Readln), the string capacity would have to > be passed as an implicit parameter (or am I missing something?). You're right. But it's the same for arrays of char and CStrings, where the capacity is passed separately already now. In the future, the AnyString parameters should cater for this. > Finally, and most importantly, why is feature this needed in the first place? > The Extended Pascal string concept is more powerful that the Borland one (as > it stores the string capacity in a field which my procedure `foo' can > access). However, the extra features of GPC (capacity field, and strings > larger than 255 bytes) are *extensions* compated to Borland Pascal, so any > Borland code with string manipulations should compile under GPC, and the > binary (program) should produce the same results. Not any code, unfortunately. It's not uncommon in BP to manipulate the string length by accessing "s[0]", lacking a proper way to access the length. (GPC will soon provide a better way in the form of "AssignLength", working on all string types...) (You might say that directly accessing the length should not be done in a good program, but it's necessary for efficiency, e.g. in order to append one character to a string. The proper way "s := s + ch" will produce code that copies the whole string around at least twice, in BP as well as (currently) in GPC.) Another example would be dynamically allocating strings of varying length in BP which is usually done (again, lacking a better way) with statements like: New(p,Length(s)+1); p^:=s; To make such statements work under GPC, it's important to have the exact string type as BP does. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: us_Timer in TimeStamp
by Frank Heckenbach 28 Oct '97

28 Oct '97

Peter Gerwinski wrote: > According to Thomas Tan: > > Are you guys going to implement us_Timer field of TimeStamps soon? > > If you tell us how to do that in a portable way - at once! ;-) > > > I need a seed for a random function and this seems to be the best way to go. > > On 21 September, Frank Heckenbach posted a Unit `Rand' to this list > which implements a `random' and a `randomize' function just this > way. Sorry, but this is probably not the best thing to look at. First of all, it's not portable (it uses the system time under DJGPP, the process ID on other systems where available, and doesn't appear to work under EMX). Then, the unit (and especially the random algorithms and data sizes) are particularly for compatibility with BP's random generator, nothing else. So, a portable way to get fractions of a second would be a fine thing (micro seconds will not always be possible; under Dos, e.g., the resolution is 1/18.2 seconds, unless you do direct hardware manipulation)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: us_Timer in TimeStamp
by Jesper Lund 28 Oct '97

28 Oct '97

> >So, a portable way to get fractions of a second would be a fine thing >(micro seconds will not always be possible; under Dos, e.g., the >resolution is 1/18.2 seconds, unless you do direct hardware manipulation)... > If we forget about portability for a minute, under DOS (DJGPP) there is a libc function, uclock (), which provides (very) high-resolution timing. Jesper Lund

1 0

Re: rand unit (was: us_Timer in TimeStamp)
by Kevin A. Foss 28 Oct '97

28 Oct '97

On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: >On 21 September, Frank Heckenbach posted a Unit `Rand' to this list >which implements a `random' and a `randomize' function just this >way. You can extract it from the GPC mailing list archives (see >http://home.pages.de/~GNU-Pascal/support.html) or download it from >ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/rand.pas. IMHO, this code is still broken. On a non-DOS platform it tries to pass an integer to a function expecting a cardinal and always returns a type check error and doesn't compile. Is there some advanced switch that should be used in situations like this to turn off type-checking (I've never really looked at all of the directives and didn't see where they were in the docs after a quick look) and the type-casting section is empty. The code in question: FUNCTION Rand:Integer; C; PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; PROCEDURE Randomize; BEGIN SRand(GetPID); RandSeed:=Rand END; -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

2 1

Re: us_Timer in TimeStamp
by Kevin A. Foss 28 Oct '97

28 Oct '97

On Mon, 27 Oct 1997 16:47:56 +0100 (MET), Peter Gerwinski wrote: >According to Thomas Tan: >> Are you guys going to implement us_Timer field of TimeStamps soon? > >If you tell us how to do that in a portable way - at once! ;-) Well the proposal in the GPC docs also adds a TimerValid field, just set that to False if the system doesn't support gettimeofday(), which is already checked for in rts-time.c. gettimeofday() should be available for any system that supports BSD and/or glibc library calls. Other systems could provide their own calls in #ifdef blocks if they want the feature. I just don't see why 100% portability is important when you already have a field that tells the programmer if he can trust the results to be valid. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: Problems with strings in GPC beta 971001
by Frank Heckenbach 28 Oct '97

28 Oct '97

Jesper Lund wrote: > I have encountered a couple problems with strings in the most recent GPC beta > version. Most of the problems are due to missing range checks, e.g. when > assigning a string to a shorter string, or passing a string to a procedure > with a shorter string as formal parameter. > > 1) The program below illustrates some of these problems: Yes, this is a known bug. I think it will be solved soon. > 2) Another facet of the problem occurs when reading strings from a text file > with Read[ln] (F, stringVar). > > If you call Readln, the program will read from the file until the next CR/LF, > no matter the size (length) of stringVar, and try to copy the entire line to > the variables stringVar (which will almost surely crash the program somehow; > but not necessarily in the call to Readln. The SIGSEGV exception could come > later, and with a stack trace which makes no sense). Strange! There has always been a check for the maximum length in the read[ln] procedure. > On the other hand, Read (F, stringVar) only reads a maximum of > Length(stringVar) characters [as it should]. Even more strange, since Read and Readln are actually the same procedure (or rather function) internally. Readln (F, stringVar) first does exactly the same as Read (F, stringVar), and then a Readln (stringVar). Perhaps something was broken temporarily while I changed other things in the Read/Write procedures. OTOH, the following program works correctly (i.e. outputs only 5 characters, even if I type more than 5) on my Linux GPC (which has been modified somewhat after 971001) as well as on my DJGPP GPC (which is the original 971001 binary distribution): program x; var s:string(5); begin readln(s); writeln(s) end. Perhaps you did some other thing in your program that triggered the first bug? If not, please send me a program and sample input to show this problem. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Strings in GPC (was: GPC question)
by Peter Gerwinski 28 Oct '97

28 Oct '97

According to Jesper Lund: > > GPC is under development, and so is the documentation. Therefore, AFAIK, > there is no *complete* list of the built-in functions. The GNU Texinfo online documentation of recent beta versions of GPC contains a complete list of all built-in identifiers - most of them without explanation, sorry, but it's a start. > Regarding your second question, I think you need to define a string type, > like > > type > str255 = string [255]; Correct. If you say "Function Foo: String", GPC accepts it as a string of length 255 but warns about it (unless you are in `--borland-pascal' mode). According to Extended Pascal, strings are written with parentheses ("Str255 = String ( 255 )"), but GPC also accepts UCSD/Borland syntax ("Str255 = String [ 255 ]"). In the future we *might* change this such that GPC produces an Extended Pascal string (unlimited length, 8 bytes overhead) with "(...)" but a Borland Pascal string (limited to 255 chars, 1 byte overhead) with "[...]". Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

2 1

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 28 Oct '97

28 Oct '97

Bill Currie wrote: > On 23 Oct 97 at 10:43, Peter Gerwinski wrote: > > > According to Jesper Lund: > > > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > > > compiler directive in Borland Pascal? [...] > > > > Not yet, but it is being worked on. (Interested to take part?;-) > > Agh, does that mean I have to pull my finger out? > > I think I've got the compiler side working in an older beta, but the > rtl has to be modified to support it. I think I can do the RTS part, if you send me a patch for your changes, along with a short description about how you did it. I'd imagine I'll do it as follows: - Whenever an I/O function encounters an error condition, it sets InOutRes to the according error code (which will, of course, *not* be the same as in BP ;-), and return in a clean state. (The latter is the difficult bit; I've already done so for the Read/Write procedures, but I expect there will be more to do so that the program can continue safely.) - At the start, each I/O function checks InOutRes, and if <>0, returns immediately, doing nothing. (Like BP does.) - After calling an I/O function, if {$I+} is turned on, the calling program must check InOutRes. The code to be generated (perhaps you've already done so) would look like "if InOutRes<>0 then _p_ioerror;" where _p_ioerror will be a RTS function I can provide. (The check "if InOutRes<>0" could also be done in the function (like in BP!), but that's inefficient, because the function has to be called after each I/O operation then.) Does this seem OK to you, or to anyone else? Any comments? One question is what kind of errors is to be considered as I/O errors. E.g., overflowing the destination string length in WriteStr, if the automatic truncating of strings (an option that will be introduced soon) is turned off, is this an I/O error or rather a "generic" (string) error? Any opinions? If there are more cases of doubt, I'll ask them here, too, when I find them. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

← Newer
1
2
3
4
5
6
7
...
16
Older →

Jump to page:

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 October 1997