V1ndaar

but just... why?

Multiverse Computing is one of the weirdest companies I've encountered here in Europe/Spain. Their product / job application descriptions are just technobabble.

Despite my doubts I applied to one of their positions a couple of years back only to receive a super late and generic "we are not moving forward" mail (I'd say I fit pretty damn well for the position, but it seems to be the new normal that most companies don't even want to chat with people 99% of the time).

Huh, I completely missed that. I've been using python-garminconnect [0] for a few months without issues. I agree though that it's annoying, though not reason enough for me to switch away from Garmin yet.

  [0]: https://github.com/cyberjunky/python-garminconnect

It's cheap to hide behind a pseudonym here and complain as you do. Given the time scales you mention and how you are complaining, I have a theory under what nick you were present in the Nim community though.

If I'm correct, I find your complaints especially about our moderators especially unfair. Arguably the only drama with moderators was in the context of Dom and you know that.

I really don't see where any of the current moderators can be described as "toxic", but you'll just say "you're one of them" anyway, so why do I even bother...

I didn't realize Keras was actually released before Tensorflow, huh. I used Theano quite a bit in 2014 and early 2015, but then went a couple years without any ML work. Compared to the modern libraries Theano is clunky, but it taught one a bit more about the models, heh.

    Location: Spain (80%) | Germany (20%)
    Remote: Preferred, but open to hybrid positions in Spain
    Willing to relocate: Not currently, but open to work-related travel
    Technologies/Skills:
      - Languages: Nim, C, C++, Python, Go, Rust, Emacs Lisp
      - Scientific computing, simulations, data visualization, research, ML
      - Open-source library development (plotting, dataframe, static physical unit checking, ...)
    Github: https://github.com/Vindaar
    Résumé/CV: Available upon request
    Email: [email protected]

PhD in Physics | Scientific Computing | Open Source

About me:

Recently defended my PhD in physics with extensive experience in scientific computing:

  - Data processing and visualization
  - Training / validating ML models for classification
  - (Monte Carlo) simulations
  - Developed many open-source libraries for the Nim programming language

Seeking opportunities in research-focused roles or software development positions. The ideal company has ambitious goals beyond profit, particularly interested in:

  - ML / AI research (advancing state of the art)
  - Energy production (nuclear & renewables)
  - Aging-related research
  - ZK cryptography
  - Motorsport

Quick learner with strong programming foundation, eager to tackle new challenges. While I may not check every "years of experience" box, I combine scientific rigor with practical coding skills.

Recent experience with freelance work; open to similar opportunities.

I would blame the majority of your criticism on the fact that HN is not the best place to read code. Also, syntax highlighting & basic familiarity with Nim helps.

His code is doing a few more things than necessary. The actual algorithm is inside the `uniqCEcvm` template. The `it` it receives is anything you can iterate over (a collection or an iterator). Multiple things in one line really only appear where they directly relate to the part at the beginning of the line.

The `when isMainModule` is Nim's way of Python's `if __name__ == "__main__"`. The entire part below that is really just a mini CL interface to bench different (random) examples. Final thing to note maybe, the last expression of a block (e.g. of the template here) will be returned.

And well, the style of comments is just personal preference of course. Whether you prefer to stay strictly below 80 cols or not, shrug.

I grant you that the usage of 2 sets + pointer access to them + swapping makes it harder to follow than necessary. But I assume the point of it was not on "how to write the simplest looking implementation of the algorithm as it appears in the paper". But rather to showcase a full implementation of a reasonably optimized version.

Here's a version (only the algorithm) following the paper directly:

    proc estimate[T](A: seq[T], ε, δ: float): float =
      let m = A.len
      var p = 1.0
      var thr = ceil(12.0 / ε^2 * log2(8*m.float / δ))
      var χ = initHashSet[T](thr.round.int)
      for i in 0 ..< m:
        χ.excl A[i]
        if rand(1.0) < p:
          χ.incl A[i]
        if χ.card.float >= thr:
          for el in toSeq(χ): # clean out ~half probabilistically
            if rand(1.0) < 0.5:
              χ.excl el
          p /= 2.0
          if χ.card.float >= thr:
            return -1.0
      result = χ.card.float / p

And not only that, in many cases they will tell you (if they reply) "oh, we can't find the source of that plot anymore". Happened to me quite a few times (although in physics).

I'm pretty sure I'm not the only one who's written themselves a mini tool to even extract data from a bitmap plot based on the axes. Involves some manual steps (cropping mainly), but is very convenient for the cases where people not even use vector graphics, but sometimes even just screenshots of plots... Do I like it? Hell no! It's why I've put quite some effort in doing it better for my PhD thesis.

Thanks your your input. You made me realize I can use my Hetzner storage box for precisely the same. Neat!

> The Datamancer data frame library is incredibly robust.

Thank you for the kind words! :) Especially given that it's a one-man side-project always makes me a bit worried people will stumble over all sorts of issues.

My hope is that thanks to stuff like DLSS frame generation in video games (or maybe AR/VR) that the opinion of a majority of people will change over time. So that eventually maybe... we might actually see movies being filmed in higher framerates. People's conditioning really stands in their way, imo.

The only bad thing about motion interpolation on most TVs in my book is the fact that the /implementation is often pretty bad/. If perfect frame interpolation was a thing, I'd watch everything upsampled to 165Hz of my monitor. Well, I do it anyway using the Smooth Video Project. But that also suffers from artifacts, so is far from perfect. Much better than judder though...

I nowhere said impossible! All I say it is tricky and that likely the code you write will have to be adapted in certain cases (compared to current existing implementations of numerical algorithms).