I posted an answer to this a year ago on Stack
Overflow: http://stackoverflow.com/a/32148113/176071
The internal implementation of the method caches has since changed, but the
concepts should still apply. If I remember right, Stefan's remarks were
about the addition of triangular subtyping,
You can also express this as a two-dimensional index:
@view x[[1:3 4:6]]
# or
@view x[reshape(1:6, 2,3)]
In this case, though, the reshaped view should a bit more performant.
On Monday, October 3, 2016 at 10:33:34 AM UTC-5, Alexey Cherkaev wrote:
>
> Ah, of course! reshape the view! Sometimes
It's pretty close. In Julia 0.5, we have all the parts that are required to
make this a possibility. We have index types that specify both how many
indices in the source array should be consumed (CartesianIndex{N} spans N
dimensions) and types that determine what the dimensionality of the
I cannot reproduce that error, and I know that the lead author of Images
uses stacked image arrays quite frequently.
julia> using TestImages, Images
src = testimage("mandrill")
arr = convert(Array{ColorTypes.Gray{FixedPointNumbers.UFixed{UInt8,8
}},2}, src)
cat(3, arr, arr)
You could implement:
Base.getindex(U::UniformScaling, I::AbstractArray, j::Int) = [U[i,j] for i
in I]
Base.getindex(U::UniformScaling, i::Int, J::AbstractArray) = [U[i,j] for j
in J]
Base.getindex(U::UniformScaling, I::AbstractArray, J::AbstractArray) = [U[i,
j] for i in I, j in J]
Then:
Even simpler: use the built-in `randperm(n)`. You can even use the `end`
keyword within the indexing expression as a shorthand for the dimension's
length:
julia> A = rand(1:100, 5, 3)
5×3 Array{Int64,2}:
15 57 20
74 92 100
17 89 31
82 12 29
93 9 66
julia> A[randperm(end),
Constructing expressions with strings for a generated function is
definitely much more complicated and harder to read. And it'll almost
certainly take more resources and time during compilation.
You'll probably also be very interested in Base.Cartesian. See the
developer documentation
here:
See
http://stackoverflow.com/questions/21152051/difference-between-nx1-array-and-n-element-array-in-julia/
In your example, sometimes returning a matrix and sometimes returning a
vector from rand(5, x) would be similarly type-unstable. More than that,
though: the logical conclusion of this
Just as a small addendum to Erik's excellent answer:
One way to think about zero-dimensional arrays is by analogy with geometry.
Matrices are like planes, vectors are like lines, and zero-dimensional
arrays are like points. Points don't have any dimensions or lengths, but
they still describe
So, if I understand correctly, the problem you're trying to solve is that
A[end] lowers to getindex(A, endof(A)), but you want to know that the index
is the last one since you can implement a more efficient algorithm in that
case.
Making getindex a macro won't solve this problem, so lets set
There's Base.isidentifier. Be aware that it's not documented or exported,
though.
julia> Base.isidentifier("1gh")
false
julia> Base.isidentifier("a_b1")
true
On Monday, May 23, 2016 at 3:17:55 PM UTC-4, vav...@uwaterloo.ca wrote:
>
> A macro I'm writing needs a function to check whether a
I believe something just like that is already implemented in
Devectorize.jl's @devec macro. Try: `@devec y[:] = y + a .* x[ind]`.
https://github.com/lindahua/Devectorize.jl
On Friday, May 20, 2016 at 11:04:34 AM UTC-4, vav...@uwaterloo.ca wrote:
>
> I'm not sure that fixed-size array solves
Good catch! Would you be willing to open a pull request to correct it?
You can edit it directly on GitHub if you'd
prefer: https://github.com/JuliaLang/julia/edit/master/doc/manual/arrays.rst
Thanks!
On Wednesday, May 4, 2016 at 2:08:58 PM UTC-4, passerby51 wrote:
>
> Hello,
>
> In the
On Monday, May 2, 2016 at 11:47:49 PM UTC-4, new to Julia wrote:
>
> when I use sparse function in Julia coding, I have the following error:
>
> LoadError: MethodError: `sparse` has no method matching
> sparse(::Array{Float64,1}, ::Array{Float64,1}, ::Array{Float64,1}, ::Int64,
> ::Int64,
At its root, isn't this just stemming from the fact that constant bindings
aren't implemented in local scopes? If you define `child` as `global`,
then it is able to infer concretely and `parent` no longer needs to hold
onto the `child` binding.
On Friday, April 22, 2016 at 1:27:21 PM UTC-4,
On Wednesday, April 20, 2016 at 8:58:35 AM UTC-4, Didier Verna wrote:
>
>
> What's the rationale behind this particular way of invoking macros
> (the @ character) ?
It's nice for both humans (it's obvious that there could be some
non-standard evaluation semantics or other such funniness)
That's https://github.com/JuliaLang/julia/pull/11242. Another common
workaround is a generated function (but the wrapper function is better if
you don't need other generated functionality):
@generated function f(x...)
N = length(x)
:(Array{Int, $N})
end
On Tuesday, April 19, 2016 at
You can take some inspiration from
DataArrays:
https://github.com/JuliaStats/DataArrays.jl/blob/44192cf6261d6eed476018fb2770c5ca8dc4e9f2/src/operators.jl#L377-L445
There's a link there to a blog post about speeding up R's multiplication —
I've not read it too carefully, but I think that may
On Monday, April 18, 2016 at 11:03:53 AM UTC-4, Didier Verna wrote:
>
> What I'm actually interested in is how deep in the language
> this needs to be grounded, since I guess this is not based on the
> AbstractArray interface. Does it need to access the language's
> internals ? How's
If I understand correctly, it looks like you're describing `C = setdiff(A,
B)`.
http://docs.julialang.org/en/release-0.4/stdlib/collections/#Base.setdiff
On Saturday, April 16, 2016 at 12:05:39 PM UTC-4, digxx wrote:
>
> Say I have 2 arrays
> A=[1,2,3,4,5,6]
> B=[1,6,7]
> and the resulting
On Thursday, April 14, 2016 at 8:38:33 AM UTC-4, James Fairbanks wrote:
>
> Is that from this package https://github.com/JuliaSparse/SparseVectors.jl
> or somewhere else?
>
Yes, and it was incorporated into Base in 0.5. It's basically a one-column
SparseMatrixCSC.
> > They should have
On Wednesday, April 13, 2016 at 6:29:21 PM UTC-4, James Fairbanks wrote:
>
> Or do you make a constructor that validates C <: Associative{NTuple{N,
> Int},T} at construction time?
> What would be the appropriate error to throw in this case?
>
Exactly! It's not currently possible to express the
If you're able to define a `size` method for the Associative types, then
I'd call them all AbstractArrays. I'd use a wrapper type like the last
example
in http://docs.julialang.org/en/release-0.4/manual/interfaces/#abstract-arrays.
You could parameterize the `data` field so any associative
It'd probably be fastest if you can pre-allocate your array:
A = Array(ASCIIString, 3, 2)
for i=1:size(A, 1)
A[i, 1] = string('w'+i, 1)
A[i, 2] = string('w'+i, 2)
end
If you don't know how many elements you'll have, you can use two column
vectors, `c1` and `c2`, and push to them
I'd use logical indexing for this:
a[isnan(a)] = 42
clean_a = a[!isnan(a)]
On Thursday, April 7, 2016 at 9:20:05 AM UTC-4, Kristoffer Carlsson wrote:
>
> to replace with 42, maybe:
>
> map!((i) -> isnan(i)? 42 : i, a)
>
> to delete:
>
> deleteat!(a, find(isnan, a))
>
>
>
>
> On Thursday, April
Perhaps a simpler solution would be to just assert that `evaluate` always
returns a Float64? You may even be able to remove the isa branches in that
case, but I'm not sure how it'll compare.
On Saturday, April 2, 2016 at 4:34:09 PM UTC-4, Cedric St-Jean wrote:
>
> Thank you for the detailed
I don't want to get too deep into the weeds here, but I want to point out
some things I like about Julia's closed ranges:
* Julia's ranges are just vectors of indices. In exchange for giving up
Python's offset style slicing, you get a fully-functional mathematical
vector that supports all
There's a few things going on here. First, you only define one method for
`g` — your second definition overwrites the first because keyword arguments
don't participate in multiple dispatch. There's been a warning added here
in 0.5.
So the one method you define just takes one argument and one
Yes, the DataArrays package exists to handle `NA` elements as a foundation
for DataFrames.
You've stumbled upon an open issue in the language, and you're exactly
right: vectorization like this is really handy, but it can make reading
code a bit harder to understand. In this case, for example,
To generalize this idiom a bit, I think I'd write it as:
Base.convert(::Type{Float64}, a::MyNum) = convert(Float64, a.x)
f(a) = f(convert(Float64, a))
f(a::Float64) = 2. # real algorithm
Of course, this will also allow things like `f(1)`.
On Tuesday, March 15, 2016 at 10:18:30 AM UTC-4, Stefan
Interpolations is very similar, but it currently only supports linear and
nearest-neighbor schemes for gridded interpolations:
using Interpolations
itp = interpolate((P_NOM,), ETA, Gridded(Linear())) # You pass the x-values
as a tuple, since this generalizes to multi-dimensional coordinates
I highly recommend reading the Interfaces chapter[1] for a walk-through on
creating your own array type. Another great trick that you can use is
`A[mod1(x, end)]`.
1. http://docs.julialang.org/en/release-0.4/manual/interfaces/
On Sunday, February 7, 2016 at 10:52:45 AM UTC-5, Erik Schnetter
Can you reproduce it if you run julia with the --check-bounds=yes command
line argument?
On Monday, February 1, 2016 at 1:55:25 PM UTC-5, Madeleine Udell wrote:
>
> This is on a mac; we've got a variety of function calls giving errors,
> some with probability ~.5 and some every time we've run
You need to manually attach the inline annotation within the function body
that gets generated. See,
e.g.,
https://github.com/JuliaLang/julia/blob/275c7e8929dd391960ba88e741c6f537ccca6cc9/base/multidimensional.jl#L233-L236
On Wednesday, January 20, 2016 at 2:27:14 PM UTC-5, Erik Schnetter
be annotated appropriately.
>
> On Wed, Jan 20, 2016 at 2:35 PM, Matt Bauman <mba...@gmail.com
> > wrote:
>
>> You need to manually attach the inline annotation within the function
>> body that gets generated. See, e.g.,
>> https://github.com/JuliaLang/julia/bl
On Monday, January 18, 2016 at 11:54:49 AM UTC-5, Anonymous wrote:
>
> As you can see, I have to define a whole other type tree just so my metric
> function can distinguish between sphere manifolds depending on what metric
> structure I want it to have. It would be both simpler and make more
On Tuesday, January 5, 2016 at 3:23:14 AM UTC-5, Ismael Venegas Castelló
wrote:
> Why force `methods` to work with anything?
>
Because you can call anything:
julia> call(x::Char) = x+1
call (generic function with 1038 methods)
julia> 'c'()
'd'
julia> methods('c')
1-element Array{Any,1}:
Oh man, fun puzzle. Even without the allocations, SubArrays that depend
upon an indexing vector (that is, not computable range) are really quite
slow since there's a lot of indirection at every element access.
You can solve the all-but-one problem with a custom view type fairly easily:
Instead of keyword argument ordering, you could use an "Exactly" wrapper
type. This would allow you to dispatch and potentially error if the exact
constraints cannot be satisfied.
immutable Exactly{T}
val::T
end
foo(Exactly(1.0), 2.0, Exactly(3.0)) # the second argument might get fudged
These are definitely not stupid questions. Tuning performance at this
level is very hard. I'll just add a few practical notes on
micro-benchmarking and introspection. Inspecting and benchmarking
splatted/slurped functions can be very tricky. One thing to remember is
that `@code_llvm`
Whenever you define an IO method, you need to make sure that all IO methods
you call within it also use that argument. Change println("x ...") to
println(io, "x …").
On Friday, November 6, 2015 at 8:17:56 AM UTC-5, Gnimuc Key wrote:
>
> we can define a good representation of a new type by
The ability to assign a single element into multiple locations like this is
called scalar broadcasting. When you have an array of arrays, however,
each element isn't a scalar. So it's trying to assign the elements of the
right side (Float64s) to the elements of the right side (matrices). You
Here's how I'd tackle this problem: I'd use dispatch with promote_type to
perform the type reduction. This is often the best way to express things
like this:
scalar_or_eltype{T}(::AbstractArray{T}) = T
scalar_or_eltype{T}(::T) = T
promote_scalar_or_eltype(A, B) =
On Tuesday, October 20, 2015 at 10:09:42 AM UTC-4, Glen O wrote:
>
> Seems to be something wrong with the dispatch system with Union...
>
Yes, Unions with TypeVars can behave strangely when the elements aren't
mutually exclusive. I think it's just greedily matching the first thing it
can. In
r 20, 2015 at 10:45:15 AM UTC-4, Glen O wrote:
>
> On Wednesday, 21 October 2015 00:15:41 UTC+10, Matt Bauman wrote:
>>
>> On Tuesday, October 20, 2015 at 10:09:42 AM UTC-4, Glen O wrote:
>>>
>>> Seems to be something wrong with the dispatch system with Union...
On Sunday, October 18, 2015 at 3:54:13 PM UTC-4, David Gold wrote:
>
> @Sebastian: If I understand you correctly, then it should at least be
> possible. If T is your datatype that behaves as such and x is the value of
> type T that designates missingness, then it seems you could
>
On Friday, October 16, 2015 at 11:29:40 PM UTC-4, Forrest Curo wrote:
>
> Okay, this might be a good time to explain that 'Compat' package.
> Evidently I do have it, because I can't Pkg.add it... How does this work?
>
See the readme here: https://github.com/JuliaLang/Compat.jl
The short version
$ is also used for interpolation, so it must be disambiguated between the
two cases. & is similar, if I remember correctly.
On Wednesday, October 7, 2015 at 3:09:08 PM UTC-4, cheng wang wrote:
>
> Thanks. Still, why + and $ are different in this case ?
>
> On Wednesday, October 7, 2015 at
In case anyone is interested in contributing here, this is a simple
optimization to make. `A[:] = 0.` is currently using the abstract
fallbacks, which is implemented with as a simple loop. There are already
some optimizations for `setindex!(::Array, …)` in cases like this where we
can take
Use ./ and .^
Whereas multiplying a matrix by a scalar is well-defined in linear algebra,
dividing by a matrix has a very specific meaning which requires the a
square matrix. Same with exponentiation. The dot-prefixed operators
explicitly work elementwise.
On Wednesday, September 30, 2015
There has been a lot of discussion about this in the past few weeks
https://groups.google.com/d/msg/julia-users/ScwXMfQIBGs/wD1HTXeZBQAJ
https://groups.google.com/d/msg/julia-users/fNisYpMdZ6o/DvFaQi_ZBAAJ
TL;DR, yes, it is possible, but it takes some care since it's violating a
fairly
A colon by itself is simply a synonym for `Colon()`, both on 0.3 and 0.4:
julia> :
Colon()
You can use colons in normal function calls and dispatch in both 0.3 and
0.4:
julia> f(x::Colon) = x
f(:)
Colon()
That's what's happening with that sub definition. `sub` acts like
indexing, but
Here's a quick rundown on the status quo:
* Colon lowering changed in 0.4, as did the AbstractArray's interface.
It's *much* easier to make your own arrays in 0.4. I suggest updating to
the latest RC.
* There is still a very strong assumption in base Julia that the valid
indices in an
The bitwise operations (&, |) broadcast over arrays and work just fine for
this. Watch out for their precedence, though: you need to wrap them in
parentheses if you want to combine them with the result of comparisons `(A
== 1) | (A == 2)`.
On Monday, September 21, 2015 at 8:41:29 AM UTC-4,
More concretely, && and || are control flow operators. They short circuit.
Therefore, they require Boolean arguments and aren't real functions.
They're syntax.
& and | are bitwise operations and real, extendable functions. They can
operate on booleans *and* integers, performing bitwise
On Thursday, September 17, 2015 at 9:09:45 AM UTC-4, Ján Dolinský wrote:
>
> Hello,
>
> Is a module name consisting of minus sign allowed ?
> E.g. my-new-module
>
Module names follow the same rules as all identifiers do. See here for
details:
On Thursday, September 17, 2015 at 9:45:11 AM UTC-4, ami...@gmail.com wrote:
>
> I don't really get why though, what mechanism prevents Julia to use the
> first version now?
> Does it look at all the available functions called f and see if one is
> better suited, is likely to produce an error of
On Monday, September 14, 2015 at 9:44:07 AM UTC-4, Andrei Zh wrote:
>
> To continue Michael's answer, I think it would be nice to collect list of
> most important features that existing editors for Julia still lack and
> think out what can be improved. So far I've seen following features:
>
>
On Friday, September 11, 2015 at 3:11:48 AM UTC-4, Leonardo wrote:
>
> I like to have a *unique* type that contains only a specified type and
> that can handle any dimension, but only during object instancing (not
> during subsequent lifecycle of object, also if both phases are at runtime),
>
Further, I'm fairly certain that we always evaluate function arguments from
left to right. I think this all comes from the Lisp-y
almost-everything-is-an-expression tradition.
On Friday, September 11, 2015 at 9:51:28 AM UTC-4, Tomas Lycken wrote:
>
> In Julia, this is actually more consistent
The reason you're needing to define more methods than the interface chapter
suggests is because you haven't specified the AbstractArray's parameters;
this is just as important as the required methods. That is, you need to
define your type as
type MyArr{T,N} <: AbstractArray{T,N}
in order for
Just define a zero-argument constructor:
type Point
x::Float64
y::Float64
Point() = new()
end
p = Point(); # Will return uninitialized memory or #undef references
depending on the field type
Note that this will override the default constructors; you'll need to
explicitly add back the
On Thursday, September 3, 2015 at 10:04:22 AM UTC-4, Michael Francis wrote:
>
> It brings up a question regarding parameterized types, how should (or
> should) one access/refer to the parameters of the type rather than an
> instance. It seems like a bad (queezy) practice to dig into the
Here's one option: use the value of the whole try-block. This is
particularly nice in cases where you have some substitute for `(t, data)`
(or whatever) that you'd like to use when an exception is thrown. This way
you can simply have the last statement of the catch block give the
substitute.
Oh man that's tricky. The trouble is that you're effectively saying
`Pair{Symbol,Int}[1]`, which is the syntax for a typed array:
Pair{Symbol,Int}[:x=>1, :y=>2]. One way around this is to define:
keytype{A,B}(::Type{Pair{A,B}}) = A
valuetype{A,B}(::Type{Pair{A,B}}) = B
You have shadowed Base.mean with a local `mean` that was bound to `0`. Try
help for Base.mean and 0.
On Tuesday, September 1, 2015 at 1:18:17 PM UTC-4, Miguel Bazdresch wrote:
>
> The Segmentation Fault strongly suggests a glitch, not an Easter egg,
> unfortunately... :)
>
> On Tue, Sep 1,
That's the point of the macro - to ensure that inference infers a concrete
result. It can help ensure that code stays type-stable. Throwing for a union is
expected.
NEWS.md is a good place to start:
https://github.com/JuliaLang/julia/blob/master/NEWS.md#julia-v040-release-notes
And Compat.jl can be very helpful in getting things to play nicely on both
0.3 and 0.4: https://github.com/JuliaLang/Compat.jl#supported-syntax
On Friday, August 28, 2015 at
The backtick command syntax looks like it ignores newlines.
http://docs.julialang.org/en/release-0.3/manual/running-external-programs/
If you're constructing shell commands, that is definitely the way to go:
julia cmd = `echo hello
world`
`echo hello world`
julia run(cmd)
hello world
Yes, this can be surprising. Look at `methods(u)`:
julia methods(u)
# 5 methods for generic function u:
u(c::Float64) at none:7
u(c::Float64, h::Float64) at none:3
u(c::Float64, h::Float64, b) at none:3
u(c::Float64, h::Float64, b, a) at none:3
u(c::Float64, a) at none:7
When you call `u(2.)`,
If the row index is intrinsically connected to and meaningful in
relationship to the other columns, you should add it as a separate column.
All arrays in Julia start indexing at 1, and data frames displays its
row indices consistent with how it would index. Indexing arrays with
Real numbers
On Tuesday, August 18, 2015 at 11:29:00 AM UTC-4, Sisyphuss wrote:
My point is these inconsistent rules are very confusing. The experience
gained in one type cannot be extrapolated to another.
I think most people here will agree with you. The discussion on how to
spell conversion and/or
. I had the same
indexing issue with MatLab. Sometimes I miss the brute straightforwardness
of Fortran.
Larry
On Mon, Aug 17, 2015 at 1:16 PM, Matt Bauman mba...@gmail.com
javascript: wrote:
On Monday, August 17, 2015 at 1:03:17 PM UTC-4, Sisyphuss wrote:
I read the interfaces
http
See the previous discussion
here: https://groups.google.com/forum/#!topic/julia-dev/NOF6MA6tb9Y
… which looks like it culminated in the OffsetArrays.jl
package: https://github.com/alsam/OffsetArrays.jl
But you'll need to be very careful about how you use them since they break
a core
On Monday, August 17, 2015 at 1:03:17 PM UTC-4, Sisyphuss wrote:
I read the interfaces
http://docs.julialang.org/en/latest/manual/interfaces/ chapter of the
documentation today. I learned that, if you define an iterable as a subtype
of AbstractArray, with only defining three methods
On Monday, August 17, 2015 at 2:17:06 PM UTC-4, Matt Bauman wrote:
That's a bug. I'll fix it shortly.
Shortly was an overestimate. Apparently I already fixed this 11 days ago.
:)
If you update Julia, you'll see that the builtin fallbacks implement the
conversion to `Int` for you.
You could create a phony 2-dimensional array that computes the distances
on the fly… but you won't be able to pass this matrix to, e.g., BLAS.
immutable DistanceMatrix : AbstractArray{Float64, 2}
locs::Array{Float64, 2} # a 2xN or 3xN matrix containing the location
coordinates
end
The basic try/catch/finally behaviors have been discussed before. I think
this is a good
summary: https://groups.google.com/d/msg/julia-users/Kqn6gNIwD5o/aKE17Nclh3kJ
On Wednesday, August 12, 2015 at 9:25:32 AM UTC-4, Yichao Yu wrote:
On Wed, Aug 12, 2015 at 9:20 AM, Sisyphuss
I think it's best to think of `...` as expanding into an argument list. So
`[A...]` makes an array, `Dict(X...)` forms a dictionary, and `tuple(A...)`
makes a tuple. On 0.4 you can even say `(A...,)` to splice the arguments
directly into the tuple syntax.
I'd recommend not using FloatRange for this task. Instead, I'd create a
new Interval type that doesn't have discrete steps and instead represents
all real numbers between (and including) its endpoints. You can even use
an unused operator (..) to allow easy construction of intervals. Naively,
I absolutely love that it's only 43 lines of code!
On Thursday, July 30, 2015 at 2:14:50 PM UTC-4, Stefan Karpinski wrote:
The ease with which you were able to put that together is pretty amazing.
On Thu, Jul 30, 2015 at 1:38 PM, Simon Kornblith si...@simonster.com
javascript: wrote:
Is your custom object `: AbstractArray`? Are you on 0.3 or a recent
0.4-dev? Are you implementing custom `setindex!` methods? I don't think
that your workaround should be necessary, but you haven't posted enough
context for me to fully appreciate the issue.
As far as support for
Yes, this is one of the ever-tricky cases of did you mean the container or
the elements of that container? Setindex always assumes that, if the RHS
of the assignment is an array of some sort, it's the elements that should
be assigned.
David, `A[:] = Vector[[1,2,3]]` works as you'd expect
I think we should probably support indexing with Array{Any}, just so long as
all the contained elements are Ints. It's not performant or recommended, but it
can still work just fine.
significant octets match (above)?
On Thursday, July 16, 2015 at 12:25:01 PM UTC-4, Matt Bauman wrote:
On Thursday, July 16, 2015 at 12:19:25 PM UTC-4, milktrader wrote:
Also, back to the OP question, is the correct solution to simply
define
Base.hash(f::Foo) = f.x
No, I'd define
How should packages that depend upon JLD update their REQUIRE files?
Should they just tag a new version that requires JLD instead (or in
addition to, if they also use HDF5's capabilities)?
On Friday, July 17, 2015 at 10:14:27 AM UTC-4, Tim Holy wrote:
Hi folks,
If you use HDF5/JLD, the
(foos[1]) and
hash(foos[2]) have the same last hex digit?
On Thu, Jul 16, 2015 at 11:30 AM, Matt Bauman mba...@gmail.com wrote:
Bizarre. I happen to have last updated on *exactly* the same commit
SHA, but I'm seeing the original (expected) behavior:
$ julia -q
julia versioninfo()
Julia
Bizarre. I happen to have last updated on *exactly* the same commit SHA,
but I'm seeing the original (expected) behavior:
$ julia -q
julia versioninfo()
Julia Version 0.4.0-dev+5860
Commit 7fa43ed (2015-07-08 20:57 UTC)
Platform Info:
System: Darwin (x86_64-apple-darwin14.3.0)
CPU: Intel(R)
On Thursday, July 16, 2015 at 12:25:01 PM UTC-4, Matt Bauman wrote:
On Thursday, July 16, 2015 at 12:19:25 PM UTC-4, milktrader wrote:
Also, back to the OP question, is the correct solution to simply define
Base.hash(f::Foo) = f.x
No, I'd define Base.hash(f::Foo) = hash(f.x
of the contents
with each other (and with `h`). And that's exactly how most base
functions do it.
On Thursday, July 16, 2015 at 12:35:25 PM UTC-4, Seth wrote:
On Thursday, July 16, 2015 at 9:25:01 AM UTC-7, Matt Bauman wrote:
On Thursday, July 16, 2015 at 12:19:25 PM UTC-4, milktrader wrote:
Also
On Thursday, July 16, 2015 at 12:19:25 PM UTC-4, milktrader wrote:
Also, back to the OP question, is the correct solution to simply define
Base.hash(f::Foo) = f.x
No, I'd define Base.hash(f::Foo) = hash(f.x, 0x64c74221932dea5b), where I
chose the constant by rand(UInt). This way it won't
One of the most powerful features of Julia is that packages (and user code in
general) aren't at a major disadvantage to code included in Julia itself. 0.4
promises to make this even better with precompilation and documentation.
Many of the folks who have spearheaded the big packages are also
Are you using 0.3 or 0.4? You could try making `SpatialData` a subtype of
`AbstractArray`. It's possible to do on either version, but it's
substantially easier to do on 0.4. Then you could use any of the methods
in base that are defined for `AbstractArray` (including `maximum`)
directly.
Are the 'unset' indices defined to have some value in your application? If
not, trying to shoehorn this into an `AbstractArray` probably won't work
very well. Also note that, while correct, using the methods in base will
be slow if you have very large and very sparse matrices.
In defining
I played with this a little while ago. It's simplest if you can manage to
always concatenate along a *new* dimension. Otherwise I think you'll have
to do a lot of bookkeeping to track when to index into which array. Here's
a very minimal starting point (requires 0.4) that requires all arrays
That's great to hear! Thanks for reporting back.
On Tuesday, June 30, 2015 at 2:48:01 PM UTC-4, David Anthoff wrote:
I had reported slow performance for a medium size code base a couple weeks
ago on 0.4 relative to 0.3. I just tested again with the latest nightly,
now 0.4 is faster. Thanks
Note the warning message you get upon trying to define Base.rand():
Warning: Method definition rand() in module Random at random.jl:195
overwritten in module Main at none:1
You're not shadowing rand; you're totally overwriting one of its main
methods. I agree with Tom that you should
Zip and enumerate are also iterators in Julia. The little performance
improvement that the @itr macro provides isn't because they aren't
iterators… it's simply from a little quirk in Julia 0.3. In the latest
development versions (0.4-), however, there is no longer a performance
difference
Right now there's not an official way to do this. You could take a look at
my Tuples package[1], which is an attempt at hashing out the API before
trying to get this functionality into base. Your feedback would be very
welcome!
1: https://github.com/mbauman/Tuples.jl
On Wednesday, June 24,
Should be fixed now! Thanks so much for reporting the problem, Julio.
https://github.com/JuliaLang/julia/pull/11810
On Monday, June 22, 2015 at 9:11:20 AM UTC-4, Matt Bauman wrote:
Yup, I would have seen this quicker if it were an posted as issue. I
don't follow the mailing list all
1 - 100 of 197 matches
Mail list logo
