# The type of a range step, defined as Float32, changes to Float64
**URL:** https://discourse.julialang.org/t/the-type-of-a-range-step-defined-as-float32-changes-to-float64/27411
**Category:** New to Julia
**Created:** [August 11, 2019, 11:27am UTC](https://discourse.julialang.org/t/the-type-of-a-range-step-defined-as-float32-changes-to-float64/27411 "2019-08-11T11:27:49Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@fedoroff](https://discourse.julialang.org/u/fedoroff)
#### Post date: [August 11, 2019, 11:27am UTC](https://discourse.julialang.org/t/the-type-of-a-range-step-defined-as-float32-changes-to-float64/27411/1 "2019-08-11T11:27:49Z")
I wonder why in the following example the type of the range step becomes Float64 while originally it was defined as Float32:
```julia
julia> x = range(1f0, 10f0, step=0.1f0)
1.0f0:0.1f0:10.0f0
julia> x.step
0.1
julia> typeof(x.step)
Float64
```
I guess, as a result of such behavior, sometimes I see failures (related to the type stabiity) when I try to use ranges inside CUDAnative kernels.
Thank you.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [August 11, 2019, 11:54am UTC](https://discourse.julialang.org/t/the-type-of-a-range-step-defined-as-float32-changes-to-float64/27411/2 "2019-08-11T11:54:04Z")
I don’t know the answer to your question. This will do what you want, though.
```julia
function range32(start; stop, step)
res = range(Float32(start), stop=Float32(stop), step=Float32(step))
return StepRangeLen{Float32,Float32,Float32}(res)
end
function range32(start; stop, length)
res = range(Float32(start), stop=Float32(stop), length=length)
return StepRangeLen{Float32,Float32,Float32}(res)
end
```
---
### Author:  [@simeonschaub](https://discourse.julialang.org/u/simeonschaub)
#### Post date: [August 11, 2019, 12:04pm UTC](https://discourse.julialang.org/t/the-type-of-a-range-step-defined-as-float32-changes-to-float64/27411/3 "2019-08-11T12:04:29Z")
I think I encountered something similar before. I believe that `range` internally uses double the precision in order to compensate loss of precision due to floating point error. Maybe in your case it might make sense to just collect this into an array or it might be better to try and use an integer range and scale it by a float.
---
### Author:  [@fedoroff](https://discourse.julialang.org/u/fedoroff)
#### Post date: [August 12, 2019, 7:03pm UTC](https://discourse.julialang.org/t/the-type-of-a-range-step-defined-as-float32-changes-to-float64/27411/4 "2019-08-12T19:03:25Z")
Thank you for the suggestions and advise.
---
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [August 12, 2019, 7:14pm UTC](https://discourse.julialang.org/t/the-type-of-a-range-step-defined-as-float32-changes-to-float64/27411/5 "2019-08-12T19:14:13Z")
From the documentation:
```julia
StepRangeLen{T,R,S}(ref::R, step::S, len, [offset=1]) where {T,R,S}
StepRangeLen( ref::R, step::S, len, [offset=1]) where { R,S}
A range `r` where `r[i]` produces values of type `T` (in the second
form, `T` is deduced automatically), parameterized by a `ref`erence
value, a `step`, and the `len`gth. By default `ref` is the starting
value `r[1]`, but alternatively you can supply it as the value of
`r[offset]` for some other index `1 <= offset <= len`. In conjunction
with `TwicePrecision` this can be used to implement ranges that are
free of roundoff error.
```
so it seems that, for whatever reason, the way this is implemented, `step` is in no way guaranteed to be stored as the same type which you gave it is an argument, but the iterable return values _are_ guaranteed to give you a `Float32` in your case.
I suspect they did this because of rounding error.