Pure function - Revision history

141.47.39.37: /* Memoization */ Missing bracket fixed, Main article template added

2025-05-21T06:55:47Z

Memoization: Missing bracket fixed, Main article template added

← Previous revision		Revision as of 06:55, 21 May 2025
Line 114:		Line 114:

	== Memoization ==		== Memoization ==
			{{Main\|Memoization}}
		⚫	The outputs of a pure function can be [[cache (computing)\|cached]] in a look-up table. Any result that is returned from a given function is cached, and the next time the function is called with the same input parameters, the cached result is returned instead of computing the function again.

		⚫	[[Memoization]] can be performed by wrapping the function in another function ([[wrapper function]]).<ref name="Aley 2017 p. 109">{{cite book \| last=Aley \| first=R. \| title=Pro Functional PHP Programming: Application Development Strategies for Performance Optimization, Concurrency, Testability, and Code Brevity \| publisher=Apress \| series=SpringerLink : Bücher \| year=2017 \| isbn=978-1-4842-2958-3 \| url=https://books.google.com/books?id=_JY3DwAAQBAJ&pg=PA109 \| access-date=2024-02-04 \| page=109}}</ref>
⚫	The outputs of a pure function can be ~~precomputed and~~ [[cache (computing)\|cached]] in a look-up table. ~~In a technique called [[memoization]], any~~ result that is returned from a given function is cached, and the next time the function is called with the same input parameters, the cached result is returned instead of computing the function again.

⚫	Memoization can be performed by wrapping the function in another function ([[wrapper function]]).<ref name="Aley 2017 p. 109">{{cite book \| last=Aley \| first=R. \| title=Pro Functional PHP Programming: Application Development Strategies for Performance Optimization, Concurrency, Testability, and Code Brevity \| publisher=Apress \| series=SpringerLink : Bücher \| year=2017 \| isbn=978-1-4842-2958-3 \| url=https://books.google.com/books?id=_JY3DwAAQBAJ&pg=PA109 \| access-date=2024-02-04 \| page=109}}</ref>

	By means of memoization, the computational effort involved in the computations of the function itself can be reduced, at the cost of the overhead for managing the cache and an increase of memory requirements.		By means of memoization, the computational effort involved in the computations of the function itself can be reduced, at the cost of the overhead for managing the cache and an increase of memory requirements.

	A [[C (programming language)\|C]] program for cached computation of [[factorial]] ([[assert.h\|<code>assert()</code>]] aborts with an error message if its argument is false; on a 32-bit machine, values beyond <code>fact(12)</code> cannot be represented ~~anyway~~.{{citation needed\|date=May 2024}}		A [[C (programming language)\|C]] program for cached computation of [[factorial]] ([[assert.h\|<code>assert()</code>]] aborts with an error message if its argument is false; on a 32-bit machine, values beyond <code>fact(12)</code> cannot be represented.{{citation needed\|date=May 2024}})

	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">

Frap: /* Memoization */

2025-05-12T12:44:17Z

Memoization

← Previous revision		Revision as of 12:44, 12 May 2025
Line 123:		Line 123:
	A [[C (programming language)\|C]] program for cached computation of [[factorial]] ([[assert.h\|<code>assert()</code>]] aborts with an error message if its argument is false; on a 32-bit machine, values beyond <code>fact(12)</code> cannot be represented anyway.{{citation needed\|date=May 2024}}		A [[C (programming language)\|C]] program for cached computation of [[factorial]] ([[assert.h\|<code>assert()</code>]] aborts with an error message if its argument is false; on a 32-bit machine, values beyond <code>fact(12)</code> cannot be represented anyway.{{citation needed\|date=May 2024}}

	<syntaxhighlight lang=C>		<syntaxhighlight lang="c">
	static int fact(int n) {		static int fact(int n) {
	return n<=1 ? 1 : fact(n-1)*n;		return n <= 1 ? 1 : fact(n - 1) * n;
	}		}

	int fact_wrapper(int n) {		int fact_wrapper(int n) {
	static int cache[13];		static int cache[13];
	assert(0<=n && n<13);		assert(0 <= n && n < 13);
	if (cache[n] == 0)		if (cache[n] == 0)
	cache[n] = fact(n);		cache[n] = fact(n);

174.88.139.35: This was inconsistent with the example given below where a pure function includes the mutation of a local static variable

2025-05-11T16:11:44Z

This was inconsistent with the example given below where a pure function includes the mutation of a local static variable

← Previous revision		Revision as of 16:11, 11 May 2025
Line 5:		Line 5:

	# the function [[Return statement\|return values]] are [[Relational operator#Location equality vs. content equality\|identical]] for identical [[Argument of a function\|arguments]] (no variation with local [[static variable]]s, [[non-local variable]]s, mutable [[Value type and reference type\|reference arguments]] or [[Input/output\|input streams]], i.e., [[referential transparency]]), and		# the function [[Return statement\|return values]] are [[Relational operator#Location equality vs. content equality\|identical]] for identical [[Argument of a function\|arguments]] (no variation with local [[static variable]]s, [[non-local variable]]s, mutable [[Value type and reference type\|reference arguments]] or [[Input/output\|input streams]], i.e., [[referential transparency]]), and
	# the function has no [[Side effect (computer science)\|side effects]] (no mutation of ~~local static variables,~~ non-local variables, mutable reference arguments or input/output streams).		# the function has no [[Side effect (computer science)\|side effects]] (no mutation of non-local variables, mutable reference arguments or input/output streams).

	== Examples ==		== Examples ==

NotAG on AWB: replace {{manual}} with {{how-to}} per TfD, cleanup

2025-01-03T13:13:43Z

replace {{manual}} with {{how-to}} per TfD, cleanup

← Previous revision		Revision as of 13:13, 3 January 2025
Line 1:		Line 1:
	{{Short description\|Program function without side effects}}		{{Short description\|Program function without side effects}}
	{{~~manual~~\|date=May 2024}}		{{how-to\|date=May 2024}}

	In [[computer programming]], a '''pure function''' is a [[Subroutine\|function]] that has the following properties:<ref>{{cite web \|url=https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|title=Basics of Haskell \|author=Bartosz Milewski \|date=2013 \|website=School of Haskell \|publisher=FP Complete \|access-date=2018-07-13 \|archive-url=https://web.archive.org/web/20161027145455/https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|archive-date=2016-10-27 \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/ch03.md \|title=Professor Frisby's Mostly Adequate Guide to Functional Programming \|author=Brian Lonsdorf \|date=2015 \|website=GitHub \|publisher= \|access-date=2020-03-20 }}</ref>		In [[computer programming]], a '''pure function''' is a [[Subroutine\|function]] that has the following properties:<ref>{{cite web \|url=https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|title=Basics of Haskell \|author=Bartosz Milewski \|date=2013 \|website=School of Haskell \|publisher=FP Complete \|access-date=2018-07-13 \|archive-url=https://web.archive.org/web/20161027145455/https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|archive-date=2016-10-27 \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/ch03.md \|title=Professor Frisby's Mostly Adequate Guide to Functional Programming \|author=Brian Lonsdorf \|date=2015 \|website=GitHub \|publisher= \|access-date=2020-03-20 }}</ref>
Line 121:		Line 121:
	By means of memoization, the computational effort involved in the computations of the function itself can be reduced, at the cost of the overhead for managing the cache and an increase of memory requirements.		By means of memoization, the computational effort involved in the computations of the function itself can be reduced, at the cost of the overhead for managing the cache and an increase of memory requirements.

	A [[C (programming language)\|C]] program for cached computation of [[factorial]] ([[assert.h\|<code>assert()</code>]] aborts with an error message if its argument is false; on a 32-bit machine, values beyond <code>fact(12)</code> cannot be represented anyway.{{cn\|date=May 2024}}		A [[C (programming language)\|C]] program for cached computation of [[factorial]] ([[assert.h\|<code>assert()</code>]] aborts with an error message if its argument is false; on a 32-bit machine, values beyond <code>fact(12)</code> cannot be represented anyway.{{citation needed\|date=May 2024}}

	<syntaxhighlight lang=C>		<syntaxhighlight lang=C>

MichaelMaggs: WP:SDNOTDEF and WP:SDSHORT

2024-10-28T14:25:49Z

WP:SDNOTDEF and WP:SDSHORT

← Previous revision		Revision as of 14:25, 28 October 2024
Line 1:		Line 1:
	{{Short description\|Program function without side effects ~~and which returns identical values for identical arguments~~}}		{{Short description\|Program function without side effects}}
	{{manual\|date=May 2024}}		{{manual\|date=May 2024}}

Chai T. Rex: Undid revision 1243265440 by Chai T. Rex (talk)

2024-08-31T14:02:14Z

Undid revision 1243265440 by Chai T. Rex (talk)

← Previous revision		Revision as of 14:02, 31 August 2024
Line 13:		Line 13:
	\|1=<code>floor</code>, returning the [[Floor and ceiling functions\|floor]] of a number;		\|1=<code>floor</code>, returning the [[Floor and ceiling functions\|floor]] of a number;
	\|2=<code>max</code>, returning the [[Maxima and minima\|maximum]] of two values.		\|2=<code>max</code>, returning the [[Maxima and minima\|maximum]] of two values.
			\|3=the function ''f'', defined as
			<syntaxhighlight lang="c++">
			void f() {
			static std::atomic<unsigned int> x = 0;
			++x;
			}
	</syntaxhighlight>		</syntaxhighlight>
			The value of <code>x</code> can be only observed inside other invocations of <code>f()</code>, and as <code>f()</code> does not communicate the value of <code>x</code> to its environment, it is indistinguishable from function <code>void f() {}</code> that does nothing. Note that <code>x</code> is <code>std::atomic</code> so that modifications from multiple threads executing <code>f()</code> concurrently do not result in a [[Race condition#Data race\|data race]], which has [[undefined behavior]] in C and C++.
	}}		}}

Chai T. Rex: /* Pure functions */ f violates both rules in the introduction to the article. It produces different outputs with the same inputs and it modifies local static variables.

2024-08-31T14:01:41Z

Pure functions: f violates both rules in the introduction to the article. It produces different outputs with the same inputs and it modifies local static variables.

← Previous revision		Revision as of 14:01, 31 August 2024
Line 13:		Line 13:
	\|1=<code>floor</code>, returning the [[Floor and ceiling functions\|floor]] of a number;		\|1=<code>floor</code>, returning the [[Floor and ceiling functions\|floor]] of a number;
	\|2=<code>max</code>, returning the [[Maxima and minima\|maximum]] of two values.		\|2=<code>max</code>, returning the [[Maxima and minima\|maximum]] of two values.
	\|3=the function ''f'', defined as
	<syntaxhighlight lang="c++">
	void f() {
	static std::atomic<unsigned int> x = 0;
	++x;
	}
	</syntaxhighlight>		</syntaxhighlight>
	The value of <code>x</code> can be only observed inside other invocations of <code>f()</code>, and as <code>f()</code> does not communicate the value of <code>x</code> to its environment, it is indistinguishable from function <code>void f() {}</code> that does nothing. Note that <code>x</code> is <code>std::atomic</code> so that modifications from multiple threads executing <code>f()</code> concurrently do not result in a [[Race condition#Data race\|data race]], which has [[undefined behavior]] in C and C++.
	}}		}}

Discospinster: Reverted edits by 49.224.246.51 (talk) (HG) (3.4.12)

2024-05-29T21:39:51Z

Reverted edits by 49.224.246.51 (talk) (HG) (3.4.12)

← Previous revision		Revision as of 21:39, 29 May 2024
Line 109:		Line 109:
	I/O is inherently impure: input operations undermine [[referential transparency]], and output operations create side effects. Nevertheless, there is a sense in which a function can perform input or output and still be pure, if the sequence of operations on the relevant I/O devices is modeled explicitly as both an argument and a result, and I/O operations are taken to fail when the input sequence does not describe the operations actually taken since the program began execution.{{clarify\|date=November 2022}}		I/O is inherently impure: input operations undermine [[referential transparency]], and output operations create side effects. Nevertheless, there is a sense in which a function can perform input or output and still be pure, if the sequence of operations on the relevant I/O devices is modeled explicitly as both an argument and a result, and I/O operations are taken to fail when the input sequence does not describe the operations actually taken since the program began execution.{{clarify\|date=November 2022}}

	The second point ensures that the only sequence usable as an argument must change with each I/O action; the first allows different calls to an I/O-performing function to return different results on account of the sequence arguments having changed.<ref>{{cite book\|last1=Peyton Jones\|first1=Simon L.\|title=Haskell 98 Language and Libraries: The Revised Report\|page=95\|date=2003\|publisher=Cambridge University Press\|location=Cambridge, United Kingdom\|isbn=0-521 826144\|url=http://it.bmc.uu.se/andlov/dev/books/haskell98-report.pdf\|accessdate=17 July 2014\|ref=haskell98}}</ref><ref>{{cite web\|last1=Hanus\|first1=Michael\|title=Curry: An Integrated Functional Logic Language\|page=33\|url=http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|website=www-ps.informatik.uni-kiel.de\|publisher=Institut für Informatik, Christian-Albrechts-Universität zu Kiel\|accessdate=17 July 2014\|ref=curry14\|archive-url=https://web.archive.org/web/20140725231927/http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|archive-date=25 July 2014\|url-status=dead}}</ref>~~alexsio nau~~		The second point ensures that the only sequence usable as an argument must change with each I/O action; the first allows different calls to an I/O-performing function to return different results on account of the sequence arguments having changed.<ref>{{cite book\|last1=Peyton Jones\|first1=Simon L.\|title=Haskell 98 Language and Libraries: The Revised Report\|page=95\|date=2003\|publisher=Cambridge University Press\|location=Cambridge, United Kingdom\|isbn=0-521 826144\|url=http://it.bmc.uu.se/andlov/dev/books/haskell98-report.pdf\|accessdate=17 July 2014\|ref=haskell98}}</ref><ref>{{cite web\|last1=Hanus\|first1=Michael\|title=Curry: An Integrated Functional Logic Language\|page=33\|url=http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|website=www-ps.informatik.uni-kiel.de\|publisher=Institut für Informatik, Christian-Albrechts-Universität zu Kiel\|accessdate=17 July 2014\|ref=curry14\|archive-url=https://web.archive.org/web/20140725231927/http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|archive-date=25 July 2014\|url-status=dead}}</ref>

	The [[I/O monad]] is a [[programming idiom]] typically used to perform I/O in pure functional languages.		The [[I/O monad]] is a [[programming idiom]] typically used to perform I/O in pure functional languages.

49.224.246.51: /* I/O in pure functions */Added content

2024-05-29T21:38:47Z

I/O in pure functions: Added content

← Previous revision		Revision as of 21:38, 29 May 2024
Line 109:		Line 109:
	I/O is inherently impure: input operations undermine [[referential transparency]], and output operations create side effects. Nevertheless, there is a sense in which a function can perform input or output and still be pure, if the sequence of operations on the relevant I/O devices is modeled explicitly as both an argument and a result, and I/O operations are taken to fail when the input sequence does not describe the operations actually taken since the program began execution.{{clarify\|date=November 2022}}		I/O is inherently impure: input operations undermine [[referential transparency]], and output operations create side effects. Nevertheless, there is a sense in which a function can perform input or output and still be pure, if the sequence of operations on the relevant I/O devices is modeled explicitly as both an argument and a result, and I/O operations are taken to fail when the input sequence does not describe the operations actually taken since the program began execution.{{clarify\|date=November 2022}}

	The second point ensures that the only sequence usable as an argument must change with each I/O action; the first allows different calls to an I/O-performing function to return different results on account of the sequence arguments having changed.<ref>{{cite book\|last1=Peyton Jones\|first1=Simon L.\|title=Haskell 98 Language and Libraries: The Revised Report\|page=95\|date=2003\|publisher=Cambridge University Press\|location=Cambridge, United Kingdom\|isbn=0-521 826144\|url=http://it.bmc.uu.se/andlov/dev/books/haskell98-report.pdf\|accessdate=17 July 2014\|ref=haskell98}}</ref><ref>{{cite web\|last1=Hanus\|first1=Michael\|title=Curry: An Integrated Functional Logic Language\|page=33\|url=http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|website=www-ps.informatik.uni-kiel.de\|publisher=Institut für Informatik, Christian-Albrechts-Universität zu Kiel\|accessdate=17 July 2014\|ref=curry14\|archive-url=https://web.archive.org/web/20140725231927/http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|archive-date=25 July 2014\|url-status=dead}}</ref>		The second point ensures that the only sequence usable as an argument must change with each I/O action; the first allows different calls to an I/O-performing function to return different results on account of the sequence arguments having changed.<ref>{{cite book\|last1=Peyton Jones\|first1=Simon L.\|title=Haskell 98 Language and Libraries: The Revised Report\|page=95\|date=2003\|publisher=Cambridge University Press\|location=Cambridge, United Kingdom\|isbn=0-521 826144\|url=http://it.bmc.uu.se/andlov/dev/books/haskell98-report.pdf\|accessdate=17 July 2014\|ref=haskell98}}</ref><ref>{{cite web\|last1=Hanus\|first1=Michael\|title=Curry: An Integrated Functional Logic Language\|page=33\|url=http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|website=www-ps.informatik.uni-kiel.de\|publisher=Institut für Informatik, Christian-Albrechts-Universität zu Kiel\|accessdate=17 July 2014\|ref=curry14\|archive-url=https://web.archive.org/web/20140725231927/http://www.informatik.uni-kiel.de/~curry/papers/report.pdf\|archive-date=25 July 2014\|url-status=dead}}</ref>alexsio nau

	The [[I/O monad]] is a [[programming idiom]] typically used to perform I/O in pure functional languages.		The [[I/O monad]] is a [[programming idiom]] typically used to perform I/O in pure functional languages.

Ingenuity: Reverted edits by 49.224.246.51 (talk) (AV)

2024-05-29T21:37:37Z

Reverted edits by 49.224.246.51 (talk) (AV)

← Previous revision		Revision as of 21:37, 29 May 2024
Line 2:		Line 2:
	{{manual\|date=May 2024}}		{{manual\|date=May 2024}}

	In [[computer programming]], a '''pure function''' is a [[Subroutine\|function]] that has the following properties:<ref>{{cite web \|url=https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|title=Basics of Haskell \|author=Bartosz Milewski \|date=2013 \|website=School of Haskell \|publisher=FP Complete \|access-date=2018-07-13 \|archive-url=https://web.archive.org/web/20161027145455/https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|archive-date=2016-10-27 \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/ch03.md \|title=Professor Frisby's Mostly Adequate Guide to Functional Programming \|author=Brian Lonsdorf \|date=2015 \|website=GitHub \|publisher= \|access-date=2020-03-20 }}</ref>~~alexsio nau~~		In [[computer programming]], a '''pure function''' is a [[Subroutine\|function]] that has the following properties:<ref>{{cite web \|url=https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|title=Basics of Haskell \|author=Bartosz Milewski \|date=2013 \|website=School of Haskell \|publisher=FP Complete \|access-date=2018-07-13 \|archive-url=https://web.archive.org/web/20161027145455/https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|archive-date=2016-10-27 \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/ch03.md \|title=Professor Frisby's Mostly Adequate Guide to Functional Programming \|author=Brian Lonsdorf \|date=2015 \|website=GitHub \|publisher= \|access-date=2020-03-20 }}</ref>

	# the function [[Return statement\|return values]] are [[Relational operator#Location equality vs. content equality\|identical]] for identical [[Argument of a function\|arguments]] (no variation with local [[static variable]]s, [[non-local variable]]s, mutable [[Value type and reference type\|reference arguments]] or [[Input/output\|input streams]], i.e., [[referential transparency]]), and		# the function [[Return statement\|return values]] are [[Relational operator#Location equality vs. content equality\|identical]] for identical [[Argument of a function\|arguments]] (no variation with local [[static variable]]s, [[non-local variable]]s, mutable [[Value type and reference type\|reference arguments]] or [[Input/output\|input streams]], i.e., [[referential transparency]]), and

← Previous revision		Revision as of 21:37, 29 May 2024
Line 2:		Line 2:
	{{manual\|date=May 2024}}		{{manual\|date=May 2024}}

	In [[computer programming]], a '''pure function''' is a [[Subroutine\|function]] that has the following properties:<ref>{{cite web \|url=https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|title=Basics of Haskell \|author=Bartosz Milewski \|date=2013 \|website=School of Haskell \|publisher=FP Complete \|access-date=2018-07-13 \|archive-url=https://web.archive.org/web/20161027145455/https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|archive-date=2016-10-27 \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/ch03.md \|title=Professor Frisby's Mostly Adequate Guide to Functional Programming \|author=Brian Lonsdorf \|date=2015 \|website=GitHub \|publisher= \|access-date=2020-03-20 }}</ref>~~alexsio nau~~		In [[computer programming]], a '''pure function''' is a [[Subroutine\|function]] that has the following properties:<ref>{{cite web \|url=https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|title=Basics of Haskell \|author=Bartosz Milewski \|date=2013 \|website=School of Haskell \|publisher=FP Complete \|access-date=2018-07-13 \|archive-url=https://web.archive.org/web/20161027145455/https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io \|archive-date=2016-10-27 \|url-status=dead }}</ref><ref>{{cite web \|url=https://github.com/MostlyAdequate/mostly-adequate-guide/blob/master/ch03.md \|title=Professor Frisby's Mostly Adequate Guide to Functional Programming \|author=Brian Lonsdorf \|date=2015 \|website=GitHub \|publisher= \|access-date=2020-03-20 }}</ref>

	# the function [[Return statement\|return values]] are [[Relational operator#Location equality vs. content equality\|identical]] for identical [[Argument of a function\|arguments]] (no variation with local [[static variable]]s, [[non-local variable]]s, mutable [[Value type and reference type\|reference arguments]] or [[Input/output\|input streams]], i.e., [[referential transparency]]), and		# the function [[Return statement\|return values]] are [[Relational operator#Location equality vs. content equality\|identical]] for identical [[Argument of a function\|arguments]] (no variation with local [[static variable]]s, [[non-local variable]]s, mutable [[Value type and reference type\|reference arguments]] or [[Input/output\|input streams]], i.e., [[referential transparency]]), and