Board index » delphi » Is it Pascal, or is it my processor?

Patrick D. Rockwel

Delphi Developer
Sat, 26 Jul 2003 05:39:56 GMT

Is it Pascal, or is it my processor?

Consider the following program.

program big;
{$N+}
var i:integer;
    f:extended;
begin
f:=1;
for i:=1 to 59 do begin
f:=f*2;
writeln(f:24:5,' ',exp(i*ln(2)):24:5,' ',f=exp(i*ln(2)));
end;
readln;
end.

In this program, f is a variable = to 2 raised to the 59 power. The
writeln statement displays this value in
two ways. On is with f which is multiplied by two at each pass of the
above loop. The other is where 2 is raised to the ith power directly
with the exp() function. the third variable in the write statment is
f=exp(i*ln2)) which is a boolean operator which is either true or false
depending upon whether exp(i*ln(2)) = f or not. Through the programs
run, f is always the correct value, but as I increases, the
values of exp(i*ln(2)) is sometimes incorrect. Try it and you'll see.

Now, I already know how to compensate for this, but waht I'd like to
know is, is this because of my processor, or is it a limitation of
Borland Pascal? Would exp(i*ln(2)) be calculated differently on someone
elses machine using Borland Pascal? TIA.

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.net
mailto:patri48...@aol.com

 
Osmo Ronkan

Delphi Developer
Sat, 26 Jul 2003 05:59:27 GMT

Re:Is it Pascal, or is it my processor?


In article <3A7F1DAC.E45CD...@thegrid.net>,
Patrick D. Rockwell <prockw...@thegrid.net> wrote:

Quote
>Consider the following program.

>program big;
>{$N+}
>var i:integer;
>    f:extended;
>begin
>f:=1;
>for i:=1 to 59 do begin
>f:=f*2;
>writeln(f:24:5,' ',exp(i*ln(2)):24:5,' ',f=exp(i*ln(2)));
>end;
>readln;
>end.

Is this a joke? You should never use = with floating point values. They
are inherently inaccurate. The multiplication method produces accurate
value in this case (as it is 2^n) but the ln method does not produce
accurate value. Ln(2) is an irrational number.  0.6931471805599...
Clearly it is not reasonable to expect a nice answer from that.

Quote
>Now, I already know how to compensate for this, but waht I'd like to
>know is, is this because of my processor, or is it a limitation of
>Borland Pascal? Would exp(i*ln(2)) be calculated differently on someone
>elses machine using Borland Pascal? TIA.

It is because of a limitation of a floating point system.

Osmo

A. Moor

Delphi Developer
Sat, 26 Jul 2003 05:53:24 GMT

Re:Is it Pascal, or is it my processor?


Quote
Patrick D. Rockwell wrote:

> Consider the following program.

<snip>

Quote
> f:=1;
> for i:=1 to 59 do begin
> f:=f*2;
> writeln(f:24:5,' ',exp(i*ln(2)):24:5,' ',f=exp(i*ln(2)));
> end;

<snip>

Quote
> f=exp(i*ln2)) which is a boolean operator which is either true or false
> depending upon whether exp(i*ln(2)) = f or not. Through the programs
> run, f is always the correct value, but as I increases, the
> values of exp(i*ln(2)) is sometimes incorrect. Try it and you'll see.

> Now, I already know how to compensate for this, but waht I'd like to
> know is, is this because of my processor, or is it a limitation of
> Borland Pascal? Would exp(i*ln(2)) be calculated differently on someone
> elses machine using Borland Pascal? TIA.

The problem is that both the ln() and the exp() functions have finite
accuracy, and in general the logarithms and exponentials are irrational
-- they cannot be precisely expressed as "real" types. in consequence,
the value of f cannot be expected to exactly equal exp(i*ln(2)). The
difference, of course, will occur in the least significant bits of the
two numbers, so, expressing them to limited precision will make them
appear equal on output, even though they are not, in fact, equal. This
is why, in general, we do not test varaibles with "real" types for
equality.

