https://github.com/JuliaLang/julia/issues/7062
> This is the bug I mentioned yesterday where Array{T} reads back as
Array{T, N}.
Array{T} and Array{T,N} describe the same type object
On Sat, May 31, 2014 at 9:01 PM, David Moon wrote:
> On Saturday, May 31, 2014 1:08:29 PM UTC-4, Iain Dunni
I should add that PEGParser's code is fairly new and untested (besides
having an uninspired name). I'm also hoping to have better action
semantics soon.
On Saturday, May 31, 2014 2:17:27 PM UTC-4, andrew cooke wrote:
>
> https://groups.google.com/d/msg/julia-users/t56VxOX1vvk/nszQYWP_pm4J
>
> h
On Saturday, May 31, 2014 1:08:29 PM UTC-4, Iain Dunning wrote:
>
> And I don't necessarily think this is wrong - look at the code it generates
> f{t,n}(::Type{Array{t,n}},::Array{t,n}) at none:3
> f{t,n}(::Type{Array{t,N}},::Array{t,n}) at none:2
>
> There is nothing to distinguish these two from
There are a number of issues about type inference for `map` and similar
functions. See 6692 and the issues linked therein:
https://github.com/JuliaLang/julia/pull/6692
On Fri, May 30, 2014 at 4:27 AM, Tomas Lycken
wrote:
> I have a `DataArray{Float64,1}` named `ps` with a bunch of values I'd li
On Sunday, 1 June 2014 00:21:07 UTC+10, Simon Kornblith wrote:
>
> Yes, this is kind of a toy solution to a toy example. It sounds like what
> you describe is implementable as:
>
> f(i, object, objects..) = min(intersect(object, i), f(i, objects...))
> f(i) = 0.0
>
> I did try something like tha
It seems the idea of JIT Hardware Compilation has been around for a while:
http://link.springer.com/chapter/10.1007%2F978-3-540-78791-4_12#page-1
http://www.informationweek.com/jit-compilation-to-hardware/d/d-id/1073781?
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6567576&url=
On Saturday, May 31, 2014 10:40:02 AM UTC-4, Robert Gates wrote:
> my colleagues and I are planning on writing cross-platform (Linux
> variants, OS X, Windows) commercial software for the research community,
> preferably in Julia. Our projected release date will be some time in the
> next 3-4
Robert,
These questions are hard to answer without knowing a little bit more about
what you are planning. How many people will be working on the project. What
are the tools used to date? What would be the considered alternative to
Julia? These are quite essential questions.
If the alternative
Hil,
DASSL.jl supports multiple equtions, I have just added an example to the
readme file [1]. If you need any further help with setting up DASSL.jl I
am ready to help you.
[1] https://github.com/pwl/DASSL.jl/blob/master/README.md
W dniu czwartek, 29 maja 2014 19:31:19 UTC+2 użytkownik Freder
https://groups.google.com/d/msg/julia-users/t56VxOX1vvk/nszQYWP_pm4J
https://groups.google.com/d/msg/julia-users/6jz3Ow5SAAE/TgKHQ48gUG4J
thanks!
On Saturday, 31 May 2014 14:04:28 UTC-4, Isaiah wrote:
>
> There was a nice looking PEG system previewed a few days ago if you search
> the users lis
There was a nice looking PEG system previewed a few days ago if you search
the users list (and I think there was another one several months back by
Michael Fox).
On Sat, May 31, 2014 at 1:22 PM, andrew cooke wrote:
> are there any libraries for parsing in julia? either parser combinator or
> s
Hello,
On Saturday, May 31, 2014 4:40:02 PM UTC+2, Robert Gates wrote:
>
> Dear Julia users:
>
> my colleagues and I are planning on writing cross-platform (Linux
> variants, OS X, Windows) commercial software for the research community,
> preferably in Julia. Our projected release date will be
are there any libraries for parsing in julia? either parser combinator or
something more traditional (maybe a wrapper for something like antlr)?
all i can find is an old discussion started by leah h in which jeff b
suggests doing everything in julia. that included a pointer to
https://github.
I don't really know exactly what is going on here, but I'm not sure
equality works like that for types, better to use <:
julia> Array{Int} <: Array{Int,1}
false
julia> Array{Int,1} <: Array{Int}
true
And I don't necessarily think this is wrong - look at the code it generates
f{t,n}(::Type{Array
Dear Julia users:
my colleagues and I are planning on writing cross-platform (Linux variants,
OS X, Windows) commercial software for the research community, preferably
in Julia. Our projected release date will be some time in the next 3-4
years. It is crucial to user-friendliness and protection
The manual says Type{xxx} matches only the object xxx, but it does not seem
to be true. Maybe this is related to my post yesterday "Reflection bug for
parameterized types?" because this could be another case of confusion
between the TypeVars declared in a parameterized type declaration and
Typ
On Saturday, May 31, 2014 3:11:40 PM UTC+2, mike c wrote:
>
>
> On Saturday, 31 May 2014 21:07:58 UTC+10, Simon Kornblith wrote:
>>
>> It may not be desirable, but I think it's expected. The relevant comment
>> in inference.jl says:
>> In this case, performance is 20% worse because the compiler c
On Saturday, 31 May 2014 21:07:58 UTC+10, Simon Kornblith wrote:
>
> It may not be desirable, but I think it's expected. The relevant comment
> in inference.jl says:
> In this case, performance is 20% worse because the compiler can't infer
> the return type of intersect if there are >4 possible
That is essentially the same as using the most recent source, but since
they are widely used, some features are enabled only once they have been
stable for a while.
-viral
On Saturday, May 31, 2014 4:04:18 PM UTC+5:30, Job van der Zwan wrote:
>
> Wow, that looks like it was a massive effort!
>
It may not be desirable, but I think it's expected. The relevant comment in
inference.jl says:
# don't consider more than N methods. this trades off between
# compiler performance and generated code performance.
# typically, considering many methods means spending lots of time
# o
Le vendredi 30 mai 2014 à 21:08 -0700, Ethan Anderes a écrit :
> After reading about it here in GoogleGroups I’ve started using A && B
> in place of if A B end and A || B for if !A B end. I love it. However,
> I wish the following would work
>
>
> true && d,v = svd(rand(2,2)) false || d,v = svd
Wow, that looks like it was a massive effort!
BTW, I subscribed to the nightly build PPA, isn't that equal to building
from the most recent source?
On Friday, 30 May 2014 21:04:26 UTC+2, Elliot Saba wrote:
>
> This would be the static compilation work that was done for 0.3 by
> everyone in this
You should definitely open an issue about this – if your timings are right
it's definitely not desirable behaviour.
https://github.com/JuliaLang/julia/issues?state=open
On 31 May 2014 11:00, mike c wrote:
> I've narrowed down the problem. It's not a profiling problem. Julia
> seems to have a
I've narrowed down the problem. It's not a profiling problem. Julia seems
to have a step-change in speed when there are too many functions of a
similar signature.
I've made a short example that reproduces this
slowdown: http://pastebin.com/iHAa2Cws
Run the code once as-is, and then uncomment
Would the results of profile help figuring out what is wrong?
I have a small test-case which is slow when benchmarked from a loop, but
fast when benchmarked from a function:
using Images
function expensive(img)
img[1, 2] * img[3, 4] + img[5, 6] - img[7, 8]
end
function benchmark(img)
for i in 1:100
expensive(img)
26 matches
Mail list logo
