I get this sometimes when I ask the agent on GitHub to suggestion improvements to my Julia code. It's kind of fun to watch it struggle to please. I'm reminded of the old "Doctor" mode in Emacs.
The curve on your diagram makes me think that you've fitted a normal (Gaussian) curve to the data. By eye, the distribution looks a bit more like log-normal, and so if you're still working on the data, you might want to try that to see. Not that anything you've said or concluded seems wrong, though.
They are doing this also for the science version, the 15C.
I bought a 15C in the 1980s, and have enjoyed it ever since. It is like a rock. Despite being treated roughly over the years, nothing is wrong with it apart from some dents in the metal parts and my name, scratched on the back. I suppose I've replaced the batteries a couple of times, but that's it. This thing just refuses to die.
The main thing is that the keys still work like on day 1. And I've never seen a calculator with keys like this, with such feedback that you never need to worry about double-presses or missed-presses.
I just love the thing. If it died, I'd buy one of these new versions in a flash. But I think it will outlast me!
I agree with this entirely. I suppose it was partly an issue of limited floor space, but maybe the largest factor was that if a store sold junk mixed with good items, they could get a bad reputation.
Another factor of purchasing in "the old days", particularly for Sears, was that it was usually quite easy to get replacements for faulty products. None of this business of packaging things up, mailing them away and waiting. Walk up to the counter, show that the item was nonfunctional, and a cheery salesperson would go out back and get a new one for you. Sometimes they didn't even ask for a receipt. Sears had products that were "good enough", and they wanted customers to keep coming back. Of course it didn't last, but that wasn't just this particular company.
The cursor changes when you get to resizing corners and edges, so I don't suffer from the problem pointed out in the original article. However, I do find something annoying: sometimes when I'm resizing (or maybe dragging) a window, it gets expanded to fill the whole screen.
I think that kind of behaviour ought to be controlled by the green dot at the top-left of windows, not by some particular mouse movements.
There was a time when the changes to the mac UI were quite good, or at least not annoying. Sometimes it seems as though they are changing stuff just to change stuff.
The teaching model is much like that proposed by the originator of this thread. Classes are 50 minutes instead of an hour (and similar for 1.5 hour classes). The start time is 5 minutes past the hour and the end time is 5 minutes before the hour. This gives students and professors enough time to get from one lecture to another (unless they have to commute across a big campus, in which case they simply do not sign up for classes that are too close in time).
I've served on a big committee on campus that solve the timing problem simply. It starts exactly on time. Every item has a designated number of minutes. And if it appears that we will not finish on time, there is a vote on whether to extend the meeting by 30 minutes.
I realize that a lot of the discussion on this thread involves bosses and employees, which is quite a different thing, of course. There's no point in starting a meeting at a designated time if the big boss is running late.
I've been in academia for more decades than I'd like to state, and I have never heard of an institute that covered article processing charges. I work in a natural science. Maybe things are different in computing fields, though.
I use a phone app called 'transit' to find out where the buses are at any moment. It's a great app for a lot of reasons, but the reason I was drawn to it at first was their witty release notes.
As the author of an R package, my release notes are much drier and businesslike. The package is quite static, so releases are mainly bug fixes. I start each item with either 'Add' or 'Change', then I name the function, and then I supply a short descriptive phrase and end with a link to the github issue where where users can see why the change was made, and what the code differences were.
I realize that this is not an answer to the question, really, because all users of the R package are basically on an even footing, in terms of knowing the R language and the science that the package is intended to support. If there is something transferrable to the OP's use-case, I guess it is to be systematic and terse, and to use a fairly fixed way of writing (being aware that not all users have English as the first language).
I agree 100% with what I think is the key phrase, viz. "the results can change without any modification to your code".
I maintain an R package that is quite stable and is widely used. But every month or so, the GHA on one of the R testing machines will report an error. The messages being quite opaque, I typically spend a half hour trying to see if my code is doing something wrong. And then I simply make a calendar item to recheck it each day for a while. Sure enough, the problems always go away after a few days.
The oral discussion does not scale well in large classes. The solution is to stop using essays for evaluation, relying on (supervised) examinations instead.
Of course, there will be complaints from many students. However, as a prof for decades, I can say that some will prefer an exam-based solution. This includes the students who are working their way through university and don't have much time for busy-work, along with students who write their essays themselves and get lower grades than those who do not.
I just tried the same prompt in chatGPT and it gave 10 errors. Mostly they were because it was using `#` as a comment character, which suggests that it has not been given very much typst code to examine.
Yup, that's pretty bad. But, as an old fart with old eyes, I now use Safari and click the 'reader' version on many sites. Frankly, the web in it's early years was preferable to much of what I see nowadays. But, like I say, I'm an old fart. Heck, I used punch cards throughout my undergraduate days.
I've never seen a publisher's template that was hard to work with.
The process of writing in latex for journals (and textbooks -- I've written for both things) is really very easy.
Publishers almost always provide a sample .tex file that has items you just fill in. For example, there will be something like
`\authorNames{}`
and you just put the names between the braces. The same goes for titles, equations, figures, etc. There will be sample paragraphs as well. And they will have examples of various citations styles, too.
Speaking of citations, latex has good support for citation databases. (Typst and markdown also provide this support.)
I'd say most people I know write their early drafts in latex. They have a target journal in mind from the start of the writing process, so they just grab the latest sample file and stylesheet(s) from the publisher's website and start entering text.
As you say, using latex for freeform documents is a different matter. That's where I've started to use typst. And I do recommend it for such things. You may find yourself wanting to make some typst templates for common tasks (meeting notes, position papers, etc.) but it's not terrible hard to make such templates. I've made a few, but often I don't bother -- I just put a few lines of customization at the start, if I want to alter how section headings look, or I want a different font from the default one.
I've started using typst for small local documents that I would previously have written in markdown (or R-markdown). Typst offers programming features that are very helpful for small writing tasks that need more customization than markdown provides but that don't need the wildly expansive set of templates available in the latex world.
Like other academics, I plan to stick with latex for journal articles and books, unless publishers provide support for typst.
Markdown still has a place for files on github, because that means that web browsers will display formatted material, not just the raw code. A similar thing applies to code documentation, with many systems (R, Julia, etc) supporting various flavours of markdown.
I recommend typst to students for small tasks like assignments. It offers more typesetting power than markdown, it's a great replacement for msword, and it's easier to learn than latex.
Long story short, typst fills a niche. But it's not the be-all and end-all, at least in my (natural science) field.
The cleanest one caught my eye, and then I read that it was a restaurant, Cy's, that was in Moncton, NB, about half an hour's drive from where I grew up. Although I never ate there, seeing that brought back fond childhood memories of the grownups talking about crossing the border to eat there.
Yes, the noise (which I'd call "the sound") is a big factor.
I teach in a classroom that had blackboard that had stood the test of time for decades. When it was replaced with a whiteboard, things went downhill. The markers dry out quickly, without much notice, so that students often have trouble reading the material. And the whiteboards get harder to erase year after year.
I guess the advantage of whiteboards is that a variety of colours can be used. But some students have deficiencies of colour recognition, so that's not really helpful. (I never used coloured chalk, for the same reason. Maximal contrast is the key.)
And the noise. That click drag click of chalk. Students after the transition to whiteboards told me that they really missed that. It enlivened the lectures. And when students were writing down notes, they knew to look up when they heard the sound.
Back to the point about the "visual show" and doing slides in real time. Yes, yes, yes. Once in a while I need to show something on the projector. The moment I turn it one, I see students start to disengage.
I agree. Here are some things that I (a science researcher and professor) like about R and CRAN:
1. There are a lot of build checks for problems involving mismatches between documentation and code, failed test suites, etc. These tests are run on the present R release, the last release, and the development version. And the tests are run on a routine basis. So, you can visit the CRAN site and tell at a glance whether the package has problems.
2. There is a convention in the community that code ought to be well-documented and well-tested. These tend not to be afterthoughts.)
3. if the author of package x makes changes, then all CRAN packages that use x will be tested (via the test suite) for new problems. This (again because of the convention of having good tests) prevents lots of ripple-effect problems.
4. Many CRAN packages come with so-called vignettes, which are essays that tend to supply a lot of useful information that does not quite fit into manpages for the functions in the package.
5. Many CRAN packages are paired with journal/textbook publications, which explain the methodologies, applications, limitations, etc in great detail.
6. CRAN has no problem rejecting packages, or removing packages that have problems that have gone unaddressed.
7. R resolves dependencies for the user and, since packages are pre-built for various machine/os types, installing packages is usually a quick operation.
PS. Julia is also very good on package management and testing. However, it lacks a central repository like CRAN and does not seem to have as strong a culture of pairing code with user-level documentation.