Add Numbers concept

[colinleach]

The introduction.md is too long, but we need to pick a concept exercise before deciding what is needed and what can be deleted.

[SleeplessByte]

Yeah probably worth it to move type conversion etc. to separate concept but fine for now.

[SleeplessByte]

It makes sense to quickly explain what 8-64 bits mean and what overflow means. Many languages do NOT have fixed-width numeric types. In Ruby for example, every number is arbitrary precision.

[colinleach]

I've added a paragraph - is this what you wanted?

[colinleach]

Revised and expanded again.

[SleeplessByte]

It's better, but assume someone doesn't know what "number can be x bytes" means. I am a strong opponent to "just" explain this, especially in about.md, but also in introduction.md if it's relevant. We could add above line 16 something like:

In Kotlin, like many strongly types languages, numbers take a fixed amount of space in memory, which also means for each numeric type there is a smallest and largest value that fits.
This is generally expressed in bits or bytes.

For numeric types that can go below and above zero, one bit is reserved to indicate the *sign*.
This effectively cuts the amount of integers that fits in the memory in half, and these are called signed integers.
In contrast, there are also unsigned integers which do not reserve a bit for the sign, doubling the maximum value the memory for that number can hold.

You may want to reword in your own words.

Sidenote: if you feel my or kahgoh's contributions are significant, feel free to add us to the contributors array when you see fit.

[colinleach]

As well as the new section on type size and overflow, I revised the reference codes to conform with your wishes in #712.

[kahgoh]

@colinleach I wasn't quite sure if you meant to remove bits from this introduction as well or just from the exercise's introduction in the comment (ignore this if you meant just from the exercise introduction), but if you're looking for something to cut or separate out, the Cars Assemble exercise dosen't cover rounding and the use of the math library.

[colinleach]

If you make a cut-down version in the exercise, I'll wait till that is merged then copy it back to the concept. Probably easier than trying to keep them in sync as yours goes through review and editing.

[colinleach]

I'm not sure what to do about the math library. I covered rounding here because some other tracks do (with an exercise that needs it such as python/currency-exchange). If this was a more mathy track (like Julia or R), a separate math concept might be appropriate - probably not for Kotlin.

I think I'll leave it in the About for now. If any of the later exercises need rounding, we can move this section to there.

[SleeplessByte]

Leave it in about, we can remove from introduction as we build the track out. Moving content between concepts is far easier than adding new content!

[kahgoh]

Isn't this true for any arithmetic operator in Kotlin? For example 3 + 2.0 will give 5.0 and 3 * 2.0 gives 6.0 (both results are doubles).

[colinleach]

True. However, only integer division causes large rounding errors. I'll try to make the wording clearer.

[colinleach]

To get a floating point result, at least one of the numbers in the calculation must be floating point. This is particularly significant for division, as integer division often leads to truncation.

Is this better?

[kahgoh]

I was wondering if it's worth explaining that Kotlin works out the result number types in the calculations. I'll try suggest something in a separate comment.

[SleeplessByte]

It's better, but assume someone doesn't know what "number can be x bytes" means. I am a strong opponent to "just" explain this, especially in about.md, but also in introduction.md if it's relevant. We could add above line 16 something like:

In Kotlin, like many strongly types languages, numbers take a fixed amount of space in memory, which also means for each numeric type there is a smallest and largest value that fits.
This is generally expressed in bits or bytes.

For numeric types that can go below and above zero, one bit is reserved to indicate the *sign*.
This effectively cuts the amount of integers that fits in the memory in half, and these are called signed integers.
In contrast, there are also unsigned integers which do not reserve a bit for the sign, doubling the maximum value the memory for that number can hold.

You may want to reword in your own words.

Sidenote: if you feel my or kahgoh's contributions are significant, feel free to add us to the contributors array when you see fit.

[SleeplessByte]

Suggested change

	4 / 3 // => 1 Int / Int always gives an Int
	-8 / 3 // => -2 Truncated towards zero
	-8.0 / 3 // => -2.6666666666666665
	12 / 4 => 3
	```
	When dividing an integer (for example an Int) by another integer (for example an Int), the result will also be an integer (in this case an Int):
	```kotlin
	4 / 3 // => 1 Int / Int always gives an Int
	-8 / 3 // => -2 Truncated towards zero
	```

[SleeplessByte]

Suggested change

	To get a floating point result, at least one of the numbers in the calculation must be floating point.
	This is particularly significant for division, as integer division often leads to truncation.
	To get a floating point result, at least one of the numbers in the calculation must be floating point (ie. a Float or a Double).
	This is particularly significant for division, as integer division often leads to truncation.
	```kotlin
	-8.0 / 3 // => -2.6666666666666665
	-8 / 3.0 // => -2.6666666666666665
	-8.0 / 3.0 // => -2.6666666666666665
	```

[SleeplessByte]

Maybe also add the Kotlin does not support arbitrary precision arithmetic in its standard library, so a userland solution is necessary for BigInteger and BigDecimal support?

It just doesn't exist for multiplatform, but does exist for JVM...