[julia-users] Re: Automatic differentiation of mapping from R^N to R^N?

The restriction that one needs to use generic functions (and as such, can't use explicit BLAS calls) isn't clearly stated in ForwardDiff.jl's documentation; I just made an issue to track documenting it . Feel free to open up an issue on

Re: [julia-users] Re: Hyper-Dual numbers

Just a note to avoid confusion: ForwardDiff.jl doesn't use complex numbers at all. It uses its own implementation of dual number/hyper-dual number "ensembles" for computing multiple partial derivatives simultaneously. There is no additional error term in ForwardDiff.jl's formulation. --

Re: [julia-users] Re: META: What are the chances of moving this forum?

't see how > that > >> is different from requiring a Google account for participating here... > >> > >> On Wednesday, September 9, 2015 at 5:33:33 PM UTC+2, Jarrett Revels > wrote: > >>> > >>> I often find myself wishing that this f

Re: [julia-users] Re: META: What are the chances of moving this forum?

gt; >> >> I'm not a fan of Google, so I think it would great to find another > >> forum. > >> >> Besides, I fully agree with the technical issues mentioned. > >> >> > >> >> Regarding the need for user accounts on e.g. GitHub, I don't

Re: [julia-users] META: What are the chances of moving this forum?

> > -1 to re-purposing GitHub issues for any sort of free-form discussion. I > don't see that as solving any problems. At scale, the GitHub issue tracker > is limited even for the intended purpose. > The main reason I mentioned it was that it was a solid example of the kind of features I had

[julia-users] Re: META: What are the chances of moving this forum?

I often find myself wishing that this forum was just a GitHub repo, with posts as issues. It would be great for supporting @-style mentions, markdown, issue-linking, etc. The main downside would be forcing everybody to have GitHub account (not bad IMO, but I can see others having an issue for

[julia-users] Re: META: What are the chances of moving this forum?

, I fully agree with the technical issues mentioned. > > Regarding the need for user accounts on e.g. GitHub, I don't see how that > is different from requiring a Google account for participating here... > > On Wednesday, September 9, 2015 at 5:33:33 PM UTC+2, Jarrett Revels wrote: >

[julia-users] Re: [ANN] ForwardDiff.jl v0.1.0 Released

> > For the latter, you would need to be able to take linear combinations of > epsilons. Is that currently possible? > If I correctly understand what you're saying, then yes. See the Types section of the notebook I previously linked

[julia-users] Re: [ANN] ForwardDiff.jl v0.1.0 Released

> > I assume it works with multi-dimensional functions f(x,y,z)? > Yes, in a sense. ForwardDiff only accepts univariate functions, but the single argument to those functions can be a Number or Vector. So, if you wanted to the gradient of the f you gave, and x, y, z are scalars, you could

[julia-users] Re: [ANN] ForwardDiff.jl v0.1.0 Released

Thanks! I'm going to be working this upcoming week on adding developer docs to our current documentation to explain some of the behind-the-scenes details; I'll post here once that's completed. In the meantime, the notebook I posted earlier

[julia-users] Re: [ANN] ForwardDiff.jl v0.1.0 Released

D'oh! Forgot to include the line: julia> x = rand(1); On Friday, September 4, 2015 at 11:14:22 AM UTC-4, Jarrett Revels wrote: > > Are there any benchmark results for the "more performant and accurate" bit? >> > > Very valid question! There are some b

[julia-users] Re: [ANN] ForwardDiff.jl v0.1.0 Released

@time fd_g(x); 0.523414 seconds (2.02 k allocations: 266.266 KB) Best, Jarrett On Friday, September 4, 2015 at 5:27:27 AM UTC-4, Johan Sigfrids wrote: > > Are there any benchmark results for the "more performant and accurate" bit? > > On Thursday, September 3, 2015 at 1

Re: [julia-users] Re: v0.4 - Pair does not behave like a Tuple

> > Though how would one correctly access the 'nth' elements type ? > It brings up a question regarding parameterized types, how should (or > should) one access/refer to the parameters of the type rather than an > instance. It seems like a bad (queezy) practice to dig into the parameters >

[julia-users] [ANN] ForwardDiff.jl v0.1.0 Released

I'm proud to announce that we've tagged and released a new version ForwardDiff.jl (https://github.com/JuliaDiff/ForwardDiff.jl). ForwardDiff.jl is a package for performing automatic differentiation on native Julia functions/callable

[julia-users] Re: Type stability (or not) in core stats functions

oesn't correctly report them, so the fixes I listed should still be useful for patching over inferencing problems with keyword arguments. Best, Jarrett On Tuesday, September 1, 2015 at 12:49:02 PM UTC-4, Jarrett Revels wrote: > > Related: https://github.com/JuliaLang/julia/issues/9551 >

[julia-users] Re: ANN: JuMP 0.10 released

Woohoo! That's a lot of new stuff. -- Jarrett On Tuesday, September 1, 2015 at 12:41:26 AM UTC-4, Miles Lubin wrote: > > The JuMP team is happy to announce the release of JuMP 0.10. > > This is a major release with the greatest amount of new functionality > since the addition of nonlinear

[julia-users] Re: Type stability (or not) in core stats functions

Related: https://github.com/JuliaLang/julia/issues/9551 Unfortunately, as you've seen, type-variadic keyword arguments can really mess up type-inferencing. It appears that keyword argument types are pulled from the default arguments rather than those actually passed in at runtime: *julia> f(x;

Re: [julia-users] Re: ANN: JuliaDiff -- differentiation tools in Julia

Hi, This could be a chance to battle-test ForwardDiff.jl's new API. It takes exact derivatives and we're trying to make it easy to use. If your discrete grid is granular enough, ForwardDiff.jl should work great. Just keep in mind that ForwardDiff is so accurate (i.e., to machine-epsilon

[julia-users] ANN: Major overhaul of ForwardDiff.jl

Hi! ForwardDiff.jl https://github.com/JuliaDiff/ForwardDiff.jl, a Julia package for performing automatic differentiation, has just been updated and is now much less buggy, much more performant, and much more comprehensively tested. An additional goal of the update was to provide a more

[julia-users] Re: GSoC 2015 with JuliaQuantum

Amit has already contributed a fair amount to QuBase.jl already. His and Alexander's work on dynamics solvers will make for an exciting summer for JuliaQuantum! Looking forward to it! -- Jarrett On Monday, May 18, 2015 at 10:50:02 PM UTC-4, Viral Shah wrote: This is amazing! Do keep us

Re: [julia-users] ANN: QuDirac.jl

PM UTC-4, Christian Peel wrote: Nice! I'm curious how tough it would be to simulate Shor's algorithm, even if it's just to factor 15; Is there some reason that this is too tough to include as an example? chris On Thu, Apr 23, 2015 at 6:02 PM, Jarrett Revels jarret...@gmail.com

[julia-users] ANN: QuDirac.jl

I'm happy to say that I've finally released QuDirac.jl https://github.com/JuliaQuantum/QuDirac.jl! This package is for performing common quantum mechanical operations using Dirac notation. Feature list: - Implementations of state types (`Ket`,`Bra`), and a variety of operator types

[julia-users] Use of convert() within setindex!() in array.jl

Hello all, I was exploring some of the base code today when I saw the implementation of setindex!(): setindex!{T}(A::Array{T}, x, i0::Real) = arrayset(A, convert(T,x), to_index(i0)) I was surprised that I couldn't find setindex!() methods for elements that used the type system to forego the

Re: [julia-users] Use of convert() within setindex!() in array.jl

Jarrett Revels wrote: Hello all, I was exploring some of the base code today when I saw the implementation of setindex!(): setindex!{T}(A::Array{T}, x, i0::Real) = arrayset(A, convert(T,x), to_index(i0)) I was surprised that I couldn't find setindex!() methods for elements

Re: [julia-users] Type Parameter Scope Inconsistency?

I also made a typo in my question; the parameter I'm referring to is the parameter of Vector in x, i.e. T in x::Dict{Int, Vector{T}}. On Friday, March 21, 2014 5:44:19 PM UTC-4, Jarrett Revels wrote: Here's a gist clarifying what I'm trying to do in my second question: https

Re: [julia-users] Type Parameter Scope Inconsistency?

} is still not fully specialized. You likely want Vector{T} or Array{T,1} so that the access to the Foo.y element can be fully optimized. On Thu, Mar 20, 2014 at 1:03 AM, Jarrett Revels jarret...@gmail.comjavascript: wrote: Hello Julianistas, I'm running into what seems to be a strange

[julia-users] Type Parameter Scope Inconsistency?

Hello Julianistas, I'm running into what seems to be a strange inconsistency in the way the compiler is treating type parameters. Consider the following code: type Bar{T} x::T end type Foo{T} y::Array{Bar{T}} end A = [Bar(1), Bar(2), Bar(3)] B = [Bar(1), Bar(A), Bar({1,2,3})] There