Please create an account to participate in the Slashdot moderation system


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Infinity (Score 1) 1064 1064

I mentioned the +/- zero thing in another comment elsewhere in this tree, actually! So we're all on board there.

It's not really that signless infinity is a contender for 'consensus' inasmuch as number systems which use signless infinity have utilities different from systems that have signed infinities, just like integer math continues to exist despite the 'improvements' of fractions and decimals.

Comment: Re:Exceptions in Python list comprehensions (Score 1) 1064 1064

Same reply: Python is not fully functional, and so list constructors like that cannot be counted upon to work elegantly in all situations. This is a completely normal thing common to basically every imperative language, and it's just something you have to accept—and write a special-purpose function for.

Comment: Re:Exceptions in a map function (Score 1) 1064 1064

I think that just means you're a zealot of functional programming; your expectations are wrong. If the language isn't fully functional in nature, don't expect key patterns like map() to work elegantly. They're hacks at best and not really part of the core language design; this is excellent proof of that.

Comment: Re:Infinity (Score 1) 1064 1064

You're just validating your own arbitrary decision to use that integer set. IEEE 754 defines positive and negative infinity separately. (However, if you look at the other comments below this one, you'll see that I argued for exactly this, reassigning the largest negative value to NaN in a signed integer format—but only for select situations.)

Comment: Re:Slow speed to orbit? (Score 2) 59 59

This should answer your question

Basically, the energy intensive part of getting to orbit isn't getting high, it's going fast enough horizontally. You basically have to be going so fast that the ground falls out from under you (due to the curvature of the Earth) before you can hit it.

Comment: Re:Infinity (Score 1) 1064 1064

I wasn't thinking of the highest bit, just the highest value. As I'm guessing you already know, because of the nature of two's complement there's an asymmetry in positive and negative numbers (2^15 - 1 positive values, 2^15 negative values, and zero) resulting in one value that could easily be discarded; assigning this single value to an error would have an additional benefit of catching counter overflow. Certain older computers like UNIVACs actually used another system called one's complement, where the most significant bit was a negative sign, and numbers otherwise counted up from zero—this had the odd result of leaving a "negative zero" in the numbering system (which IEEE floating point numbers also have); this could also have been reassigned to NaN.

Yes, I agree that try/catch blocks are annoying from the perspective of people writing elaborate flat code—but they do force the programmer to actually handle errors instead of letting them propagate. In certain contexts this is vitally important. A programming language that permits NaNs is essentially making the decision that the division's failure is Not A Problem by default, which is a key point of contention: are we developing for a safety-critical application where a failure to test properly could have dire consequences? What if someone forgets to check for NaN values in the speed control system in an automobile? Is that better or worse than the program aborting entirely? (Almost certainly worse, as it's more likely there would be management code for catching and fixing that!)

So I would argue that, say, MATLAB or Lisp should support NaNs, but definitely not Ada, and I guess now I'm unsure about the C languages again.

Comment: Re:Infinity (Score 1) 1064 1064

It was a big story on Slashdot years ago. A similar cascade of discussions resulted. Let's think for a moment.

If you don't want to code to prevent a division by zero error in any situation where NaN isn't handled elegantly, you have an easy alternative, which is a try/catch structure. Adding NaN is basically just a magic error value, like -1 being returned on failure for C functions (example: failing to find a substring returns -1 as the index in many languages.) This practice is considered Generally Bad And Inadvisable by structured programming dogmatists, as it encodes control information inside of a content signal and potentially obfuscates the meaning of the program (and, in languages like Python, where negative indices have meaning, it can cause lots of subsequent problems.)

To keep things consistent, I would argue that NaN doesn't have a place in modern high-level languages that subscribe to structured programming paradigms; a division by zero is an error that occurs when data is improperly initialized or collected, and letting errors like this (a) propagate by ruining subsequent expressions and (b) potentially get displayed to the user is the vice of a PHP programmer who would rather just be told his or her code works rather than know if it was actually doing what was intended.

On the other side of things, I do actually agree with you and would propose that signed integer formats should reserve 0x8000000 (whatever the negative maximum value is, that one extra number you can't fit into the positive side anyway due to the asymmetry of two's complement) for NaN, because exception-handling invariably means unnecessary stack frame manipulation when used in C++, and programmers in low-level languages like the C family should have an alternative, just like they do with string search functions.

Comment: Re:Infinity (Score 4, Insightful) 1064 1064

More importantly is what happens when you graph it: the limit of 1/x as x approaches zero is discontiguous. It's positive infinity when descending on the positive numbers, but negative infinity when ascending from the negatives. No one value can represent both!

Ask Slashdot: Are There Any Search Engines Left That Don't Try To Think For Me? 424 424

An anonymous reader writes: As a programmer especially, I'm becoming increasingly unhappy with Google searches. They try very hard to present me with what they think I'm searching for instead of what I'm actually searching for. This issue mostly shows up when searching error messages, obscure type and function names and stuff like that. What I think though, is that I only notice the issue when searching for stuff I know a lot about, namely programming, but my queries get distorted when I'm searching for just about anything, I just don't know enough about the subject to notice. Are there any alternative search engines left that don't think they know better than me what I'm looking for and just search for my phrase, like in the 2000s? Searching for exact strings is an option with Google, but what search engines are the most hands-off to start with?

I never cheated an honest man, only rascals. They wanted something for nothing. I gave them nothing for something. -- Joseph "Yellow Kid" Weil