Re: [julia-users] Packing and Unpacking several Matrixes into flat vectors
In the long-term, the best way to do this will be to use SubArray and
ReshapeArray. You'll allocate enough space for all parameters, then unpack
them into separate objects when that helps.
-- John
On Thursday, May 14, 2015 at 2:03:27 AM UTC-7, Tim Holy wrote:
Some Optim algorithms, like cg, already allow you to optimize a matrix.
--Tim
On Wednesday, May 13, 2015 11:50:00 PM Lyndon White wrote:
Hi all,
I've been trinking about this for a while.
Numerical Optimistation Libraries, eg
NLopt(https://github.com/JuliaOpt/NLopt.jl) and Optim
(https://github.com/JuliaOpt/Optim.jl),
require the parameter to be optimised (x), to be a vector.
In Neural Networks, the paramer to be optimise are Weight Matrixes and
and
Bias Vectors.
The work around to train a Neural Network with such an optimistation
library is to Pack those matrixes and vectors down to single vector,
when
returning the gradient,
and to unpack it into the matrixes and vectors when acted to evaluate
the
gradient/loss.
Like follows:
type NN
W_e::Matrix{Float64}
b_e::Vector{Float64}
W_d::Matrix{Float64}
b_d::Vector{Float64}
end
function unpack!(nn::NN, θ::Vector)
W_e_len = length(nn.W_e)
b_e_len = length(nn.b_e)
W_d_len = length(nn.W_d)
b_d_len = length(nn.b_d)
W_e_shape = size(nn.W_e)
W_d_shape = size(nn.W_d)
nn.W_e = reshape(θ[1: W_e_len],W_e_shape)
nn.b_e = θ[W_e_len+1: W_e_len+b_e_len]
nn.W_d = reshape(θ[W_e_len+b_e_len+1:
W_e_len+b_e_len+W_d_len],W_d_shape
)
nn.b_d = θ[W_e_len+b_e_len+W_d_len+1: end]
nn
end
function pack(nn::NN)
pack(nn.W_e[:],nn.b_e, nn.W_d[:],nn.b_d[:]] _
end
pack(∇W_e::Matrix{Float64}, ∇b_e::Vector{Float64},
∇W_d::Matrix{Float64}, ∇
b_d::Vector{Float64})
[∇W_e[:], ∇b_e, ∇W_d[:], ∇b_d]
end
Then use it like:
function loss_and_loss_grad!(θ::Vector, grad::Vector) #NLOpt and Optim
both provide the grad matrix to be overwritten in place
grad[:] = 0
unpack!(nn_outer, θ) #Keep a global nn to track size, (and handy if
the
algorithm crashes)
function loss_and_loss_grad(train_datum)
∇W_e, ∇b_e, ∇W_d, ∇b_d, err =
loss_and_loss_grad_single(nn_outer,
train_datum)
[pack(∇W_e, ∇b_e, ∇W_d, ∇b_d), err]
end
ret = map(loss_and_loss_grad, training_data)| sum
grad[:] = ret[1:end-1]
err=ret[end]
grad[:]/=length(training_data)
err/=length(training_data)
err
end
This works.
But in involved excessive array copies (I suspect).
The order in the packed vector does not matter, so long as it is
consistent.
Now, memory is already linear -- matrices are Vectors in memory with
special operations defined that say how to interpret them in 2D.
and the matrixes in the composite type, are adjacent in memory (i
assume,
since why not be like a C struct).
So it is logically simple to just reinterpret them them as a single
vector.
I don't think reinterpet functions on composite types though.
In C of PL/I, this could be solved by defining the Composite type as an
untagged union, of a Vector and a Structure.
I don't think Julia has this facility. (It is pretty niche, this is one
of
the only times i can think of it as being actually convenient).
Anyone have any suggestions?
Regards
Re: [julia-users] Biggest Julia program so far?
I've seen a few proprietary code bases that are 2-3x that big, which is not huge, but pretty substantial. I suspect that not many Julia code bases have had time to grow much larger than that. I think that this is large enough to be confident that nothing horrible happens when the code base gets larger – it's just as manageable as it is in Ruby or Python. The main issue is startup time when loading all your modules (which Jameson is working on addressing for 0.4). On Wed, May 13, 2015 at 1:05 PM, Páll Haraldsson pall.haralds...@gmail.com wrote: On Wednesday, May 13, 2015 at 4:32:01 PM UTC, Tim Holy wrote: No clue how this fares, but my lab has a code base of approximately 35k lines if you include tests. This does not include documentation, nor does it include any packages. Thanks, Anyone want to raise? :) Now, that is fairly big.. But could you guess the ratio of tests/real code..? I assume you mean one code base for one project? Or do you have many and this is combined.. not sure if easy to divide or how you scientists work..
Re: [julia-users] Re: verbs for immutable collections
@Tomas, thank you, I had briefly started down this path but thought perhaps
it was the wrong direction ( when I looked at what * or + should mean ).
Now you point it out again I'm thinking that following the notions that
these are sets might be the correct thing, so
# {} is not a syntax for immutable set today
S = { a = 1, b = 2 }
U =union( S, { c = 3 } )
I =intersect(S, {c = 3 } )
compliment( S, { c = 3 } ) == S \ { c = 3 } == S - { c = 3 }
# removal from set, using a partially specialized set ?
R = S \ { c = _ }
Where equality of the pairs is defined on the keys for these operations.
Currently equality takes the order into account, but that would be easy to
change if required. I'm a little uncomfortable with '-' but that does seem
to be fairly common in set theory.
{} would be a rather nice short form for immutable sets in general as it
maps well to set theory, but that's a different conversation.
Thoughts ?
On Thursday, May 14, 2015 at 4:20:20 AM UTC-4, Tomas Lycken wrote:
I'd like to raise a voice against using these immutable forms altogether.
If the set S is immutable, then we aren't actually going to delete
anything from anything by calling delete(S, x) - we're going to return a
new set S' which has all the elements of S except x. Thus, a better name
might be without(S, x), or it could be implemented as -(S, x) to allow for
writing S' = S - x. Similarly, doing other things that can be done in place
on mutable sets should not be called the same thing for immutable sets,
since they aren't actually doing the same thing.
// Tomas
Re: [julia-users] Example of imread from an imagemagick stream
If you dig through the commit history of Images.jl, at some point you'll find the commit that switched from using Cmd to the C api for interacting with ImageMagick. That should have quite a few examples. --Tim On Thursday, May 14, 2015 05:25:19 AM Yakir Gagnon wrote: Can someone please post a simple example of reading an image stream from imagemagick? So something like this (though this doesn't work): cmd = `convert img.png do some imagemagick things that I wish I could do with Images.jl but are only possible with imagemagick -compress none ppm:-` I = imread(readall(cmd),Images.PPMBinary) I'm trying to avoid writing the image imagemagick created to disk and read it straight into julia. The readall(cmd) part works awesome, it spews all the image bits to the stdout. But I can't get imread to pick it up as an image. Thanks in advance!
Re: [julia-users] Re: Construct range with custom type
If you do decide to keep it as a FloatingPoint subtype, you should probably
go the other route of just making sure it interacts natively with the
standard core operators, promote, convert, etc... Then the colon syntax
should work automatically, returning a FloatRange{JDate} (which can become
an Array{JDate,1} via collect()).
On Wed, May 13, 2015 at 9:06 PM, Chris 7hunderstr...@gmail.com wrote:
Now that you mention it, I think the only reason I made it a subtype of
FloatingPoint was some (very) vague notion of type inference and
performance. I will re-examine that decision now, I think. Thanks for your
help.
Chris
On Wednesday, May 13, 2015 at 2:30:53 PM UTC-4, Josh Langsfeld wrote:
Yeah, I missed that you were subtyping FloatingPoint before. It still
worked ok for me though once I also defined colon methods suggested by the
ambiguity warnings. in my case it was:
colon(::JDate, ::JDate, ::JDate)
colon(::JDate, ::FloatingPoint, ::JDate)
colon(::JDate, ::Real, ::JDate)
It seems to cause a lot of problems to subtype it as a FloatingPoint
though, and I'm not sure what benefit you are getting out of it. For
example, my installation won't even print a JDate value because it checks
for finiteness first which requires subtraction to be defined. But I assume
you can work around that by just defining enough methods of operators and
promotion rules.
On Wednesday, May 13, 2015 at 12:29:30 PM UTC-4, Chris wrote:
What should the new method be, precisely? I tried colon(start::JDate,
step::Real, stop::JDate) = JDate(colon(float64(start),step,float64(stop)) (I
have conversion rules defined for the JDate to Float64 conversions), but I
get several warning messages of the form:
Warning: New definition
colon(JDate,Real,JDate) at path\types.jl:25
is ambiguous with:
colon(T:FloatingPoint,T:FloatingPoint,T:FloatingPoint) at
range.jl:122.
To fix, define
colon(JDate,JDate,JDate)
before the new definition.
Then, when I test this, I still get a Array{Float64,1}.
Thanks,
Chris
On Wednesday, May 13, 2015 at 12:05:19 PM UTC-4, Josh Langsfeld wrote:
I believe you only need to add a method to Base.colon of the form
'colon(start::JDate, step::Real, stop::JDate)'
I just tested it and that was the only thing needed to make the the
[J1:s:J2] syntax work.
On Wednesday, May 13, 2015 at 11:13:53 AM UTC-4, Chris wrote:
I have a simple custom type called JDate:
immutable JDate : FloatingPoint
t::Float64
end
When I construct a range, e.g. [J1:s:J2], where J1::JDate, s::Real,
J2::JDate, I'd like the result to be an Array{JDate,1}. What
conversion/promotion rules are necessary to do this?
Thanks in advance,
Chris
Re: [julia-users] problem with bigfloat precision
Using the log2 function does what you expect: julia log2(big(2)^100) 1e+02 with 256 bits of precision log(b,x) is defined as log(x)./log(b) https://github.com/JuliaLang/julia/blob/9a47c3b833758c1170ffc428eb6162fdae887111/base/math.jl#L94 whereas log2 makes a direct call to the mpfr_log2 function. I'm not sure if there's a clever way to make this work better besides having cases in the definition of log(b,x) that call log(x), log2(x) and log10(x) when appropriate. On Thu, May 14, 2015 at 12:29 PM, harven har...@free.fr wrote: There is something I don't understand with bigfloat precision. I have some task where I need to compute exactly with a thousand significant digit. I wrote a small benchmark, just by taking a power of two and its logarithm. julia with_bigfloat_precision(10_000) do log(2,big(2)^100) end 1.33456773379254076470278870835616524546375 [long string of random digits] 9219723375649773e+02 with 1 bits of precision I would have expected to obtain 1.000... with a far better precision (at least 600 zeros after the point). What I am doing wrong here?
Re: [julia-users] Determine if an array is memory-mapped?
As far as I can tell, we don't store this information [1] -- mmap_array simply calls pointer_to_array [2] on the address returned by mmap, and at that point the array is just like any other created from a pointer. Your idea to to try writing to the array may actually be the least heavy-handed possibility I can think of! But for the sake of ...completeness... here are a few other ideas: - mmap_array attaches a finalizer to the object. I don't think we have an API to look at finalizers right now, but we could potentially add a few lines of C code in gc.c to introspect whether a finalizer is attached to an object, then see whether that finalizer is calling Libdl.munmap. - find an API that allows to check whether a pointer is mmap'd (unfortunately I didn't see an obvious candidate in a quick scan of the POSIX shm docs) - relatedly: on Linux, you could look at /proc/PID/maps and see if the pointer comes from one of those regions (see e.g. [4]) [1] https://github.com/JuliaLang/julia/blob/master/src/julia.h#L151-L162 [2] https://github.com/JuliaLang/julia/blob/861f02712eb4b41c08fed3f21c5a4206b8d669bc/base/mmap.jl#L78 [3] https://github.com/JuliaLang/julia/blob/861f02712eb4b41c08fed3f21c5a4206b8d669bc/base/mmap.jl#L79 [4] http://stackoverflow.com/questions/1401359/understanding-linux-proc-id-maps On Wed, May 13, 2015 at 2:29 PM, Douglas Bates dmba...@gmail.com wrote: Is there a way to determine if an array is memory-mapped? I know that if the file was opened read-only then trying to write to the array throws an error but that seems a rather heavy-handed approach. Perhaps this is not possible because the memory-mapped file behaves just like a chunk of memory.
Re: [julia-users] problem with bigfloat precision
Yes, I do think that's a good solution. On Thu, May 14, 2015 at 2:32 PM, harven har...@free.fr wrote: Thanks for the answer. I understand now. So log(2,x) is log(x)/log(2) and the denominator is a Float64 so we don't get the desired precision. So I can just write julia with_bigfloat_precision(10_000) do log(big(2)^10_000)/log(big(2)) end 1e+04 with 1 bits of precision A solution maybe is to promote the base to the same type as the argument? julia mylog(b,x) = log(x)/log(oftype(x,b)) mylog (generic function with 1 method) julia with_bigfloat_precision(10_000) do mylog(2,big(2)^10_000) end 1e+04 with 1 bits of precision
Re: [julia-users] problem with bigfloat precision
Thanks for the answer. I understand now. So log(2,x) is log(x)/log(2) and the denominator is a Float64 so we don't get the desired precision. So I can just write julia with_bigfloat_precision(10_000) do log(big(2)^10_000)/log(big(2)) end 1e+04 with 1 bits of precision A solution maybe is to promote the base to the same type as the argument? julia mylog(b,x) = log(x)/log(oftype(x,b)) mylog (generic function with 1 method) julia with_bigfloat_precision(10_000) do mylog(2,big(2)^10_000) end 1e+04 with 1 bits of precision
Re: [julia-users] Re: Mysterious errors due to new Tuple{S,V}
On Thu, May 14, 2015 at 11:02 AM, David P. Sanders dpsand...@gmail.com wrote:
El miércoles, 13 de mayo de 2015, 23:51:33 (UTC-5), Sheehan Olver escribió:
This is for latest build of 0.4 on Mac OS X Yosemite
On Thursday, May 14, 2015 at 2:51:07 PM UTC+10, Sheehan Olver wrote:
I get the error message below, and cannot find any sign of the cause.
With debug statements, I found that its dying trying to call a function with
the signature
function
linsolve{T:Operator,N:Number}(A::Vector{T},b::Array{N};tolerance=0.01,maxlength=100)
Here, `Array{N}` is a strange type. Do you mean `Array{T, N}`? Or what kind
of object should `b` be?
The `N` here should be fine since `N:Number`. It is indeed a little
bit confusing given `N` is often used as the name of a number
parameter but it shouldn't cause any issue.
I guess it will probably help to see the code that is calling this
function to tell what exactly is wrong.
David.
...
end
Any thoughts? Maybe its a bug in Julia?
TypeError: subtype: expected Type{T}, got Tuple{TypeVar,TypeVar}
in abstract_call_gf at ./inference.jl:586
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_interpret at ./inference.jl:1080
in typeinf_uncached at ./inference.jl:1518
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_call at ./inference.jl:817
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_call at ./inference.jl:817
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_interpret at ./inference.jl:1080
in typeinf_uncached at ./inference.jl:1518
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_interpret at ./inference.jl:1080
in typeinf_uncached at ./inference.jl:1518
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf_ext at ./inference.jl:1251
in linsolve at
/Users/solver/.julia/v0.4/ApproxFun/src/Operators/linsolve.jl:108
in linsolve at
/Users/solver/.julia/v0.4/ApproxFun/src/Operators/linsolve.jl:126
in linsolve at
/Users/solver/.julia/v0.4/ApproxFun/src/Operators/linsolve.jl:130
in ./ at
[julia-users] problem with bigfloat precision
There is something I don't understand with bigfloat precision. I have some task where I need to compute exactly with a thousand significant digit. I wrote a small benchmark, just by taking a power of two and its logarithm. julia with_bigfloat_precision(10_000) do log(2,big(2)^100) end 1.33456773379254076470278870835616524546375 [long string of random digits] 9219723375649773e+02 with 1 bits of precision I would have expected to obtain 1.000... with a far better precision (at least 600 zeros after the point). What I am doing wrong here?
[julia-users] error compiling fill!: box: argument not of a primitive type
Hi,
I'm returning to Julia after a long break (a year?) and am trying to get
some old code I had lying around compiling.
When I try to run tests for https://github.com/andrewcooke/IntModN.jl (at
4bc2734b80a15108ff66fd61705681e9d50a94c1) I see the error:
andrew@laptop:~/project/IntModN julia -e 'Pkg.test(IntModN)'
INFO: Computing test dependencies for IntModN...
INFO: Installing Polynomial v0.1.1
INFO: Testing IntModN
ERROR: LoadError: error compiling tests: error compiling tests_p2: error
compiling test_p2_show: error compiling print_to_string: error compiling
_convert: error compiling fill!: box: argument not of a primitive type
in include at ./boot.jl:252
in include_from_node1 at loading.jl:134
in process_options at ./client.jl:310
in _start at ./client.jl:409
while loading /home/andrew/.julia/v0.4/IntModN/test/runtests.jl, in
expression starting on line 5
which seems to be triggered by the code at
https://github.com/andrewcooke/IntModN.jl/blob/d138efabf7112bdb961e66b281dea40838e06f4f/src/IntModN.jl#L533
:
function _convert{T, F}(::Type{T}, from::F)
result, mask = zero(T), one(T)
for _ in 1:length(from)
if from one(F) != zero(F)
result += mask
end
from = 1
mask = 1
end
result
end
which is (as far as I can tell / remember) just converting from one
representation of a polynomial in GF2 to another (from a bit pattern to an
explicit polynomial).
I am pretty sure this code worked just fine. Has something changed in
Julia? Is this a bug? Should I be using a stable version of Julia these
days rather than git?
Any guidance appreciated. It seems like a low-level error (I don't
remember having to care about boxing!) and I can't find much info googling.
Thanks,
Andrew
[julia-users] ploting a line in a 3D surface
Hi, I'm trying to plot a line segment between the points [1,1] and [0,0] in Z function x^2 + y^2, i've already plotted f with: using PyPlot using Distributions function f(x) return (x[1]^2 + x[2]^2) #return sin(x[1]) + cos(x[2]) end n = 100 x = linspace(-1, 1, n) y = linspace(-1,1,n) xgrid = repmat(x',n,1) ygrid = repmat(y,1,n) z = zeros(n,n) for i in 1:n for j in 1:n z[i:i,j:j] = f([x[i],y[j]]) end end plot_wireframe(xgrid,ygrid,z) I know already about R (ggplot2) and C, but i'm new with python and julia librarys like matlibplot
Re: [julia-users] Re: verbs for immutable collections
I don't think it should be allowed. What if two packages try to add functions with the same name to Base that do completely different things? And what if they are both applicable to some of the same argument types? Beyond that, I think being able to add definitions to a module from the outside comes with an extra set of problems. What if you define a function that shadows a function that it was using from another module? What if there was a big where someone was trying to access a function from another module that wasn't there, but is was named because the function had been introduced from the outside?
[julia-users] Re: problem with bigfloat precision
I would think it is even more robust a definition like mylog(b, x) = (promote(b, x); log(x) ./ log(b)) in case someone wants to write mylog(2.1, 2). Stefan, should this be the definition in Base?
[julia-users] Re: error compiling fill!: box: argument not of a primitive type
Well, this all works fine with 0.3, so I'm going to chalk this up to weirdness in git trunk 0.4 (the above was with git as of an hour or so before posting). Andrew
Re: [julia-users] use dictionary as named arguments for function
To whom it may concern:
I am having trouble adding elements to my dictionary and then passing it
into a function:
function f(;kw...)
for (k,v) in kw
println(k,,,v)
end
end
d = {:a = 1, :b = c} # this works
# d = Dict() # but this line
# d[d] = 2 # with this fails
f(;d...)
Thanks,
Ed
On Tuesday, October 15, 2013 at 9:46:17 PM UTC-4, Jeff Bezanson wrote:
Although converting a string to a symbol is reasonably efficient, it's too
much extra work to do for something like a function call where every cycle
counts. You could easily end up doing this work repeatedly, for each one of
many calls. It also might lead somebody to think strings are equally valid
in this context, and use them exclusively, which I would consider a
performance trap.
On Aug 7, 2013 3:04 PM, Westley Hennigh westley...@gmail.com
javascript: wrote:
I think the issue is transparency for the user. If they have a dictionary
and get an error when they call (I kind of like Elliot's
name) `dictsplat()`, it's pretty obvious what the problem is. If they just
use the dictionary of strings and we do the conversion for them it might
not be as clear.
On Wednesday, August 7, 2013 12:55:42 AM UTC-7, Ivar Nesje wrote:
What is the problem with having minus or space in a symbol? You'd have
to generate the code using Expr() and symbol(var-with minusspace), as
the parser uses those characters as delimiters when it parses code. Errors
should be given when you use a dictionary with keys that does not match the
keyword arguments of the function, so there is no reason to give a
different error if some of the characters should be invalid.
Ivar
kl. 07:40:50 UTC+2 tirsdag 6. august 2013 skrev Elliot Saba følgende:
One of the problems with this is that strings have quite a bit more
leeway in what they can contain than symbols. What happens if your
strings
have spaces? Or minus symbols? Getting an error from the `symbol()`
function while trying to splat a dictionary seems like it might be
confusing.
If doing this conversion automatically wouldn't take too much cpu time,
then doing it manually won't take too much cpu time either. :) It should
be pretty straightfoward to write e.g. a `dictsplat()` function that
converts any string keys to symbols, and throws a meaningful error if they
are unable to do so.
On Mon, Aug 5, 2013 at 6:38 PM, Westley Hennigh westley...@gmail.com
wrote:
Hmm, maybe it is. I'm a partial judge.
But just to be clear: I don't want to actually modify the dict or
pursue this if it will be considerably slower.
I do think it's fairly unambiguous. And if you pulled a dictionary out
of some json and wanted to use it as parameters, I think this would seem
pretty straightforward / convenient.
On Monday, August 5, 2013 6:08:12 PM UTC-7, Jacob Quinn wrote:
Auto-converting strings to symbols in this case seems pretty
auto-magical (in a bad way). I would just expect the user to call the
symbol(x) call themselves before passing them in.
-Jacob
On Monday, August 5, 2013 8:01:56 PM UTC-5, Westley Hennigh wrote:
Ok, I have -perhaps- a slightly more interesting question based on
this.
In your above example, suppose you have a dict `d = {x = 3, y
= 4}`. Note the strings.
If you called your function f with said dict, I think (could be
wrong) that what you're after is pretty unambiguous (to treat the
strings
as symbols). What's more, I think that the conversion between strings
and
symbols can be pretty cheap.
So maybe we could add support for more efficiently calling functions
with dictionaries of strings of named args (without generating one
containing symbols).
I see line 429 in https://github.com/JuliaLang/julia/blob/master/
src/julia-syntax.scm, I think dictionaries are being expanded
around like 1670 and then passed as an unsorted list. So maybe this
wouldn't be more efficient... Not sure, are you more familiar with this
code?
On Monday, August 5, 2013 5:14:02 PM UTC-7, Westley Hennigh wrote:
Lol. I apologize for taking your time, thanks!
On Monday, August 5, 2013 5:08:45 PM UTC-7, Mike Nolta wrote:
```
julia f(;x=0,y=0) = (x,y)
# methods for generic function f
f() at none:1
julia d = {:x = 3, :y = 4}
{:y=4,:x=3}
julia f(;d...)
(3,4)
```
-Mike
On Mon, Aug 5, 2013 at 8:02 PM, Westley Hennigh
westley...@gmail.com wrote:
Heh, ya, but I can always pass a dictionary. It would be sweet
if the names
could be broken out so that you can read the defaults and we
don't end up
with big blocks of `get(args, thing, default)` at the top of
functions.
On Monday, August 5, 2013 4:53:55 PM UTC-7, Mike Nolta wrote:
```
julia f(;kw...) = for (k,v) in kw; println(k,,,v); end
# methods for generic function f
f() at none:1
julia d = {:a = 1, :b = c}
{:b=c,:a=1}
julia f(;d...)
b,c
a,1
```
-Mike
On Mon, Aug 5, 2013 at 7:17 PM,
Re: [julia-users] use dictionary as named arguments for function
I believe you want
d[:d] = 2
Peter.
On Thursday, May 14, 2015 at 1:25:58 PM UTC-6, Edward Chen wrote:
To whom it may concern:
I am having trouble adding elements to my dictionary and then passing it
into a function:
function f(;kw...)
for (k,v) in kw
println(k,,,v)
end
end
d = {:a = 1, :b = c} # this works
# d = Dict() # but this line
# d[d] = 2 # with this fails
f(;d...)
Thanks,
Ed
On Tuesday, October 15, 2013 at 9:46:17 PM UTC-4, Jeff Bezanson wrote:
Although converting a string to a symbol is reasonably efficient, it's
too much extra work to do for something like a function call where every
cycle counts. You could easily end up doing this work repeatedly, for each
one of many calls. It also might lead somebody to think strings are equally
valid in this context, and use them exclusively, which I would consider a
performance trap.
On Aug 7, 2013 3:04 PM, Westley Hennigh westley...@gmail.com wrote:
I think the issue is transparency for the user. If they have a
dictionary and get an error when they call (I kind of like Elliot's
name) `dictsplat()`, it's pretty obvious what the problem is. If they just
use the dictionary of strings and we do the conversion for them it might
not be as clear.
On Wednesday, August 7, 2013 12:55:42 AM UTC-7, Ivar Nesje wrote:
What is the problem with having minus or space in a symbol? You'd have
to generate the code using Expr() and symbol(var-with minusspace), as
the parser uses those characters as delimiters when it parses code. Errors
should be given when you use a dictionary with keys that does not match
the
keyword arguments of the function, so there is no reason to give a
different error if some of the characters should be invalid.
Ivar
kl. 07:40:50 UTC+2 tirsdag 6. august 2013 skrev Elliot Saba følgende:
One of the problems with this is that strings have quite a bit more
leeway in what they can contain than symbols. What happens if your
strings
have spaces? Or minus symbols? Getting an error from the `symbol()`
function while trying to splat a dictionary seems like it might be
confusing.
If doing this conversion automatically wouldn't take too much cpu
time, then doing it manually won't take too much cpu time either. :) It
should be pretty straightfoward to write e.g. a `dictsplat()` function
that
converts any string keys to symbols, and throws a meaningful error if
they
are unable to do so.
On Mon, Aug 5, 2013 at 6:38 PM, Westley Hennigh westley...@gmail.com
wrote:
Hmm, maybe it is. I'm a partial judge.
But just to be clear: I don't want to actually modify the dict or
pursue this if it will be considerably slower.
I do think it's fairly unambiguous. And if you pulled a dictionary
out of some json and wanted to use it as parameters, I think this would
seem pretty straightforward / convenient.
On Monday, August 5, 2013 6:08:12 PM UTC-7, Jacob Quinn wrote:
Auto-converting strings to symbols in this case seems pretty
auto-magical (in a bad way). I would just expect the user to call the
symbol(x) call themselves before passing them in.
-Jacob
On Monday, August 5, 2013 8:01:56 PM UTC-5, Westley Hennigh wrote:
Ok, I have -perhaps- a slightly more interesting question based on
this.
In your above example, suppose you have a dict `d = {x = 3, y
= 4}`. Note the strings.
If you called your function f with said dict, I think (could be
wrong) that what you're after is pretty unambiguous (to treat the
strings
as symbols). What's more, I think that the conversion between strings
and
symbols can be pretty cheap.
So maybe we could add support for more efficiently calling
functions with dictionaries of strings of named args (without
generating
one containing symbols).
I see line 429 in https://github.com/JuliaLang/julia/blob/master/
src/julia-syntax.scm, I think dictionaries are being expanded
around like 1670 and then passed as an unsorted list. So maybe this
wouldn't be more efficient... Not sure, are you more familiar with
this
code?
On Monday, August 5, 2013 5:14:02 PM UTC-7, Westley Hennigh wrote:
Lol. I apologize for taking your time, thanks!
On Monday, August 5, 2013 5:08:45 PM UTC-7, Mike Nolta wrote:
```
julia f(;x=0,y=0) = (x,y)
# methods for generic function f
f() at none:1
julia d = {:x = 3, :y = 4}
{:y=4,:x=3}
julia f(;d...)
(3,4)
```
-Mike
On Mon, Aug 5, 2013 at 8:02 PM, Westley Hennigh
westley...@gmail.com wrote:
Heh, ya, but I can always pass a dictionary. It would be sweet
if the names
could be broken out so that you can read the defaults and we
don't end up
with big blocks of `get(args, thing, default)` at the top of
functions.
On Monday, August 5, 2013 4:53:55 PM UTC-7, Mike Nolta wrote:
```
julia f(;kw...) = for (k,v) in kw; println(k,,,v); end
# methods for generic function f
f() at none:1
julia d = {:a = 1, :b
Re: [julia-users] problem with bigfloat precision
On Thursday, May 14, 2015 at 3:46:25 PM UTC-4, Stefan Karpinski wrote: On Thu, May 14, 2015 at 3:43 PM, Steven G. Johnson steve...@gmail.com javascript: wrote: I think the right thing would be for log(b,x) to first promote its arguments to the same type. Otherwise, you run into the problem here where you have a spurious loss of accuracy. I'll file a PR. Is this different than what my PR does? No. What happened was that I wrote my response and my PR, then a student came into my office and we talked for a couple hours, and then I turned back to my computer and hit post and then pushed the PR, not realizing that you'd arrived at the same solution in the meantime.
Re: [julia-users] error compiling fill!: box: argument not of a primitive type
Hi Andrew, could you file an issue? Cheers, Kevin On Thursday, May 14, 2015, andrew cooke and...@acooke.org wrote: Well, this all works fine with 0.3, so I'm going to chalk this up to weirdness in git trunk 0.4 (the above was with git as of an hour or so before posting). Andrew
Re: [julia-users] problem with bigfloat precision
On Thu, May 14, 2015 at 3:43 PM, Steven G. Johnson stevenj@gmail.com wrote: I think the right thing would be for log(b,x) to first promote its arguments to the same type. Otherwise, you run into the problem here where you have a spurious loss of accuracy. I'll file a PR. Is this different than what my PR does?
[julia-users] Re: problem with bigfloat precision
Nevermind I saw your PR.
Re: [julia-users] Re: problem with bigfloat precision
Just waiting for CI to pass: https://github.com/JuliaLang/julia/pull/11269. On Thu, May 14, 2015 at 3:14 PM, Pablo Zubieta pablof...@gmail.com wrote: Nevermind I saw your PR.
Re: [julia-users] use dictionary as named arguments for function
Ah yeah that works!
The wikibooks documentation is wrong then, maybe i'll correct it:
http://en.wikibooks.org/wiki/Introducing_Julia/Dictionaries_and_sets
On Thursday, May 14, 2015 at 4:08:45 PM UTC-4, Peter Brady wrote:
I believe you want
d[:d] = 2
Peter.
On Thursday, May 14, 2015 at 1:25:58 PM UTC-6, Edward Chen wrote:
To whom it may concern:
I am having trouble adding elements to my dictionary and then passing it
into a function:
function f(;kw...)
for (k,v) in kw
println(k,,,v)
end
end
d = {:a = 1, :b = c} # this works
# d = Dict() # but this line
# d[d] = 2 # with this fails
f(;d...)
Thanks,
Ed
On Tuesday, October 15, 2013 at 9:46:17 PM UTC-4, Jeff Bezanson wrote:
Although converting a string to a symbol is reasonably efficient, it's
too much extra work to do for something like a function call where every
cycle counts. You could easily end up doing this work repeatedly, for each
one of many calls. It also might lead somebody to think strings are equally
valid in this context, and use them exclusively, which I would consider a
performance trap.
On Aug 7, 2013 3:04 PM, Westley Hennigh westley...@gmail.com wrote:
I think the issue is transparency for the user. If they have a
dictionary and get an error when they call (I kind of like Elliot's
name) `dictsplat()`, it's pretty obvious what the problem is. If they just
use the dictionary of strings and we do the conversion for them it might
not be as clear.
On Wednesday, August 7, 2013 12:55:42 AM UTC-7, Ivar Nesje wrote:
What is the problem with having minus or space in a symbol? You'd have
to generate the code using Expr() and symbol(var-with minusspace), as
the parser uses those characters as delimiters when it parses code.
Errors
should be given when you use a dictionary with keys that does not match
the
keyword arguments of the function, so there is no reason to give a
different error if some of the characters should be invalid.
Ivar
kl. 07:40:50 UTC+2 tirsdag 6. august 2013 skrev Elliot Saba følgende:
One of the problems with this is that strings have quite a bit more
leeway in what they can contain than symbols. What happens if your
strings
have spaces? Or minus symbols? Getting an error from the `symbol()`
function while trying to splat a dictionary seems like it might be
confusing.
If doing this conversion automatically wouldn't take too much cpu
time, then doing it manually won't take too much cpu time either. :)
It
should be pretty straightfoward to write e.g. a `dictsplat()` function
that
converts any string keys to symbols, and throws a meaningful error if
they
are unable to do so.
On Mon, Aug 5, 2013 at 6:38 PM, Westley Hennigh westley...@gmail.com
wrote:
Hmm, maybe it is. I'm a partial judge.
But just to be clear: I don't want to actually modify the dict or
pursue this if it will be considerably slower.
I do think it's fairly unambiguous. And if you pulled a dictionary
out of some json and wanted to use it as parameters, I think this would
seem pretty straightforward / convenient.
On Monday, August 5, 2013 6:08:12 PM UTC-7, Jacob Quinn wrote:
Auto-converting strings to symbols in this case seems pretty
auto-magical (in a bad way). I would just expect the user to call the
symbol(x) call themselves before passing them in.
-Jacob
On Monday, August 5, 2013 8:01:56 PM UTC-5, Westley Hennigh wrote:
Ok, I have -perhaps- a slightly more interesting question based on
this.
In your above example, suppose you have a dict `d = {x = 3, y
= 4}`. Note the strings.
If you called your function f with said dict, I think (could be
wrong) that what you're after is pretty unambiguous (to treat the
strings
as symbols). What's more, I think that the conversion between strings
and
symbols can be pretty cheap.
So maybe we could add support for more efficiently calling
functions with dictionaries of strings of named args (without
generating
one containing symbols).
I see line 429 in https://github.com/JuliaLang/julia/blob/master/
src/julia-syntax.scm, I think dictionaries are being expanded
around like 1670 and then passed as an unsorted list. So maybe this
wouldn't be more efficient... Not sure, are you more familiar with
this
code?
On Monday, August 5, 2013 5:14:02 PM UTC-7, Westley Hennigh wrote:
Lol. I apologize for taking your time, thanks!
On Monday, August 5, 2013 5:08:45 PM UTC-7, Mike Nolta wrote:
```
julia f(;x=0,y=0) = (x,y)
# methods for generic function f
f() at none:1
julia d = {:x = 3, :y = 4}
{:y=4,:x=3}
julia f(;d...)
(3,4)
```
-Mike
On Mon, Aug 5, 2013 at 8:02 PM, Westley Hennigh
westley...@gmail.com wrote:
Heh, ya, but I can always pass a dictionary. It would be sweet
if the names
could be broken out so that you can read the defaults and we
don't end up
with big blocks of `get(args, thing, default)` at the top
[julia-users] 0.3 prereleases should not be tagged.
please can someone explain to me what the subject means, in the conversation here - https://github.com/JuliaLang/METADATA.jl/pull/2589 i understand waiting for travis - there was some warning i shouldn't have clicked through - but i have no idea what prerelease is referring to. thanks, i'd just like to wrap this up and go to bed, andrew
[julia-users] Re: Julia will always be open source
Here is a related question: Who will own and operate the julialang.org domain? Would you be willing to transfer it to NumFocus or a similar nonprofit, community entity? On Monday, May 11, 2015 at 10:55:00 AM UTC-7, Brian Granger wrote: Congrats on Julia Computing stuff! We (IPython/Jupyter) are always thinking about various approaches to making open source sustainable and it is great to see explorations like this. I wish you the best of success!!! I wanted to share some thoughts and questions about trademark as it relates to open source projects. These thoughts have come out of many years of thinking about, and even enforcing, trademarks in the context of Jupyter/IPython. With IPython/Jupyter, the yet-to-be-filed trademarks (there is a bit of subtlety about the IPython trademark - that is another topic) will belong to our non-profit sponsor, NumFocus (we will transfer it to them). Along with that, we will be developing a trademark usage policy that clarifies to the community how our names and logos can be used. I am guessing that our policy will be similar to that of other open source projects like Python: https://www.python.org/psf/trademarks/ It is likely that we will have a trademark policy that allows generous usage of the names IPython/Jupyter by the open source community, but we would not allow companies to use the trademarks in ways that would confuse users. A company could say our platform uses the open source Project Jupyter but not our company is called JupyterFoo. IANAL, but it is my understanding that the bar for trademark confusion is relatively low and that there is a real danger to not enforcing trademarks, so these issues are important to understand. I think you can see where this is going wrt Julia... * Who holds the trademarks on Julia? NumFocus, an individual or Julia Computing? * What is the trademark policy of that entity? If it doesn't exist, who will create it? * Is Julia Computing infringing upon the Julia trademark? Has the trademark owner given permission to Julia Compute to use the trademark? * By using the name Julia in the company and open source project, is the trademark owner creating a precedence of not enforcing the trademark? * Do you want *other* companies to be allowed to use Julia trademarks in their name? I want to be clear - I am all for commercialization efforts around open source and am very excited about where Julia is headed. I also don't have any ideas about what the answers to these questions should be for your community. Cheers, Brian On Saturday, May 9, 2015 at 1:20:15 PM UTC-7, Viral Shah wrote: Hello all, You may have seen today’s Hacker News story about Julia Computing: https://news.ycombinator.com/item?id=9516298 As you all know, we are committed to Julia being high quality and open source. The existence of Julia Computing was discussed a year ago at JuliaCon 2014, though we recognize that not everyone is aware. We set up Julia Computing to assist those who asked for help building Julia applications and deploying Julia in production. We want Julia to be widely adopted by the open source community, for research in academia, and for production software in companies. Julia Computing provides support, consulting, and training for customers, in order to help them build and deploy Julia applications. We are committed to all the three organizations that focus on different users and use cases of Julia: 1. The open source Julia project is housed at the NumFocus Foundation. http://numfocus.org/projects/ 2. Research on various aspects of Julia is anchored in Alan’s group at MIT. http://www-math.mit.edu/~edelman/research.php 3. Julia Computing works with customers who are building Julia applications. http://www.juliacomputing.com/ Our customers make Julia Computing self-funded. We are grateful that they have created full time opportunities for us to follow our passions. Open source development will never cease. You may have questions. Please shoot them here. We will respond back with a detailed blog post. -viral
Re: [julia-users] 0.3 prereleases should not be tagged.
No problem; what he's referring to is the fact that the version number you've put there, `julia 0.3-` doesn't actually refer to julia 0.3; it refers to a version of Julia that is *before* Julia 0.3, e.g. a 0.3 prerelease. You should get rid of the minus sign, and all will be okay. -E On Thu, May 14, 2015 at 4:11 PM, andrew cooke and...@acooke.org wrote: please can someone explain to me what the subject means, in the conversation here - https://github.com/JuliaLang/METADATA.jl/pull/2589 i understand waiting for travis - there was some warning i shouldn't have clicked through - but i have no idea what prerelease is referring to. thanks, i'd just like to wrap this up and go to bed, andrew
Re: [julia-users] Re: Mysterious errors due to new Tuple{S,V}
Found it!!The following definition was not updated. It seems very
weird that this triggered an error message while compiling a completely
unrelated routine...
immutable KroneckerOperator{S,V,DS,RS,T}: BivariateOperator{T}
ops::(S,V)
domainspace::DS
rangespace::RS
end
On 15 May 2015, at 1:09 am, Yichao Yu yyc1...@gmail.com wrote:
On Thu, May 14, 2015 at 11:02 AM, David P. Sanders dpsand...@gmail.com
mailto:dpsand...@gmail.com wrote:
El miércoles, 13 de mayo de 2015, 23:51:33 (UTC-5), Sheehan Olver escribió:
This is for latest build of 0.4 on Mac OS X Yosemite
On Thursday, May 14, 2015 at 2:51:07 PM UTC+10, Sheehan Olver wrote:
I get the error message below, and cannot find any sign of the cause.
With debug statements, I found that its dying trying to call a function
with
the signature
function
linsolve{T:Operator,N:Number}(A::Vector{T},b::Array{N};tolerance=0.01,maxlength=100)
Here, `Array{N}` is a strange type. Do you mean `Array{T, N}`? Or what kind
of object should `b` be?
The `N` here should be fine since `N:Number`. It is indeed a little
bit confusing given `N` is often used as the name of a number
parameter but it shouldn't cause any issue.
I guess it will probably help to see the code that is calling this
function to tell what exactly is wrong.
David.
...
end
Any thoughts? Maybe its a bug in Julia?
TypeError: subtype: expected Type{T}, got Tuple{TypeVar,TypeVar}
in abstract_call_gf at ./inference.jl:586
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_interpret at ./inference.jl:1080
in typeinf_uncached at ./inference.jl:1518
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_call at ./inference.jl:817
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_call at ./inference.jl:817
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_interpret at ./inference.jl:1080
in typeinf_uncached at ./inference.jl:1518
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_interpret at ./inference.jl:1080
in typeinf_uncached at ./inference.jl:1518
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at
Re: [julia-users] 0.3 prereleases should not be tagged.
thanks, fixed. On Thursday, 14 May 2015 21:05:42 UTC-3, Elliot Saba wrote: No problem; what he's referring to is the fact that the version number you've put there, `julia 0.3-` doesn't actually refer to julia 0.3; it refers to a version of Julia that is *before* Julia 0.3, e.g. a 0.3 prerelease. You should get rid of the minus sign, and all will be okay. -E On Thu, May 14, 2015 at 4:11 PM, andrew cooke and...@acooke.org javascript: wrote: please can someone explain to me what the subject means, in the conversation here - https://github.com/JuliaLang/METADATA.jl/pull/2589 i understand waiting for travis - there was some warning i shouldn't have clicked through - but i have no idea what prerelease is referring to. thanks, i'd just like to wrap this up and go to bed, andrew
Re: [julia-users] Re: Julia will always be open source
As much as I would like to do so, I also want to have enough funding for the Julia foundation (NumFocus) in place before transferring over community resources. We look at everything closely so that things don't fall through the cracks. For someone else to do that, we need an organisational structure. We are working hard with a couple of folks on funding some people to work full time for the foundation. I welcome any ideas on raising funds to pay for a couple of developers and a part time project manager, to start with. -viral On 15 May 2015 5:47 am, Stefan Karpinski ste...@karpinski.org wrote: Currently I own the domain, but transferring it to NumFocus would be fine if they do that (which I can find out). On Thu, May 14, 2015 at 6:55 PM, Jim Garrison j...@garrison.cc wrote: Here is a related question: Who will own and operate the julialang.org domain? Would you be willing to transfer it to NumFocus or a similar nonprofit, community entity? On Monday, May 11, 2015 at 10:55:00 AM UTC-7, Brian Granger wrote: Congrats on Julia Computing stuff! We (IPython/Jupyter) are always thinking about various approaches to making open source sustainable and it is great to see explorations like this. I wish you the best of success!!! I wanted to share some thoughts and questions about trademark as it relates to open source projects. These thoughts have come out of many years of thinking about, and even enforcing, trademarks in the context of Jupyter/IPython. With IPython/Jupyter, the yet-to-be-filed trademarks (there is a bit of subtlety about the IPython trademark - that is another topic) will belong to our non-profit sponsor, NumFocus (we will transfer it to them). Along with that, we will be developing a trademark usage policy that clarifies to the community how our names and logos can be used. I am guessing that our policy will be similar to that of other open source projects like Python: https://www.python.org/psf/trademarks/ It is likely that we will have a trademark policy that allows generous usage of the names IPython/Jupyter by the open source community, but we would not allow companies to use the trademarks in ways that would confuse users. A company could say our platform uses the open source Project Jupyter but not our company is called JupyterFoo. IANAL, but it is my understanding that the bar for trademark confusion is relatively low and that there is a real danger to not enforcing trademarks, so these issues are important to understand. I think you can see where this is going wrt Julia... * Who holds the trademarks on Julia? NumFocus, an individual or Julia Computing? * What is the trademark policy of that entity? If it doesn't exist, who will create it? * Is Julia Computing infringing upon the Julia trademark? Has the trademark owner given permission to Julia Compute to use the trademark? * By using the name Julia in the company and open source project, is the trademark owner creating a precedence of not enforcing the trademark? * Do you want *other* companies to be allowed to use Julia trademarks in their name? I want to be clear - I am all for commercialization efforts around open source and am very excited about where Julia is headed. I also don't have any ideas about what the answers to these questions should be for your community. Cheers, Brian On Saturday, May 9, 2015 at 1:20:15 PM UTC-7, Viral Shah wrote: Hello all, You may have seen today’s Hacker News story about Julia Computing: https://news.ycombinator.com/item?id=9516298 As you all know, we are committed to Julia being high quality and open source. The existence of Julia Computing was discussed a year ago at JuliaCon 2014, though we recognize that not everyone is aware. We set up Julia Computing to assist those who asked for help building Julia applications and deploying Julia in production. We want Julia to be widely adopted by the open source community, for research in academia, and for production software in companies. Julia Computing provides support, consulting, and training for customers, in order to help them build and deploy Julia applications. We are committed to all the three organizations that focus on different users and use cases of Julia: 1. The open source Julia project is housed at the NumFocus Foundation. http://numfocus.org/projects/ 2. Research on various aspects of Julia is anchored in Alan’s group at MIT. http://www-math.mit.edu/~edelman/research.php 3. Julia Computing works with customers who are building Julia applications. http://www.juliacomputing.com/ Our customers make Julia Computing self-funded. We are grateful that they have created full time opportunities for us to follow our passions. Open source development will never cease. You may have questions. Please shoot them here. We will respond back with a detailed blog post. -viral
Re: [julia-users] Re: Mysterious errors due to new Tuple{S,V}
I’ve narrowed the bug a bit further. But it still doesn’t make any sense.
The offending function is actually
adaptiveqr{T:Operator}(B::Vector{T},v::Array,tol::Real,N) =
adaptiveqr!(AlmostBandedOperator(B),convertvec(B[end],v),tol,N) #May need to
copy v in the future
But calling the line itself doesn’t help. I can’t even @code_typed the
function call!
julia using ApproxFun
julia d=Interval(-10.,5.);
julia Bm=Evaluation(d,d.a);
julia Bp=Evaluation(d,d.b);
julia B=[Bm;Bp];
julia D2=Derivative(d,2);
julia X=Multiplication(Fun(x-x,d));
julia A=[B;D2-X];b=[airyai(d.a),airyai(d.b),0.]
3-element Array{Float64,1}:
0.0402412
0.000108344
0.0
julia methods(ApproxFun.adaptiveqr)
# 4 methods for generic function adaptiveqr:
adaptiveqr(B::ApproxFun.Operator{T},v::Array{T,N},tol::Real,N) at
/Users/solver/.julia/v0.4/ApproxFun/src/Operators/adaptiveqr.jl:170
adaptiveqr{T:ApproxFun.Operator{T}}(B::Array{T:ApproxFun.Operator{T},1},v::Array{T,N},tol::Real,N)
at /Users/solver/.julia/v0.4/ApproxFun/src/Operators/adaptiveqr.jl:171
adaptiveqr(M,b) at
/Users/solver/.julia/v0.4/ApproxFun/src/Operators/adaptiveqr.jl:135
adaptiveqr(M,b,tol) at
/Users/solver/.julia/v0.4/ApproxFun/src/Operators/adaptiveqr.jl:136
julia @code_typed ApproxFun.adaptiveqr(A,b)
ERROR: TypeError: subtype: expected Type{T}, got Tuple{TypeVar,TypeVar}
in abstract_call_gf at ./inference.jl:586
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
On 15 May 2015, at 1:09 am, Yichao Yu yyc1...@gmail.com wrote:
On Thu, May 14, 2015 at 11:02 AM, David P. Sanders dpsand...@gmail.com
wrote:
El miércoles, 13 de mayo de 2015, 23:51:33 (UTC-5), Sheehan Olver escribió:
This is for latest build of 0.4 on Mac OS X Yosemite
On Thursday, May 14, 2015 at 2:51:07 PM UTC+10, Sheehan Olver wrote:
I get the error message below, and cannot find any sign of the cause.
With debug statements, I found that its dying trying to call a function
with
the signature
function
linsolve{T:Operator,N:Number}(A::Vector{T},b::Array{N};tolerance=0.01,maxlength=100)
Here, `Array{N}` is a strange type. Do you mean `Array{T, N}`? Or what kind
of object should `b` be?
The `N` here should be fine since `N:Number`. It is indeed a little
bit confusing given `N` is often used as the name of a number
parameter but it shouldn't cause any issue.
I guess it will probably help to see the code that is calling this
function to tell what exactly is wrong.
David.
...
end
Any thoughts? Maybe its a bug in Julia?
TypeError: subtype: expected Type{T}, got Tuple{TypeVar,TypeVar}
in abstract_call_gf at ./inference.jl:586
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_eval_call at ./inference.jl:881
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in abstract_interpret at ./inference.jl:1080
in typeinf_uncached at ./inference.jl:1518
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_call at ./inference.jl:817
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in typeinf_uncached at ./inference.jl:1591
in typeinf at ./inference.jl:1307
in typeinf at ./inference.jl:1257
in abstract_call_gf at ./inference.jl:696
in abstract_call at ./inference.jl:857
in abstract_call at ./inference.jl:817
in abstract_eval_call at ./inference.jl:904
in abstract_eval at ./inference.jl:931
in
Re: [julia-users] Re: Julia will always be open source
Currently I own the domain, but transferring it to NumFocus would be fine if they do that (which I can find out). On Thu, May 14, 2015 at 6:55 PM, Jim Garrison j...@garrison.cc wrote: Here is a related question: Who will own and operate the julialang.org domain? Would you be willing to transfer it to NumFocus or a similar nonprofit, community entity? On Monday, May 11, 2015 at 10:55:00 AM UTC-7, Brian Granger wrote: Congrats on Julia Computing stuff! We (IPython/Jupyter) are always thinking about various approaches to making open source sustainable and it is great to see explorations like this. I wish you the best of success!!! I wanted to share some thoughts and questions about trademark as it relates to open source projects. These thoughts have come out of many years of thinking about, and even enforcing, trademarks in the context of Jupyter/IPython. With IPython/Jupyter, the yet-to-be-filed trademarks (there is a bit of subtlety about the IPython trademark - that is another topic) will belong to our non-profit sponsor, NumFocus (we will transfer it to them). Along with that, we will be developing a trademark usage policy that clarifies to the community how our names and logos can be used. I am guessing that our policy will be similar to that of other open source projects like Python: https://www.python.org/psf/trademarks/ It is likely that we will have a trademark policy that allows generous usage of the names IPython/Jupyter by the open source community, but we would not allow companies to use the trademarks in ways that would confuse users. A company could say our platform uses the open source Project Jupyter but not our company is called JupyterFoo. IANAL, but it is my understanding that the bar for trademark confusion is relatively low and that there is a real danger to not enforcing trademarks, so these issues are important to understand. I think you can see where this is going wrt Julia... * Who holds the trademarks on Julia? NumFocus, an individual or Julia Computing? * What is the trademark policy of that entity? If it doesn't exist, who will create it? * Is Julia Computing infringing upon the Julia trademark? Has the trademark owner given permission to Julia Compute to use the trademark? * By using the name Julia in the company and open source project, is the trademark owner creating a precedence of not enforcing the trademark? * Do you want *other* companies to be allowed to use Julia trademarks in their name? I want to be clear - I am all for commercialization efforts around open source and am very excited about where Julia is headed. I also don't have any ideas about what the answers to these questions should be for your community. Cheers, Brian On Saturday, May 9, 2015 at 1:20:15 PM UTC-7, Viral Shah wrote: Hello all, You may have seen today’s Hacker News story about Julia Computing: https://news.ycombinator.com/item?id=9516298 As you all know, we are committed to Julia being high quality and open source. The existence of Julia Computing was discussed a year ago at JuliaCon 2014, though we recognize that not everyone is aware. We set up Julia Computing to assist those who asked for help building Julia applications and deploying Julia in production. We want Julia to be widely adopted by the open source community, for research in academia, and for production software in companies. Julia Computing provides support, consulting, and training for customers, in order to help them build and deploy Julia applications. We are committed to all the three organizations that focus on different users and use cases of Julia: 1. The open source Julia project is housed at the NumFocus Foundation. http://numfocus.org/projects/ 2. Research on various aspects of Julia is anchored in Alan’s group at MIT. http://www-math.mit.edu/~edelman/research.php 3. Julia Computing works with customers who are building Julia applications. http://www.juliacomputing.com/ Our customers make Julia Computing self-funded. We are grateful that they have created full time opportunities for us to follow our passions. Open source development will never cease. You may have questions. Please shoot them here. We will respond back with a detailed blog post. -viral
Re: [julia-users] Example of imread from an imagemagick stream
Thanks! OK, I finally found the commit you were talking about (commit 7ba0d6093c093acfc5c1d71fa3cad1ff33bccdfc). I managed to find an example for the stuff I wanted: cmd = `convert $filename -depth $bitdepth $colorspace:-` stream, _ = readsfrom(cmd) nchannels = length(colorspace) data = read(stream, T, nchannels, sz...) But I couldn't find this mysterious readsfrom. I suspect it's something to do with OSX (I'm on linux). I blindly switched it with readandwrite on a complete whim. And it works!!! I'll be happy to know if this is sub-optimal. On Friday, May 15, 2015 at 12:08:01 AM UTC+10, Tim Holy wrote: If you dig through the commit history of Images.jl, at some point you'll find the commit that switched from using Cmd to the C api for interacting with ImageMagick. That should have quite a few examples. --Tim On Thursday, May 14, 2015 05:25:19 AM Yakir Gagnon wrote: Can someone please post a simple example of reading an image stream from imagemagick? So something like this (though this doesn't work): cmd = `convert img.png do some imagemagick things that I wish I could do with Images.jl but are only possible with imagemagick -compress none ppm:-` I = imread(readall(cmd),Images.PPMBinary) I'm trying to avoid writing the image imagemagick created to disk and read it straight into julia. The readall(cmd) part works awesome, it spews all the image bits to the stdout. But I can't get imread to pick it up as an image. Thanks in advance!
Re: [julia-users] Julia will always be open source
I am one of the more recent people to join Julia Computing, so that I am now able to work full-time on Julia. It's been a great way to merge a mutual hobby – of contributing to the open-source Julia project – with day-to-day responsibilities. On Wed, May 13, 2015 at 10:55 AM Scott Jones scott.paul.jo...@gmail.com wrote: Very good to know! I assume Alan is staying on as an MIT professor, evangelizing Julia to bright young MIT students. ;-) What about Keno and Jameson? Digging around shows they are still students (which surprised me a bit... I’ve been very impressed with their comments and contributions). I’d hope that they would think that working full time on Julia at JC would be a great gig after they finish their pesky degrees... The more major contributors are working full-time at JC (or another Julia-centric company), the easier I think it is to “sell” using Julia is to my clients... -Scott On Wednesday, May 13, 2015 at 10:35:41 AM UTC-4, Viral Shah wrote: The co-founders include the three of us, Alan, Keno, and Deepak who is helping develop the business. The team strength is closing in on 12. We will be updating our website shortly with all this information. On the open source part, we have reaffirmed our commitment here. As I said in my earlier email, we will also write a blog post addressing all issues raised here. It seems that most of the questions have already been raised, and some also discussed. We’ll put out a well articulated response in the next few days, so that everything is clear and in one place. -viral On 13-May-2015, at 7:42 pm, Scott Jones scott.pa...@gmail.com wrote: Yes, it was clear that you were also a cofounder of Julia Computing, what was not clear, just from your GitHub info, if you were actively working for JC, or for MIT, or splitting your time between them. I do hope there’s enough funding so that you’ll be able to work full time on the language. Besides Jeff, Viral, and yourself, who else is currently working full or part-time for JC? (just thinking about the initials... is this the “Second Coming, at least for computer languages? ;-) ) This isn’t meant to be overly nosy, however, it is important information for people like me who are trying to convince their clients that 1) any issues they have in Julia can be addressed, 2) Julia will be around for the long haul, and 3) Julia will not suddenly split into an open source version and a closed “enterprise” version that has all the good stuff... (it kind of seems that way with Aerospike, for example). I really do wish all of you all the best, and for a very long future for Julia!
Re: [julia-users] Re: Julia will always be open source
Hi Viral and Stefan, Thanks for the replies. To be clear, I have no opposition to a third party organization (e.g. Julia Computing) hosting the web site as an in-kind donation to Julia (the community project). The GNOME website, for instance, is currently hosted by Canonical, and it has been hosted by Red Hat in the past. The gnome.org domain, on the other hand, is owned by the GNOME Foundation, which is how I believe it should be for a community .org. The administrative cost to owning and periodically renewing a domain is nevertheless nonzero, even though it is less than the cost of hosting web/email/etc. I agree that it is important to make sure that the organization tasked with maintaining it is able to do so without things falling through the cracks, and I'd hope that NumFocus could handle this as a fiscal sponsor; in fact, they mention hosting as a service they offer at http://numfocus.org/foundation/. As Viral mentions, when relying on NumFocus to do more it is important to make sure they are adequately funded. I will plan to think more about how we can raise funds for them to do Julia-related things. As a first step, I just myself joined NumFocus as a Supporting Member, which I had not realized was possible until now. Jim On 05/14/2015 07:13 PM, Viral Shah wrote: As much as I would like to do so, I also want to have enough funding for the Julia foundation (NumFocus) in place before transferring over community resources. We look at everything closely so that things don't fall through the cracks. For someone else to do that, we need an organisational structure. We are working hard with a couple of folks on funding some people to work full time for the foundation. I welcome any ideas on raising funds to pay for a couple of developers and a part time project manager, to start with. -viral On 15 May 2015 5:47 am, Stefan Karpinski ste...@karpinski.org mailto:ste...@karpinski.org wrote: Currently I own the domain, but transferring it to NumFocus would be fine if they do that (which I can find out). On Thu, May 14, 2015 at 6:55 PM, Jim Garrison j...@garrison.cc mailto:j...@garrison.cc wrote: Here is a related question: Who will own and operate the julialang.org http://julialang.org domain? Would you be willing to transfer it to NumFocus or a similar nonprofit, community entity? On Monday, May 11, 2015 at 10:55:00 AM UTC-7, Brian Granger wrote: Congrats on Julia Computing stuff! We (IPython/Jupyter) are always thinking about various approaches to making open source sustainable and it is great to see explorations like this. I wish you the best of success!!! I wanted to share some thoughts and questions about trademark as it relates to open source projects. These thoughts have come out of many years of thinking about, and even enforcing, trademarks in the context of Jupyter/IPython. With IPython/Jupyter, the yet-to-be-filed trademarks (there is a bit of subtlety about the IPython trademark - that is another topic) will belong to our non-profit sponsor, NumFocus (we will transfer it to them). Along with that, we will be developing a trademark usage policy that clarifies to the community how our names and logos can be used. I am guessing that our policy will be similar to that of other open source projects like Python: https://www.python.org/psf/trademarks/ It is likely that we will have a trademark policy that allows generous usage of the names IPython/Jupyter by the open source community, but we would not allow companies to use the trademarks in ways that would confuse users. A company could say our platform uses the open source Project Jupyter but not our company is called JupyterFoo. IANAL, but it is my understanding that the bar for trademark confusion is relatively low and that there is a real danger to not enforcing trademarks, so these issues are important to understand. I think you can see where this is going wrt Julia... * Who holds the trademarks on Julia? NumFocus, an individual or Julia Computing? * What is the trademark policy of that entity? If it doesn't exist, who will create it? * Is Julia Computing infringing upon the Julia trademark? Has the trademark owner given permission to Julia Compute to use the trademark? * By using the name Julia in the company and open source project, is the trademark owner creating a precedence of not enforcing the trademark? * Do you want *other* companies to be allowed
[julia-users] Re: Job posting policy...
Here is the post on julia-jobs: https://groups.google.com/forum/#!topic/julia-jobs/hA5SE1nECZk On Monday, May 11, 2015 at 10:33:54 AM UTC-7, Brian Granger wrote: Hi, This is Brian Granger, one of the core devs on IPython/Jupyter. I am wondering if it would be OK to post a full time job for work on Jupyter/IPython to this list? Cheers, Brian
Re: [julia-users] Re: Trouble getting tests to pass on v0.3.8 with icc/mkl
I think the logdet problem has the same underlying cause as the mod2pi issue I just backported the fix for, see https://github.com/JuliaLang/julia/issues/10188 for some more background. On Thursday, May 14, 2015 at 2:21:07 AM UTC-7, Jim Garrison wrote: Thanks! That fixes the mod2pi issue. Mysteriously enough, the linalg4 tests are all passing now for me too. (I have no idea how this happened, as I've started from a clean build each time and none of the other commits to release-0.3 since v0.3.8 seem to be related; also my Make.user is identical. There must have been some change in my environment variables that I am not accounting for.) On 05/13/2015 07:24 PM, Tony Kelman wrote: Oh right, give me a minute to backport 3ab9af16015b23426c0936bbe73a6d4007c32040 then try from latest release-0.3. On Wednesday, May 13, 2015 at 7:15:05 PM UTC-7, Jim Garrison wrote: Other than logdet, the mod2pi tests fail pretty miserably. Everything else passes. On Wed, 2015-05-13 at 14:45 -0700, Jim Garrison wrote: Thanks Tony! If I disable the logdet test, everything else in linalg4 works. (I'm running the remainder of the test suite now to see if anything else errors.) If there's no hope of backporting the fix, I wonder if it makes sense to put a note in the 0.3-release README. On Wed, 2015-05-13 at 14:34 -0700, Tony Kelman wrote: Which function there is causing trouble? There are a few @test_approx_eq_eps lines that are very similar there, for det, trace, expm, logdet, and sqrtm. I think logdet has given problems with Intel compilers in the past. Most likely there's a complex calling convention mismatch that was fixed by some of the ccall rework on master that can't really be backported to release-0.3. On Wednesday, May 13, 2015 at 12:13:24 PM UTC-7, Jim Garrison wrote: OK, that thread does not seem to apply for me because I am indeed using ifc as my fortran compiler. My full Make.user is as follows: MARCH = nehalem USEICC = 1 USEIFC = 1 USE_INTEL_MKL = 1 USE_INTEL_MKL_FFT = 1 USE_INTEL_LIBM = 1 I get the same error even without the `MARCH = nehalem` line. On Wednesday, May 13, 2015 at 12:10:19 PM UTC-7, Jim Garrison wrote: Sorry for the noise; just discovered the thread at https://groups.google.com/forum/#! searchin/julia-users/linalg4 $20icc/julia-users/ZsGhxR0Pd_s/7V4LNjNO0foJ and will report back if I still have trouble after reading that. On Wednesday, May 13, 2015 at 12:08:41 PM UTC-7, Jim Garrison wrote: With the merging of #11251, I have been attempting (once again) to get julia 0.3 working on a cluster where it has so far resisted working fully. When I compile master with icc/mkl according to the instructions in the README, all tests pass. But when I do the same thing for v0.3.8 (using icc 15.0.2), I get a test failure in linalg4: * linalg4 exception on 1: ERROR: assertion failed: | func(D) - func(DM)| = 3.4332275e-5 func(D) = 1.048798f0 - 1.5707964f0im func(DM) = 1.0487979650497437 - 0.5797938426309308im difference = 0.9910025278753558 3.4332275e-5 in error at error.jl:22 in test_approx_eq at test.jl:109 in anonymous at no file:295 in runtests at /home/garrison/julia/v0.3.8-mkl/test/testdefs.jl:5 in anonymous at multi.jl:660 in run_work_thunk at multi.jl:621 in remotecall_fetch at multi.jl:694 in remotecall_fetch at multi.jl:709 in anonymous at task.jl:1365 while loading linalg4.jl, in expression starting on line 263 ERROR: assertion failed: |func(D) - func(DM)| = 3.4332275e-5
[julia-users] how to create a command with an unquoted backslash in it?
I'm trying to run an external imagemagick command. As such, it needs to include some escaped parenthesis. In shell it would look like this: convert img.png \( -clone 0 -crop 450x+450+0 -dither None -remap colormap1.png \) \( -clone 0 -crop 450x+951+0 -dither None -remap colormap2.png \) -delete 0 z%d.png But when I build something like this in julia: cmd = `convert $fname ( -clone 0 -crop wx+$(w+1)+0 -dither None -remap colormap1.png ) ( -clone 0 -crop 450x+$(sz[1]-w+1)+0 -dither None -remap colormap2.png ) -delete 0 z%d.png` the parenthesis don't get escaped (as they should be). This is not the first time I've gone crazy over this issue. Any ideas?
