Thank you, I should have checked the issues list first.
On Fri, Nov 20, 2015 at 4:13 PM, Milan Bouchet-Valat
wrote:
> Le vendredi 20 novembre 2015 à 04:54 -0800, Michele Zaffalon a écrit :
> > Should `linspace` act as an array for `repeat`?
> Yes, the signature of repeat() is
Le vendredi 20 novembre 2015 à 04:54 -0800, Michele Zaffalon a écrit :
> Should `linspace` act as an array for `repeat`?
Yes, the signature of repeat() is clearly too strict. This has been
discussed at
https://github.com/JuliaLang/julia/issues/12953
There was a clear support for this, but a
Should `linspace` act as an array for `repeat`?
On Wednesday, October 21, 2015 at 10:00:46 PM UTC+2, Art Kuo wrote:
>
> I don't think there is much to argue about, except perhaps names.
>
>1. `linspace` returns a range, but is otherwise a drop-in replacement
>for an array, and should
I *really* wish there was a way to collapse LinSpace and FloatRange into a
single type, but I cannot for the life of me figure out how to do it
without making both of them much slower.
On Tue, Oct 20, 2015 at 11:14 PM, Art Kuo wrote:
> By the way, the original issue has
Call `collect` on them ;)
On Wed, Oct 21, 2015 at 12:43 PM, Stefan Karpinski
wrote:
> I *really* wish there was a way to collapse LinSpace and FloatRange into a
> single type, but I cannot for the life of me figure out how to do it
> without making both of them much
I agree with this downvote so much it hurts. The logspace/linspace is
painfully ugly. linrange is the right name in my find for the iterator
version.
On Wednesday, 30 September 2015 10:31:55 UTC-7, Alex Ames wrote:
>
> Another downvote on linspace returning a range object. It seems odd for
>
I don't think there is much to argue about, except perhaps names.
1. `linspace` returns a range, but is otherwise a drop-in replacement
for an array, and should act as one for any naive user, other than
sometimes being faster and taking less memory. This is not hidden from the
This thread is tragically long on opinions and short on arguments backing
them up. It occurs to me that we can write specialized methods for
collect(::LinSpace) that generate the collected version more efficiently
than generic iteration does, which eliminates one of the potential
arguments for
I think much of the problem is that many necessary packages (e.g. for
plotting) don’t currently allow Range/AbstractVector, and many functions in
Base are slower for ranges than for vectors. These are probably just teething
problems, but until they are resolved “collect” ends up
Sorry to dredge up this issue again but was there any reason for the return
type of linspace to be LinSpace instead of FloatRange. They are seemingly
indistinguishable.
On Friday, October 9, 2015 at 3:31:31 AM UTC-7, Stefan Karpinski wrote:
>
> It's amazing how often the problem is the way
On Tue, Oct 20, 2015 at 9:03 PM, Luke Stagner wrote:
> Sorry to dredge up this issue again but was there any reason for the return
> type of linspace to be LinSpace instead of FloatRange. They are seemingly
> indistinguishable.
Not sure if this si **the** reason but you
On Tuesday, October 20, 2015 at 9:03:52 PM UTC-4, Luke Stagner wrote:
>
> Sorry to dredge up this issue again but was there any reason for the
> return type of linspace to be LinSpace instead of FloatRange. They are
> seemingly indistinguishable.
>
They are not quite the same because of
It's amazing how often the problem is the way something is printed.
On Fri, Oct 9, 2015 at 8:26 AM, Art Kuo wrote:
> Oh, clearly I did not understand show(). I've ported the changes to
> writemime instead, and as a bonus figured out how to automatically format
> for screen
+1, I like the new display a lot.
On Wednesday, October 7, 2015 at 10:53:00 PM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Wednesday, October 7, 2015 at 8:05:19 PM UTC-4, Art Kuo wrote:
>>
>> I've coded up a simple replacement to the show() function for ranges. The
>> idea is to give the user
Oh, clearly I did not understand show(). I've ported the changes to
writemime instead, and as a bonus figured out how to automatically format
for screen width (using Base.print_matrix_row).
Just to recap: There is little or no problem with linspace or range being
an object rather than array as
I know it may feel to the insiders/developers that the requestors are being
a bit dogmatic with expectations from other languages.
2 cautions:
1. Insiders need to be careful not to be defensive: converts are here
because they are fans and evangelists (potentially) in their community.
Gotchas
Note, however, that this "display" output should probably be a method of
writemime(io::IO, ::MIME"text/plain", x). The show(io, x) for ranges
should continue to be the compact output.
On Wednesday, October 7, 2015 at 8:05:19 PM UTC-4, Art Kuo wrote:
>
> I've coded up a simple replacement to the show() function for ranges. The
> idea is to give the user information more likely to be what they are
> wondering. Here are some examples of its output:
>
It looks great to me;
I've coded up a simple replacement to the show() function for ranges. The
idea is to give the user information more likely to be what they are
wondering. Here are some examples of its output:
*julia> **0:4*
*5-element UnitRange{Int64}:*
*0,1,2,3,4*
*julia> **0:10*
*11-element
Just to add my 2 cents:
I posted a question about linspace and collect not too long ago.
Collect wasn't obvious to me at first, and I tried something like linspace
(0, 1, 10)[:] to get the array first.
I only needed it for PyPlot. As long as PyPlot works with whatever linspace
returns, I'm
Ranges check bounds when you index them with x[i], but not when you use `for y
in x`. Someone could submit a PR for the appropriate change in base/ops.jl.
--Tim
On Thursday, October 01, 2015 02:55:25 PM Sheehan Olver wrote:
> The timings seem to be a sign that special functions over ranges are
I think an argument for linspace returning an Array is that it makes
teaching new programmers Julia a lot easier.
If it returns an Array, its sufficient to teach students the Array type. But
if it returns a Range, one has to teach an extra data type before the students
can use it.
On Thursday, October 1, 2015 at 8:37:28 AM UTC-4, Sheehan Olver wrote:
>
>
> I think an argument for linspace returning an Array is that it
> makes teaching new programmers Julia a lot easier.
>
> If it returns an Array, its sufficient to teach students the Array type.
> But if it
On Thursday, October 1, 2015 at 3:49:13 AM UTC-4, Tim Holy wrote:
>
> Ranges check bounds when you index them with x[i], but not when you use
> `for y
> in x`. Someone could submit a PR for the appropriate change in
> base/ops.jl.
See also https://github.com/JuliaLang/julia/issues/13401
On Thu, Oct 01 2015, Sheehan Olver wrote:
> I think an argument for linspace returning an Array is that it makes
> teaching new programmers Julia a lot easier.
>
> If it returns an Array, its sufficient to teach students the Array type.
> But if it returns a
saying "linspace returns a vector" is a lot easier than explaining "linspace
returns a special data type that sometimes acts like a vector, except for when
you try to write to it, etc." since linspace is a basic function in numerical
analysis, it would come up way before trying to introduce
I agree and mostly fall in the camp of keeping the new behaviour.in my
experience trying to attract MATLAB users is a waste of time: the faster code
is in MATLAB the slower it is in Julia, which makes for an awful first
experience. It's also not clear why at this early stage Julia would
I want to add my voice to the dislikers. Those are the type of surprises
that are not welcome mainly for matlab users.
quarta-feira, 30 de Setembro de 2015 às 16:53:57 UTC+1, Christoph Ortner
escreveu:
>
> I also strongly dislike the `linspace` change; I like the idea though of
> having
Another downvote on linspace returning a range object. It seems odd for
linspace and logspace to return different types, and linrange provides the
low-memory option where needed. Numpy's `linspace` also returns an array
object.
I ran into errors when trying to plot a function over a linspace
Le mercredi 30 septembre 2015 à 10:31 -0700, Alex Ames a écrit :
> Another downvote on linspace returning a range object. It seems odd
> for linspace and logspace to return different types, and linrange
> provides the low-memory option where needed. Numpy's `linspace` also
> returns an array
On Wednesday, September 30, 2015 at 1:31:55 PM UTC-4, Alex Ames wrote:\
>
> I ran into errors when trying to plot a function over a linspace of x
> values, since plotting libs currently expect vectors as arguments, not
> range objects. Easily fixed if you know Julia well, but Matlab/Python
>
On Wednesday, September 30, 2015 at 2:51:46 PM UTC-4, Christoph Ortner
wrote:
>
> I, on the other hand, don't understand the obsession with abstraction.
>
> Also, by your argument the following should all be special types rather
> than box-standard arrays.
>
> julia> typeof(ones(10))
>
> I, on the other hand, don't understand the obsession with abstraction.
I guess reasons to use a high-level language differ, which is good. As
long as we don't get too obsessive ;-)
> Also, by your argument the following should all be special types rather
> than box-standard arrays.
>
> julia>
I don't understand this obsession with wanting to store a bunch of
numbers in memory which trivially compress. Even more so as most
numerical computations are memory bound, so storing more stuff is bad.
All the interface functions work with a range (or if not a bug report
should be filed), apart
I, on the other hand, don't understand the obsession with abstraction.
Also, by your argument the following should all be special types rather
than box-standard arrays.
julia> typeof(ones(10))
Array{Float64,1}
julia> typeof(zeros(10))
Array{Float64,1}
julia> typeof(eye(10))
Array{Float64,2}
I wasn't even aware that linspace in Python also gives an array. What about
R? I think some consistency with existing terminology is useful, at the
very least for early adopter.
Since range and array are more or less interchangeable computationally (but
not memory-wise), I suspect the main issue is how a range object should be
reported in the REPL. Julia REPL already tries to be smart about reporting
an array, either listing out all the elements or showing the
Just curious: linspace returns a Range object, but logspace returns a
vector because there is no much use case for a LogRange object?
@feza: I have also seen the deprecation warning going away after a couple
of calls, but I am not sure why. If you restart Julia, the deprecations
reappear.
On
FYI this discussion is in relation to Julia 0.4. Initially I had some
deprecation warnings but they have mostly gone away. I have no real
objection, perhaps it's just a little weird that the repl returns
julia> x
linspace(0.0,10.0,50)
as opposed to printing it out like a full array. Perhaps
My main objection is that changing the behaviour of linspace is superfluous
considering linrange already existed. If the goal was to encourage users to
use a range instead of an array that should of been done through
documentation through something like a best practices section (e.g. Use
On Wednesday, 30 September 2015 20:58:31 UTC+1, Luke Stagner wrote:
>
> My main objection is that changing the behaviour of linspace is
> superfluous considering linrange already existed. If the goal was to
> encourage users to use a range instead of an array that should of been done
>
On Wednesday, September 30, 2015 at 4:01:17 PM UTC-4, Christoph Ortner
wrote:
>
> I simply dislike is that linspace does not behave as expected, and I
> expect that this is the main reason for other as well. To give an extreme
> analogy, we don't go around and start defining A * B = A + B
On Wednesday, 30 September 2015 20:27:02 UTC+1, Matt Bauman wrote:
>
> There can be reasons where a special read-only `Ones` array type is
> beneficial: http://stackoverflow.com/a/30968709/176071. It's just five
> lines of code, and Julia/LLVM is able to optimize it such that
>
On Wed, Sep 30, 2015 at 9:50 AM, Milan Bouchet-Valat
wrote:
> Le mercredi 30 septembre 2015 à 08:55 +0200, Michele Zaffalon a écrit :
> > Just curious: linspace returns a Range object, but logspace returns a
> > vector because there is no much use case for a LogRange object?
>
I just realize that the thread is about 0.3.11 and I am showing output for
0.4.0-rc2. Sorry for the noise.
On Wed, Sep 30, 2015 at 11:17 AM, Michele Zaffalon <
michele.zaffa...@gmail.com> wrote:
>
> On Wed, Sep 30, 2015 at 9:50 AM, Milan Bouchet-Valat
> wrote:
>
>> Le
On Wednesday, 30 September 2015 21:42:33 UTC+1, Steven G. Johnson wrote:
>
>
>
> On Wednesday, September 30, 2015 at 4:01:17 PM UTC-4, Christoph Ortner
> wrote:
>>
>> I simply dislike is that linspace does not behave as expected, and I
>> expect that this is the main reason for other as well.
The timings seem to be a sign that special functions over ranges are not yet
optimized, see variants below using comprehensions that do much better. Note
also that collect uses 2x the memory with only a 30% speedup (or 10% slow down,
if you also count the time to collect).
julia> function
In matlab x = linspace(0,1,n) creates a vector of floats of length n. In
julia it seems like the only way to do this is to use x = collect(
linspace(0,1,n) ) . Is there a nicer syntax? I do mainly numeric computing
and I find this quite common in my code.
Thanks.
I'm curious why you need a vector rather than an object. Do you mutate it
after creating it? Having linspace return an object instead of a vector was
a bit of a unclear judgement call so getting feedback would be good.
On Tuesday, September 29, 2015, Patrick Kofod Mogensen <
Personally I don't like the behaviour. (Perhaps I am just too used to
numpy/matlab convention). Also we already had linrange (although curiously
not logrange) if we wanted to use a range.
On Tuesday, September 29, 2015 at 5:59:52 PM UTC-7, Stefan Karpinski wrote:
>
> I'm curious why you need a
A range should act (for the most part) exactly like an array. For example
indexing into a range is identical (syntax-wise) to indexing an array. What
I am concerned about is performance. For instance if I had a range that has
a large amount of elements would indexing into it be slower then
A range should act (for the most part) exactly like an array. For example
indexing into a range is identical (syntax-wise) to indexing an array. What
I am concerned about is performance. For instance if I had a range that has
a large amount of elements would indexing into it be slower then
Strange it *was* giving me an error saying deprecated and that I should use
collect, but now it's fine.
On Tuesday, September 29, 2015 at 10:28:12 PM UTC-4, Sheehan Olver wrote:
>
> fez, I'm pretty sure the code works fine without the collect: when exp is
> called on linspace it converts it to
For me, I think I just expect a vector from experience, and I could
probably just change the way I work with a little effort.
One exception (I think) is that I often do numerical integration over a
range of values, and I need the results at every value. I'm not sure if
there's a way to do that
On Wednesday, September 30, 2015 at 11:37:44 AM UTC+10, Luke Stagner wrote:
>
> A range should act (for the most part) exactly like an array. For example
> indexing into a range is identical (syntax-wise) to indexing an array. What
> I am concerned about is performance. For instance if I had a
55 matches
Mail list logo