HN user

fundamental

639 karma

http://fundamental-code.com

Posts2
Comments323
View on HN

I occasionally update my web log, however updates are rare because writing ends up taking a lot of time. You have to identify an interesting topic, research it to fill the gaps needed to describe it, create a writeup with associated figures/pictures, edit it, and then commit to publishing it. Yes, it's entirely possible to create lower effort content, but it's substantially less satisfying to me.

Find a small project that you're interested in and check out the developmental discussion channels to see if there's any way you can lend a hand. Starting with trying to find complex coding tasks in large bureaucratic projects is setting yourself up for failure IMO.

For example, https://zynaddsubfx.sourceforge.io/contribute.html shows a few different levels of involvement in one project I maintain. That's not me saying you should work on this project specifically though; you'll want to find projects that you're enthusiastic to learn about.

No, I would not work on any personal projects during work hours as I don't want to risk any IP clauses getting applied to my own personal/side projects. Generally down time is a good opportunity to learn more about tools which could be applied in the future, but are not immediately required.

You're not (likely) going to be working casually on VLSI design, but for basic circuitry and embedded design you can work on hobby projects. I wouldn't compare that to having a fulltime job working on complex systems where you're going to be exposed to more elaborate challenges, but you can at least avoid letting hardware skills atrophy over time by using them for comparatively simple tasks.

If you want to have ragged starting information displaying pricing information for the various symbols in the range they're defined, I'd assume it's much more common that there's different start dates, but they're all defined for today. So, you could have a single checkbox to normalize based upon equal value at today's value and I'd default to having that on. As your baguette argument about the absolute values not having huge significance still applies it seems like it would work with no other modifications (i.e. it doesn't matter that it could require fractional shares and the like).

If the goal is to demonstrate relative performance over time, wouldn't it be useful to use a normalization such that all lines either start at the same point (e.g. simulating investing X amount) or ending at the same point (showing requirement to get to X final amount)?

Taking a quick look at the source it doesn't look too bad all things considered. First off, assume that there's going to be some sort of 32bit->64bit issues (likely casting pointers into 32bit words). So, start off on a 32bit setup, get things to cleanly build on -std=gnu99 (no need to cause yourself extra pain if it's optional). Then tidy things up with warnings (-Wall -Wextra on clang&gcc) such that the compiler can help you spot any existing bugs. Next up is the transition to 64bit. You're likely going to have to spot any pointer manipulation and where possible change 'int', 'long', etc into types which specify their length to make reading the code easier (subjective, but that's my opinion) e.g. uint32_t, uint64_t, etc. Then you ought to be pretty close to having all system tests pass on 32bit and the 64bit port.

I'd be worried if the code was old enough you were seeing K&R C notation or if it was a huge codebase, but it doesn't look like either case has occurred.

Of course if you're very much not a C programmer, learn some C. It's a comparatively small language overall (IMO) even if it's a low level one. Newer versions of the K&R book should get you up to speed pretty quick.

Certainly not as much as I used to, but yes I contribute to open source projects. It's a combination of making things I'm interested in, drive by patches for tools that almost do what I want or have a bug that I've managed to trigger, and chatting with others building things they're interested in. Being a maintainer is a different ballgame than contributing to a project without the long term responsibility, though both can scratch an itch and help develop new skillsets while helping to create new pieces of software.

his dataset is pretty worthless and the claims around it have been largely unsubstantiated.

The really sad part of it is that with fairly minor changes it could have been a landmark dataset IMO. Having better recording equipment, a lower noise floor environment for data collection (e.g. don't run fluorescent lights while recording), having precise timestamps integrated into the recording, better temporal separation between recording of various phrases, adding simultaneous EMG/EEG, etc would have resolved quite a few data related issues. It's a unique situation (for good reason), but bad data...

From seeing the data, I suspect the electrode placement was in a good enough location that novel things could have been done with a cleaner data source. I guess the major limiting factor is that absolutely no one would want to be involved with the project at that stage. What sort of IRB would approve any of this? Better data would answer some key questions that could generalize to lock-in patients (theoretically) and worst case it would provide a strong indicator that no significant BCI can be made for the task given the electrode placement.

I still use meetup, though it is a bit of a mixed bag when it comes to meeting people. Groups tend to either be small enough that it's a challenge to get around how tight knit the dynamics are or they're huge with mostly inactive members and almost never the same people event to event. I certainly haven't used meetup as much since the pandemic began as virtual events don't have a lot of appeal to me personally.

As per discord, it can be a quite nice tool for building communities, however there's a lack of locality in almost all of the servers I've interacted with, so discord ends up serving a different purpose IMO.

Personally I don't buy that line of argument. The endgame for a business is not a binary choice between acquisition or taking over the entire market.

Ideally I (and I'd assume other commenters) would have preferred to see bandcamp remain independent. It's not like there's a huge need to scale up quickly or provide large partnerships. Bandcamp was an effective way of paying small independent musicians with a good overall website which should have given bandcamp a reliable revenue source. Acquisition likely means the website will get worse, artists will be driven of onto other platforms (i.e. harder to discover ones), and if there's alternative financial incentives then small artists will likely end up making less (e.g. track streaming revenue).

I'd be disappointed if apple had made the purchase, though it would be less out of left field.

For code, git has won out among the other options. As per ML data+model versioning that area is still evolving and what the right choices are there depends on ML frameworks as well as your approaches to deploying new models.

Generally I'd view data and trained model versioning to be separate, but linked to the training code versioning. In an ideal world you end up with a system where data version+training code version is in the metadata of a given model version, but there's plenty of other aspects of the data science themed addons to consider.

Sure, I encounter TIFF images when working on various datasets if that counts as using the format. One of the first things I do though tends to be converting the tiff images into a more common format. Once the conversion is complete I don't need to worry about which apps/tools have limited support for TIFF files.

Yes Hello 5 years ago

'Hello' as a method of establishing a synchronous chat makes sense, but if you just need an answer to a question when someone reads through chat next, then it's by no means a required formality. My personal stance is when a discussion can be asynchronous, let it stay that way.

Perhaps the described patch based routing to experts isn't a problem in practice, but at first glance it does seem to discard more spatial information than you'd like as well as introducing more image boundaries than would be ideal. You could argue that the former is a known issue with many DNN architectures, though if the intent is to enable larger scale generalization it seems like this paper might be trading away more information in the source material for speed than would be desired. AFAIK the shuffling would be less of an issue in textual models than image processing tasks. As per the boundaries, I guess there could be padding in play, though I suspect that the resulting network is going to have higher sensitivities to shifts up/down or left/right by a few pixels.

Even with those issues I'd imagine there could be some nice benefits and the authors are correct (IMO) for leaning on the areas of conditional execution and routing as it allows for the network to specialize on a given subdomain while being computationally efficient. We'll have to see where subsequent work takes this approach.

Call me a pessimist, but if the site caught onto some non-trivial traction it would be quickly overrun with unreasonably loud clips, people generally saying horrifying things without much recourse, and then slightly down the road TTS voices selling/promoting other sites. IMO for other anonymous text based sites it's easier to overlook some of these issues as well as it being easier to moderate the issues as they appear.

Looks like a nice implementation of the idea, the overall visual design is clean, and the preloaded content is nice, but I just don't trust the internet to not ruin a good thing.

What I do know is that junior people are complaining that there are only jobs for senior devs and seniors are complaining that all the jobs are for juniors.

I imagine some of that is how people understand job postings over time. Reading between the lines there's a lot of fairly junior roles out there that include a lot of senior sounding requirements. It's also not hard to find many senior roles which only offer a junior salary (I wonder why those listing stay open for so long...).