Al Moore

Ing. Franz Glase

Delphi Developer
Sat, 26 Jul 2003 06:13:39 GMT

Re:Is it Pascal, or is it my processor?


Quote
Osmo Ronkanen wrote:
> ... Ln(2) is an irrational number.  0.6931471805599...
> Clearly it is not reasonable to expect a nice answer from that.

It is suggested to use the Str procedure for both values, then
compare the strings. This should be sufficient.

Greetings,
--
Franz Glaser, Glasau 3, A-4191 Vorderweissenbach Austria +43-7219-7035-0
Muehlviertler Elektronik Glaser.  Industrial control and instrumentation
http://members.eunet.at/meg-glaser/    http://members.xoom.com/f_glaser/
http://www.geocities.com/~franzglaser/            http://start.at/bedarf

Patrick D. Rockwel

Delphi Developer
Sat, 26 Jul 2003 08:36:15 GMT

Re:Is it Pascal, or is it my processor?


Quote
Osmo Ronkanen wrote:
> In article <3A7F1DAC.E45CD...@thegrid.net>,
> Patrick D. Rockwell <prockw...@thegrid.net> wrote:
> >Consider the following program.

> >program big;
> >{$N+}
> >var i:integer;
> >    f:extended;
> >begin
> >f:=1;
> >for i:=1 to 59 do begin
> >f:=f*2;
> >writeln(f:24:5,' ',exp(i*ln(2)):24:5,' ',f=exp(i*ln(2)));
> >end;
> >readln;
> >end.

> Is this a joke? You should never use = with floating point values. They
> are inherently inaccurate. The multiplication method produces accurate
> value in this case (as it is 2^n) but the ln method does not produce
> accurate value. Ln(2) is an irrational number.  0.6931471805599...
> Clearly it is not reasonable to expect a nice answer from that.

Point taken. The program that I submitted is only a test program for a much
larger program that I'm
writing which factors numbers using Newtons method. My program doesn't need
to to test for equality
in the way that is presented in my previous post, but it does deal with
large numbers.

Quote
> >Now, I already know how to compensate for this, but waht I'd like to
> >know is, is this because of my processor, or is it a limitation of
> >Borland Pascal? Would exp(i*ln(2)) be calculated differently on someone
> >elses machine using Borland Pascal? TIA.

> It is because of a limitation of a floating point system.

Ok, in that case,  I have to compensate since I believe that your saying
that this would happen on all
machines, not just mine.

--
Patrick D. Rockwell
mailto:prockw...@thegrid.net
mailto:HNHC...@prodigy.net
mailto:patri48...@aol.com

Rudolf Polz

Delphi Developer
Sat, 26 Jul 2003 06:06:57 GMT

Re:Is it Pascal, or is it my processor?


Patrick D. Rockwell <prockw...@thegrid.net> schrieb Folgendes:

Quote
>     f:extended;

It is your processor using a numeric format with a limited number of
digits. See the FAQ. All x86 processors use that numeric format, not only
yours.

--
$p=q;.;;$_=<<'learn.to/quote';s/./pack"C",9^unpack"C",$&/gem;eval;'RP'
-u""2of{!zye`}&&%+khza)*)'{'d')'$'{'o')'&'Ug'''khza)*)'e'f'n'f'|'}'UgU
C|z})b`mm`gn.g.hgf}al{)'Y'l'{'e)ahjbl{Ug+ r-V)lx-y//zelly)8'9uuy{`g}2t
learn.to/quote

Rudolf Polz

Delphi Developer
Mon, 28 Jul 2003 00:26:13 GMT

Re:Is it Pascal, or is it my processor?


h_c...@my-deja.com <h_c...@my-deja.com> schrieb Folgendes:

Quote
> Hi

> I'm afraid that '/' does not return what is expected, that is if you
> expect the same result as pascal integer arithmetic!

