Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!kth!sunic!dkuug!freja!damm
From: damm@freja.diku.dk (Kristian Damm Jensen)
Newsgroups: comp.lang.pascal
Subject: Re: Realint qestion
Message-ID: <4664@freja.diku.dk>
Date: 14 May 89 21:29:45 GMT
References: <19573@adm.BRL.MIL> <21930@santra.UUCP> <10247@socslgw.csl.sony.JUNET>
Organization: DIKU, U of Copenhagen, DK
Lines: 31

diamond@diamond.csl.sony.junet (Norman Diamond) writes:

>In article <21930@santra.UUCP> s32935k@taltta.hut.fi (Carl Torsten Stenholm) writes:

>>I was looking at a bit of software posted on the net and there was a function
>>looking like this (I hope I don't break any copyrights now...)

>>function realint (x: real): real;
>>begin
>>  realint := x - (x - trunc (x));
>>end;

<< stuf deleted >>

>>Well now the only difference between this function and putting "trunc (x)" 
>>directly in the code is that trunc returns an integer (I  think). In that
>>case -- is there any situation where you must have an real returned instead
>>of an integer and thus forced to use this function ?

>Suppose MAXINT is 2147whatever (about 2 billion), and x is -2.35e+3000 ?

In that case you would REALLY be in trouble since the code contains a
call trunc (x).

The only likely reason to use the above mentioned function that I can 
think of is as a parameter for a function that needs a "realint" value.
I that case you can't just use the standard trunc-function since the 
restriction on types are much stronger on parameters than on plain assignment.
In an assignment the types just has to be compatible (for the full 
description of type compatibility see the Users Manual And Report 
p. 159 (3. ed.))- in parameters they have BE the same type.