Giter Site home page Giter Site logo

inverselaplace.jl's Introduction

inverselaplace.jl's People

Contributors

jlapeyre avatar heltonmc avatar juliatagbot avatar mortenpi avatar

Stargazers

daviehh avatar dunxen avatar  avatar Inni Dynamics avatar Haroun Meghaichi avatar  avatar Orestis Ousoultzoglou avatar Yakir Luc Gagnon avatar STYLIANOS IORDANIS avatar ebigram avatar Alexandre Kabla avatar Qingyu Qu avatar  avatar  avatar Okon Samuel avatar David P. Sanders avatar  avatar mnh avatar Théo Galy-Fajou avatar Shi Pengcheng avatar Pranav Vempati avatar Moritz Schauer avatar Elías Snorrason avatar  avatar  avatar  avatar hasundue avatar Zacharias Steinmetz avatar Jonny Brooks-Bartlett avatar Wow001 avatar

Watchers

James Cloos avatar  avatar Elías Snorrason avatar  avatar  avatar  avatar

inverselaplace.jl's Issues

talbotarr yields NaN with single element array argument [0.0]

Apologies if this is expected behavior (if so I will try and put in a PR to the docs), but it was unexpected to me:

julia> using InverseLaplace

julia> Jbar(s) = (1/s^2)*(1 + s^(0.5))/(1 + 1/s+ s^(-0.5));

julia> InverseLaplace.talbotarr(s -> Jbar(s), [0.0, 1.0])
2-element Array{Float64,1}:
 0.02312633959753949
 0.7837570956002141

julia> InverseLaplace.talbotarr(s -> Jbar(s), [0.0])
1-element Array{Float64,1}:
 NaN

However,

julia> InverseLaplace.talbotarr(s -> Jbar(s), [1.0])
1-element Array{Float64,1}:
 0.7837570956002141

So the 0.0 argument works when the array size > 1, but fails when 0.0 is the only element.

And single-element arrays work fine when the single array element > 0.0.

I've reproduced this behavior on the most up to date versions compatible with Julia 0.6 and Julia 1.0.1. Using Windows 7, 64 bit.

Excessive memory allocation when evaluating w(t)::Complex compared to w(t)::Float64

The following code solves a linear system of equations in the Laplace domain. Then it uses Weeks' method to determine the inverse Laplace transform of the first element of the solution.

using InverseLaplace
using Base.LinAlg.LAPACK: gesv!

######  Function definitions

function randmatvec(N::Int64)
    # Initialize the matrix A  and the vector b for the equation (sI - A)x = b
    A = complex.(rand(N^2,N^2),rand(N^2,N^2))
    b = zeros(Complex{Float64},N^2)
    b[N*(N-1)] = complex.(1.0,0.0)
    return (A, b)
end

function matrixequation!(A::AbstractArray{T},s::T) where T
    # Returns the l.h.s. of the equation (sI - A)x = b
    A .= s.*eye(A) .- A
    return A
end

function solvematrixequation!(A::AbstractArray{T},b::AbstractVector{T},s::T) where T
    # Return the first element of the solution of (sI - A)x = b
    gesv!(matrixequation!(A,s),b)
    return b[1]
end

function laplaceelement(s::Complex{Float64}, N::Int64)
    # Wrapper for first element of x(s) = (sI -A)⁻¹b
    (A,b) = randmatvec(N)
    return solvematrixequation!(A,b,s)
end
######


N = 8
laplaceelement(s::Complex) = laplaceelement(s, N)

trange = collect(linspace(0.0,3.0,1E5))

begin
    println("Float64")
    @time w1 = Weeks.(laplaceelement)
    @time w1.(trange)
    println("")

    println("Complex{Float64}")
    @time w2 = Weeks.(laplaceelement,datatype=Complex)
    @time w2.(trange)
    println("")
end

After running the begin block twice, I get the following output:

Float64
  0.044574 seconds (2.05 k allocations: 24.277 MiB, 16.83% gc time)
  0.267619 seconds (6 allocations: 781.484 KiB)

