Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 26 23:15
    VolodymyrOrlov commented #5
  • May 26 23:15
    VolodymyrOrlov commented #5
  • May 26 23:14
    VolodymyrOrlov commented #5
  • May 26 23:14
    VolodymyrOrlov commented #5
  • May 19 07:38
    stefan-k commented #223
  • May 19 02:26
    deloused closed #223
  • May 19 02:26
    deloused commented #223
  • May 19 02:20
    deloused opened #223
  • May 16 07:32

    dependabot[bot] on cargo

    (compare)

  • May 16 07:32
    dependabot[bot] closed #82
  • May 16 07:32
    dependabot[bot] commented #82
  • May 16 07:32
    dependabot[bot] labeled #83
  • May 16 07:32
    dependabot[bot] opened #83
  • May 16 07:32

    dependabot[bot] on cargo

    Update pyo3 requirement from 0.… (compare)

  • May 14 19:47
    nikmas-dev opened #222
  • May 11 20:20
    stefan-k edited #220
  • May 11 20:19
    stefan-k synchronize #220
  • May 11 20:15
    stefan-k labeled #221
  • May 11 20:15
    stefan-k opened #221
  • May 08 14:11
    stefan-k synchronize #220
Stefan Kroboth
@stefan-k
hopefully that won't be negative again
but it probably will potentially be negative
Daniel Brooks
@db48x
oh, except that it doesn’t completely isolate the t
Stefan Kroboth
@stefan-k
ah you're right
also I think there are many local minima when computing t (since planets tend to go in circles)... so maybe not such a good idea, i apologize
Daniel Brooks
@db48x
it would be easier if they would hold still
Stefan Kroboth
@stefan-k
yes, i've been saying that for years
Daniel Brooks
@db48x
solving the second element of the gradient for θ is nicer
Stefan Kroboth
@stefan-k
true, that also has many minima but they should all be the same
Daniel Brooks
@db48x
oooh, I am an idiot
line 6 of my gist double–counts the current position of the target
when I fix that I get a perfect solution about half the time, and an invalid one the rest
Daniel Brooks
@db48x
I’m adding e^−2*t to the distance, and it’s helping quite a bit
@stefan-k, thank you for your advice!
db48x @db48x yawns
Daniel Brooks
@db48x
it is hours past my bed–time, but I can’t help but play with this: http://db48x.net/temp/plotting%20a%20course%20sometimes%20works%20correctly-2021-07-30_16.59.32.webm
Stefan Kroboth
@stefan-k
ha, why is this so satisfying to watch?? happy to see that it works. Are the red ones continuously optimizing their trajectory?
Daniel Brooks
@db48x
the red ones are doing the simplest thing and just heading straight for the target
Stefan Kroboth
@stefan-k
ah yes, of course
Daniel Brooks
@db48x
local minimums are really annoying
Hubert Hirtz
@hhirtz

Hi! I'm trying to run the GaussNewton algorithm but unfortunately hit an error: Lapack(LapackComputationalFailure { return_code: 1 })

Is there a way to get more info/logs out of lapack?

