Turun @ Turun @feddit.de

Posts

0

Comments

599

Joined

2 yr. ago

I wonder if it would be possible with rust's macro system?

I don't know, but maybe check out numbat, it's a new scientific calculator that is written in rust.

But all the downsides you mention are inherent to the problem, not to adding dimensions.

managing scales

How do you add a nanometer and a meter without units? You need to make the choice loss of precision vs convert to nanometer anyway. Types just give you reassurance that you did the right thing (at opposed to, say convert m to gigameter instead of nanometer, because you forgot a minus sign for the conversion).

Constants

A good unit system has the constants saved. I don't need to look up the dimensions of hbar in eV, I just do units.hbar and get the thing I mean, not the number that implicitly has a J or eV next to it. And if you have a constant that is not in the units library, you only need to define it once. This really isn't the problem you make it seem.

Logarithms

I am very curious where you take logarithms of measures with dimensions and why you cannot normalize to e.g. l/1m // length in meters before taking the log. A unit system doesn't prevent you from doing this, it just makes it explicit what you implicitly did anyway (but didn't tell anyone else, because it's implicit)

Performance

This is a fair point and I will grant you that. If you do large scale simulations you need performance more than anything. But most math you do in science is a short script that I don't want to pour an hour into to make sure I didn't fuck up the units. I want to write the script, have the computer check the units and then take a break while the computer takes an hour to compute the result.

Units and namespaces

Not a big problem in my experience. The vast, vast majority of variables are derived. You don't need to write v = 3 * meters / second, you have distance = 100 * meters and time = 33 * seconds somewhere in your code anyway, so you only need v = distance/time. The assignment to v is identical, if you have units or not. You only need to define the input, and only do it once.

normalized form

The units library simply allows you to choose. print(fuel_efficiency.in(1 * liter / (100 * kilometer))) // 5 l/100km or print(fuel_efficiency.to_si_base_units()) // 5e-8 m**2

I have written code of the form xxxx_in_meV, yyyy_in_per_cm_cubed, etc before. It's much worse than a proper unit system library.
Because if you don't use a library you may be able to use a number for your constants - but you have to find out the value of your constants in some weird jumble of dimensions. It's the difference between target_efficiency = 5 * liter / (100 * km) and target_in_metersquared = 5e-8 // 5 l/100km, converted to base units

Taking user input is much easier too. Just do units.parse(user_input), and the user is free to give um or nm or Å. No need for a prominent tip in the ui "input must be given in um!".

