> But do you agree that the usage of x::T as a formal parameter is quite
different when T is a type parameter compared to when it is a plain type?
I'm not 100% sure I grok what you're getting at, but *if *what you're
asking is whether I see a difference between foo(x::Real) and
foo{T<:Real}(x:
Hello all,
I wanted to create an array of an immutable type and initialize an empty
copy in each (with the default constructor).
I am wondering which is the best way to do it, so far:
immutable ChannVals
taus::Vector{Float64}
alphas::Vector{Float64}
ChannVals() = new( Float64[], Float64[] )
* correction, 'allVals' is 'arr' in the last line of code.
--
Carlos
On Fri, May 16, 2014 at 10:27 AM, Carlos Becker wrote:
> Hello all,
>
> I wanted to create an array of an immutable type and initialize an empty
> copy in each (with the default constr
Here is an example of the difference Toivo refers to (I think):
julia> foo{T<:Real}(a::Array{T},b::T) = T
foo (generic function with 1 method)
julia> bar(a::Array{Real},b::Real) = Real
This is just an anouncement that I have been working on a package for
performing non-equidistant fast Fourier transforms (NFFT). The package
should now be accessible using Pkg.add("NFFT"). Some basic usage examples
can be found here: https://github.com/tknopp/NFFT.jl
The NFFT (also known as Gri
Try
arr = [ChannVals() for i = 1:10]
On Friday, May 16, 2014 01:27:18 AM Carlos Becker wrote:
> Hello all,
>
> I wanted to create an array of an immutable type and initialize an empty
> copy in each (with the default constructor).
> I am wondering which is the best way to do it, so far:
>
>
On Friday, May 16, 2014 02:57:13 AM Tobias Knopp wrote:
> I initially wrote this to play with Julia and determine how close to C
> speed one can get.
But it will be quite useful functionality to have! Thanks for contributing it.
Best,
--Tim
Thank you!
Correct me if I am wrong, but IMHO the comparison of the two functions in
Mauro's last post is not entirely fair for :: because the parametrized version
imposed an additional constraint which has nothing to do with ::
Essentially in the two cases the following types are required:
foo: T <: Rea
How close did you get to c speed?
I might try something like (note the code code is written for clarity, not
for compactness or completeness):
function encode_name(name::String)
if name == "setosa"
return [1 0 2];
elseif name == "versicolor"
return [2 1 0];
else
return [0 2 1];
end
end
output = map(encode_na
Well, this is actually an interesting story. In my first test the code was
about 100 times slower for which reason I did not investigate Julia further
and concentrated on a Numpy like multidimensional array package called
numcpp: https://github.com/tknopp/numcpp. And with C++11 I got actually
q
Thank you so much!
I am very busy with other things at the moment, but will dive into the
code, attempt to update as necessary in a few weeks and share the results,
if any.
On Monday, 12 May 2014 22:52:17 UTC+2, Ariel Keselman wrote:
>
> Just looked for the code in some old backup drive and fou
Hi all,
I have been using julia and ijulia for a while and everything worked fine.
over time I get more and more issues, trying to upgrade/reinstall etc and
now I can't get it to work at all anymore. As I intend to reinstall osx
anyway, I was wondering if you good people have any good setup for
Hello, new user and subscriber here. Is there a way to decompose a
UnionType back into its constituent type(s)?
I tried names():
> dt = Union(Int,Float64)
> names(dt)
1-element Array{Symbol,1}:
:types
convert() seems to hit dead-ends.
Help appreciated.
Tony
On Friday, May 16, 2014 2:09:03 AM UTC-5, Tony Fong wrote:
>
> Hello, new user and subscriber here. Is there a way to decompose a
> UnionType back into its constituent type(s)?
>
> I tried names():
>
> > dt = Union(Int,Float64)
> > names(dt)
> 1-element Array{Symbol,1}:
> :types
>
> convert() see
the `names` function is indeed the right way to go about it:
julia> un = Union(Int, Float64)
Union(Int64,Float64)
julia> names(un)
1-element Array{Symbol,1}:
:types
julia> un.types
(Int64,Float64)
julia> un.types[1]
Int64
julia> un.types[2]
Float64
For datatypes:
julia> type A
a::In
I am not sure if this appeals to you, but I'm happy to share my
configuration. I just use the REPL and a decent editor (vim), which I'm
happy with.
I've been using this setup for the past couple months (mid-March). I've
only had occasionally issues, but I follow HEAD so that is expected. I am
no
Hi,
I'm struggling to understand the scheduling subsection (in the parallel
computation section) of the docs; specifically how the pmap function as
shown there works. I've copy-pasted the code I used below my questions.
Question 1) Is the purpose of the @sync block just to wait for all the
pro
I follow an identical process to Cameron, with the same results.
- Adrian.
On Fri, May 16, 2014 at 3:37 PM, Cameron McBride
wrote:
> I am not sure if this appeals to you, but I'm happy to share my
> configuration. I just use the REPL and a decent editor (vim), which I'm
> happy with.
>
> I've
+1 for Cameron. I use the same workflow.
Hey guys,
I'm confused by this dictionary behaviour.
I create a dictionary like this:
for line=readlines(open(string(directo, "4_column_file.tab")))[2:end]
tmp = split(line, '\t')
ste_data[(tmp[1], tmp[2], tmp[3])] = tmp[4]
end
Then I run
v = collect(keys(ste_data))
to get an array
Found the problem.
The indices are tuples of substrings and I'm querying using strings.
We really need to make that work the same way – can you open an issue?
On Fri, May 16, 2014 at 10:42 AM, Andrew B. Martin <
andrew.brown.mar...@gmail.com> wrote:
> Found the problem.
>
> The indices are tuples of substrings and I'm querying using strings.
>
>
>
Should this be mentioned in the documentation?
Currently it reads that split returns an array of strings, but I'm finding
that it returns an array of SubStrings.
Since they are immutable, fill! did exactly what you wanted
On Friday, May 16, 2014, Tim Holy wrote:
> Try
>
> arr = [ChannVals() for i = 1:10]
>
> On Friday, May 16, 2014 01:27:18 AM Carlos Becker wrote:
> > Hello all,
> >
> > I wanted to create an array of an immutable type and initialize an e
Well, SubStrings are Strings. The issue here is that we're hashing tuples
based on their type, which is problematic. We very much need to (re)think
how collection hashing works. The basic question is whether containers
should hash differently based on their type, their eltype, or just their
content
Issue filed:
https://github.com/JuliaLang/julia/issues/6870
I'm new to filing issues on github, so please feel free to clarify if I'm
not expressing the problem well.
No, that's perfect. Thanks!
On Fri, May 16, 2014 at 11:14 AM, Andrew B. Martin <
andrew.brown.mar...@gmail.com> wrote:
> Issue filed:
> https://github.com/JuliaLang/julia/issues/6870
>
> I'm new to filing issues on github, so please feel free to clarify if I'm
> not expressing the problem well.
Hello all
I'm trying to index a dataframe in the folowing manner:
df = DataFrame(A = round(rand(1000) * 10), B = round(rand(1000) * 10))
df[:C] = 0
df[(df[:A] .== 1 & df[:B] .== 1),: C] = 1
I get an error "ERROR: no method &(Int64, DataArray{Float64, 1})
if i index like this, it works but i wo
This is a result of the weird precedence of &. Try this:
(df[:A] .== 1) & (df[:B] .== 1)
— John
On May 16, 2014, at 8:25 AM, Jason Solack wrote:
> Hello all
>
> I'm trying to index a dataframe in the folowing manner:
>
> df = DataFrame(A = round(rand(1000) * 10), B = round(rand(1000) * 10))
perfect, thank you!
On Friday, May 16, 2014 11:28:46 AM UTC-4, John Myles White wrote:
>
> This is a result of the weird precedence of &. Try this:
>
> (df[:A] .== 1) & (df[:B] .== 1)
>
> — John
>
> On May 16, 2014, at 8:25 AM, Jason Solack >
> wrote:
>
> > Hello all
> >
> > I'm trying to
Yes, that is exactly the kind of example that I'm referring to. (As is the
example that started this thread as well.)
In all other cases, x::T is covariant in the sense that it allows typeof(x)
<: T. But in an argument list when T is a type parameter to the same
method, x::T is instead invariant
That form of iteration is common from Ruby, which is where I'm guessing
this interest is coming from? Ruby has the block/proc/lambda distinction
that makes the for loop and .each forms behaviorally similar, whereas in
Julia, there's just the one kind of anonymous function. As a result, if
this were
I think it is great to have most topics advanced, it is a fun and
educational way to engage with contributors and see all the power of the
language in action.
However if one of the objectives of the conference is also to broaden a bit
the audience -- e.g., spark the interest of a few more R/Mat
in matlab :
x=[1,4]
B=repmat(A,x)
/(B==)
how to replicate A in Julia
Paul
Julia has repmat. You can look up its methods like this:
julia> methods(repmat)
# 3 methods for generic function "repmat":
repmat(a::AbstractArray{T,1},m::Int64) at abstractarray.jl:964
repmat(a::Union(AbstractArray{T,2},AbstractArray{T,1}),m::Int64) at
abstractarray.jl:950
repmat(a::Union(Abstra
B=repmat(A,x...)
On Friday, May 16, 2014 8:18:14 PM UTC+2, paul analyst wrote:
> in matlab :
> x=[1,4]
> B=repmat(A,x)
>
> /(B==)
>
>
> how to replicate A in Julia
> Paul
>
>
>
Are you going to film/livestream it? Are you going to have lightning talks?
If the answer to both questions is "yes", don't forget to film/stream the
latter! Apparently the GopherCon last month had some amazing lightning
talks but nobody remembered to film them.
On Tuesday, 13 May 2014 05:43:3
On Fri, 2014-05-16 at 17:18, Toivo wrote:
> Yes, that is exactly the kind of example that I'm referring to. (As is the
> example that started this thread as well.)
Haha, well sometimes I just take a bit longer to figure things
out... ;-)
> I suspect that the pragmatic rule that Julia follows is
We're going to film but not live stream. We'll film the lightning talks too
– good to have a reminder.
On Fri, May 16, 2014 at 3:50 PM, Job van der Zwan
wrote:
> Are you going to film/livestream it? Are you going to have lightning
> talks? If the answer to both questions is "yes", don't forget t
Hi,
I am starting to use Julia, and I would like to learn and contribute a bit.
As I have some experience in numerics I am thinking of contributing to the
ODE package.
I've read the ideas for the API, and I believe that we can still improve
it. Usually, for this kind of solver, we could expect
Hi Sorami,
Yes, JuliaText is meant to be the repository of Julia NLP packages and I
agree with you about Julia's potential in the NLP domain. There hasn't been
a lot of action there since I think there aren't many people using Julia
for NLP yet (although I hope that changes). Any contributions y
@Jameson They are immutable, but they contain references to mutable arrays,
and all the immutable types will reference the same arrays. That way you
would not just need a copy but a deepcopy. That will probably be too much
overhead for fill!(), and will be problematic if someone decided to fill!
Comprehensions and for loops do not perform nested looping in the same
order:
julia> [begin println((i,j)); (i,j) end for i = 1:3, j = 1:4]
(1,1)
(2,1)
(3,1)
(1,2)
(2,2)
(3,2)
(1,3)
(2,3)
(3,3)
(1,4)
(2,4)
(3,4)
3x4 Array{(Int64,Int64),2}:
(1,1) (1,2) (1,3) (1,4)
(2,1) (2,2) (2,3) (2,4)
I am very new to Julia, but here is my guess :
- for i = , j =
should be the same as
for i =
for j =
It would be awkward to have something else.
- For comprehensions, the order is the other way around because matrices
are stored in Julia in column order as in Fortran (and maybe Matlab) a
It's less about the array ordering and more about the fact that mathematically
the row index comes before the column index and doing it the other way would be
very confusing. It's a shame these don't match, but there's not much to do
about it.
> On May 16, 2014, at 4:57 PM, francois.fay...@gmai
No big deal, just now noticed it, is all. FWIW, I like the comprehension
order better (inner = faster). Although I also see François' point about
the for loop nesting.
Thanks,
--Peter
On Friday, May 16, 2014 2:10:19 PM UTC-7, Stefan Karpinski wrote:
>
> It's less about the array ordering and
Why would it be confusing ?
I've seen as many math people (with no knowledge of memory ordering in
programming languages) giving matrices in row major order and giving
matrices in column major order.
On Friday, May 16, 2014 11:10:19 PM UTC+2, Stefan Karpinski wrote:
>
> It's less about the arra
Hi François,
Nice to hear that you are interested in contributing to ODE.jl. Any input is
greatly appreciated! I guess you have also seen some of the open issues
discussing the API over at ODE.jl, so if you have a github account it might be
good to post your thoughts there as well.
Regarding t
Hi Alex,
I do have a GitHub account, and I'll post my ideas over there. Here are my
thoughts :
- The solver need to be fast and for that, inlining is of paramount
importance. I know that there is no way to inline F for the time being. Do
we expect inlining on function argument in the near futu
When you write fill!(arr, ChannVals()) you are asking to fill arr with the
one value that is the result of evaluating ChannVals() once. Doing anything
else would be bizarre. We could have a version of fill! that takes a thunk
so you could write
fill!(arr) do
ChannVals()
end
That would have the
It would be confusing because it's at odds with all the mathematical literature
in existence.
> On May 16, 2014, at 5:21 PM, francois.fay...@gmail.com wrote:
>
> Why would it be confusing ?
>
> I've seen as many math people (with no knowledge of memory ordering in
> programming languages) givi
I am new to GitHub. Is there some kind of forum, or do you mean to create a
new file with my thoughts on it ?
On Friday, May 16, 2014 11:26:21 PM UTC+2, Alex wrote:
>
> so if you have a github account it might be good to post your thoughts
> there as well.
>
Github provides a web-based issue tracker tool where many of the
discussions have occurred and may be commented on:
https://github.com/JuliaLang/ODE.jl/issues
On Fri, May 16, 2014 at 10:26 PM, wrote:
> I am new to GitHub. Is there some kind of forum, or do you mean to create
> a new file with
Fantastic. Thank you all.
Hello--sorry to bug you all.
This from Julia 0.2.0 on MacOSX 10.7.5, using the DataFrames package,
just now updated before the following attemp to execute example code from
the manual:
Version 0.2.0 (2013-11-16 23:44 UTC)
Official http://julialang.org release
x86_64-apple-darwin12.5.0
julia> usi
This from Julia 0.2.1 on MacOSX 10.7.5, using the DataFrames package,
just now updated before the following attemp to execute example code from
the manual:
Version 0.2.1 (2014-02-11 06:30 UTC)
_/ |\__'_|_|_|\__'_| | Official http://julialang.org/ release
|__/ | x86_64-apple
On Thursday, 15 May 2014 09:36:06 UTC+2, Ariel Keselman wrote:
>
> they are MIT licensed, no need for permission :)
>
> how efficient is Voroni construction using conic hulls, I think Qhull
> which uses convex hulls is way slower than what I plan with the algorithms
> described in here: http://
59 matches
Mail list logo
