Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Update euclidean.md with all the go imports
  • Loading branch information
chin123 authored Jun 29, 2018
commit 13dd643ad61540506365f5e7e6b308d6df1c024c
7 changes: 6 additions & 1 deletion chapters/euclidean_algorithm/euclidean.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ The algorithm is a simple way to find the *greatest common divisor* (GCD) of two
{% sample lang="java" %}
[import:9-22, lang="java"](code/java/euclidean_example.java)
{% sample lang="go" %}
[import:7-38, lang="go"](code/go/euclidean.go)
[import:25-38, lang="go"](code/go/euclidean.go)
{% endmethod %}

Here, we simply line the two numbers up every step and subtract the lower value from the higher one every timestep. Once the two values are equal, we call that value the greatest common divisor. A graph of `a` and `b` as they change every step would look something like this:
Expand Down Expand Up @@ -58,6 +58,8 @@ Modern implementations, though, often use the modulus operator (%) like so
[import:3-7, lang="ocaml"](code/ocaml/euclidean_example.ml)
{% sample lang="java" %}
[import:24-35, lang="java"](code/java/euclidean_example.java)
{% sample lang="go" %}
[import:14-23, lang="go"](code/go/euclidean.go)
{% endmethod %}

Here, we set `b` to be the remainder of `a%b` and `a` to be whatever `b` was last timestep. Because of how the modulus operator works, this will provide the same information as the subtraction-based implementation, but when we show `a` and `b` as they change with time, we can see that it might take many fewer steps:
Expand Down Expand Up @@ -104,6 +106,9 @@ Program.cs
{% sample lang="java" %}
### Java
[import, lang="java"](code/java/euclidean_example.java)
{% sample lang="go" %}
### Go
[import, lang="go"](code/go/euclidean.go)
{% endmethod %}


Expand Down