All that being said, a new language is not what I am looking for. I use python sympy (though it's not very ergonomic to use) for proper script programs and insect.sh if I need to convert something quickly.

EDIT: insect.sh tells its users to use numbat now, hahaha! numbat.dev has exactly the same UX though, so I'll just recommend that now for those quick physics calculations. It really is an invaluable tool to have.

I disagree with this article.

The first one is a good point in principle, but I would call it pushing down the ifs. A method is usually used to group logic together. So pulling the assertion checks out of that method forces you to replicate it every single time before calling the function. It's very likely you forget to update these conditions in one place and not worth the miniscule loss of performance.

Now, if frobnicate is only something a walrus can do, then it should take a walrus. But if it is something like "given a picture of an animal, check if it is of a walrus, determine its sex and if it is a male, then give the likelihood that is the dominant male on this part of the beach" then you should most certainly push the ifs down to contain all that logic in one single frobnicate method.

Regarding the loops:

If the example given is really all the code you have, then sure, pull that condition out of the loop if you want. But the compiler will optimize it anyway if the condition does not change every loop iteration. And if it does you can't pull the condition out of the loop anyway. A for loop I have much more often in my code looks like this though:

 rust

    
//BAD?
for walrus in walruses { 
    if !walrus.has_tracker() {
        continue;
    }

    if weather.is_bad() {
        continue;
    }


    let weight = estimate_weight(walrus);
    if weight <= threshold_weight {
        continue;
    }

    if study.is_about_frovnication { 
        walrus.frobnicate() 
    } else { 
        walrus.transmogrify()
    } 
} 

  

Which you do not want to spread to two for loops! Sure, in this toy example the if conditions could be simplified. And if you have such trivial loops, you should use iterators anyway. But sometimes you have logic you need to apply to every element, do not want to put that logic in the frobnicate method (especially if you push your ifs up) and can't use iterators in an elegant way.

For the love of god, do not turn it into

 rust

    
if study.is_about_frobnication {
for walrus in walruses { 
    if !walrus.has_tracker() {
        continue;
    }

    if weather.is_bad() {
        continue;
    }


    let weight = estimate_weight(walrus);
    if weight <= threshold_weight {
        continue;
    }

walrus.frobnicate()
} else {
for walrus in walruses { 
    if !walrus.has_tracker() {
        continue;
    }

    if weather.is_bad() {
        continue;
    }


    let weight = estimate_weight(walrus);
    if weight <= threshold_weight {
        continue;
    }

    walrus.transmogrify()
}

  

And last but not least, Profile before you optimize anything. The part about the ifs, and the enum example may not actually impact your performance at all! The compiler is very smart about moving code around, so the enum thing would most likely be inlined and then reduced down further, potentially eliminating the enum from the code completely. It can still be a worthwhile code change to make, because it improves legibility. But since the author mentioned the performance a few times I wanted to give a counterpoint. (That being, profile before you optimize!)

If you are hired to do a task and then overrun the budget by 14B$ I wouldn't exactly call it furthering the cause. More like incompetence and/or trying to detail the project.

This creates a situation where people can be corrupt. Like of the type "the fine is 200$, but if you pay me 50, I'll make sure the ticket will go away". But the article didn't actually show us anything like that happening.

It's more concerned about people who break the law having to pay a fine. I don't care who is holding court over a traffic violation of driving 50% over the speed limit. 75 in a 50? Having your license revoked is the reasonable consequence here.

Or just not break the speed limit?

I get the concerns about possible corruption (though the article didn't show us anything in this regard), but I'm like what's the problem? If you break the law you get a fine. I'd be more concerned about the paces where you don't!

The 11 stands for the number of arms that have been bolted onto the dog in an attempt to turn it into an octopus.

It very very much depends on the country you're from. In Ukraine a better slogan would probably be "my moral compass led me to Lockheed Martin"

when an asteroid inevitably punches through said bus and/or diner.

Or, you know there is a crash? Lol

I've never heard it with the asteroid explanation. But thousands of people die every year in car crashes. Most in single occupant vehicles, but a bus can be involved too.

Of course, but that is precisely the problem. It gets expensive really really fast.

I expect the data size to be a problem. Stable diffusion defaults to 512x512px, because it simply requires a lot of resources to generate an image. Even more so to train one. Now do that times 30 to generate even one second of video. I think we need something that scales better.

I fully expect this to work decently in a few years though, no matter how hard the challenge is, ai is moving really fast.

A major concern has been busing. Even in normal times, districts use the same buses and drivers for students of all ages. They stagger start times to do that, with high schoolers arriving and leaving school earliest in the day. The idea is that they can handle being alone in the dark at a bus stop more readily than smaller children, and it also lets them get home first to help take care of younger siblings after school.

If high schools started as late as middle and elementary schools, that would likely mean strain on transportation resources. O'Connell said Nashville's limited mass transit compounds the problem.

Are staggered start times common in America?

We also exhibit wave-particle duality. It's just that our wavelength is on the order of 10^-25 m or something.

It's stereotypes all the way down.

I have used https://github.com/Nixola/VRRTest before to check the refresh frequency. I use X11 and wanted to check if my 144Hz monitors work with my older 60Hz one. Set the test mode to squares and the frame rate to twice your monitor's refresh rate. You should see every second square light up. If this is not the case, play around with the frame rate in the program until every second square lights up.

I can't see the difference either though. Yes, the mouse moves a bit quicker if I pay attention to it. But I do not care or notice, to be honest.

Your usecase may be different, but I am usually not required to catch solid color frames in my day to day computer use.

Me neither, but I also don't read a lot of handwriting from other parts of the world. But I have heard that some places teach the 1 with a horizontal bar and the 7 without one.

To be fair you can say that about the US (and related allies) as well.

Fine, coloured then!

I think the argument is that if you write a 1 with a line at the bottom it is easy to confuse it with a sloppily written 7, whose bar moved down a bit.

Which invalidates the argument of the user above. (If not inverse it - a lot more numbers in life start with a 1 than with a 7)