mabster

Companies have complex telecoms but generally want the outside as one company number. Solution, the sender send a packet with the number they should get perceived as. Everyone sends this on. Everyone "looks the other way" by design haha

I'm the same. I've used a lot of build systems over the years and they all get complicated fast. And they always have "spooky action at a distance". I prefer the simplicity and expliteness of makefiles.

Every time I've setup makefiles for projects someone always comes in and tries to make determining of dependencies happen before building rather than "determining dependencies as we build for the next build", which is just as robust. I don't know why software engineers always don't like that haha.

I was doing the "chase the beam" approach, but never got it off the ground (home project, mostly curiosity). But always on the back of my mind was: even if you're doing everything in low latency HDMI signals, there's no guarantee that the display isn't still buffering it, even if you have "game mode" on on your TV.

Yep, we've always had our own implementation of std::shared_ptr<> for this reason.

Either the reference is elsewhere (and now you have to dereference another area of memory occasionally which is the worst case for cache performance), or its alongside your object. If its alongside your object it's better to know it's there for padding, etc.

And it's easy to forget to allocate for the alongside case, so you can have hidden poor performance.

Every work place I've worked at has their own container classes for performance reasons.

We did use some C++ standard library but very sparingly. For example, std::unique_ptr<> was fine, but std::shared_ptr<> was not because of the way it implicitly stores it's reference, so we had our own implementation that exposed the reference.

When I was doing console games this was a must. You would often have restrictions where the container itself should live in a different area of memory to the items which is much easier to manage with your own classes.

I don't know why no-one here sees this as a bad design...

If a line is missing a newline then we just disregard it?!

A way better way to deal with newline is it's a separator like comma. And like in modern languages we allow a final separator, but ignore it so that is easier for tools to generate files.

Now all combinations of characters, including newline characters, has an interpretation without dropping anything.

I picked up my git workflow from a very commit-centric workplace.

Instead of stashing or anything like that we would commit with the text "WIP". Every time we had a stable point, we would make a "WIP" commit and then continue, giving us a good point to revert to if the next steps don't work.

If someone interrupts me I would make a WIP commit and then revert it and then make the change they're asking about.

Later on we would squash the WIP commits and make real commits out of the changes.

Another nice thing about this workflow is that everything goes into the reflog.

I haven't kept up in this space, but there was a bunch of papers under "cache agnostic algorithms" that were actually taking the concept of cache into account. The cache agnostic here being regardless of cache size, sort of treating cache in the O() sense.

You could still beat them by tweaking for your hardware. But for the first time there was research into why Q sort is faster than heap sort

It's not even necessarily enough for communication. With the Pareto curve on word commonality it's really quick to get high percentages of vocabulary. But it's the words you don't know on a sentence that are usually the important ones.

I really wish something like https://github.com/fasiha/ebisu becomes the norm. That is, the idea of fitting the cards to your time (by prioritising) rather than you having to do everything there software wants.

The only bit missing is some algorithm deciding how often to introduce new cards based on your historical data.

I started making the cards, noticed a lot of repetition in what I was doing and then started coding solutions to clusters of cards.

I definitely spent way too long on the "making the cards" phase!

Argh, sounds really frustrating! It's hard enough to get accuracy when you can control operations never mind when the compiler is doing magic behind the scenes!

FMAs were difficult. The Visual Studio compiler in particular didn't support purposeful FMAs for SSE instructions so you had to rely on the compiler to recognise and replace multiply-additions. Generally I want FMAs because they're more accurate but I want to control where they go.

I spent most of my career working with rsqrt haha. And had my fair share of non-754 architectures too!

Every 754 architecture (including SSE) I've worked on has an accurate sqrt().

I'm assuming you're talking about with "fast math" enabled? In which case all bets are off anyway!

For game development we had them off as well because of performance issues. Most stuff calculates around 0 so it was pretty common to trigger denorms.

The slowing down on Intel platforms has always frustrated me because denorms provide nice smoothing around 0.

At the same time it was nice only having to consider normal floating point when trying to get more accuracy out of calculations, etc.

I'm surprised by this, regarding sqrt. The standard stipulates correct rounding for simple arithmetic, including sqrt ever since 754 1985.

Unless of course we are talking about the 80 bit format.

If that's not the case, would be interested to know where they differ.

Unfortunately for the transcendental function the accuracy still hasn't been pinned down, especially since that's still an ongoing research problem.

There's been some great strides in figuring out the worst cases for binary floating point up to doubles so hopefully an upcoming standard will stipulate 0.5 ULP for transcendentals. But decimal floating point still has a long way to go.

