- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
The New Zero is a really catchy song, that was my frist time hearing it. Thanks for sharing!
Admin
Was that better than a formula? Throw an exception or 0 for 0 weight then go from 17x+5 to 20x+5.
I wasn't programming back then, so I don't know if looking up an array was significantly faster than basic math.
Admin
I doubt that the real prices were amenable to a formula; Remy did say that the numbers in the post were only illustrative.
Kudos to you for deriving that, though!
If you look at real USPS prices today, you'll find all sorts of complications due to non-integer prices, different categories of stuff, stuff with slab rates, and so on.
Even back in 1988, I'm guessing that - in the absence of some DB-adjacent solution - a lookup table was probably the most workable solution.
Admin
In answer to your question, it's indeed possible to have a table be more useful. Back in the day, I owned an Amiga. The 68000 CPU was a nice machine, but I had a long loop that needed squares of 0 through 255. I did some tests and indeed found that it was faster to have a table of all those squares rather than doing the multiply in the loop. "Ah, but what about negatives?" Well, C being what C is and not having bounds checking, I wrote something like:
static int negatives[] = { /* values left out*/, 25, 16, 9, 4, 1 }; static int squares[] = { 0, 1, 4, 9, 16, 25, 36, /* etc */ };
If you index 'squares' by a negative value, it just pulled from the array in memory before it. This is horrible practice and I'd never do it today, but it worked a treat for performance on that old machine.
Admin
Octal is such a terrible idea. The fact that some languages treat 13 and 013 as different is unintuitive and causes weird bugs.
Prefixes (or suffixes) are much better. 0b, 0o, 0x. No confusion then.
Admin
I'm pretty sure you can do that without the undefined behavior, though I doubt it'd be worth doing on a modern machine anyway.
static int squaresArray[] = { /* values left out*/, 25, 16, 9, 4, 1, 0, 1, 4, 9, 16, 25, 36, /* etc */ }, *squares = squaresArray + 255;
return squares[index];
Admin
One of my own nasty 'C' bugs in the 80's was looking for a space character like this:
if ( c == ' ' )
Unfortunately, what I thought was a space was actually a tab character in column 16. I only found the problem by compiling to assembler and reading the assembler. Java and many languages have the same problem today. Even Python, which depends on indentation for flow control, doesn't complain about this issue.
Admin
Well, no, it wouldn't, because "indentation for flow control" is entirely unrelated to "tab characters inside literal strings are treated as tab characters instead of space characters".
But there was the time that one of our C source files ended up with an ASCII NUL character half-way along a line. That induced some strange misbehaviour.