by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 17 05:47

    dependabot-preview[bot] on cargo

    (compare)

  • Sep 17 05:47
    dependabot-preview[bot] closed #38
  • Sep 17 05:47
    dependabot-preview[bot] commented #38
  • Sep 17 05:47
    dependabot-preview[bot] labeled #39
  • Sep 17 05:47
    dependabot-preview[bot] opened #39
  • Sep 17 05:47

    dependabot-preview[bot] on cargo

    Update pyo3 requirement from 0.… (compare)

  • Sep 14 05:52

    dependabot-preview[bot] on cargo

    (compare)

  • Sep 14 05:52
    dependabot-preview[bot] closed #35
  • Sep 14 05:52
    dependabot-preview[bot] commented #35
  • Sep 14 05:52
    dependabot-preview[bot] labeled #38
  • Sep 14 05:52
    dependabot-preview[bot] opened #38
  • Sep 14 05:52

    dependabot-preview[bot] on cargo

    Update pyo3 requirement from 0.… (compare)

  • Sep 08 05:48
    dependabot-preview[bot] labeled #12
  • Sep 08 05:48
    dependabot-preview[bot] opened #12
  • Sep 08 05:48

    dependabot-preview[bot] on cargo

    Update openblas-src requirement… (compare)

  • Sep 01 05:24
    stefan-k labeled #71
  • Sep 01 05:24
    stefan-k labeled #71
  • Sep 01 05:24
    stefan-k opened #71
  • Aug 26 07:02

    dependabot-preview[bot] on cargo

    (compare)

  • Aug 26 07:02

    stefan-k on master

    Update nalgebra requirement fro… Merge pull request #70 from arg… (compare)

Gernot Bauer
@g-bauer

Sure. My problem description looks smth like this:

#[derive(Clone, FakeSerialize, FakeDeserialize)]
struct StateOp {
    eos: Arc<EquationOfState>,
    spec: StateSpecs,
    moles: Array1<f64>,
    initial_density: Option<f64>,
    phase: Option<Phase>,
}

which works. StateSpecs is an Enum with f64 fields. But f64 is a specific case - I want to support different precisions as well as a different numerical type which is implemented within my library.

I'd like to generalize this struct to smth like:

#[derive(Clone, FakeSerialize, FakeDeserialize)]
struct StateOp <T> {
    eos: Arc<EquationOfState>,
    spec: StateSpecs<T>,
    moles: Array1<T>,
    initial_density: Option<T>,
    phase: Option<Phase>,
}

where for T would be also ArgminOps Output and Param types. This does not compile. Now, this could come from my limited knowledge using rust. I tried different solutions with trait bounds on T but couldn't figure it out. Maybe I'm stretching the boundaries of what this crate is supposed to do ;).

Stefan Kroboth
@stefan-k
It doesn't compile because T is not Serialize + Deserialize?
Gernot Bauer
@g-bauer
This is a stripped down version. I added Serialize + Deserializeto the trait bounds but then I run into liftetime issues because of Deserialize.
Stefan Kroboth
@stefan-k
You may need to use DeserializeOwned instead
If that doesn't work I may have another, slightly hacky solution
Gernot Bauer
@g-bauer
I'll try it. Thanks for your patience ;-)
Stefan Kroboth
@stefan-k
no worries
you're not pushing the boundaries of this crate. Trait bounds are often a pain. We've had a lengthy discussion about this exact problem in #7. It is possible to hide serialization behind a feature gate, but it may have unpleasant side effects. I may give it a try though if I find the time
Gernot Bauer
@g-bauer
I haven't looked into best practices on APIs in rust, but I am generally struggling using structs and traits that enforce multiple trait bounds. If hiding functionalities that may not be used in every (or most of?) use case behind features would help a lot with these pain points I guess? But, again, I'm new to rust so this might simply be an issue of my ignorance.
Stefan Kroboth
@stefan-k
I have another idea. I may redesign checkpointing such that only the internal state needs to be serializable.
Generics is often no fun when doing numerical computing in Rust. Just being generic over Floats is difficult:
pub trait SphrsFloat: Float + FloatConst + FromPrimitive + Debug {}
impl<I> SphrsFloat for I where I: Float + FloatConst + FromPrimitive + Debug {}

pub fn sh3p3<T: SphrsFloat>(p: &dyn SHCoordinates<T>) -> T {
    T::from_f64(0.25).unwrap()
        * (T::from_f64(35.0 / 2.0).unwrap() * T::FRAC_1_PI()).sqrt()
        * (p.x().powi(2) - T::from_f64(3.0).unwrap() * p.y().powi(2))
        * p.x()
        / p.r().powi(3)
}
Gernot Bauer
@g-bauer
Yes I have the same issues for my own numeric types. It's a real pain. And then you want to do math with arrays of these generic types...
I added trait bounds to T: Sync + Send + Serialize + DeserializeOwned + Copy but when I try to derive FakeSerialize for my struct StateOp<T: ...>, I get
error[E0107]: wrong number of type arguments: expected 1, found 0
   --> eos-core/src/state.rs:660:8
    |
