linspace: try to "lift" linspace the float ranges are [close #9637]

[StefanKarpinski]

No description provided.

[JeffBezanson]

Is there any way to have [linrange(...)] do this, so we don't need as many functions?

[StefanKarpinski]

Not quite – the lifted cases are the same, but the unlifted cases are different: ranges use start + k*step whereas linspace uses start*(n-k)/n + stop*k/n.

[StefanKarpinski]

This now seems to be uniformly better than what we had before – the tests are pretty comprehensive. There are still some corner cases like this:

julia> linspace(realmin(),realmax(),maxintfloat())
linspace(0.0,1.7976931348623157e308,9007199254740992)

Note that the start of the resulting LinSpace object is exactly zero, rather than realmin(). I don't actually think that can be fixed, however, without adding significant complexity to the implementation. I'm not sure if we should throw an error upon construction of such a linear space object or not.

[tkelman]

looks like there's a 32 bit failure

[timholy]

What should the policy be for these?

julia> [0.0,0.5,1.0] == linspace(0.0, 1.0, 3)
false

julia> convert(Vector, linspace(0.0, 1.0, 3))
ERROR: MethodError: `convert` has no method matching convert(::Type{Array{T,1}}, ::LinSpace{Float64})
This may have arisen from a call to the constructor Array{T,1}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  convert{T}(::Type{T}, ::T)
  convert{T<:Integer}(::Type{T<:Integer}, ::Rational{T<:Integer})
  convert{T<:Integer}(::Type{T<:Integer}, ::Float16)
  ...

[timholy]

Bump @StefanKarpinski

[StefanKarpinski]

So we have the same issue with FloatRanges:

julia> [0.0,0.5,1.0] == 0:0.5:1
false

julia> convert(Vector, 0:0.5:1)
ERROR: MethodError: `convert` has no method matching convert(::Type{Array{T,1}}, ::FloatRange{Float64})
This may have arisen from a call to the constructor Array{T,1}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  convert{T}(::Type{T}, ::T)
  convert{T<:Tuple{Any,Vararg{Any}}}(::Type{T<:Tuple{Any,Vararg{Any}}}, ::Tuple{Any,Vararg{Any}})
  convert{T<:Integer}(::Type{T<:Integer}, ::Rational{T<:Integer})
  ...

[StefanKarpinski]

Which doesn't really answer the question, but at least it's consistent. The same answer should apply.

[timholy]

convert(Vector{Float64}, obj) works but not convert(Vector, obj)---is this deliberate? Can we add convert{T}(::Type{Vector}, r::LinSpace{T}) = convert(Vector{T}, r)?

[BobPortmann]

Shouldn't this have become a new version of linrange (and LinRange) instead of linspace (and LinSpace) since it returns a range object. Then linspace would be removed?

[StefanKarpinski]

Linspace is the traditional name for this kind of functionality.

[BobPortmann]

OK, I'll take your word for it. I've never run across the name in many years using Fortran and IDL and a bit of Mathematica and R. Julia was the first place I saw it.

[StefanKarpinski]

It's from Matlab

[StefanKarpinski]

I'd be fine with renaming it to linrange, but I'd like some input from others before doing that. Any opinions?

[nalimilan]

Since you made it return a range-like object, it makes sense to me to rename it to linrange. (Coming from R, I admit linspace was not familiar to me either -- but nor was linrange of course :-).

[sebastiang]

So now linspace returns a cleverer object, but if people are expecting it to be an array as once it was, what should they do now? I'm running into this trying to fix Gadfly issues with v0.4

[StefanKarpinski]

An obvious solution is to do collect(linspace(start, stop, len)). What's the specific issue you're encountering?

[sebastiang]

A call to distinguishable_colors in Gadfly assumes linspace will match the ::Vector constraint required, as do apparently the default values provided in the library. To be honest it looks like the constraints could be lifted from distinguishable_colors itself and the code would work correctly, but you hate to dig too deep.

function distinguishable_colors{T<:ColorValue}(n::Integer,
                        seed::Vector{T};
                        transform::Function = identity,
                        lchoices::Vector = linspace(0, 100, 15),
                        cchoices::Vector = linspace(0, 100, 15),
                        hchoices::Vector = linspace(0, 340, 20))

[mbauman]

I'd just change it to be an AbstractVector, but you're right that it probably doesn't need to be typed at all.

(This is an impressive tour d'packages that you've embarked upon! Very nice work. 👍 )

[StefanKarpinski]

Note that if we have automatic conversion of default arguments to the type of the argument then this wouldn't be a problem at all since the LinSpace object would be automatically converted to Vector. Between this and the Nullable argument, I really think the evidence that automatic conversion is the right thing to do is piling up.

[sebastiang]

You've seen a lot more than I have, but it seems odd to have conversion for some arguments and not others. The type magic is already pretty daunting as it is.

[StefanKarpinski]

There's no magic, it would just mean that f(x::T=d) implicitly calls convert(T,d) for you.

[sebastiang]

Ah, not for callers, just for the guy who writes the default value into his function definition.

[quinnj]

I think it makes a lot of sense as well @StefanKarpinski; particularly as we've made the push to have convert(T,x) be as conservative as possible and throw errors if something doesn't convert cleanly.