> var c: comp;
> begin
> c:=20/3;
> writeln ('c = ',c);
> end.

Of course it does not work.
But try
 c := Comp(20) / Comp(3)
and it will work!

Quote

> The result is "c = 7.000...E+0000".
> I've left out some of the zeros. Comp division rounds off the number, it
> does not truncate.

That was not Comp division, that was Extended division done by the
compiler.

Quote
> Also if you try c:= a - (a/b)*b you will get c=0, (when a,b,c are of
> type comp). Evidently the compiler optimizes (a/b)*b to a. to get a
> correct anser do it in two stages.
> tmp:=a/b;
> tmp:=a-tmp*b;
> if tmp < 0
> then tmp:=b+tmp;
> result:=tmp;

Or:
c := Comp(a) - Comp(Comp(a) / Comp(b)) * Comp(b).
Then you can remove as many typecasts as you can if it still remains
working.

--
#!/usr/bin/perl -w
$0=q{$0="\n".'$0=q{'.$0.'};eval$0;'."\n";for(<*.pl>){open X,">>$_";print
X$0;close X;}print scalar reverse"\nPR!suriv lreP rehtona tsuJ"};eval$0;
######################## http://learn.to/quote/ ########################

Dr John Stockto

Delphi Developer
Sun, 27 Jul 2003 23:32:57 GMT

Re:Is it Pascal, or is it my processor?


JRS:  In article <95puah$n...@nnrp1.deja.com>, seen in
news:comp.lang.pascal.borland, h_c...@my-deja.com wrote at Tue, 6 Feb
2001 22:37:06 :-

Quote

>var c: comp;
>begin
>c:=20/3;
>writeln ('c = ',c);
>end.

>The result is "c = 7.000...E+0000".
>I've left out some of the zeros. Comp division rounds off the number, it
>does not truncate.

It's maybe not the division as such, but the fact that you assign to a
comp.  BTW, 20/3 will be done at compile time too, I suspect.

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

h_c..

Delphi Developer
Mon, 28 Jul 2003 05:02:35 GMT

Re:Is it Pascal, or is it my processor?


In article <slrn982tp5.16s.rpol...@rebounce.rpolzer-lx>,
Quote
  grauezel...@gibts.net wrote:
> h_c...@my-deja.com <h_c...@my-deja.com> schrieb Folgendes:
> > Hi

> > I'm afraid that '/' does not return what is expected, that is if you
> > expect the same result as pascal integer arithmetic!

> > var c: comp;
> > begin
> > c:=20/3;
> > writeln ('c = ',c);
> > end.

> Of course it does not work.
> But try
>  c := Comp(20) / Comp(3)
> and it will work!

> > The result is "c = 7.000...E+0000".
> > I've left out some of the zeros. Comp division rounds off the
number, it
> > does not truncate.

> That was not Comp division, that was Extended division done by the
> compiler.

> > Also if you try c:= a - (a/b)*b you will get c=0, (when a,b,c are of
> > type comp). Evidently the compiler optimizes (a/b)*b to a. to get a
> > correct anser do it in two stages.
> > tmp:=a/b;
> > tmp:=a-tmp*b;
> > if tmp < 0
> > then tmp:=b+tmp;
> > result:=tmp;

> Or:
> c := Comp(a) - Comp(Comp(a) / Comp(b)) * Comp(b).
> Then you can remove as many typecasts as you can if it still remains
> working.

