lolcatuser

il y a 2 ansdiscuss

Definitely. This, plus a graduate degree in a more specific field, and you end up with a very well-rounded education.

il y a 3 ansdiscuss

The reason division by zero can be a number is that floating-point numbers aren't individual numbers but ranges of numbers. So 0.0 isn't really the integer 0, it is the range of numbers between 0 and the smallest representable non-zero number. So division by 0.0 may be division by zero, or it may be division by a very small number, in which case it would approach infinity.

The same goes for the floating-point infinity: it doesn't represent the concept of infinity, it is a placeholder for every number between the largest representable number and infinity. That's how dividing a very large number by a very small number can result in infinity, a number which is really not a number.

This is the philosophy by which IEEE floating-point numbers were designed, and it's the explanation behind which negative zeroes and infinities make sense in floating point.

The way I find it easiest to reason about is by taking a graph of an asymptote and rounding it to the nearest units. You somehow need a way to say "there is an asymptote here!" even though you might not have all the units, and so you introduce infinities and negative zeroes to maintain as much precision as possible.

lolcatuser

il y a 3 ansdiscuss

I don't know how they work internally, but I can say that power hammers used for blacksmithing sound similar to the woodpecker in the video, only much slower. A couple hard, fast hits with absurd force before slowing down and stopping.

I'm guessing the woodpecker behaves that way because it's putting momentum into the hitting, even if that doesn't totally make sense in my head. When hammering on something, it's easiest to let the gravity do most of the work and focus your effort on aiming and raising the hammer, so you naturally have 1-2 hits that are solely momentum based at the end.

The woodpecker is horizontal, though, - not pecking in line with gravity - so my thought process isn't a perfect analogue. But if their tongue works like a spring then I can imagine it making sense.

lolcatuser

il y a 3 ansdiscuss

A hypothetical god would not destroy the world, but absolutely could.

I think that's the idea - they're not reveling in the fact that they can do anything anybody could reasonably want to do, they're reveling in the fact that they can also do everything else, too.

lolcatuser

il y a 3 ansdiscuss

It's better to say that, in C, characters are bytes. That's why coming at this from the modern perspective of "characters are the things on my screen" is always going to confuse you - C doesn't have bytes, only characters. C programmers (should) understand this the same way Lisp programmers understand that "CAR" and "CDR" refer to "first" and "rest" or Forth programmers understand that "the stack" is the data stack and has no relation to the call stack.

lolcatuser

il y a 3 ansdiscuss

C isn't Java. Even Niklaus Wirth in Pascal, Oberon, and the like avoided naming their identifiers too long. 'GetStrSz()' is enough to achieve (most of) what you want, assuming certain naming conventions:

- Makes it clear that this returns the number of bytes, assuming a naming convention where `sz` refers to size (in bytes) and `ln` refers to length (in some other unit which would be specified in the type). Note that in C, 'characters' refers to bytes. It's a flaw in how C names its types, yes, but I wouldn't say it should be any different just because other languages do things differently.

- It doesn't use full words because I don't think it needs to. Abbreviations are OK as long as every (invested) party agrees that they're sane, and I think they're pretty sane.

- It makes it explicit that it is performing a calculation (hence, is O(n)) via 'get'.

I don't think all this is necessary, though - I actually think 'strln()' is enough. First, because characters means bytes, I can assume that this function is getting the number of characters (bytes) in a string. I wouldn't expect it to give me anything else! Second, in C, if strings were a struct of some sort, I'd expect to be able to get their length via 'str->ln', which would be O(1). The fact that the length is found through a function in the first place signals to me that it's doing something behind the scenes to figure that out. Remember - that's just my opinion, which I admit is extreme - but I think yours is just as extreme.

lolcatuser

il y a 3 ansdiscuss

Maybe my least favorite "feature" of C. I can manage most aspects of zero-terminated strings well enough, but when I have to specify the length of them, is it an 'int', 'size_t', 'ssize_t', or something else? (Answer: All of the above!)

lolcatuser

il y a 3 ansdiscuss

It's entirely possible to write a wrapper function with a short name to convert string literals to actual string objects.

    my_function(my_var, 3.6, $("bzarflo"), my_other_var, false);

Isn't that much more of a mouthful, and as long as 'my_function' knows to free it, then you're A-OK! The only trouble is '$()' isn't legal in standard C, so a real solution would have to be something like 'str()'.

lolcatuser

il y a 3 ansdiscuss

You're being willfully obtuse here.

When somebody says "this algorithm is unbounded" they of course don't mean that they've changed the laws of the universe to allow for an infinite array of memory that it can work with. They just mean that if you could do that, it'd work.

As an example: `while (node) node = node->next;` (in C, where `node`'s type defines a reference to `next` of the same type) will traverse an unbounded list. It will work just as well for zero nodes, one node, a dozen nodes, a billion nodes, and so on, as the number of nodes approaches infinity. Obviously it is impossible for you to ever create a computer with an unbounded amount of memory, but computer scientists can talk about algorithms the same way mathematicians can talk about what `f(x)=x^2` at infinity.

No mathematician, with the knowledge we have now, would ever say, "It's unreasonable for us to talk about infinity. That's simply not possible, ever, now or in the future, so let's limit things at 999,999,999,999,999,999,999,999,999." We settled this debate back in the 1600s.

lolcatuser

il y a 3 ansdiscuss

You absolutely can justify infinity - even if your real system can't represent numbers larger than X, you can't guarantee that won't change in the future.

For example, in C, integers have minimum sizes, but no maximum. We're lucky nobody ever went, "well, our PDP-11 can only go up to 2^16, so let's set the maximum there."

That's not to say it doesn't make sense to limit things after a certain point, but you'd damn well better be able to justify it, especially if you're using a recursive data structure that could absolutely grow to infinity if needed.

lolcatuser

il y a 3 ansdiscuss

Ounces can measure both volume and weight, depending on the context.

In this case, there's not enough context to tell, so the comment is total BS.

If they meant ounces (volume), then an ounce of gold would weigh more than an ounce of feathers, because gold is denser. If they meant ounces (weight), then an ounce of gold and an ounce of feathers weigh the same.

lolcatuser

il y a 3 ansdiscuss

That's lame.

Ounces are an ambiguous unit, and most people don't use them for volume, they use them for weight.

lolcatuser

il y a 3 ansdiscuss

I use octal for this.

  x << (3 * 8);

vs.

  x << 030;

lolcatuser

il y a 3 ansdiscuss

wikipedia.org/wiki/Paradox_of_tolerance

Too often I hear people complain that they're being oppressed for their "differing opinions." A tolerable opinion is something like "my favorite color is blue," not "gay people shouldn't exist." If your opinion revolves around the intolerance of other opinions, then I'm not going to be tolerant towards that.

lolcatuser

il y a 3 ansdiscuss

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

Section 6.10 (Page 145): Preprocessing Directives

Hey, would you look at that! The preprocessor is a mandatory part of the language!

lolcatuser

il y a 3 ansdiscuss

But that is a legitimate problem.

Using a language feature that is a known footgun (`if ...` instead of `if {...}`) without being cautious enough to avoid shooting yourself in the foot is not the fault of the footgun, it's the fault of the programmer.

Additionally, in the above linked case, the problem isn't a misused `goto`, it's a misused `if ...`. It would be just as problematic if they typed `cleanup_context();` instead of `goto fail;`, but nobody complains about cleaning up state, do they?

comments