MATEMATIKA DISKRIT

PENERAPAN RELASI DAN FUNGSI DALAM IT

Dosen Pengampu :
Irma Wulandari, S.Si., M.Sc.

Disusun oleh :
1. Ahmad Ilham Santosa
2. Dhani Fajar Nugroho
3. Audy Istania Narita
4. Geluh Tanaya Bestari
5. Made Rahano Satriyani Widhi

TEKNIK INFORMATIKA
POLITEKNIK ELEKTRONIKA NEGERI SURABAYA
2019
In programming, a named section of a program that performs a specific task. In this sense, a
function is a type of procedure or routine. Some programming languages make a distinction
between a function, which returns a value, and a procedure, which performs some operation
but does not return a value.

Most programming languages come with a prewritten set of functions that are kept in a
library. You can also write your own functions to perform specialized tasks.

(2) The term function is also used synonymously with operation and command. For example,
you execute the delete function to erase a word.

Functions (maps)

Mathematical functions transform inputs to outputs.

The set of functions from the set A into the set B is the set A → B.

Under the interpretation of (→) as an operator on sets, the signature:

f:X→Y

can be interpreted as the function f is a member of the set X → Y:

f∈X→Y

In mathematical notation, there are several extant notations for application:

f(x) = f x = f.x

All of these are the application of the function f to the value x.

In code, functions can translate into procedures and methods, but if they're finite, they can
also translate into finite maps backed by hash tables or sorted, balanced tree maps.

Fuctions as code

Most of the time a mathematical function will map into a procedure in the underlying
language.

When a function is supposed to map into executable code, it's usually straightforward to
make the mapping using the data structures and algorithms presented elsewhere in this guide.
Functions as maps

In some cases, mathematicians use functions as the formal analog of a hash table or a
dictionary. For example:

f[x ↦ y]

represents a function identical to f except that x maps to y.

Please note that extending a function like this does not (and cannot) change the original
function f!

Immutable red-black tree map are a great data structure for representing these finite functions
meant to be extended.

Once again, it is not safe to use the mutable sorted maps and hash tables provided by the Java
library, or the mutable dictionaries provided by Python.

Haskell provides the Data.Map library for this purpose, and Racket also offers immutable
hash maps.

Sometimes, it is acceptable to hijack the native notion of functions to get them to act like
immutable dictionaries. For instance, in Python, we can define extend:

def extend (f, x, y):

return lambda xx: y if xx == x else f(xx)

def empty(x): raise Exception("No such input")

so that the following works:

g = extend(extend(empty, 3, 4), 5, 6)

print(g(3)) # prints 4
print(g(5)) # prints 6

The disadvantage of taking over the internal notion of function like this is that one cannot
enumerate the contents of the function, as with a hash or tree-backed formulation.

Immutable maps atop mutable structures

If a language already provides a good native map-like structure (like Python's dictionaries),
then it is possible to exploit this structure through shallow copies every time the map is
extended:

class DictMap:

def __init__(self, contents):

self.contents = contents

def extend(self,x,y):
contents_ = copy.copy(self.contents)
 contents_[x] = y
return DictMap(contents_)

def __call__(self,x):
return self.contents[x]

Relations

Structurally, a relation R is a (possibly infinite) set of subset of some Cartesian product.

The set of all relations over A × B is P(A × B).

Computational encodings of relations center around understanding relations in terms of other

data structures.

In the special case where a relation relates elements of the same set, e.g. R ⊆ A × A, then R
defines a directed graph over nodes in A.

Given a relation R, the notation:

R(x1,...,xn)

is equivalent to:

(x1,...,xn) ∈ R.

There are three common ways to encode a relation computationally: as a collection, as a

function and as a predicate.

Relations as collections

Structurally, a relation is a set of tuples, and for finite relations, an encoding as a set of tuples
is reasonable.

Relations as functions

Given a relation R ⊆ A × B, the following congruences allow a relation to be represented as a

function:

P(A × B) ≅ A → P(B).

This functional encoding of a relation is particularly popular for implementing the transition
relation of abstract machines, which relates a machine state to all of its possible successors.

Relations as predicates

If one only needs to know whether or not some tuple is within the relation, then it is
frequently most efficient to encode the relation as a predicate.
This view is supported by another congruence:

P(A × B) ≅ A × B → {true,false}

Why

The first reason is reusability. Once a function is defined, it can be used over and over and
over again. You can invoke the same function many times in your program, which saves you
work. Imagine what programming would be like if you had to teach the computer about sines
every time you needed to find the sine of an angle! You'd never get your program finished!

Another aspect of reusability is that a single function can be used in several different (and
separate) programs. When you need to write a new program, you can go back to your old
programs, find the functions you need, and reuse those functions in your new program. You
can also reuse functions that somebody else has written for you, such as the sine and cosine
functions.

The second reason is abstraction. In order to use a particular function you need to know the
following things:

1. The name of the function;

2. What the function does;
3. What arguments you must give to the function; and
4. What kind of result the function returns.

But notice: If you just want to use the function in your program, you don't have to know how
it works inside! You don't have to understand anything about what goes on inside the
function.

It's sort of like driving a car or using a telephone. With an automobile, you don't need to
understand every detail about the engine and drive train and wheels, if all you want to do is
drive the car. Similarly, with a telephone, you don't have to understand everything about the
phone system in order to make a call.

The only time you need to know how a function works inside is when you need to write the
function, or change how it works. (It's like a car again; you need to know how a car works in
order to build one or fix one.) But once a function is written and working, you never need to
look at its insides again.

Together, these two reasons make functions extremely useful--practically essential!-for

programmers who write large programs. The ability to divide a program into abstract,
reusable pieces is what makes it possible to write large programs that actually work right.