Hisoft Pascal 4T floating point problem

[revaldinho]

Has anyone come across this issue in HiSoft Pascal 4T before ?

Code Select Expand


program incr;
var i : real;
   n  : integer;
begin
   i := 0.0;
   for n := 0 to 10 do
      begin
         writeln(i);
         i := i+0.25 ;
      end   
end.


The code should just increment 'i' by 0.25  a few times, but the variable gets to 1.0 and then increments no more ! See the attached screen shot.


R

[Chinnery]

Hey there.
It looks like Pascal is outputting the value in scientific notation. There should be a way to specify a format string for output. In the .net world, I would use "0#.##" but it's been so long since I used pascal/Delphi I can't remember how...

[revaldinho]

yes, but why does the sequence go 0.25, 0.5, 0.75, 1.0, 1.0, 1.0, 1.0 ... it seems to saturate.


R

[Chinnery]

You need to check the exponent - the + and - towards the end. If you set your loop to end much higher you would see the exponent changing. Check out the following link for a bit more help.
https://en.m.wikipedia.org/wiki/Scientific_notation

[SRS]

Maybe this helps ? I do not have HiSoft P4T to test ...

For real values, you can use the aforementioned syntax to display scientific notation in a specified field width, or you can convert to fixed decimal-point notation with:

Value : field_width : decimal_field_width

The field width is the total field width, including the decimal part. The whole number part is always displayed fully, so if you have not allocated enough space, it will be displayed anyway. However, if the number of decimal digits exceeds the specified decimal field width, the output will be displayed rounded to the specified number of places (though the variable itself is not changed).

write (573549.56792:20:2);

would look like (with 11 spaces in front):
573549.57

[revaldinho]

Here's a slightly modified code to show the difference between incrementing by 0.25 and calculating the same thing by multiplying the loop counter by 0.25:

Code Select Expand



program incr;
var i, j : real;
   n  : integer;
begin
   i := 0.0;
   j := 0.0;
   for n := 1 to 10 do
      begin
         writeln(i, j);
         i := i+0.25 ;
         j := n*0.25 ;
      end   
end.



This one produces this new screenshot ...


...but the numbers on left and right should be the same....




R

[AMSDOS]

My test shows it's working fine. I can only imagine there's something going wrong within your Hisoft Pascal, unsure though.

[revaldinho]

Ah, great! I stumbled on this while trying to write some other code and it was driving me mad. I see the same behaviour on my CPC464 and in the Arnold emulator.


The version of Pascal I have announces itself as Version of 26/9/84


Do you have a different version ?


R.

[AMSDOS]

Ah, great! I stumbled on this while trying to write some other code and it was driving me mad. I see the same behaviour on my CPC464 and in the Arnold emulator.

Hmmm, were you using the same copy of Hisoft Pascal 4t on both machine and emulator? If not, that's of concern.

The version of Pascal I have announces itself as Version of 26/9/84


Do you have a different version ?


R.

That's the one and only version Hisoft made for the 464, but there are different copies floating around. I downloaded a Cracked Disk version of this from CPC-Power and tested it on the Online CPC Emulator - CPCBox. I tested both 464 and 6128 and got the same result, but if a real 464 is returning those results I can only guess either something is going wrong with your version or the emulator isn't emulating the flaw correctly.

[revaldinho]

Good news - in fact my CPC464 seems to run the code ok now. I was sure I'd tried it and failed originally, but it seems to work now.


I have 2 versions of Arnold - 1.7.8 and 1.7.9 - and both fail the test in exactly the same way as originally reported when using the same .dsk images.


JavaCPC runs fine though - no problems there..


So the problem seems to be with Arnold rather than the HiSoft compiler. That's good news in a way, but also a shame because on the Mac I have always found that to be a pretty good emulator.


R.

[AMSDOS]

Good news - in fact my CPC464 seems to run the code ok now. I was sure I'd tried it and failed originally, but it seems to work now.


I have 2 versions of Arnold - 1.7.8 and 1.7.9 - and both fail the test in exactly the same way as originally reported when using the same .dsk images.


JavaCPC runs fine though - no problems there..


So the problem seems to be with Arnold rather than the HiSoft compiler. That's good news in a way, but also a shame because on the Mac I have always found that to be a pretty good emulator.


R.

I haven't got Arnold unfortunately. Hisoft Pascal 4t I think uses a lookup table, I'm just wondering if that has been compromised to return the odd results, just seems like it's calculating "i" as an percentage, rather than a decimal number. I recoded the BASIC circle program out of the manual some years into HP4T, which use the cos() and sin() functions with degree function to plot circle in degrees. Just wonder how that would go since cos() and sin() use a lookup table to return the result quickly in BASIC, I think the same may apply with HP4T only because of it being much faster than Turbo Pascal 3 (which doesn't use one).

[revaldinho]

I recoded the BASIC circle program out of the manual some years into HP4T, which use the cos() and sin() functions with degree function to plot circle in degrees. Just wonder how that would go since cos() and sin() use a lookup table to return the result quickly in BASIC, I think the same may apply with HP4T only because of it being much faster than Turbo Pascal 3 (which doesn't use one).

Thanks for the pointer to the other thread. In fact I came across this Arnold problem while trying to get another 'circle' program working. And now it is working in JavaCPC and definitely on my CPC464. It's this one ... see screenshot ... adapted from an Acornsoft BASIC original. Takes about 12s to run in HP4T vs 31s in Locomotive BASIC and pretty much all of the time is spent in the cos() and sin() routines. I'll post some code and details in the HiSoft Pascal thread later.


R