This is interesting thanks. I didn't realise you could re-assign j inside
the index like that. A very neat notational trick. But I agree that looking
forward the filter! option is probably best. I'll adjust my code
accordingly, many thanks.
As an aside, every time I post code to this list I get
Yep. Agreed. Totally redundant :-)
Cheers,
Colin
On 4 June 2016 at 05:11, DNF wrote:
> Your in-method is a bit odd:
>
> Base.in{T}(x::T, r::BasicInterval{T}) = (r.start <= x <= r.stop) ? true :
> false
>
> Why don't you just write
>
> Base.in{T}(x::T, r::BasicInterval{T}) =
On Thursday, June 2, 2016 at 11:42:32 PM UTC-4, colint...@gmail.com wrote:
>
> function Base.filter!{T}(x::AbstractVector{T}, r::BasicInterval{T})
> for n = length(x):-1:1
> !in(x[n], r) && deleteat!(x, n)
> end
> return(x)
> end
>
I'm pretty sure this implementation has
Your in-method is a bit odd:
Base.in{T}(x::T, r::BasicInterval{T}) = (r.start <= x <= r.stop) ? true :
false
Why don't you just write
Base.in{T}(x::T, r::BasicInterval{T}) = (r.start <= x <= r.stop)
?
The extra stuff is redundant.
Very true. For boring reasons, I actually prefer it that way for my own
work (I want errors if the types don't exactly match as it means other
parts of my code are doing something unexpected - I like cheap redundant
error checks). But I agree that for general use it should work as you
suggest.
Looks ok, but I think you could generically have less restricted types in your
functions: e.g.
4 in BasicInterval(3.1,4.9)
won't work, nor will you be able to construct an interval BasicInterval(3,4.5)
For those interested, I just hacked together the following implementation
of what I was after. I've extended in, filter, and replace to the new type:
#Type BasicInterval
#My own extremely simple interval type that denotes all elements between
start and stop
immutable BasicInterval{T}