I originally had the length field as an Int, but then you can't make
*really* long LinSpace objects, which is part of why having this being an
object rather than a materialized array is useful anyway. Then I considered
having the length type as a second type parameter, but that's really
annoying. Finally, I realized that since you have to convert the length to
the floating-point type anyway, why not just store it as that type? That's
one less conversion to do on each element computation anyway. So this way
you can, for example, do this:
julia> s = linspace(big(0),big(1),big(2)^100-1)
linspace(0.000000000000000000000000000000000000000000000000000000000000000000000000000000e+00,1.000000000000000000000000000000000000000000000000000000000000000000000000000000,1267650600228229401496703205375)
julia> typeof(s)
LinSpace{Base.MPFR.BigFloat}
julia> length(s)
1267650600228229401496703205375
julia> s[end>>>1]
4.999999999999999999999999999992111390947789881945882714347159691672712213365495e-01
julia> s[end>>>1+1]
5.000000000000000000000000000000000000000000000000000000000000000000000000000000e-01
julia> s[end>>>1+2]
5.000000000000000000000000000007888609052210118054117285652840308327287786634505e-01
On Fri, May 29, 2015 at 11:24 AM, Patrick Kofod Mogensen <
[email protected]> wrote:
> In the definition of the immutable LinSpace, we have start, stop, len, and
> divisor. They are all floating point typed. Why is that? I mean, len is
> supposed to be the number of elements, why wouldn't that be an integer?
>
> - Patrick
>