> --
> #!/usr/bin/perl -w
> $0=q{$0="\n".'$0=q{'.$0.'};eval$0;'."\n";for(<*.pl>){open
X,">>$_";print
> X$0;close X;}print scalar reverse"\nPR!suriv lreP rehtona
tsuJ"};eval$0;
> ######################## http://learn.to/quote/

########################
Quote

Hi

Did you think I wouldn't try it? c:=comp(20)/comp(3); will not even
compile!!! Error 20 Variable Identifier Expected. (BP7)

Tried to compile it in Delphi5. No dice. Invalid Type Cast.

also
program testcomp; {BP7}
var a,b,c: comp;
begin
a:=20; b:=3; {forcing 20 and 3 to a comp types}

c:=a/b;
writeln ('c = ',c);
end.

Care to guess what the answer is? Yep, that's right 7.
And that happens in both Delphi5 and BP7.

What compiler are you using?

Regards Hanford

Sent via Deja.com
http://www.deja.com/

Rudolf Polz

Delphi Developer
Tue, 29 Jul 2003 01:24:27 GMT

Re:Is it Pascal, or is it my processor?


h_c...@my-deja.com <h_c...@my-deja.com> schrieb Folgendes:

Quote
> Hi

> Did you think I wouldn't try it? c:=comp(20)/comp(3); will not even
> compile!!! Error 20 Variable Identifier Expected. (BP7)

> Tried to compile it in Delphi5. No dice. Invalid Type Cast.

> also
> program testcomp; {BP7}
> var a,b,c: comp;
> begin
> a:=20; b:=3; {forcing 20 and 3 to a comp types}

> c:=a/b;
> writeln ('c = ',c);
> end.

> Care to guess what the answer is? Yep, that's right 7.
> And that happens in both Delphi5 and BP7.

> What compiler are you using?

I used TP6 and it worked (I wrote working prime tests using
Square-And-Multiply using it, and I never saw any negative numbers
in the debugging output). Now I use TP7 and it does not work any
more. Sorry.

Quote

> Regards Hanford

> Sent via Deja.com
> http://www.deja.com/

--
#!/usr/bin/perl -w
$0=q{$0="\n".'$0=q{'.$0.'};eval$0;'."\n";for(<*.pl>){open X,">>$_";print
X$0;close X;}print ''.reverse"\n!suriv lreP rehtona tsuJ>RH<\n"};eval$0;
######################## http://learn.to/quote/ ########################
Dr John Stockto

Delphi Developer
Mon, 28 Jul 2003 23:14:21 GMT

Re:Is it Pascal, or is it my processor?


JRS:  In article <95sd53$4v...@nnrp1.deja.com>, seen in
news:comp.lang.pascal.borland, h_c...@my-deja.com wrote at Wed, 7 Feb
2001 21:02:35 :-

Quote
>In article <slrn982tp5.16s.rpol...@rebounce.rpolzer-lx>,
>  grauezel...@gibts.net wrote:
>> h_c...@my-deja.com <h_c...@my-deja.com> schrieb Folgendes:
>> > I'm afraid that '/' does not return what is expected, that is if you
>> > expect the same result as pascal integer arithmetic!
>program testcomp; {BP7}
>var a,b,c: comp;
>begin
>a:=20; b:=3; {forcing 20 and 3 to a comp types}

>c:=a/b;
>writeln ('c = ',c);
>end.

>Care to guess what the answer is? Yep, that's right 7.
>And that happens in both Delphi5 and BP7.

COMP is not an integer type; it is merely restricted to integer values.
COMP arithmetic uses the FPU.  There is no reason to expect pure-COMP
division to give the same result as integer div, and it cannot in
general give the same result as integer /.  The division of COMPs with /
gives an Extended, I think; one cannot div COMPs.

   Integer in : Twenty div Three = 6
   Integer in : Twenty  /  Three = 6.66666666666666 or thereabouts
   Comp    in : Twenty  /  Three = Ditto

After evaluation, the result is THEN persuaded into a destination.

        var X, Y, Z : comp ;
        begin
        X := 20 ; Y := 3 ; Z := X/Y ;
        Write(X/Y, '    ', Z) ;
        readln end.

gives

        6.66666666666667E+0000     7.00000000000000E+0000

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

Osmo Ronkan

Delphi Developer
Tue, 29 Jul 2003 07:13:33 GMT

Re:Is it Pascal, or is it my processor?


In article <8AJzMMJNfrg6E...@merlyn.demon.co.uk>,
Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:

Quote

>COMP is not an integer type; it is merely restricted to integer values.
>COMP arithmetic uses the FPU.  There is no reason to expect pure-COMP
>division to give the same result as integer div, and it cannot in
>general give the same result as integer /.  The division of COMPs with /
>gives an Extended, I think; one cannot div COMPs.

The solution is to use int(x/y).

Osmo

Rudolf Polz

Delphi Developer
Tue, 29 Jul 2003 16:11:21 GMT

Re:Is it Pascal, or is it my processor?


Osmo Ronkanen <ronka...@cc.helsinki.fi> schrieb Folgendes:

Quote
> In article <8AJzMMJNfrg6E...@merlyn.demon.co.uk>,
> Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:

> >COMP is not an integer type; it is merely restricted to integer values.
> >COMP arithmetic uses the FPU.  There is no reason to expect pure-COMP
> >division to give the same result as integer div, and it cannot in
> >general give the same result as integer /.  The division of COMPs with /
> >gives an Extended, I think; one cannot div COMPs.

> The solution is to use int(x/y).

Does this even work with big comps? I do not know if extendeds have more
significant digits than comps.

--
#!/usr/bin/perl
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################

Osmo Ronkan

Delphi Developer
Tue, 29 Jul 2003 23:04:52 GMT

Re:Is it Pascal, or is it my processor?


In Article <slrn9879h9.qp.rpol...@rebounce.rpolzer-lx> rpol...@web.de (Rudolf Polzer) wrote:

Quote
>Osmo Ronkanen <ronka...@cc.helsinki.fi> schrieb Folgendes:

>> The solution is to use int(x/y).

>Does this even work with big comps? I do not know if extendeds have more
>significant digits than comps.

Sure it works. Why would it not. Both Comp and Extended have 63 bit
accuracy.

Osmo

smread_bog..

Delphi Developer
Wed, 30 Jul 2003 00:35:46 GMT

Re:Is it Pascal, or is it my processor?


On Fri, 9 Feb 2001 09:11:21 +0100, rpol...@web.de (Rudolf Polzer)
wrote:

Quote
>Osmo Ronkanen <ronka...@cc.helsinki.fi> schrieb Folgendes:
>> In article <8AJzMMJNfrg6E...@merlyn.demon.co.uk>,
>> Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:

>> >COMP is not an integer type; it is merely restricted to integer values.
>> >COMP arithmetic uses the FPU.  There is no reason to expect pure-COMP
>> >division to give the same result as integer div, and it cannot in
>> >general give the same result as integer /.  The division of COMPs with /
>> >gives an Extended, I think; one cannot div COMPs.

>> The solution is to use int(x/y).

>Does this even work with big comps? I do not know if extendeds have more
>significant digits than comps.

Under BP 7.0 help for Reals

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Turbo Pascal provides five predefined real types. Each type has a
specific range and precision:

    Type     | Range               | Digits | Bytes
    ---------+---------------------+--------+------
    real     | 2.9e-39..1.7e38     | 11-12  |  6
    single   | 1.5e-45..3.4e38     |  7-8   |  4
    double   | 5.0e-324..1.7e308   | 15-16  |  8
    extended | 3.4e-4932..1.1e4932 | 19-20  | 10
    comp     | -9.2e18..9.2e18     | 19-20  |  8

 Note: The comp type is a 64-bit integer. It holds only integral
values within the range (-2 63 + 1) to (2 63 - 1).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Steve
----
due to SPAM robots and other leaches, I no longer post my e-mail address

Go to page: [1] [2]

Other Threads

1. I am looking for DOS based PASCAL

2. I Am Interested in Pascal for Windows

3. Help,I am new for pascal.

4. Event coding, or How I Am Foundering In Pascal (YANQ)

5. I am really sorry

6. Am I hitting the Limit here?

7. Losing File Handles - But I am not using Files

8. Am I in protected mode?

9. I am so confused....

10. What am I doing wrong