Stefan Kroboth
@stefan-k
Hi, are you trying to run the example or did you implement something yourself?
Hubert Hirtz
@hhirtz
Right, I'm implementing something else, the example works fine
Stefan Kroboth
@stefan-k
Does the error also appear when you manually call the ArgminOp methods you implemented for your problem?
Hubert Hirtz
@hhirtz
ArgminOp methods do not call lapack, this error happens when the executor runs I think
Stefan Kroboth
@stefan-k
I'm afraid there is no way to get more information about Lapack out of the solver unless you edit the library code... At first glance I'd expect that one of the ArgminOp methods is returning something containing NaNs or INFs. Have you tried printing the return values of those methods during a solver run?
wfsteiner
@wfsteiner:matrix.org
[m]
Hello @stefan-k I went through argmin-rs/argmin#2 and I think argmin-rs/argmin#184 will fix it. The steepestdescent.rs and hagerzhang.rs examples both seem to work as expected now. I think there was an error with the Wolfe condition which resulted in early termination before the iteration started, since the first condition can happen to be satisfied if one chooses good starting parameters. Cheers
Stefan Kroboth
@stefan-k
Hi @wfsteiner:matrix.org I was very happy to see your PR! I will have a closer look (hopefully) tomorrow, but at first glance it seems absolutely reasonable that both conditions need to be met. Thanks a lot for fixing this and also thanks for fixing my typos :)
wfsteiner
@wfsteiner:matrix.org
[m]
Hey! My pleasure :) I also intend to attack #5, but I just started reading the paper, and will not make any significant progress until next week. I will message you then, probably via a draft PR. Cheers!
Stefan Kroboth
@stefan-k
That would be great! :) Currently there is only one population based method (PSO) in argmin, therefore the architecture of argmin may not be ideal yet. Let me know if you run into any problems, we'll find a solution. May I ask which paper you're reading? If I find some time I might read it too.
2 replies
Regarding your other PR: Would it be fine for you if I merged it into master instead of doing a patch release for 0.5? I tried to rebase it but honestly I have no idea what happened :D
1 reply
Gernot Bauer
@g-bauer
Hey @stefan-k. We developed a crate that provides generalized (hyper-) dual numbers which allow you to compute (partial) derivatives without the need to implement analytical derivatives. Might be interesting for argmin-rs. The crate can be found here
Stefan Kroboth
@stefan-k
Hey @g-bauer , thanks for letting me know! This looks great, I will consider integrating this into argmin (after #198) :)
Reece Humphreys
@ReeceHumphreys
Hey @stefan-k, I was using FiniteDiff today and have been experiencing some strange results. It seems the values are correct but central_diff is not returning me the full f64, it is only returning me the values with two decimal places. Is this expected behavior or is there some configuration I need to set? Im pretty new to rust so I may be missing something.
Stefan Kroboth
@stefan-k
@ReeceHumphreys This sounds indeed strange. Do you have a minimal example I could have a look at? I just looked at the code and couldn't find anything that could be causing this.
Reece Humphreys
@ReeceHumphreys
Here is the code I was running, to run it you will need to add a file to data folder that I have also included
The file is 250Mb so Gitter isnt letting me upload it, from https://earth-info.nga.mil click EGM2008 Spherical Harmonics, inside there is a file called EGM2008_to2190_TideFree, add .txt extension to it and the code should run! Let me know if I am just missing something silly (which I probably am haha!)
Stefan Kroboth
@stefan-k
I think the numbers are correct. If I take the numbers printed by your closure and do the math manually (in google), I get the exact same result: (62475811.3671359-62475811.36713561)/(2* sqrt(2.2204460492503131e-16)) = 9.75. This is either correct or there are numerical issues (in that case I'm afraid there's not much I can do). There could still be a problem in finitediff, but so far I couldn't find any indication. If you still think there is something wrong with finitediff then it would be great if you could provide a very minimalistic example because it is difficult for me to understand code from a field I'm not used to :)
Reece Humphreys
@ReeceHumphreys
I think you might be right! Im not an expert in the field either so i could be doing the matn wrong. I’ll follow up once I get a definative answer
Reece Humphreys
@ReeceHumphreys
Found the issue, was not with finitediff, The normalized spherical legendre polynomials I was using from the rgsl crate where normalized using the convention for quantum physics not geophysics. Sorry for bugging you!
Stefan Kroboth
@stefan-k
No worries, glad you found the issue. Thanks for letting me know!
Nikita Maslov
@nikmas-dev
Can somebody share a working code example of using NelderMead algorithm? Whatever I do, the program just crashes

Can somebody share a working code example of using NelderMead algorithm? Whatever I do, the program just crashes

or even don't compile

Stefan Kroboth
@stefan-k
@nikmas-dev Which version of argmin are you using and which example is your code based on? The examples on the main branch on github are based on a yet unreleased version of argmin and hence won't work with 0.5.1 (and below). You should either use the main branch and base it on the current example in github or use version 0.5.1 and this example. Make sure that the number of initial parameter vectors that you provide is n+1 where n is the number of dimensions of your problem.
1 reply
Nikita Maslov
@nikmas-dev
@stefan-k, do you plan to implement the Powell method like in scipy minimize: https://docs.scipy.org/doc/scipy/reference/optimize.minimize-powell.html#optimize-minimize-powell ?

@stefan-k, do you plan to implement the Powell method like in scipy minimize: https://docs.scipy.org/doc/scipy/reference/optimize.minimize-powell.html#optimize-minimize-powell ?

It seems very commonly used and simple

Stefan Kroboth
@stefan-k
Glad you got it to work! Powell's method is certainly in the scope of argmin, but there are currently no plans to implement it in the near future. Would you mind opening an issue on Github about it? That way I won't forget about your request :) You're of course also invited to issue a pull request :)
1 reply