Become a fan of Slashdot on Facebook

 



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

Comment: Mayday! Mayday! (Score 1) 87 87

I've been binge-watching Mayday (a.k.a. Air Crash Investigations), and I have not seen a single episode where bug splatter on the wings brought down a plane. There was one episode where a spider built a nest in the pitot tube, but nothing with the wings. They would be far better off developing anti-ice coating. Ice brings down planes on a regular basis.

Comment: Re:Never knew the concert conductor did that! (Score 1) 61 61

Maybe, but I suspect maybe not. The electromagnetic spectrum (which includes light frequencies) has particular characteristics that do not change much with increases in frequencies, closed system or not.

Granted, but optical signals are not generated by a coil of wire and interleaved metal plates. You can't just tweak a capacitor to adjust the frequency of a laser.

Comment: Re:This problem needs a technical solution (Score 1) 264 264

by camperdave (#50001859) Attached to: Drone Diverts Firefighting Planes, Incurring $10,000 Cost
No private citizen NEEDS a gun either; or a car, or a computer, or porno magazines. That doesn't mean we can't have them.

The reality of the situation is that the persons taking video of the fire with their fancy flying cameras were probably unaware that they were interfering with the fire-fighting effort.

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: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.

Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read.

Working...