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 ;).
If that doesn't work I may have another, slightly hacky solution
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
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.
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)
}
I added trait bounds to
T: Sync + Send + Serialize + DeserializeOwned + Copy but when I try to derive FakeSerialize for my struct StateOp<T: ...>, I geterror[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
I can certainly try.
sorry about the inconvenience
sorry about the inconvenience
No problem - thanks for your help. I'm learning a lot ;-)
you're welcome. I opened issue #34 which addresses this problem and I hope I will find time soon to fix this
ebenfalls :)
@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 :)
Also - moving to
thiserror is awesome! Thanks for that
@g-bauer I think was able to remove the
Serializetrait bound onArgminOpin 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!
Thanks for your feedback!
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
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.
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! :)
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.
@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).