Back in the day I had a dual boot machine and was using a corner skin of Winamp on the Windows side and missed this on the Linux side.

So I started reverse engineering the Winamp skinning engine with the intention of making an engine that can run it on one of the Linux media apps. I did this by writing short programs and looking at the generated binary.

I had about 95% of it figured out when we had a robbery and the thief took the laptop I was using. By the time I got a new machine I had completely lost interest!

I wouldn't be surprised if it was using a well known VM that I just didn't know about at the time!

I'm surprised by that as well.

I haven't done this stuff for quite a while, so my memory might be foggy, but the main advantage of Vulcan was that you can control all the CPU locking rather than the API doing it. This allows you to do stuff like prepare on one thread and submit on another, etc.

But that would be negated if you're using an abstraction layer.

I've done games in both. My favourite is mostly imperative C++ so you can use templates.

I think the larger writings like books are generally going to be written by academics so they'll be rigorous and hard to read.

So that leaves blog posts for most developers actually implementing this stuff.

But the solution here is that when you finally figure out a good strategy to deal with something muddy like this is to write that better blog post :)

I thought derivative works were okay if they were "transformative"? That lawsuit sounded like he had copied text verbatim.

I'm not in the US, so I could easily be off base.

I really enjoyed The Time Ships by Stephen Baxter, which is a sequel to The Time Machine by H. G. Wells. He's a UK author, so maybe it's different.

As a society I think we are better off with this kind of remixing so I'd hope that's the direction we head in.

I've got an engineers style mindset for these kind of calculations.

897 is about 900. 394 is about 400. 900×400 = 360,000. Only 2% error!

When I was doing a lot of C++ gamedev, we were definitely doing a lot of stuff that would trip up static analysis, e.g. X-macros.

We would still use refactoring tools even though they would often miss stuff. You just rely on a combination of refactoring tool / search and replace / the compiler.

We would also debug our code in release mode with symbols. You get used to a debugging environment where you don't trust anything you're seeing in variables, etc. too.

When I was doing low-level optimisation for games (lots of SIMD), I was using mine quite frequently.

Now that I'm doing more application development it's sitting on my bookshelf looking neglected.

I once had a function call in a rather large outer function causing unbalanced stack operations. It would pop more space than it pushed to invoke the function. Thankfully that meant a pretty quick crash. After trying a number of things, the solution in the end was to call the function twice since it was idempotent.

I started game development around the Gameboy Color days and everything was in assembly. Every other platform had shifted to C/C++.

It wasn't bad actually. We had macros to do 16 bit work with 8 bit registers, etc. so the code was much more high level than it sounds. We did have to be very careful with the stack (making sure it's balanced), but otherwise very similar to coding in C.

With modern architectures, I much prefer C and intrinsics and let the compiler deal with it (and nudge it when it gets it wrong).

There's also "Krondor, The Betrayal" where he turned the game back into a book! Unfortunately not as good as his earlier works.

I tried to use the spec as a description of disassembled data sections for a toy disassembler I was writing a while back. So I was using the spec but not the tools.

It is great that the spec is YAML because that's quick to get up and running. It was just unfortunate that the expression language is custom string, i.e. not YAML.

It may have improved, but at the time the custom language wasn't unambiguously specified either.

We had a touch typing class in the mid nineties in South Africa.

I told my teacher I don't need to touch type (I could already use a keyboard from tons of programming) so she said if I could beat her I could sit it out. I beat her and she kept up her end of the bargain.

However years later I wish I had just sucked up my pride and learnt it because I had to eventually anyway. It wasn't so useful for programming, but it's great for text (emails, etc.).

I find it interesting that in your view most people aren't touch typist. My experience (now in Australia) is that most people touch type. Although, there does seem to be a spectrum of purity. e.g. my fingers always remain on the home rows, but I use left shift for all capitals except Q, A, Z (when I'm using QWERTY).

This. But you can get pretty close to "stuffing in the bits". What we used to do to get a random float:

Set the exponent to 0 and stuff in bits for the significand. This gets you a random float in the range [1,2). Now subtract 1.0.

Note that this misses many floating point values that should be selectable if you wanted all floats between 1 and 2, but it was good enough for video games.

It's worth pointing out that IEEE 754-2008 has decimal numbers like you describe without the hidden bit. But for decimals this can be really useful because numbers "remember" their exponent. So if you're doing addition of dollar values, for example, .84 + .12 = 1.00 rather than 1 (i.e. it remembers its significant digits).