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

That is certainly true (and why added a general "embed plot data as bitmap into SVG/PDF" option to https://github.com/Vindaar/ggplotnim that works not only for raster heatmaps). But realistically such plots are often not ideal anyway (too many data points in a plot is often a sign that a different type of plot would be better; typically one that aggregates in some way) and it's just another argument to make the data for plots available as well.

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).

I mean that article of yours highlights the difficulties one encounters fairly well, I would say. I don't disagree that this is (generally) a tricky problem!

Nim allows you to do a lot, e.g. derivatives of a unitful expression with measurement errors [0]. But other aspects run into the reality of dealing with a static type system. For example in Measuremancer [1], the library handling measurements with uncertainties, each `Measurement` is a single generic `Measurement[T]`. Each measurement stores the derivatives for error propagation. Obviously the derivatives have different units. Now, we could make `Measurement` a two-fold generic, `Measurement[T, U]`, but that just makes things more unwieldy in practice, for not much gain.

Without rewriting a majority of existing code you will always run into trouble where your perfect unit type system will either break or you'll need to work around it anyway (e.g. calling into some C library for part of the code).

[0]: https://github.com/SciNim/astGrad#extra-fun

[1]: https://github.com/SciNim/Measuremancer/

Yeah, unicode characters in Nim code are supported. However, if by `x²` you'd want to square an identifier `x`, that won't work. The Nim lexer parses `x²` as a single identifier.

We do have infix unicode operators though. So `x ÷ y` (spacing required though!) could be implemented easily. I use this for `±` in Measuremancer [0] (which btw also supports Unchained units, for error propagation on unitful measurements).

[0]: https://github.com/SciNim/Measuremancer

Gaussian elimination in what context even? If your LA library supports generic types, it might work. But generally generic math operations are tricky to get right, because math often does things that from a pure physical perspective don't make a whole lot of sense / you run into trouble with too many competing types due to temporary multiplication / divisions etc (which is a big issue in any statically typed language, because your container (vector, matrix, tensor whatever) type is typically a single unit type!

Whoops, guilty as charged. I did indeed glance over that (both the text and the equation not actually being 1/r²).

In this case to get compiler help it's pretty much identical to Numbat. Annotating the "force" variables with a `Force` type. There's a few technicalities involved though. Normally the user is supposed to use explicit type annotations for variables. Quantities like `Force`, `Energy` etc. are mainly supported for function arguments (they are "concepts" in Nim lingo, a specific version of generics).

Technically you can abuse these concepts for type checking, by annotating with `Force`, e.g. `let force_sun: Force = ...`. That will correctly raise a CT error about mismatching units in this case. However, the code will /also/ not compile if you type `Energy` due to the underspecified type.

So what you're supposed to do is:

    import unchained
    
    let earth_mass = 5.972168e24.kg
    let solar_mass = 1.9885e30.kg
    let lunar_mass = 7.342e22.kg
    
    let distance_sun = 1.AU  # astronomical unit
    let distance_moon = 384_400.km
    
    let force_sun: N = G_Newton * earth_mass * solar_mass / distance_sun
    let force_moon: N = G_Newton * earth_mass * lunar_mass / distance_moon
    
    echo force_sun / force_moon

which will correctly raise a

    Error: type mismatch: got 'Joule' for '...' but expected 'Newton = Alias'

(or any other unit of force; note that if it was a non SI unit, e.g. `eV` for an energy, you'd need to explicitly convert the RHS expression into `eV` using `.to(eV)`. That will perform the CT check of whether the conversion is valid, and if so, hands you the value in `eV`. Implicit conversions to explicitly given types is not supported)

So I think we more or less do the same things. :)

And just to clarify, I'm always happy to see more libraries / programs etc. that do units as types. But for the same reason you hadn't even heard about Unchained, is the reason I can't stop myself from mentioning it in such a context. :D (niche programming language + niche topic clearly doesn't help).

Or you could just use Nim [0], where this sort of thing can be implemented in Nim's macro system. Then you have a regular programming language combined with CT safe units. :)

It even pretty much looks identical to those Numbat snippets!

    import unchained
    
    let earth_mass = 5.972168e24.kg
    let solar_mass = 1.9885e30.kg
    let lunar_mass = 7.342e22.kg
    
    let distance_sun = 1.AU  # astronomical unit
    let distance_moon = 384_400.km
    
    let force_sun = G_Newton * earth_mass * solar_mass / distance_sun
    let force_moon = G_Newton * earth_mass * lunar_mass / distance_moon
    
    echo force_sun / force_moon
    # 69593.6 UnitLess

Sorry for the shameless plug. ;) Numbat looks quite cool though and the article talks about a lot of things to think about when writing such a program / lib / programming language.

[0]: https://github.com/SciNim/Unchained

