OK, I think I got it:
type Foo{T}
x::T
y::T
end
Base.hash(f::Foo) = hash(f.x, hash(f.y, pair_seed))
On Thursday, July 16, 2015 at 9:46:12 AM UTC-7, Matt Bauman wrote:
Goodness, I'll get this right one of these times. Sorry for spouting off
so much disinformation! I'll try to make
Immutables automatically have value-based hashing defined for them. That's
a dangerous default for mutable values since it makes it easy to stick
something in a dict, then mutate it, and lose it, e.g.:
type Mutable
x::Int
end
Base.hash(m::Mutable, h::UInt) = hash(m.x, h +
I realize it's not what you were aiming for, but since you mentioned that
you hoped for a simpler solution … you do have full use of the Julia
language, compile-time, when writing macros. So you could use a loop, for
example – or even call the built-in factorial function compile-time:
*macro
The unique function doesn't appear to work using iterables of custom
composite types, e.g.,
julia type Foo
x::Int
end
julia import Base: ==
julia ==(f1::Foo, f2::Foo) = f1.x == f2.x
== (generic function with 85 methods)
julia unique(foos)
2-element Array{Foo,1}:
Foo(4)
Foo(4)
How did you get foos?
On Thursday, July 16, 2015 at 9:16:01 AM UTC-4, Marc Gallant wrote:
The unique function doesn't appear to work using iterables of custom
composite types, e.g.,
julia type Foo
x::Int
end
julia import Base: ==
julia ==(f1::Foo, f2::Foo) = f1.x ==
Question 2) What advantage is there for changing the scoping rules for
nested functions?
How is this for an explanation:
https://github.com/mauro3/julia/blob/m3/scope-doc/doc/manual/variables-and-scoping.rst#hard-vs-soft-local-scope
Whoops! Here is the updated code:
julia type Foo
x::Int
end
julia import Base: ==
julia ==(f1::Foo, f2::Foo) = f1.x == f2.x
== (generic function with 85 methods)
julia foos = [Foo(4), Foo(4)]
2-element Array{Foo,1}:
Foo(4)
Foo(4)
julia unique(foos)
2-element Array{Foo,1}:
You need to also define a hash method for this type.
On Jul 16, 2015, at 9:16 AM, Marc Gallant marc.j.gall...@gmail.com wrote:
The unique function doesn't appear to work using iterables of custom
composite types, e.g.,
julia type Foo
x::Int
end
julia import Base: ==
I don't see that on 0.4-dev – it also doesn't seem possible without having
defined a hash method since unique is implemented with a dict.
On Thu, Jul 16, 2015 at 10:29 AM, milktrader milktra...@gmail.com wrote:
Julia 0.4- has different behavior ...
First, with 0.3.9
julia versioninfo()
Julia 0.4- has different behavior ...
First, with 0.3.9
julia versioninfo()
Julia Version 0.3.9
Commit 31efe69 (2015-05-30 11:24 UTC)
Platform Info:
System: Darwin (x86_64-apple-darwin13.4.0)
CPU: Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz
WORD_SIZE: 64
BLAS: libopenblas
Dan and/or Seth, can you try that again and check if hash(foos[1]) and
hash(foos[2]) have the same last hex digit?
On Thu, Jul 16, 2015 at 11:30 AM, Matt Bauman mbau...@gmail.com wrote:
Bizarre. I happen to have last updated on *exactly* the same commit SHA,
but I'm seeing the original
Sure enough:
julia unique([Foo(4),Foo(4)])
2-element Array{Foo,1}:
Foo(4)
Foo(4)
julia unique([Foo(4),Foo(4)])
1-element Array{Foo,1}:
Foo(4)
julia unique([Foo(4),Foo(4)])
2-element Array{Foo,1}:
Foo(4)
Foo(4)
I think they just got unlucky. This seems to collide far too easily.
On
Ahhh, the closure explanation makes sense Mauro. I have used closures
before but my shared state variables were always arrays which were mutated
inplace so the closure scoping behavior acted just like the global scoping
rules. For example, my closures always looked like this:
julia function
I can confirm this works as described by milktrader on 0.4.0-dev+5860
(2015-07-08 20:57 UTC) Commit 7fa43ed (7 days old master).
julia unique(foos)
1-element Array{Foo,1}:
Foo(4)
On Thursday, July 16, 2015 at 7:52:03 AM UTC-7, Stefan Karpinski wrote:
I don't see that on 0.4-dev – it also
I just tried it on that exact version and do not see that behavior:
julia versioninfo()
Julia Version 0.4.0-dev+5587
Commit 78760e2 (2015-06-25 14:27 UTC)
Platform Info:
System: Darwin (x86_64-apple-darwin14.3.0)
CPU: Intel(R) Core(TM) M-5Y71 CPU @ 1.20GHz
WORD_SIZE: 64
BLAS: libopenblas
julia hash(foos[1]) #and hash(foos[2])
0xfa40ebab47e8bee1
julia hash(foos[2])
0x00ef97f955461671
On Thursday, July 16, 2015 at 11:36:03 AM UTC-4, Stefan Karpinski wrote:
Dan and/or Seth, can you try that again and check if hash(foos[1]) and
hash(foos[2]) have the same last hex digit?
On
Suppose I want to apply the trick that makes `broadcast!` fast to `map!`.
Because of the specificity of `map!`'s functionality, I don't necessarily
need to cache the internally declared functions, so I just write:
function map!{F}(f::F, dest::AbstractArray, src::AbstractArray)
_f =
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,
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, 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,
Goodness, I'll get this right one of these times. Sorry for spouting off
so much disinformation! I'll try to make up for it by adding more examples
to the documentation.
const _foo_seed = UInt === UInt64 ? 0x64c74221932dea5b : 0x80783eb4
Base.hash(f::Foo, h::UInt) = hash(f.x, h += _foo_seed)
This is just an artifact of memory layout – hashing by identity is based on
object_id which is based on memory address. It's not a meaningful
behavioral difference between Julia versions. Sticking mutable objects for
which hash and == disagree is an undefined behavior and causes dictionaries
to do
Also, back to the OP question, is the correct solution to simply define
Base.hash(f::Foo) = f.x
On Thursday, July 16, 2015 at 12:13:15 PM UTC-4, Seth wrote:
Ah, ok, thanks. This might cause issues with one of my packages, which is
why I'm interested. How would you approach creating the
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
Well, that's it then. Cause: accidental hash collision. The fix is to
define hash for the type. This makes me wonder if we shouldn't just leave
hash undefined for custom mutable types and make it easy to opt into
hashing by identity. At least then you'll get a clear no method error (and
we could
Yep, restarting I don't get the one-element array
julia type Foo
x::Int
end
julia import Base: ==
julia ==(f1::Foo, f2::Foo) = f1.x == f2.x
== (generic function with 108 methods)
julia foos = [Foo(4), Foo(4)]
2-element Array{Foo,1}:
Foo(4)
Foo(4)
julia unique(foos)
Is there a way to use a timeout with `recv(sock::UdpSocket)`?
-s
I can't because I just rebuilt to latest to
test https://github.com/JuliaLang/julia/issues/12063 - but I'll try on the
latest master...
... and Julia Version 0.4.0-dev+6005 Commit 242bf47 does not appear to have
the issue (I'm getting two results returned for unique()).
On Thursday, July 16,
On Thu, Jul 16, 2015 at 12:07 PM, Seth catch...@bromberger.com wrote:
Stefan,
If I'm reading between the lines correctly, the default/existing hash
function is based on the last byte of the ID? Is there a reason we don't
make the table wider to reduce the chances of collisions (or would this
Ah, ok, thanks. This might cause issues with one of my packages, which is
why I'm interested. How would you approach creating the hash dispatch for
custom types, and does this impact immutables as well?
On Thursday, July 16, 2015 at 9:09:08 AM UTC-7, Stefan Karpinski wrote:
This is just an
Stefan,
If I'm reading between the lines correctly, the default/existing hash
function is based on the last byte of the ID? Is there a reason we don't
make the table wider to reduce the chances of collisions (or would this
have bad effects on memory utilization)?
On Thursday, July 16, 2015 at
I'm curious to know also. I remember running into the same problem and not
finding an easy solution.
So I'm trying to iterate over the list of partitions of something, say
`1:n` for some `n` between 13 and 21. The code that I ideally want to run
looks something like this:
valid_num = @parallel (+) for p in partitions(1:n)
int(is_valid(p))
end
println(valid_num)
This
First, a note: Please disregard the use of `A` in the above function
definitions! Those ought to be `src`. I just got very confused as to why
those definitions worked at all, until I realized that my test `Array`
argument was also named `A`... So, the definitions in question ought to be
julia versioninfo()
Julia Version 0.3.10
Commit c8ceeef* (2015-06-24 13:54 UTC)
Platform Info:
System: Windows (x86_64-w64-mingw32)
CPU: AMD Opteron(tm) Processor 4171 HE
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Barcelona)
LAPACK: libopenblas
LIBM:
Sorry I'm not being very clear. Lets try some code. I ran your first
version, which creates a global method func which is a function
specialized on the function f. Here's the comparison to the local function
that is created in the second version. Notice the areas in bold, which are
where
Thanks Jameson.
My error was from the line: trialCounts = MySimulation(trial, numIter)
Error message: trialCounts not defined
This had something to do with the variable name (used later, perhaps if
statements guarding scope and now local)
In any case, if I change variable name, it works: counts
Yichao Tom,
Thank you both for your explanations. It's starting to come together for me
now. Tom, I will admit that I'm unclear on what you mean by `f` not being
accessed as `the same kind of function` between access in the global scope
vs. access within the closure of `map`. I mean, I (more
OK thanks.
I didn't consider @parallel (probably because I considered it for only
large trials of small work units, whereas I considered pmap more suited to
relatively small trials of longer running work units)
In any case, @parallel works fine.
Old pmap code skeleton:
trialCounts =
i believe that length(chunks) will be = nworkers()
the last statement of the for loop should be the return value from that
iteration. (for example: the variable name `trialCount`).
On Fri, Jul 17, 2015 at 12:12 AM Greg Plowman greg.plow...@gmail.com
wrote:
OK thanks.
I didn't consider
fzero(f, j, guess) works for me when f and j are functions. f(Af, guess)
works for me now when Af is an @anon function.
On Tuesday, July 7, 2015 at 7:34:39 PM UTC-4, j verzani wrote:
Okay, this just got fixed as much as I could with v0.1.15 (there is no
fzero(f,j,guess) signature).
On
Hi all,
I'm working on a module that will use a toggle button to show and hide
content in an IJulia notebook. Everything works as intended if the content
is HTML, but I also need to be able to display equations. I have two
questions:
1. Is it possible to display equations within blocks of
hi, seth contacted me to see whether my ParserCombinator library could do
this, and i've just finished adding support for GML. you can see it at
https://github.com/andrewcooke/ParserCombinator.jl#parsers
that is currently only available via git (not yet in a published release).
i've also
David: the f(src(i)) in the second call is referencing the local argument
f::Function passed into the map! method. It is not accessing the same
kind of function as if you defined it globally. I think the first
definition is effectively just grabbing f's Symbol, and then calling the
method
44 matches
Mail list logo