Live data from Hacker News

Show HN: Numbat – A programming language with physical dimensions as types

numbat.dev

101–110 of 122 posts

Re: Show HN: Numbat – A programming language with physical dimensions as types

#102
post #25

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…

Would you be able to do nice looking syntax like this in Nim?

x÷y

Re: Show HN: Numbat – A programming language with physical dimensions as types

#103
post #102
post #25

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…

Would you be able to do nice looking syntax like this in Nim? x² x÷y

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

Re: Show HN: Numbat – A programming language with physical dimensions as types

#104
post #84
post #83

Earlier quoted context omitted.

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…

most linear algebra requires vectors of multiple unit types. think of runge-kutta for a second-order system, for example, or just about any multivariate system. see https://yosefk.com/blog/can-your-static-type-system-handle-l... for more information if your static type system can't handle that, it can't handle unit types for basic linear algebra subroutines

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/

Re: Show HN: Numbat – A programming language with physical dimensions as types

#105
post #102

Earlier quoted context omitted.

Would you be able to do nice looking syntax like this in Nim? x² x÷y

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

Required spacing is a blocker/friction, that's one of the benefits of DSLs, I guess, being able to eschew the conservative syntax of the general-purpose languages (though Unicode support is a good step forward)

Re: Show HN: Numbat – A programming language with physical dimensions as types

#106
post #81

Earlier quoted context omitted.

So 'year' refers to the Gregorian year and is equal to 365.243 days [1]. We also have 'julian_year' which is equal to '365.25 days'. We also have 'sidereal_day' equal to '23.9345 hours', and if you believe it is useful, we can also add 'sidereal_years'. [1] https://numbat.dev/doc/list-units.html

Ok so I did some reading and I like what I see, its important however to properly disambiguate between the two kinds of time units. Chronological Time units and Calendrical Time units... These are fundamentally different concepts that overlap a lot in day to day life but when you need to ensure technical accuracy, can be very different. - Planck time, Stoney time, Second: Unambiguously valid for both chronological an…

The entire type system needs to be parameterized by the inertial frame of reference, too.

Re: Show HN: Numbat – A programming language with physical dimensions as types

#107
post #76
post #31

Super cool! I love when programming languages try to do more with types. Julia has a neat little library called Unitful.jl[1] which does almost exactly what Numbat does by taking advantage of Julia's extremely flexible type system. Extending it to cover all of Numbat's functionality could be trivially accomplished in a few lines. In fact, fun type magic like this is pretty much my primary motivation for using Julia i…

I looked at Julia and Unitful.jl quite a bit when designing Numbat. It looks great. > Extending it to cover all of Numbat's functionality could be trivially accomplished in a few lines. Look, I'm not claiming that Numbat is superior. But I think Numbat might have its own little niche. And even if not, it's always good to have alternative solutions available. - Numbat is specifically designed to handle physical dimens…

> Numbat can be compiled to Web Assembly and you can run it in your browser. I'm not sure if that is possible with Julia?

It's fine these days. https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp...

I think the biggest issue with unit systems though is that algorithms are not generally unitful. I develop the Julia SciML solvers (https://docs.sciml.ai/Overview/stable/) and there's certain pieces like the initial dt calculation of an ODE solver which are not canonically correct in a unitful sense. So there's certain pieces where you have to opt out of unit checks which gets a bit messy. But other than that Unitful.jl is fine, and that's an algorithmic thing not a unit package thing.

Re: Show HN: Numbat – A programming language with physical dimensions as types

#108

Earlier quoted context omitted.

All are physical units. In particular in special relativity time is couples with position and you myst use cuadrivectors (t, x, y, z).

Time exists independent of location and can not be visualized in any "physical" way. The same is true for lots of other units of measure. https://phys.org/news/2012-04-physicists-abolish-fourth-dime...

That paper is not good.

I Special Relativity you have many cuadrivectors, for example:

* time-space (t, x, y, z)

* energy-omentum (E, px, py, pz)

* Electromagnetic Potencial (V, Ax, Ay, Az)

and even a few 4x4 matices like the electric and magnetic fields together.

All of them change with the same equations. You can't break (t, x, y, z) and keep all the other.

And there are extensions to particle physics that mix Special Relativity and Quantum Mechanics that use the same equations, and they have an agreement of theory and experiment of 8 digits. You can't break (t, x, y, z) and keep all the other!

Also, the paper is published in a journal I never heard about. It's impossible to be sure, but it has a lot of single author articles that is a big red flag, and the titles of the other articles are too weird (Nobel price or crackpot, nothing in between).

Re: Show HN: Numbat – A programming language with physical dimensions as types

#109
post #20
post #8

So if I try to get the Falcon to do the Kessel run in two Parsecs, Numbat will raise an exception.

Because that’s too short (12 parsecs being close to the theoretical maximum without being swallowed by a black hole) or because it thinks that you confused a unit of distance and speed?

The latter. FYI - Han Solo makes that mistake in the Original Star Wars (A New Hope).

Re: Show HN: Numbat – A programming language with physical dimensions as types

#110
post #20

Earlier quoted context omitted.

Because that’s too short (12 parsecs being close to the theoretical maximum without being swallowed by a black hole) or because it thinks that you confused a unit of distance and speed?

The latter. FYI - Han Solo makes that mistake in the Original Star Wars (A New Hope).

Han Solo’s quote makes sense if you understand it as a unit of distance, optimized by the onboard computer to be as short as possible, by dodging black holes, and therefore fast.
Post reply on HN