HackerTrans
TopNewTrendsCommentsPastAskShowJobs

krull10

no profile record

comments

krull10
·w zeszłym miesiącu·discuss
Alternatively, many faculty may be simply adjusting their curves to avoid failing too many students because they are incentivized to avoid giving too many low grades. Lower grades generally result in lower course evals, which can impact raises and promotion, and low grades can also result in additional attention from admin that no professor wants to deal with…
krull10
·5 miesięcy temu·discuss
Their review of MacOS 26 is 79 pages when downloaded as a pdf, so they still sometimes have in depth articles. But I agree that that level of detail isn’t as common as in the past.
krull10
·9 miesięcy temu·discuss
I've nearly exclusively used Julia since 2017. I don't think this is a perverse use of such functions -- long ago I naturally guessed I could use `cumsum!` on the same input and output and it would correctly overwrite the values (which now gives a similar warning in the documentation). However, when I first used it that way I tested if it did what I expected to verify my assumption.

It is good the documentation is now explicit that the behavior is not guaranteed in this case, but even better would be if aliasing were detected and handled (at least for base Julia arrays, so that the warning would only be needed for non-base types).

Still, the lesson is that when using generic functions one should look at what they expect of their input, and if this isn't documented one should at least test what they are giving thoroughly and not assume it just works. I've always worked this way, and never run into surprises like the types of issues reported in the blog post.

Currently there is no documentation on what properties an input to `sum!` must support in the doc string, so one needs to test its correctness when using it outside of base Julia data types (I haven't checked the broader docs for an interface specification, but if there is one it really should be linked in the docstring).
krull10
·10 miesięcy temu·discuss
The simplest approach is to always read the interface of packages one wants to use, and if one isn't provided look at the code / open an issue to interact with the developers about their input assumptions. One should also make tests to ensure the interface behaves in the expected manner when working with your code.

Using this approach since 2017 I've never really encountered the types of issues mentioned in Yuri's blog post. The biggest issue I've had is if some user-package makes a change that is effectively breaking but they don't flag it the associated release as breaking. But this isn't really a Julia issue so much as a user-space issue, and can happen in any language when relying on others' libraries.
krull10
·10 miesięcy temu·discuss
Use spectral methods? But you’d presumably also have to use higher precision number types if you want that many digits.