On Mon, Sep 29, 2014 at 6:25 PM, Art Kuo wrote:
> I am interpreting this to mean that LLVM can't optimize as well if it
> doesn't know the size of the array. I would be tempted to say that arrays
> should ideally be kept fast when people aren't resizing, but nevertheless
> allow resizing with per
I think the point is this: rather than implementing it for arrays, with the
risk of performance problems that Stefan highlighted, why not implement it for
array views? If we do it through views (which don't modify the underlying
memory), we can give users this behavior and guarantee that we won'
I am interpreting this to mean that LLVM can't optimize as well if it
doesn't know the size of the array. I would be tempted to say that arrays
should ideally be kept fast when people aren't resizing, but nevertheless
allow resizing with perhaps a sizable performance penalty when it is used.
As
An important but non-obvious consideration is that resizeability of arrays
makes it much harder to eliminate bounds checks. As it is, there are cases
where code for vectors is slower than code for arrays with any other
dimensionality because only vectors can change size. Adding this one feature
On Monday, September 29, 2014 10:00:28 AM Art Kuo wrote:
> Third, consider
> implementing A[:, ![3,5]] if possible.
We're now very close to having this be possible. See #8501.
--Tim
For operations that require lots of additions/deletions of rows from
matrices, perhaps we should have something like ChainedVectors.
https://github.com/tanmaykm/ChainedVectors.jl
I don't know how important it is to put in all that effort into a data
structure that supports this effectively, and
I would like to revive this discussion. I understand that it's not terribly
efficient to add/delete a row from a matrix, but this is a case where some
syntactic sugar could really help. Here are a couple arguments for it.
1. Control systems people use this feature in Matlab a lot. This is a
You are correct. That's essentially what I'm doing ATM. That particular
step has never been a bottle-neck in any of my Matlab code. Doing things in
place in nice when you can, but I'm not going to ruminate over it too much.
On Wednesday, February 12, 2014 4:45:36 PM UTC-5, Steven G. Johnson wrot
On Wednesday, February 12, 2014 3:41:21 PM UTC-5, Jason Pries wrote:
>
> FWIW, The place I use this the most is when solving PDEs using finite
> elements with Dirichlet/Periodic boundary conditions. If I want to preserve
> the symmetry of the matrix before factorization, I end up needing to del
Interesting. Now that's a compelling use case.
On Wed, Feb 12, 2014 at 3:41 PM, Jason Pries wrote:
> FWIW, The place I use this the most is when solving PDEs using finite
> elements with Dirichlet/Periodic boundary conditions. If I want to preserve
> the symmetry of the matrix before factorizat
FWIW, The place I use this the most is when solving PDEs using finite
elements with Dirichlet/Periodic boundary conditions. If I want to preserve
the symmetry of the matrix before factorization, I end up needing to delete
some rows and columns. I could write the code to create the matrix the way
The reason for "special cases" is that arrays in Julia really serve two
very different purposes: a highly flexible array/stack/dequeue data
structure and tensors of arbitrary dimension for linear algebra. The
array/stack/dequeue use case requires the ability to grow and shrink and
remove elements f
I'm sure you know this, but I think you are failing to acknowledge in this
discussion is that everything is a tradeoff when dealing with memory
representations of tensors. The reality is always going to be that the
machine organizes everything internally one way, and languages paper over
that t
On Wednesday, February 12, 2014 8:32:42 AM UTC-8, Stefan Karpinski wrote:
>
> On Wed, Feb 12, 2014 at 3:28 AM, Don Gateley
> > wrote:
>
>> Nonsense.
>>
>
> It would be much more helpful (not to mention polite) to make an actual
> counter argument. Given a convincing argument for a feature like
On Wed, Feb 12, 2014 at 3:28 AM, Don Gateley wrote:
> Nonsense.
>
It would be much more helpful (not to mention polite) to make an actual
counter argument. Given a convincing argument for a feature like this, it
may very well get implemented and included in the language. Given
"Nonsense", I for
Hello colleagues,
i couldn't track down, where the Nonsense applies, but in general (also in
Matlab) it's better for organizing the data in a fixed array and track
down, what you access from that. This helps the computer/language system.
However, it's not fully uncommon to formulate algorithms
Nonsense.
On Tue, Feb 11, 2014 at 6:54 PM, Stefan Karpinski wrote:
> It could be made to work but it's generally not a good idea to delete
> random slices of arrays generally isn't a good idea for performance
> reasons. It's better to design an algorithm that doesn't need to do this.
>
>
> On Tu
It could be made to work but it's generally not a good idea to delete
random slices of arrays generally isn't a good idea for performance
reasons. It's better to design an algorithm that doesn't need to do this.
On Tue, Feb 11, 2014 at 9:06 PM, Kevin Squire wrote:
> This thread has a few more de
This thread has a few more details on why deleting from the middle of an
array isn't easy:
https://groups.google.com/forum/#!topic/julia-users/B4OUYPFM5L8
Kevin
On Tuesday, February 11, 2014 4:55:02 PM UTC-8, Kevin Squire wrote:
>
> On Tue, Feb 11, 2014 at 4:45 PM, Steven G. Johnson
> wrote:
>
On Tue, Feb 11, 2014 at 4:45 PM, Steven G. Johnson wrote:
> On Friday, November 30, 2012 7:46:46 AM UTC-5, Stefan Karpinski wrote:
>>
>> To clarify [1 2 3] is a row-matrix, rather than a vector and cannot have
>> an element excised from it.
>
>
> You could delete by reshaping to a column (1d) vect
On Friday, November 30, 2012 7:46:46 AM UTC-5, Stefan Karpinski wrote:
>
> To clarify [1 2 3] is a row-matrix, rather than a vector and cannot have
> an element excised from it.
You could delete by reshaping to a column (1d) vector, deleting, and then
reshaping back. Since the reshaping chea
On Friday, November 30, 2012 4:46:46 AM UTC-8, Stefan Karpinski wrote:
>
> To clarify [1 2 3] is a row-matrix, rather than a vector and cannot have
> an element excised from it.
>
>
Is that an architectural problem or just implementation lag?
On Mon, Feb 10, 2014 at 10:45 AM, Steven G. Johnson
wrote:
> On Monday, February 10, 2014 1:42:56 PM UTC-5, Steven G. Johnson wrote:
>>
>> On Thursday, November 29, 2012 3:24:50 PM UTC-5, Jeff Bezanson wrote:
>>>
>>> We have del(x, i) and del(x, i:j). We could add del(x, I) where I is a
>>> vector
On Monday, February 10, 2014 1:42:56 PM UTC-5, Steven G. Johnson wrote:
>
>
>
> On Thursday, November 29, 2012 3:24:50 PM UTC-5, Jeff Bezanson wrote:
>>
>> We have del(x, i) and del(x, i:j). We could add del(x, I) where I is a
>> vector, but we can't do it any faster than
>> for i in I del(x,i)
On Thursday, November 29, 2012 3:24:50 PM UTC-5, Jeff Bezanson wrote:
>
> We have del(x, i) and del(x, i:j). We could add del(x, I) where I is a
> vector, but we can't do it any faster than
> for i in I del(x,i) end
Why can't it be done faster? Presumably you could move all of the
non-delete
On Sunday, February 09, 2014 09:22:55 PM Jason Pries wrote:
> but this isn't ideal since (I assume) it involves allocating
> additional memory for A[!I,!J] as an intermediate step.
In Matlab, it allocates new memory for the array, too:
>> format debug
>> A = zeros(5,3)
A =
Structure address =
I ran into this same problem recently as well. This is a hard Matlab habit
to break and none of the solutions is intuitive. My solution involves
preallocating a boolean array and then looping through the actual data
checking which values I need to keep. At the end I use the boolean array to
fil
I recently ran into this issue. For future reference, this functionality
seems to have been renamed to splice!
julia> x = [1,2,3]
3-element Array{Int64,1}:
1
2
3
julia> splice!(x,2)
2
julia> x
2-element Array{Int64,1}:
1
3
I use the idiom A(I,:) = []; A(:,J) = []; a lot in Mat
28 matches
Mail list logo