Complex{Float64}
  0.042009 seconds (2.32 k allocations: 24.293 MiB, 10.89% gc time)
  0.869980 seconds (37.80 M allocations: 1.030 GiB, 18.26% gc time)

The evaluation of the complex w(t) takes three times as long as the real one.
I would have expected it to take only twice as long.
What causes the increase in memory allocation?

Also do the Laplace Transform

Currently your package provides the inverse laplace transform. Would it be possible to add an Laplace transform too? Or is that functionality best contained in a another package?

`talbot` yields NaN where it shouldn't

This is related, but different to, issue #5. Apologies if I have misunderstood something from your answer in that issue.

I have a function defined in the time domain as J(t) = 1 - exp(-t) which yields 0.0 at t=0.0. The Laplace transform of this function is Jbar(s) = 1/s - 1/(s + 1).

For various reasons, the inputs and outputs should be of type Float64. However, recalling what you said about using BigFloat, I defined a few different versions of this:

J_i(s) = 1/s - 1/(s + 1);

J_f64(s) = 1.0/s - 1.0/(s + 1.0);

For all numerically computed values I get NaN:

julia> talbot(s -> J_i(s), big(0.0))
NaN

julia> talbot(s -> J_f64(s), 0)
NaN

julia> talbot(s -> J_f64(s), 0.0)
NaN

julia> talbot(s -> J_f64(s), big(0))
NaN

Is this just a corner case that causes numerical instabilities? It is strange because it happens for all the creep moduli (https://en.wikipedia.org/wiki/Creep_%28deformation%29) in my program that are defined in terms of their Laplace transform, and I am sure that they all have well defined values at t=0.0 in the time domain.

Note that it gets closer to the correct value for extremely small values of t, and this is the approximation I am currently using to get round the issue:

julia> talbot(s -> J_f64(s), 1e-5)
9.999950291077498e-6

julia> talbot(s -> J_f64(s), 1e-15)
2.4006857918196764e-12

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Check status of Optim.jl

Use of Optim.jl was disabled pre julia 1.0. Check if the brokenness has been resolved. Consider reenabling.

Scalar method requires element-wise evaluation of array-valued functions

I have a function definition that solves a system of equations by calling gesv!.
If the system is large, gesv! is called multiple times for each solution element.
This is because the current FFT call in '_wcoeff' only handles scalar valued functions.

I can make a seperate method that deals with array valued functions by storing the Laguerre-coefficients in higher dimensional arrays and applying a FFT along the first dimension of those arrays.

For simplicity, I'd start with vector valued functions.

Registering current changes as v0.3.3

Is there anything preventing this repo from releasing/registering changes since v0.3.2? It looks like the current commit (7811acf) is passing all the checks and there hasn't been a commit for about a year. I found myself needing to use the Weeks method parameter optimizer, which is not functional in v0.3.2 due to a removed Optim dependency, but seems to work fine on the current commit (dependency reinstated with 6205482). Installing directly via GitHub is certainly a solution, but I'm just curious if there are lingering issues that would prevent releasing current changes as a v0.3.3

Many thanks!

Fix documentation deployment

There are lots of check marks and green things in Actions when building docs and deploying. But this is not reflected in the gh pages. Instead, the last pages built before transferring from jlapeyre to JuliaMath appear.

Also export `gaverstehfest` as alias to `postwilder`.

Hi,

Would it be possible to also export a gaverstehfest method that would be an alias for the current postwilder ? I was looking for this algorithm and was about to start a fork to implement it because I did not saw it.

In a large part of the literature, the name of this algorithm is 'Gaver-Stehfest', in the names of Gaver, who found the approximating series, and Stehfest, who found the accelerated convergence tricks. Post-Wilder are the ones that found the continuous formula that Gaver's work derives from.

Also, the principal cited source in postwilder.jl is written by Stehfest, not Post-Wilder.

I do not ask for a change of name -- would probably be breaking --, an alias would be enough.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.