-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
various LinSpace-related changes #17408
Conversation
StefanKarpinski
commented
Jul 14, 2016
•
edited
Loading
edited
- LinSpace: print vertically like Vectors
- do something about linspace(...)[1] can differ from linspace start value #14420
It's not clear to me why you would want to print a linspace (or, perhaps, a vector) vertically? Our screens tend to have more horizontal than vertical space, much of which is wasted. |
Because it's different than everything else. We print vectors vertically and this is a type of vector. Printing this one thing horizontally is bizarrely inconsistent. We should either print linspaces like other vectors or print it in input form like other ranges. |
Of course, the other issue is that given #14420, we should possibly just get rid of LinSpace altogether and just return a vector like we used to. |
The reason for printing vectors vertically is that vectors correspond to columns of matrices. We used to print vectors horizontally and it was a source of constant confusion for people. Since we started printing vectors vertically, that confusion has vanished. |
Fair point. Could there be an IOContext - ish way to have this (column versus row printing) be user controllable? |
Whatever multiline is called now could maybe be responsible for this? We could also deprecate the |
I don't think we should get rid of immutable NewLinSpace{T} <: OrdinalRange{T,T}
start::T
stop::T
len::Int
leninv::Float64
NewLinSpace(start,stop,len) = new(start,stop,len,1/(len-1))
end
function NewLinSpace(start, stop, len::Integer)
T = typeof((stop-start)*(1/(Int(len)-1)))
NewLinSpace{T}(start, stop, len)
end
Base.step(r::NewLinSpace) = (last(r)-first(r))/(r.len-1)
Base.length(r::NewLinSpace) = r.len
Base.:-(r::NewLinSpace) = NewLinSpace(-r.stop, -r.start, r.len)
Base.getindex(r::NewLinSpace, i::Integer) = first(r)*((length(r)-i)*r.leninv) + last(r)*((i-1)*r.leninv) Reasons:
Obviously, we could have this in a package instead, and perhaps that is a reason to get rid of it from Base. But we shouldn't tuck it in |
LinSpaces.jl then? could easily have many different variations within a package, allowing users to choose what features are or are not important to them as opposed to trying to pick something one-size-fits-all for base. |
I'm with @timholy in thinking that |
it's pretty rarely used within base, and any adjustments to functionality would be far more flexible and less constrained by the release schedule of the language if it weren't defined here. |
Oh man having to do a |
The obvious middle ground is to keep |
Just to make sure I understand the point, in terms of ulp-level behavior this allows you to both guarantee that first and last points are preserved and do fancy stuff in the middle, right? (An alternative is to add |
Yep, that's about the extent of it. |
I'd be fine with that. |
Would love it if the fancy read-your-mind stuff is restricted to |
Yes, it doesn't make much sense for non-floats. |
The other middle ground would be to try out some kind of standard library idea. Have a LinSpace.jl which defines a whole bunch of fancy LinSpace types / functions, and have it auto-installed and auto-imported (for example, by default adding |
I use I would also be very unhappy if it was changed to returning an ordinary vector. The current I wouldn't have minded a different name, though. |
Check out the discussion at JuliaMath/Grids.jl#3. Instead of LinSpace.jl, I called it Grids.jl since linspace is essentially for making 1D grids, and I think the issue is more about having good set of lightweight types/tools for these problems (including meshgrid and ndgrid which have been ignored in Base). For large grids, especially when nD, it's simply not possible to fit the whole array in memory, so some kind of standard tooling for this is necessary. |