Beruflich Dokumente
Kultur Dokumente
What is an Algorithm
An algorithm is an effective method for solving a problem. Algorithms date back to early 300 B.C.
and apply in a wide variety of areas today, ranging from mathematical, physical, astrophysical,
logical, statistical, financial, biological etc.
-
Methodology
ALGORITHM
DATA
OPERATORS
INTERMEDIARY
DATA (OPERANDS)
INFORMATION
OPERATORS
PROCEDURES
PROCEDURES
FUNCTIONS
FUNCTIONS
Systematic Process
1.
2.
3.
4.
Example
Problem: We need to have fresh water readily available in a portable fashion.
-
Intuition tells us that air is lighter than water, so we can simply sink the bottle in the river, and
air will escape from the bottle naturally, allowing the bottle to fill with water. This is more
efficient than the first method because:
-
Can our solution be transformed and scaled up to any liquid, any location on a planet, any water
size, any bottle capacity? Sure.
We have identified, through intuitive reasoning, that this is the optimal solution. We can now tell
a robot to do it:
Robot.extendArm();
For (var I in bottles){
Robot.moveArmTo(Bottle.x, Bottle.y, Bottle.z + bottle.height/2)
Robot.openArm()
Robot.moveArmTo(Bottle.x, Bottle.y, Bottle.z + Bottle.height/2 Robot.arm.height);
Robot.closeArm(); // uses some pressure sensors to find out when arm is in contact with bottle neck
Robot.moveArmTo(Pond.x, Pond.y, 0-(Bottle.height)); // dip bottle in pond
// how much we wait would have to factor in some physics equations, for example we would need to figure out
water density by weighing it, extract mass, factor in gravitational pull, add some tolerances, factor in Bernoulli to take
air compression into account on initial dip etc., check time taken to overcome bottle buoyancy force, maybe factor in
the time taken to extend the arm into the water and back.
// but lets assume it takes 1 second to take out 1 liter of air out of a 10x10x10cm cube
// Bottle.volume is Math.PI * Bottle.diameter * Bottle.height
// if Bottle.height = Bottle.diameter then it takes (Bottle.volume/1000) second
// if Bottle.height is twice the diameter, it takes 2 seconds
// therefore total time required is Bottle.height / Bottle.diameter * (Bottle.volume/1000)
// but the bottle neck also affects our time
// if Bottle.neckDiameter = Bottle.diameter then it takes what it would take normally
// time reduction is inversely proportional but cannot be less than 1
// so final equation is this
Bottle.volume = Math.PI * Bottle.diameter * Bottle.height;
Var timeToFill = (Bottle.height / Bottle.diameter) * (Bottle.volume/1000);
Var bottleNeck = Bottle.diameter / Bottle.neckDiameter;
If(bottleNeck < 1){
bottleNeck = 1;
}
timeToFill = timeToFill * bottleNeck;
Robot.wait(timeToFill);
Robot.moveArmTo(Bottle.originalX, Bottle.originalY, Bottle.originalZ + bottle.height/2);
Robot.openArm()
Robot.moveArmTo(Bottle.originalX, Bottle.originalY, Bottle.originalZ + bottle.height/2 + Robot.arm.height);
}
Robot.parkArm();
// done.
We run the program above and conclude the bottle gets wet on the outside but doesnt fill with
water. Maybe only a few drops.
Can you figure out why? There are two reasons why in the program above.
Truths
-
Comparison
Situation
Approach
Estimates
Prep work
Beginner
- Is either too subjective, or too
objective
- May like or not like the project
based on his limited experience
with other similar projects
- May like or not like the project
based on presumptions about
the people involved in the
project
- Is inconsistent, doesnt know.
- Gets asked when its going to
be ready, gets mood-swingy
because of this; delays
releases; causes failed launches
Engineer
- Is pragmatic
- Doesnt care how interesting the
project is. To him, it is a problem
that can be solved using a
computer through skill
- Knows his team, his customer,
his end-user. Makes
recommendations/assigns tasks
based on this
- Gives both optimistic and
pessimistic estimates, follows-up
after analysis
- Updates regularly, can easily
commit to compromise in the
face of hard deadlines, but does
everything in his power to avoid
compromising
- Utilizes the right tool for the right
job. Is fast with no framework,
faster with time-tested tools,
some likely dating back to the
Starting a
new project
Taking over
a project
Finding a
bug
Solving a
bug
Writing a
feature
Result
Technical
debt
Profitability
Project destruction.
The product is not entirely
valueless, but hard to develop
on, hard to write features, hard
to maintain
Product is on risk to the
company, can turn from an
asset into a liability in time
Speed
Arguably the biggest mistake beginners do is writing code when they shouldnt. As developers,
we want to spend as little time coding as possible, while achieving the highest amount of return
available. We wind our algorithms around universally true situations, and we handle as many
cases as possible if not all, using code that is inherently reusable.
This is immensely preferred, because we want to avoid:
-
Obviousness
In a typical problem, an apparent solution may not be obvious. However, nothing stops a dev
from updating a project Readme from time to time if discovers that a better solution better suits
a task at hand.
Example
$1000
BOX A
$0
BOX A
$1000
$1000
$700