> An obvious question when formalising a maths paper is how much the proof needed to change to be formalised: in other words whether there were any flaws in the paper. This question is surprisingly subtle, but a simple summary is that most of the mistakes I identified were easily fixable. Importantly all mistakes were fixable in a way that preserved the spirit of the argument, so the Lean version of the proof can reasonably be said to be a translation of the informal proof.

> I like to consider certain such small mistakes “mathematical typos”. It’s fair to call them errors, and just like typos in English prose can confuse a non-native speaker, mathematical typos can impede meaning for a reader who isn’t familiar with mathematics. However, with a little experience, it’s not hard to see what the intended meaning was, and fixing it isn’t too bad. A mathematical typo certainly doesn’t constitute a flaw in the proof, and almost all the problems I found fall in this category.

If only we had better ways to distribute fixes to papers. These kind of issues happen all the time and unlike in code where someone can just come in and provide a fix, these usually remain forever in papers. Yes, some publish errata or upload a new version to the arxiv, but the majority remain as a form of horrendous "exercise for the reader". If I'm an expert in a field I may quickly notice such issues, but more often than not I won't spend the time required to do so. And hence I probably propagate wrong information myself / wonder why my numerical calculations don't produce the correct result etc.

It is especially bad when branching out into areas somewhat out of your area. The amount of mistakes and utterly wrong information I had to deal with just in the last few months thanks to papers being sloppy is just sad. So much time wasted. :( (I'm a physicist)

Oh, thanks a lot for the clarification! And thanks for the work on the book in general. :)

I need to look into the changes then. The spectrum implementation of the 3rd version served as inspiration for an X-ray raytracer I've been working on.

Pretty sure the 3rd edition already contained that, no? At that time (not sure if that's still the case now) the choice was a compile time option, iirc.

Evince does the same. It's a great feature, I agree.

I mean honestly, the closest language to Mojo really is Nim. In the latest Lex Fridman interview with Chris Lattner [0] when he talks about his ideas behind Mojo it pretty much sounds like he's describing Nim. Ok fair, he wants Mojo to be a full superset of Python, but honestly with nimpy [1] our Python interop is about as seamless as it can really be (without being a superset, which Mojo clearly is not yet). Even the syntax of Mojo looks a damn lot like Nim imo. Anyway, I guess he has the ability to raise enough funds to hire enough people to write his own language within ~2 years so as not have to follow random peoples whim about where to take the language. So I guess I can't blame him. But as someone who's pretty invested in the Nim community it's quite a shame to see such a hyped language receive so much attention by people who should really check out Nim. ¯\_(ツ)_/¯

[0]: https://youtu.be/pdJQ8iVTwj8?si=LfPSNDq8UKKIsJd3

[1]: https://github.com/yglukhov/nimpy

For me it is partially that for sure. There's plenty of stuff I would - in theory - not mind to post publicly. E.g. my personal notes about interesting stuff I stumble on, want to read up on, how to troubleshoot stuff etc. But the issue is a) I don't feel like investing the time to individually post only subsets and b) posting all of it makes me feel way too vulnerable. At a quick glance suddenly everyone would just know all my interests, my expertise and lack thereof in areas and so on. Just not worth it in the current internet and societal discourse.

Honestly, the "golden days" of using reddit for that purpose are over, too. Both the fact that random other crap comes up due to how stuff is linked on reddit and generally most search engines being too lenient with your search terms and finally more and more conversation going to discord and other places that cannot be searched.

It really is one of the most unfortunate things of the modern internet. :(

Sure, it's very common to flush a system with dry nitrogen for that reason. But of course if you have to fully open a part of the system you're usually out of luck (also you usually don't have valves at every intersection etc., so some part may still be exposed to the atmosphere even if part is "kept dry").

It seems really neat! I recently received a .usdz file and was hoping this would be able to work with it. Unfortunately, that's not the case yet (but there's an issue about it [0]). Compiling the entire OpenUSD framework was a bit of a failure here on Void Linux.

[0]: https://github.com/f3d-app/f3d/issues/780

For people scared off by C++ and who want faster recompile times, check out the Nim bindings [0]. Check out his Twitter/X account [1] for plenty of cool things it brings to the table.

[0]: https://github.com/jmgomez/NimForUE

[1]: https://twitter.com/_jmgomez_

Check out the paper and not a PR piece [0].

[0]: https://stsci-opo.org/STScI-01HA2G716KS9YGAGVY1WBVFJ8Y.pdf

Nope, that is the old paper about Hubble measurements of the same planet.

The preprint of the Webb based paper is here [0] from here [1].

[0]: https://stsci-opo.org/STScI-01HA2G716KS9YGAGVY1WBVFJ8Y.pdf

[1]: https://webbtelescope.org/contents/news-releases/2023/news-2...