Merge pull request #1203 from Arnaud-de-Grandmaison-ARM/integer-float…

…-conversions

[IG] integer-vs-floats: minor wording fixes.

content/learning-paths/cross-platform/integer-vs-floats/integer-float-conversions.md

@@ -145,7 +145,7 @@ The second type of conversions are called implicit and are harder to track.
 
 When a conversion is not explicitly stated it is called implicit. In general, it's a conversion that the compiler issues when there is an operation involving two (or more) elements of different data types.
 
-In that case, the compiler has to convert one of the values to the same datatype as the other, as most operations require elements of the same size. 
+In that case, the compiler has to convert one of the values to the same datatype as the other, as most operations require elements of the same type.
 
 {{% notice Note %}}
 There are some conversion exceptions, for example, the `SADDW`/`UADDW` Advanced SIMD instructions which add elements of different widths. Such instructions do not require any kind of conversion. 

content/learning-paths/cross-platform/integer-vs-floats/type-demotion-problems.md

@@ -80,7 +80,7 @@ e1 = 2147483647, e2 = 2147483647
 
 Obviously `w` is a huge value and it does not fit in a `float` (remember that the largest positive float is `3.4e+38`), but the compiler only complains about `z` which uses bracket initialization and not `y` which uses assignment. 
 
-Similarly, `d1` an `int16_t` uses assignment and does not generate a warning but `d2`, also an `int16_t`, uses bracket initialization and triggers a compiler warning.
+Similarly `d1`, with type `int16_t`, uses assignment and does not generate a warning but `d2`, also an `int16_t`, uses bracket initialization and triggers a compiler warning.
 
 The same happens with the demotion/conversion of the `double w` to the `int32_t` variables `e1`, `e2`.