I have just moved to RC 3. Looking at the list of fixed bugs it is obvious that a lot of work has been done in the last few months; thanks to all concerned. The stricter type checking required a lot of effort to get our code to compile but in fairness did highlight a number of problems in our code; so I think it was time well spent. However I am now stuck because of the following problem:
Program WriteTest;
Procedure ZWriteln(AString:String); Begin AString:=AString+'ML'; Writeln('String [',AString,'] Length is ',Length(AString)); End;
Begin ZWriteln(' '); End.
What I see is that length is reported as 1 i.e. the string concatenation is failing. Is this expected behaviour or a bug?
I also note that trying to set the Capacity of a string schema is now flagged as an error. Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above.
On 17 Mar 2002 at 13:16, Martin Liddle wrote:
I have just moved to RC 3. Looking at the list of fixed bugs it is obvious that a lot of work has been done in the last few months; thanks to all concerned. The stricter type checking required a lot of effort to get our code to compile but in fairness did highlight a number of problems in our code; so I think it was time well spent. However I am now stuck because of the following problem:
Program WriteTest;
Procedure ZWriteln(AString:String); Begin AString:=AString+'ML'; Writeln('String [',AString,'] Length is ',Length(AString)); End;
Begin ZWriteln(' '); End.
What I see is that length is reported as 1 i.e. the string concatenation is failing. Is this expected behaviour or a bug?
It is a bug alright. If you pass a string variable rather than a literal to 'ZWriteln', the concatentation is successful. So, something seems to have gone awry somewhere.
I also note that trying to set the Capacity of a string schema is now flagged as an error.
My understanding that it should always have been flagged as an error.
Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above.
'SetLength' should work. However, I am not sure that you can use it for increasing (as opposed to decreasing) the maximum length of a string.
I am not sure what your original problems were. I haven't experienced any problems with strings (as long as you actually initialise the variables (e.g., s := '') at some point, and don't expect the compiler to do it automatically).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
On 17 Mar 2002 at 13:16, Martin Liddle wrote:
I have just moved to RC 3. Looking at the list of fixed bugs it is obvious that a lot of work has been done in the last few months; thanks to all concerned. The stricter type checking required a lot of effort to get our code to compile but in fairness did highlight a number of problems in our code; so I think it was time well spent. However I am now stuck because of the following problem:
Program WriteTest;
Procedure ZWriteln(AString:String); Begin AString:=AString+'ML'; Writeln('String [',AString,'] Length is ',Length(AString)); End;
Begin ZWriteln(' '); End.
What I see is that length is reported as 1 i.e. the string concatenation is failing. Is this expected behaviour or a bug?
It is a bug alright. If you pass a string variable rather than a literal to 'ZWriteln', the concatentation is successful. So, something seems to have gone awry somewhere.
No, it's not a bug. `AString' is a formal parameter of undiscriminated schema type. This means it assumes the discriminants (in case of String: Capacity) of the actual parameter. In the example, the actual parameter is a string constant of length 1. It also has capacity 1, since constants can't change, anyway.
So also the parameter has capacity 1 during the execution of `ZWriteln'. Assigning ` ML' (the result of concatenation) to a capacity 1 string results in truncation to ` '. This behaviour is not new, BTW.
As a rule of thumb, the problem generally might show when you have value parameters of type `String' and you extend their length in the routine. (Var parameters are not affected since you can't pass constants to them, anyway, and const/protected parameters are safe because they can't be changed in the routine. Discriminated string parameters are no problem provided the declared capacity is big enough. Shortening the parameters, or modifying them with the same length is also no problem, obviously.)
So, one solution here is to declare `AString' with a capacity (e.g., of type `TString' if you use the GPC unit). This will work if you know a constant bound on the capacity (e.g., 255 for those used to BP ;-). If that's not the case, something like the following might help (e.g., if you know the the string will not be enlarged by more than 2 characters):
Procedure ZWriteln(AString:String); var LocalAString: String (Length (AString) + 2); Begin LocalAString:=AString+'ML'; Writeln('String [',LocalAString,'] Length is ',Length(LocalAString)); End;
I also note that trying to set the Capacity of a string schema is now flagged as an error.
My understanding that it should always have been flagged as an error.
Indeed.
Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above.
'SetLength' should work. However, I am not sure that you can use it for increasing (as opposed to decreasing) the maximum length of a string.
`SetLength' is for setting the (current) length, not the Capacity (= maximum length). The Capacity cannot be changed reasonably because it would apparently change the size of the variable.
If you still need the workarounds, let me know, so I can try to fix the problems and/or give you an advice how to adapt the workaround.
Frank
In article 200203172141.WAA10883@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
Prof Abimbola Olowofoyeku wrote:
On 17 Mar 2002 at 13:16, Martin Liddle wrote:
I have just moved to RC 3. Looking at the list of fixed bugs it is obvious that a lot of work has been done in the last few months; thanks to all concerned. The stricter type checking required a lot of effort to get our code to compile but in fairness did highlight a number of problems in our code; so I think it was time well spent. However I am now stuck because of the following problem:
Program WriteTest;
Procedure ZWriteln(AString:String); Begin AString:=AString+'ML'; Writeln('String [',AString,'] Length is ',Length(AString)); End;
Begin ZWriteln(' '); End.
What I see is that length is reported as 1 i.e. the string concatenation is failing. Is this expected behaviour or a bug?
It is a bug alright. If you pass a string variable rather than a literal to 'ZWriteln', the concatentation is successful. So, something seems to have gone awry somewhere.
No, it's not a bug. `AString' is a formal parameter of undiscriminated schema type. This means it assumes the discriminants (in case of String: Capacity) of the actual parameter. In the example, the actual parameter is a string constant of length 1. It also has capacity 1, since constants can't change, anyway.
So also the parameter has capacity 1 during the execution of `ZWriteln'. Assigning ` ML' (the result of concatenation) to a capacity 1 string results in truncation to ` '. This behaviour is not new, BTW.
Thanks that has clarified the situation. I had changed the arguments to this procedure from a type with a known capacity to just String because I thought it might avoid future problems. I can revert back to a known capacity.
So, one solution here is to declare `AString' with a capacity (e.g., of type `TString' if you use the GPC unit). This will work if you know a constant bound on the capacity (e.g., 255 for those used to BP ;-). If that's not the case, something like the following might help (e.g., if you know the the string will not be enlarged by more than 2 characters):
Procedure ZWriteln(AString:String); var LocalAString: String (Length (AString) + 2); Begin LocalAString:=AString+'ML'; Writeln('String [',LocalAString,'] Length is ',Length(LocalAString)); End;
Interesting; I didn't realise that was possible.
I also note that trying to set the Capacity of a string schema is now flagged as an error.
My understanding that it should always have been flagged as an error.
Indeed.
Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above.
'SetLength' should work. However, I am not sure that you can use it for increasing (as opposed to decreasing) the maximum length of a string.
`SetLength' is for setting the (current) length, not the Capacity (= maximum length). The Capacity cannot be changed reasonably because it would apparently change the size of the variable.
If you still need the workarounds, let me know, so I can try to fix the problems and/or give you an advice how to adapt the workaround.
I'll report back when I have made some progress. I am afraid I am going to have to backtrack first.
On Sun, 17 Mar 2002, Prof Abimbola Olowofoyeku wrote:
On 17 Mar 2002 at 13:16, Martin Liddle wrote:
[..]
However I am now stuck because of the following problem:
Program WriteTest;
Procedure ZWriteln(AString:String); Begin AString:=AString+'ML'; Writeln('String [',AString,'] Length is ',Length(AString)); End;
Begin ZWriteln(' '); End.
What I see is that length is reported as 1 i.e. the string concatenation is failing. Is this expected behaviour or a bug?
It is a bug alright. If you pass a string variable rather than a literal to 'ZWriteln', the concatentation is successful. So, something seems to have gone awry somewhere.
As a work around you might try this:
Program WriteTest;
Procedure ZWriteln(AString:String); var BString : string( length(AString)+20 ); {used 20 instead of 2 to show that the length reported didn't come from here} Begin BString:=AString+'ML'; Writeln('String [',BString,'] Length is ',Length(BString)); End;
Begin ZWriteln(' '); End.
I also note that trying to set the Capacity of a string schema is now flagged as an error.
My understanding that it should always have been flagged as an error.
Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above.
'SetLength' should work. However, I am not sure that you can use it for increasing (as opposed to decreasing) the maximum length of a string.
Be carefull not to confuse length with capacity.
Also, length =< capacity and you can get garbage if you increase the length into an uninitialized area of the string's capacity.
Russ
On 17 Mar 2002 at 14:26, Russell Whitaker wrote:
[...]
'SetLength' should work. However, I am not sure that you can use it for increasing (as opposed to decreasing) the maximum length of a string.
Be carefull not to confuse length with capacity.
Yes, I am confusing them. It would be nice to be able to increase the capacity though. Perhaps some compiler magic can just treat a call to something like "SetCapacity" as the declaration of a new variable, and then allocate the appropriate storage to it. An extension of this might be that, any attempt to assign a value that is longer than the current capacity should be treated as equivalent to: SetCapacity (s, length (newvalue)); s := newvalue; With this, you can have dynamically growing strings. Perhaps I am just being naïve in thinking that this can be done at all, or that, even if it can be done, it will not involve a major and/or undesirable changes to the compiler. But if I were to implement something like Delphi's "AnsiString", I might well consider something like this.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
Yes, I am confusing them. It would be nice to be able to increase the capacity though. Perhaps some compiler magic can just treat a call to something like "SetCapacity" as the declaration of a new variable, and then allocate the appropriate storage to it. An extension of this might be that, any attempt to assign a value that is longer than the current capacity should be treated as equivalent to: SetCapacity (s, length (newvalue)); s := newvalue;
For "normal" global and local strings that's just impossible because the size can't be changed afterwards once their address in memory is fixed.
With this, you can have dynamically growing strings. Perhaps I am just being naïve in thinking that this can be done at all, or that, even if it can be done, it will not involve a major and/or undesirable changes to the compiler. But if I were to implement something like Delphi's "AnsiString", I might well consider something like this.
As you might know, this is planned, but it will involve bigger changes, e.g. because such variables will have to be implemented via pointers internally so changing the size becomes possible at all.
Frank
On 18 Mar 2002 at 14:25, Frank Heckenbach wrote:
Yes, I am confusing them. It would be nice to be able to increase the capacity though. Perhaps some compiler magic can just treat a call to something like "SetCapacity" as the declaration of a new variable, and then allocate the appropriate storage to it. An extension of this might be that, any attempt to assign a value that is longer than the current capacity should be treated as equivalent to: SetCapacity (s, length (newvalue)); s := newvalue;
For "normal" global and local strings that's just impossible because the size can't be changed afterwards once their address in memory is fixed.
Yes, I realised that this would be a problem. I have tried in the past to get around this problem, without success, other than to write a small string object that uses a pointer internally and so the string can grow or decrease dynamically.
With this, you can have dynamically growing strings. Perhaps I am just being naïve in thinking that this can be done at all, or that, even if it can be done, it will not involve a major and/or undesirable changes to the compiler. But if I were to implement something like Delphi's "AnsiString", I might well consider something like this.
As you might know, this is planned, but it will involve bigger changes, e.g. because such variables will have to be implemented via pointers internally so changing the size becomes possible at all.
Yes.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
In article 3C94EC4A.21401.25BB33@localhost, Prof Abimbola Olowofoyeku African_Chief@bigfoot.com writes
On 17 Mar 2002 at 13:16, Martin Liddle wrote:
I also note that trying to set the Capacity of a string schema is now flagged as an error.
My understanding that it should always have been flagged as an error.
Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above.
'SetLength' should work. However, I am not sure that you can use it for increasing (as opposed to decreasing) the maximum length of a string.
I am not sure what your original problems were. I haven't experienced any problems with strings (as long as you actually initialise the variables (e.g., s := '') at some point, and don't expect the compiler to do it automatically).
I can assure that were in the past very serious problems with the capacity of strings not being initialised. There is still an outstanding bug on the bug list 'The capacity of strings declared in interfaces of modules is not initialised (daj3.pas)'. But we saw very other situations in which it occurred. I'll report back on whether there are any other remaining problems.
Martin Liddle wrote:
I can assure that were in the past very serious problems with the capacity of strings not being initialised. There is still an outstanding bug on the bug list 'The capacity of strings declared in interfaces of modules is not initialised (daj3.pas)'.
Oh yeah, this one. :-/ Do you use modules? (It doesn't affect BP style units.)
At least I think now I know how to fix it. But it's not a small change, so I'd rather do it after 2.1.
But we saw very other situations in which it occurred. I'll report back on whether there are any other remaining problems.
OK.
Frank
In article 200203180421.FAA05755@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
Martin Liddle wrote:
There is still an outstanding bug on the bug list 'The capacity of strings declared in interfaces of modules is not initialised (daj3.pas)'.
Oh yeah, this one. :-/ Do you use modules? (It doesn't affect BP style units.)
We don't use modules any more because of this problem. We converted everything to UCSD style Units.
At least I think now I know how to fix it. But it's not a small change, so I'd rather do it after 2.1.
No need to do it on our account.
But we saw various other situations in which it occurred. I'll
report back >>on whether there are any other remaining problems.
OK.
I've finished back-tracking and got everything to compile again and a VERY preliminary test doesn't show any problems :-) We'll do some more serious testing over the next few days and report back.
Thanks as always to everybody that chipped in with suggestions.
In article ci5ZQwAybhl8EwQA@tcs02.demon.co.uk, Martin Liddle martin@tcs02.demon.co.uk writes
I've finished back-tracking and got everything to compile again and a VERY preliminary test doesn't show any problems :-) We'll do some more serious testing over the next few days and report back.
We (principally my colleagues Ron Jackson and George Brown) have done more testing. Most things look OK but they have discovered one apparent problem when writing to a file whose records are string(25). I am investigating but so far my attempts to produce a test program that shows the problem are failing (i.e. my test programs work as expected). Hence this is just a heads up of a possible problem and I'll put some more effort into understanding what is going on, hopefully tomorrow.
In article wc$y$BBnrPm8EwuI@tcs02.demon.co.uk, Martin Liddle martin@tcs02.demon.co.uk writes
We (principally my colleagues Ron Jackson and George Brown) have done more testing. Most things look OK but they have discovered one apparent problem when writing to a file whose records are string(25). I am investigating but so far my attempts to produce a test program that shows the problem are failing (i.e. my test programs work as expected). Hence this is just a heads up of a possible problem and I'll put some more effort into understanding what is going on, hopefully tomorrow.
OK I now understand. This is not a compiler problem. I failed to understand how some code written by a colleague worked and hence my workaround for the inability to set capacity failed in this case. I now have a new work around that seems to do what I want.
Apologies for wasting everybody's time.
In article ci5ZQwAybhl8EwQA@tcs02.demon.co.uk, Martin Liddle martin@tcs02.demon.co.uk writes
We'll do some more serious testing over the next few days and report back.
Just to close of my branch of the thread, we have done a lot more testing of our application looking for problems with string capacity not being initialised correctly. We found several more failures but they have all turned out to be bugs in our code (typically using fillchar to initialise a record and stamping over the capacity). So from our perspective things look good.
Martin Liddle wrote:
Just to close of my branch of the thread, we have done a lot more testing of our application looking for problems with string capacity not being initialised correctly. We found several more failures but they have all turned out to be bugs in our code (typically using fillchar to initialise a record and stamping over the capacity). So from our perspective things look good.
Thanks for the info. This looks promising. :-)
Frank
On Mon, Mar 18, 2002 at 05:21:35AM +0100, Frank Heckenbach wrote:
Martin Liddle wrote:
I can assure that were in the past very serious problems with the capacity of strings not being initialised. There is still an outstanding bug on the bug list 'The capacity of strings declared in interfaces of modules is not initialised (daj3.pas)'.
Oh yeah, this one. :-/ Do you use modules? (It doesn't affect BP style units.)
How can I get more details on that bug? I can't find the file daj3.pas on my machine.
Does this apply to constant strings only, so can you program around it by declaring var's and initialize them in the init-code of the implementation module? Sure hope so.
At least I think now I know how to fix it. But it's not a small change, so I'd rather do it after 2.1.
Carel Fellinger wrote:
How can I get more details on that bug? I can't find the file daj3.pas on my machine.
It's part of the GPC source distributions, or the separate test suite distributions in ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/.
Does this apply to constant strings only, so can you program around it by declaring var's and initialize them in the init-code of the implementation module? Sure hope so.
No, it applies to variables declared in a module interface.
Frank
Hello,
I tried compiling this simple program, with GPC RC3 (20020304), with GCC 2.95.3 (20010315).
program espa;
var
i, j, k: integer;
esp: double;
res: double;
begin
for i := 1 to 50 do begin
esp := i * 1000 ;
res := exp ( -esp );
writeln (' Minus the exponential of ', esp :1 :0, ' is ', res :1 :15 );
end;
end.
Surprisingly, and disappointingly, when I run it I get the following result:
espa: error in exponentiation (Numerical result out of range) (error #700 at 8049c75)
while with any Pascal (like FPC), and C compiler, I get no error (like it should be ). It really looks like a bug.
Can anyone help?
Thanks, regards
Silvio a Beccara
On 26 Mar 2002 at 11:01, Silvio a Beccara wrote:
Hello,
I tried compiling this simple program, with GPC RC3 (20020304), with GCC 2.95.3 (20010315).
[...]
I don't get any runtime errors (with gpc-20020318).
This is what I get: Minus the exponential of 1000 is 0.000000000000000 Minus the exponential of 2000 is 0.000000000000000 Minus the exponential of 3000 is 0.000000000000000 Minus the exponential of 4000 is 0.000000000000000 Minus the exponential of 5000 is 0.000000000000000 Minus the exponential of 6000 is 0.000000000000000 Minus the exponential of 7000 is 0.000000000000000 Minus the exponential of 8000 is 0.000000000000000 Minus the exponential of 9000 is 0.000000000000000 Minus the exponential of 10000 is 0.000000000000000 Minus the exponential of 11000 is 0.000000000000000 Minus the exponential of 12000 is 0.000000000000000 Minus the exponential of 13000 is 0.000000000000000 Minus the exponential of 14000 is 0.000000000000000 Minus the exponential of 15000 is 0.000000000000000 Minus the exponential of 16000 is 0.000000000000000 Minus the exponential of 17000 is 0.000000000000000 Minus the exponential of 18000 is 0.000000000000000 Minus the exponential of 19000 is 0.000000000000000 Minus the exponential of 20000 is 0.000000000000000 Minus the exponential of 21000 is 0.000000000000000 Minus the exponential of 22000 is 0.000000000000000 Minus the exponential of 23000 is 0.000000000000000 Minus the exponential of 24000 is 0.000000000000000 Minus the exponential of 25000 is 0.000000000000000 Minus the exponential of 26000 is 0.000000000000000 Minus the exponential of 27000 is 0.000000000000000 Minus the exponential of 28000 is 0.000000000000000 Minus the exponential of 29000 is 0.000000000000000 Minus the exponential of 30000 is 0.000000000000000 Minus the exponential of 31000 is 0.000000000000000 Minus the exponential of 32000 is 0.000000000000000 Minus the exponential of 33000 is 0.000000000000000 Minus the exponential of 34000 is 0.000000000000000 Minus the exponential of 35000 is 0.000000000000000 Minus the exponential of 36000 is 0.000000000000000 Minus the exponential of 37000 is 0.000000000000000 Minus the exponential of 38000 is 0.000000000000000 Minus the exponential of 39000 is 0.000000000000000 Minus the exponential of 40000 is 0.000000000000000 Minus the exponential of 41000 is 0.000000000000000 Minus the exponential of 42000 is 0.000000000000000 Minus the exponential of 43000 is 0.000000000000000 Minus the exponential of 44000 is 0.000000000000000 Minus the exponential of 45000 is 0.000000000000000 Minus the exponential of 46000 is 0.000000000000000 Minus the exponential of 47000 is 0.000000000000000 Minus the exponential of 48000 is 0.000000000000000 Minus the exponential of 49000 is 0.000000000000000 Minus the exponential of 50000 is 0.000000000000000
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 26 Mar 2002 at 11:01, Silvio a Beccara wrote:
Hello,
I tried compiling this simple program, with GPC RC3 (20020304), with GCC 2.95.3 (20010315).
[...]
I don't get any runtime errors (with gpc-20020318).
This is what I get: Minus the exponential of 1000 is 0.000000000000000
[...]
Minus the exponential of 50000 is 0.000000000000000
So the question is, should gpc catch underflows. Apparently the result does not depend only on gpc, but also on the underlying system libraries. With djgpp and the program unmodified I get the error #700 With an instruction uses libml; which is an unit which imports the CEPHES math library I obtain like the Chief. AFAIK when there is no special instruction exp is imported from libm if it exists there or libc if not, and the result is thus system dependant.
Maurice
On 26 Mar 2002 at 12:31, Maurice Lombardi wrote: [...]
So the question is, should gpc catch underflows. Apparently the result does not depend only on gpc, but also on the underlying system libraries. With djgpp and the program unmodified I get the error #700 With an instruction uses libml; which is an unit which imports the CEPHES math library I obtain like the Chief. AFAIK when there is no special instruction exp is imported from libm if it exists there or libc if not, and the result is thus system dependant.
You are right. My first test was with Mingw, and there was no error. I have now tried it under Cygwin, and I do get the error: "error in exponentiation (Math result out of range) (error #700 at 4010b9)".
I am not sure now whether this is a GPC problem or a system library problem, and I am not sure what GPC should do about it.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Hello,
has anyone tried under Linux?
Regards
Silvio
You are right. My first test was with Mingw, and there was no error. I have now tried it under Cygwin, and I do get the error: "error in exponentiation (Math result out of range) (error #700 at 4010b9)".
I am not sure now whether this is a GPC problem or a system library problem, and I am not sure what GPC should do about it.
Best regards, The Chief
Hello, I changed your program somewhat:
PROGRAM espa; var i, j, k : integer; esp, res : double;
begin writeln (exp(1.0)); for i := 1 to 50000 do begin esp := i * 0.1 ; res := exp ( -esp ); writeln (' Minus the exponential of ', esp :5 :1, ' is ', res ); end end.
Last lines written are: ...... Minus the exponential of 744.9 is 4.940656458412465e-324 Minus the exponential of 745.0 is 4.940656458412465e-324 Minus the exponential of 745.1 is 4.940656458412465e-324 espa: error in exponentiation (Numerical result out of range) (error #700 at 8049c8a)
This indicates that res runs into undefined range between zero and minimum valid value of IEEE double precision numbers. Minimum decimal value is approximately +/- 10**(-323). If your application allows lower values to be interpreted as zero (0.0) you may tell it to gpc, but I don't know how to do that..
Ernst-Ludwig
On Tue, 26 Mar 2002, Silvio a Beccara wrote:
Hello,
I tried compiling this simple program, with GPC RC3 (20020304), with GCC 2.95.3 (20010315).
program espa;
var
i, j, k: integer;
esp: double;
res: double;
begin
for i := 1 to 50 do begin
esp := i * 1000 ;
res := exp ( -esp );
writeln (' Minus the exponential of ', esp :1 :0, ' is ', res :1 :15 );
end;
end.
Surprisingly, and disappointingly, when I run it I get the following result:
espa: error in exponentiation (Numerical result out of range) (error #700 at 8049c75)
while with any Pascal (like FPC), and C compiler, I get no error (like it should be ). It really looks like a bug.
Can anyone help?
Thanks, regards
Silvio a Beccara
-
Carel Fellinger -
Ernst-Ludwig Bohnen -
Frank Heckenbach -
Martin Liddle -
Maurice Lombardi -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)
-
Russell Whitaker -
Silvio a Beccara