Tracking units is a thing that I rarely have a use for (as a non-engineer), but when I do, I’m totally mystified by how bad almost every language is at it. F# is the only actual programming language I found that even tries. It does a pretty decent job, but even it has some disappointing holes (e.g. not being able to understand g and kg as scaled versions of the same dimension). I guess the overlap between physicists/…
This is something that Matlab really shines at with symbolic computation. Is there really not a numpy/scipy equivalent?
Atlas, a hopefully better engineering IDE
131–136 of 136 posts
Re: Atlas, a hopefully better engineering IDE
#132Earlier quoted context omitted.
Or we could not police people's language. "So" is a way to start sentences; like anything else, it can be overused. Just like "like", etc. There's a good podcast episode from John Mcwhorter on this "So" phenomenon. [0] TL;DL It has some interesting applications (including functioning as a discourse marker), and isn't going away anytime soon. [0]: https://slate.com/human-interest/2018/10/john-mcwhorter-on-s...
There was an article in Salon (or was it Slate?) in 1996 on beginning sentences in "So". So, it's interesting it goes that far back. Update: the language log says it goes back before the 1850s. With an early peak around 1870. https://languagelog.ldc.upenn.edu/nll/?p=2570
"Where did you go to lunch?"
"So, we headed downtown..."
I think it's aggravating because it feels evasive, as if the person is pretending they're not answering a question and are instead just starting a new story.
Re: Atlas, a hopefully better engineering IDE
#133> Write equations; not code This is a little odd to me - I generally prefer to write my math in code if its going to be executed. I find my preferences to be pen and paper (or whiteboard)> latex, so perhaps I am not the target demographic here.
You prefer to write code as code, which makes sense as it skips the translation part - but technical code is the implementation of the math so any given equation can represent multiple possible code-implementations.
From that perspective, it might make sense to separate the two, with good tooling. Since tooling generally isn't good, it's just as hassle.
Re: Atlas, a hopefully better engineering IDE
#134Earlier quoted context omitted.
For a while I toyed with writing an extensible spreadsheet engine/app that would allow extensions to do that kind of thing - maybe I should dust that idea off again! ;-)
Seems like many people started on this but never finished it, me too. I got carried away trying to speed up my custom grid control, and borked it up when I tried to use threads :-P.
Combine that with all of the other grandiose plans (writing extension in WASM) then it's no wonder that I wasn't making too much progress... interesting though!
Re: Atlas, a hopefully better engineering IDE
#135Tracking units is a thing that I rarely have a use for (as a non-engineer), but when I do, I’m totally mystified by how bad almost every language is at it. F# is the only actual programming language I found that even tries. It does a pretty decent job, but even it has some disappointing holes (e.g. not being able to understand g and kg as scaled versions of the same dimension). I guess the overlap between physicists/…
When I was a physics student, I would have loved a spreadsheet that tracks units, and automatically does conversions as needed. There is another huge thing that this enables: Tracking uncertainties. It would be awesome if you could not just write "10", but "10 cm ± 1 cm". Then the spreadsheet could do error propagation! Even the simplest case of non-correlated errors would be useful. Also you could have functions lik…
Re: Atlas, a hopefully better engineering IDE
#136Earlier quoted context omitted.
When I was a physics student, I would have loved a spreadsheet that tracks units, and automatically does conversions as needed. There is another huge thing that this enables: Tracking uncertainties. It would be awesome if you could not just write "10", but "10 cm ± 1 cm". Then the spreadsheet could do error propagation! Even the simplest case of non-correlated errors would be useful. Also you could have functions lik…
Fusion 360 has tolerance parameters, that should work for you: https://knowledge.autodesk.com/support/fusion-360/learn-expl...