Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > pure functions

Reply
Thread Tools

pure functions

 
 
Walter Roberson
Guest
Posts: n/a
 
      06-13-2005
In article <4Gjre.52$X71.31@fed1read07>,
Anonymous 7843 <(E-Mail Removed)> wrote:
>There are also "short term" pure functions like time() and ftell()
>which normally cannot be treated as pure by the compiler, but which
>are nonetheless good candidates for manually hoisting out of tight loops
>in which nothing in the loop resets the date or writes to the file.


That's an interesting idea; I'm not sure that the examples are
the best ones, though.

time() deals in terms of seconds, not in terms of "dates"; any
loop that operates for long enough is going to tick over to a new
second. One could imagine an algorithm that sleep() until just before
an action was to be taken, and then went into a loop polling time()
until the crossover. (The algorithm should, of course, check that
the time() is returning a valid value, for the cases where there is
no real-time clock.)


ftell()... one should look at signals for this one. One cannot
do much within a pure C signal handler routine, but C does not
prohibit implementation extensions such as POSIX.1 . In POSIX.1,
two of the routines that are considered "signal safe" (allowed to
execute them inside a signal handler) are close() and write().
Both of those operate on file descriptors, not on FILE*, but
if I'm interpreting correctly, close() on the file descriptor
"underlying" a FILE* has an effect on the FILE*'s state.

The POSIX.1 1990 language about the connection between file descriptors
and FILE* is not the clearest, so I'm not certain of the exact POSIX.1
proper behaviour in the case of close() and write() on the
underlying descriptors... plausibly the FILE* level wouldn't properly
catch on until the next fseek() [or until sufficient data was
read to exhaust the in-memory buffer, thus calling upon the underlying
read() routine that would notice the end-of-file.] We'd need someone
well versed in POSIX.1 to detail this situation for us.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      06-13-2005
http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
> In article <4Gjre.52$X71.31@fed1read07>,
> Anonymous 7843 <(E-Mail Removed)> wrote:
>>There are also "short term" pure functions like time() and ftell()
>>which normally cannot be treated as pure by the compiler, but which
>>are nonetheless good candidates for manually hoisting out of tight loops
>>in which nothing in the loop resets the date or writes to the file.

>
> That's an interesting idea; I'm not sure that the examples are
> the best ones, though.
>
> time() deals in terms of seconds, not in terms of "dates"; any
> loop that operates for long enough is going to tick over to a new
> second. One could imagine an algorithm that sleep() until just before
> an action was to be taken, and then went into a loop polling time()
> until the crossover. (The algorithm should, of course, check that
> the time() is returning a valid value, for the cases where there is
> no real-time clock.)


time() deals in terms of time_t, an arithmetic type capable of
representing times. The standard doesn't specify the resolution of
time_t or of the time() function; 1 second is common, but not
required.

An aggresively optimizing compiler presumably can know what the
resolution is, but I'm still skeptical that optimizing away a call to
time() would be worth the effort.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
 
Lawrence Kirby
Guest
Posts: n/a
 
      06-21-2005
On Mon, 13 Jun 2005 17:48:48 +0000, Anonymous 7843 wrote:

> In article <(E-Mail Removed)>,
> Chris Croughton <(E-Mail Removed)> wrote:
>>
>>On Fri, 10 Jun 2005 21:30:57 +0000 (UTC), Malcolm
>> <(E-Mail Removed)> wrote:
>>
>>> For instance you could have a convention that pure functions always take
>>> single-letter parameters, non-pure functions always take at least one
>>> parameter with more than one letter.

>>
>>Or no parameters at all (a function which has no parameters can't be
>>'pure' unless it is trivial and returns a constant).

>
> There are also "short term" pure functions like time() and ftell()
> which normally cannot be treated as pure by the compiler, but which
> are nonetheless good candidates for manually hoisting out of tight loops
> in which nothing in the loop resets the date or writes to the file.


However taking time() out of the loop can produce different results. It
isn't a matter of assuming that the results will be the same, it is
whether the potentially different results can still be considered correct
in context. They may even be preferable.

On some platforms a file position can be altered by something other than
the executing program.

Lawrence








 
Reply With Quote
 
Anonymous 7843
Guest
Posts: n/a
 
      06-22-2005
In article <(E-Mail Removed)> ,
Lawrence Kirby <(E-Mail Removed)> wrote:
>
>On Mon, 13 Jun 2005 17:48:48 +0000, Anonymous 7843 wrote:
>
>> In article <(E-Mail Removed)>,
>> Chris Croughton <(E-Mail Removed)> wrote:
>>>
>>>On Fri, 10 Jun 2005 21:30:57 +0000 (UTC), Malcolm
>>> <(E-Mail Removed)> wrote:
>>>
>>>> For instance you could have a convention that pure functions always take
>>>> single-letter parameters, non-pure functions always take at least one
>>>> parameter with more than one letter.
>>>
>>>Or no parameters at all (a function which has no parameters can't be
>>>'pure' unless it is trivial and returns a constant).

>>
>> There are also "short term" pure functions like time() and ftell()
>> which normally cannot be treated as pure by the compiler, but which
>> are nonetheless good candidates for manually hoisting out of tight loops
>> in which nothing in the loop resets the date or writes to the file.

>
>However taking time() out of the loop can produce different results. It
>isn't a matter of assuming that the results will be the same, it is
>whether the potentially different results can still be considered correct
>in context. They may even be preferable.


I should have used different words: by "manually" I meant "as
performed by a human not by the compiler". "hoist" in this
context however is usually meant as an optimization performed
by the compiler, so I apologize for the confusion.

Obviously, if the compiler wanted to do such a thing it would have to
be quite careful about the conditions, or even be specifically
told (e.g. gcc -O9) that it's okay to make aggressive
assumptions about short-term functiony pure-ness.

>On some platforms a file position can be altered by something other than
>the executing program.


(ITYM file length, but point taken.)

So any program that uses time() or ftell() is already
non-deterministic. Extra out-of-dateness from my proposed
trick would only make the problem worse, but would not
make a deterministic program non-deterministic.
--
7842++
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pure space directly inside div ignored, but pure space directlyinside span honored liketofindoutwhy@gmail.com HTML 4 03-29-2008 06:06 PM
private virtual functions and pure virtual functions with bodies John Goche C++ 10 12-08-2006 04:00 PM
Pure functions still pure after definition Todd Aspeotis C++ 3 05-30-2005 03:53 AM
please help me in distinguish redefining functions, overloading functions and overriding functions. Xiangliang Meng C++ 1 06-21-2004 03:11 AM
Re: Alternate syntax for pure virtual functions? David White C++ 0 08-11-2003 10:11 AM



Advertisments