Most active commenters

    ←back to thread

    Show HN: Rust library for numerical integration of real-valued functions

    (github.com)
    123 points mtantaoui | 16 comments | 19 Nov 24 12:41 UTC | HN request time: 1.462s | source | bottom

    Integrate is a fast, small, lightweight Rust library for performing numerical integration of real-valued functions. It is designed to integrate functions, providing a simple and efficient way to approximate definite integrals using various numerical methods.

    Integrate supports a variety of numerical integration techniques: - Newton-Cotes methods:

      - Rectangle Rule.
  - Trapezoidal Rule.
  - Simpson's Rule.
  - Newton's 3/8 Rule.
    - Gauss quadrature methods:

      - Gauss-Legendre.
  - Gauss-Laguerre.
  - Gauss-Hermite.
  - Gauss-Chebyshev First Kind.
  - Gauss-Chebyshev Second Kind.
    - Adaptive Methods:

      - Adaptive Simpson's method
    - Romberg’s method.
    1. JanisErdmanis ◴[19 Nov 24 14:42 UTC] No.42183942[source]▶
    It looks a bit sloppy to hardcode so many constants in a single file: `src/gauss_quadrature/legendre.rs`. Isn't it possible to generate them with the help of rust macros in the same way Julia uses metaprogramming?
    replies(3): >>42184353 #>>42185117 #>>42185548 #
    2. ok123456 ◴[19 Nov 24 15:18 UTC] No.42184353[source]▶
    Gaussian quadrature points are typically solved numerically. There's a good chance these ultimately came from a table.

    Additionally, compile time floating-point evaluation is limited. When I looked around recently, I didn't see a rust equivalent of gcem; any kind of transcendental function evaluation (which finding Gaussian quadrature points absolutely would require) would not allow compile-time evaluation.

    replies(2): >>42185264 #>>42186782 #
    3. two_handfuls ◴[19 Nov 24 16:19 UTC] No.42185117[source]▶
    Probably but that would slow down compilation a lot.
    replies(3): >>42186409 #>>42186665 #>>42190112 #
    4. AlotOfReading ◴[19 Nov 24 16:29 UTC] No.42185264[source]▶
    Support for float const fns was merged just a couple months ago and hasn't been officially announced yet.
    replies(2): >>42185347 #>>42185528 #
    5. ok123456 ◴[19 Nov 24 16:37 UTC] No.42185347{3}[source]▶
    IIRC, that only supports elementary arithmetic operations. Useful but not general.
    replies(1): >>42185534 #
    6. BD103 ◴[19 Nov 24 16:54 UTC] No.42185528{3}[source]▶
    Support for constant float operations was released in Rust 1.82! https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html
    7. AlotOfReading ◴[19 Nov 24 16:54 UTC] No.42185534{4}[source]▶
    It's relatively straightforward to build transcendental functions out of the basic operations and the stdlib support will eventually get there, but rust's float story is still a work in progress. They're trying to do things more properly and document semantics better than C and C++ have.
    8. mtantaoui ◴[19 Nov 24 16:55 UTC] No.42185548[source]▶
    this was mainly to use an Iteration free method in this paper: https://www.cfm.brown.edu/faculty/gk/APMA2560/Handouts/GL_qu...

    this method is much faster and simpler.

    9. simlevesque ◴[19 Nov 24 18:06 UTC] No.42186409[source]▶
    Exactly, it's not like the constants are gonna change.
    10. blharr ◴[19 Nov 24 18:32 UTC] No.42186665[source]▶
    You wouldn't have to recompile them every time. What if you didn't necessarily use macros but auto-generated it in a file that you keep separate from the other code at the bottom?
    11. zokier ◴[19 Nov 24 18:44 UTC] No.42186782[source]▶
    I was under the impression that macros can execute arbitrary code, surely some FP would not be big problem. And if not macros then build.rs script certainly could do the trick.
    replies(1): >>42187277 #
    12. dhosek ◴[19 Nov 24 19:39 UTC] No.42187277{3}[source]▶
    build.rs can definitely execute arbitrary code, which means that a lot of places (including, IIRC crates.io) will forbid crates that rely on build.rs. I ended up refactoring my build.rs into a separate sub-application in finl_unicode that built data tables which are then checked into git and used pre-built. I include the sub-app in the source code so that anyone with access to the repo could continue development if I were to die tomorrow.
    replies(1): >>42188113 #
    13. n_plus_1_acc ◴[19 Nov 24 21:09 UTC] No.42188113{4}[source]▶
    There are many crates with build.rs scripts on crates.io, because they host just the source code with the Cargo.{toml,lock}.
    replies(1): >>42188859 #
    14. dhosek ◴[19 Nov 24 22:42 UTC] No.42188859{5}[source]▶
    I ran into some issues with crates.io and my build.rs when I first released the crate, although it’s long enough ago, that I don’t remember exactly what the issue was. It might also have been that the build.rs script downloaded raw data files from unicode.org
    replies(1): >>42190262 #
    15. dataflow ◴[20 Nov 24 01:52 UTC] No.42190112[source]▶
    What I would do in these cases is to define the general computation function, but special-case it to return the hard-coded value for specific common inputs if it's being evaluated at compile time. Then add a test to verify both behaviors.
    16. Arnavion ◴[20 Nov 24 02:20 UTC] No.42190262{6}[source]▶
    crates.io doesn't care what your build.rs does because it doesn't try to compile your code, neither now or ever in the past. There would be no point in it trying to compile your code; there are lots of crates that are bindings to C libraries that crates.io's builders can't be expected to have, crates that target architectures which crates.io can't be expected to have builders for, etc.