660 | struct StateOp<T: Clone + Serialize + DeserializeOwned + Send + Sync> {
    |        ^^^^^^^^^^^^^^ expected 1 type argument

error: aborting due to previous error
Stefan Kroboth
@stefan-k
Weird... ok, then I guess it is time for my hacky suggestion
Gernot Bauer
@g-bauer
But for now I'm ok with some code duplication. I simply implement my optimization problems for some cases by hand. No need for you to spent your precious time on my problems.
Stefan Kroboth
@stefan-k
you could try to derive Serialize and Deserialize (not fake), but use #[skip(serde)] (I think, you may have to look this up) for every field which causes problems. But this may require your types to implement Default.
Gernot Bauer
@g-bauer
by the way, my code is currently 20% faster than my old fortran code which uses minpack for optimization.
I can certainly try.
Stefan Kroboth
@stefan-k
oh thats quite a lot... using argmin or your own implementation?
Gernot Bauer
@g-bauer
Ok, it compiles using #[serde(skip_serializing)] for fields that threw errors. Yeah!
Stefan Kroboth
@stefan-k
hooray!
sorry about the inconvenience
Gernot Bauer
@g-bauer
Well I cannot clearly say which parts of my code yield the performance improvement since I rewrote almost everything. But my benchmark includes Argmin optimization.

sorry about the inconvenience

No problem - thanks for your help. I'm learning a lot ;-)

Stefan Kroboth
@stefan-k
you're welcome. I opened issue #34 which addresses this problem and I hope I will find time soon to fix this
Gernot Bauer
@g-bauer
Nice, thank you very much. Stay safe in Freiburg . Grüße aus Stuttgart.
Stefan Kroboth
@stefan-k
Danke :)
ebenfalls :)
Stefan Kroboth
@stefan-k
@g-bauer I started working on removing the Serialize trait bound from ArgminOp but ran into some problems (#36). I hope I'll be able to get back to it soon, but if you want to have a go at it, feel free to do so :)
Stefan Kroboth
@stefan-k
@g-bauer I think was able to remove the Serialize trait bound on ArgminOp in the current master branch. In case you give it a try I'd appreciate it if you could tell me whether it worked for you or not :)
Gernot Bauer
@g-bauer
Thanks a ton. I'll try it out.
Also - moving to thiserror is awesome! Thanks for that
Gernot Bauer
@g-bauer

@g-bauer I think was able to remove the Serialize trait bound on ArgminOp in the current master branch. In case you give it a try I'd appreciate it if you could tell me whether it worked for you or not :)

Works like a charm. Thanks - makes my code much clearer and (imho) it's way easier to use your crate!

Stefan Kroboth
@stefan-k
Great :)
Thanks for your feedback!
Stefan Kroboth
@stefan-k
@g-bauer sorry to bother you again, but I just wanted to let you know that it is now also not necessary anymore to implement Copy for your operator
Ethan Smith
@ethanhs
Hi! I work on a project that could do with going a bit faster. I'd like to move some existing Python code to Rust, but to enable taking advantage of threads, I'd like to use a Rust optimizer. We currently can use BFGS, but I was wondering if it would be possible to get a Levenberg-Marquardt (or similar least squares method) implementation
Stefan Kroboth
@stefan-k
Hi @ethanhs ! I would love to have Levenberg-Marquardt in argmin, but I'm afraid I won't have time to implement it, at least for the next couple of weeks (if not months) due to other obligations. If you are interested in providing an implementation, I'm happy to guide you through the process though.
Ethan Smith
@ethanhs
@stefan-k ah I see! I'm not really familiar with the inner workings of LM, but I might consider contributing an implementation!
Ethan Smith
@ethanhs
Does anyone have advice on how to choose parameters for particle swarm?
Ethan Smith
@ethanhs
Hm, it seems I only get 2 points from particle swarm, is there any way to set the dimension of the optimizer?
Stefan Kroboth
@stefan-k
This was implemented by @jjbayer, maybe he can help. I tried to add him to this channel but seems like I can't. Please, could you open an issue?
Ethan Smith
@ethanhs
Sure!
Adrian Benavides
@adrianbenavides_gitlab
hey guys, I think https://argmin-rs.github.io/ is down!
Stefan Kroboth
@stefan-k
Hey @adrianbenavides_gitlab , thanks for letting me know! The URL you posted never really worked, but you are right, the argmin-pages ( https://argmin-rs.github.io/argmin/argmin/ ) were broken. I fixed it and it should work again. Thanks a lot! :)
Alex Lang
@alang9
Hi. Is it recommended to run solvers without Executor?
Stefan Kroboth
@stefan-k
Hi @alang9 . You can run them without Executor, but you will need to be very careful, because many solvers rely on a properly updated internal state (which Executor handles for you). If you are able to provide more context as to why you want to do that, I might be able to give you a more detailed answer.
Alex Lang
@alang9
@stefan-k hmm I want to be able to resume from a previous state without having to write to disk
Stefan Kroboth
@stefan-k
@alang9 I see. Allowing users to implement their own checkpointing mechanisms would actually be a pretty useful feature. If I remember correctly, I tried to do this in the past, but couldn't get it to work because of trait bounds. But in the meantime the design of argmin has changed a lot in that regard and I think it should be fairly straightforward to implement (if one takes the implementation of the observers as reference). Unfortunately I don't have any time to spend on this now and in the foreseeable future :( I'd be happy to help if you (or anyone else) is willing to work on this (I opened #71 to keep track of it).