Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

numbat.dev

Post reply on HN
Print view View original

31–40 of 122 posts

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

#31

Post by cosmojg »

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 in the first place.

Not that I want to detract from the author's hard work, of course, I'm just very excited about Julia! Numbat is obviously an awesome project, and I can't wait to see where it leads!

[1] https://painterqubits.github.io/Unitful.jl/stable/

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

#32

Post by geysersam »

jskherman wrote: post #26
iNic wrote: post #23

Earlier quoted context omitted.

Those types of functions are only allowed to take in dimensionless (ie scalar) values. Numbat seems to handle this correctly, see [1]. [1]: https://numbat.dev

I guess that's logical, still a bit tedious in converting values to scalars...

If the value passed to the function isn't dimensionless there's very likely a unit error somewhere.

I can't come up with an example where that would be a reasonable thing to do, but haven't thought too much about it.

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

#33

Post by BasilPH »

indentit wrote: post #30

Can it be used as a date calculator? I didn't see a way to specify "today" or "tomorrow". Like "today" + 14 days etc.

I was also looking into this, and couldn't find a way to do it.

My guess is that it has support for time, but not for calendars. The fact that a "month" is a static length points in this direction.

Maybe there's going to be a calendar module in the future though?

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

#35

Post by xigoi »

jskherman wrote: post #26
iNic wrote: post #23

Earlier quoted context omitted.

Those types of functions are only allowed to take in dimensionless (ie scalar) values. Numbat seems to handle this correctly, see [1]. [1]: https://numbat.dev

I guess that's logical, still a bit tedious in converting values to scalars...

If you find yourself wanting to do that, you're probably making the exact kind of error that the language is meant to prevent.

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

#39

Post by [deleted] »

cosmojg wrote: 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…

[deleted]

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

#40

Post by vlovich123 »

manifoldgeo wrote: post #19

How does something like `let y: Time = 1 year` work? Does it take into consideration the idea of leap years and leap seconds, counting a single year as 365.2422 days[0]? Or does it count as 365 days? I got curious and installed the CLI tool[1] and found that it does indeed account for leap second / leap years: >>> let jahr: Time = 1 year >>> let tage: Time = jahr -> days >>> tage = 365.243 day [Time] References: 0: h…

I feel like that’s unit confusion. Converting from year to day should require you to specify what calendar year you’re in to resolve the ambiguity. Otherwise I set an alarm for today + 1 year and things are off by 6 hours.

Time is nasty because there’s lots of overloaded concepts and bugs hide in the implicit conversions between meanings.

I’m also kinda curious what the underlying type is. Is it a double or do they use arbitrary precision math and take the perf hit.

Post reply on HN