...bug you can do

julia> A = big(randn(3,3));
julia> lu(A);
julia> qr(A);
julia> chol(A'A);
julia> big(randn(10,2))\ones(10)
2-element Array{BigFloat,1}:
 
-3.159225931277445120604659524255654976434759649748354505550941362505085384003288e-01

4.105614943861208993931724574474979425594621393874386147118234751387185525595618e-01

I have done some of the work on eigenvalues, but it is not done yet.

Med venlig hilsen

Andreas Noack

2014-09-19 21:09 GMT-04:00 Spencer Lyon <spencerly...@gmail.com>:

> Hey Jameson,
>
> Thanks for the tip, but I don’t think we have “most linear algebra
> operations” defined on BigFloat types. See the example below (on Julia
> master, one day old):
>
> julia> P1
> 3x3 Array{Float64,2}:
>  1.0  0.0  0.0
>  0.2  0.5  0.3
>  0.0  0.0  1.0
>
> julia> big_P1 = big(P1)
> 3x3 Array{BigFloat,2}:
>  1e+00                                                        …  0e+00
>  2.00000000000000011102230246251565404236316680908203125e-01     
> 2.99999999999999988897769753748434595763683319091796875e-01
>  0e+00                                                           1e+00
>
> julia> eig(P1)
> ([0.5,1.0,1.0],
> 3x3 Array{Float64,2}:
>  0.0  0.928477  0.0
>  1.0  0.371391  0.514496
>  0.0  0.0       0.857493)
>
> julia> eig(big_P1)
> ERROR: `eigfact!` has no method matching eigfact!(::Array{BigFloat,2})
>  in eigfact at linalg/factorization.jl:451
>
> On Friday, September 19, 2014 8:27:50 PM UTC-4, Jameson wrote:
>
> > arbitrary precision linear algebra
>>
>> i think most linear algebra operations are defined in julia and thus will
>> work for bignums. sticking a call to big() somewhere in the code is usually
>> enough to promote everything
>>
>> On Fri, Sep 19, 2014 at 8:06 PM, Spencer Lyon <spence...@gmail.com>
>> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for the questions, I’ll respond in chunks.
>>>
>>> Any experiences/opinions/pitfalls your group discovered on the Python vs
>>> Julia question?
>>>
>>> I personally love both languages and use both regularly. I find myself
>>> reaching for Julia for most things right now — I love the more advanced
>>> features like metaprogramming and parallel processing that are either
>>> non-existent or not as well integrated into the python language itself (I
>>> know there are many packages that provide similar features for python, but
>>> they don’t feel as natural as they do in Julia).
>>>
>>> Did you find one is faster than the other?
>>>
>>> As you might expect, we found that Julia was faster than Python for most
>>> things. This is probably an artifact of the type of algorithms we used.
>>> Often we would define an operator that loops over a grid, and then iterate
>>> on that operator until we find a fixed point. Because of this looping,
>>> Julia has a predictable speed advantage.
>>>
>>> Were there major areas where Julia lagged behind Python?
>>>
>>> I can think of two places where performance in Julia wasn’t as good as
>>> performance in python:
>>>
>>>    1. We often need to do quadrature in the innermost part of our loops
>>>    (to approximate expected values) and we found that Julia’s quadgk
>>>    routine was much slower scipy.integrate.fixed_quad. This is *not* a
>>>    fair comparison because the algorithms employed by the two functions are
>>>    very different. Specifically quadgk uses an adaptive algorithm while
>>>    fixed_quad just uses standard Gaussian quadrature. To get around
>>>    this we actually implemented a whole suite of quadrature routines in the
>>>    file quad.jl
>>>    <https://github.com/QuantEcon/QuantEcon.jl/blob/master/src/quad.jl>.
>>>    After switching the Julia code from using quadgk to our own internal
>>>    quadrature methods, we got approximately the same solutions, but the code
>>>    was between 35-115 faster.
>>>    2. Linear interpolation. The function numpy.interp does simple
>>>    piecewise linear interpolation. We ended up using the CoordInterpGrid
>>>    type from Grid.jl to accomplish this. As of right now the
>>>    interpolation steps are the biggest bottleneck in most of the functions 
>>> we
>>>    have.
>>>
>>> We also didn’t really find that Julia was lagging behind Python in terms
>>> of libraries that we needed. All the functionality we needed was already
>>> available to us. We are using PyPlot.jl to generate graphics, so I
>>> guess the some of the Julia code is dependent on Python. Come to think of
>>> it the one thing we would like to have that we haven’t been able to find is
>>> arbitrary precision linear algebra. In Python this can be achieved through
>>> SymPy’s wrapping of mpmath, but as far as I know we don’t yet have
>>> arbitrary precision linear algebra in Julia.
>>>
>>> On Friday, September 19, 2014 12:40:01 PM UTC-4, David Anthoff wrote:
>>>
>>> This is fantastic!
>>>>
>>>>
>>>>
>>>> Any experiences/opinions/pitfalls your group discovered on the Python
>>>> vs Julia question? I guess you pretty much implemented the same algorithms
>>>> in both languages. Did you find one is faster than the other? Were there
>>>> major areas where Julia lagged behind Python?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On
>>>> Behalf Of *Spencer Lyon
>>>> *Sent:* Thursday, September 18, 2014 7:14 PM
>>>> *To:* julia...@googlegroups.com
>>>> *Subject:* [julia-users] ANN: QuantEcon.jl
>>>>
>>>>
>>>>
>>>> New package QuantEcon.jl <https://github.com/QuantEcon/QuantEcon.jl>.
>>>>
>>>> This package collects code for quantitative economic modeling. It is
>>>> currently comprised of two main parts:
>>>>
>>>> 1.      A toolbox of routines useful when doing economics
>>>>
>>>> 2.      Implementations of types and solution methods for common
>>>> economic models.
>>>>
>>>> This library has a python twin: QuantEcon.py
>>>> <https://github.com/QuantEcon/QuantEcon.py>. The same development team
>>>> is working on both projects, so we hope to keep the two libraries in sync
>>>> very closely as new functionality is added.
>>>>
>>>> The library contains all the code necessary to do the computations
>>>> found on http://quant-econ.net/, a website dedicated to providing
>>>> lectures that each economics and programming. The website currently (as of
>>>> 9/18/14) has only a python version, but the Julia version is in late stages
>>>> of refinement and should be live very soon (hopefully within a week).
>>>>
>>>> The initial version of the website will feature 6 lectures dedicated to
>>>> helping a new user set up a working Julia environment and learn the basics
>>>> of the language. In addition to this language specific section, the website
>>>> will include 22 other lectures on topics including
>>>>
>>>> ·         statistics: markov processes (continuous and discrete
>>>> state), auto-regressive processes, the Kalman filter, covariance stationary
>>>> proceses, ect.
>>>>
>>>> ·         economic models: the income fluctuation problem, an asset
>>>> pricing model, the classic optimal growth model, optimal (Ramsey) taxation
>>>> , the McCall search model
>>>>
>>>> ·         dynamic programming: shortest path, as well as recursive
>>>> solutions to economic models
>>>>
>>>> All the lectures have code examples in Julia and most of the 22 will
>>>> display code from the QuantEcon.jl library.
>>>>
>>>> ​
>>>>
>>> ​
>>>
>>
>>  ​
>

Reply via email to