Please create an account to participate in the Slashdot moderation system

 



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

Comment: Re:Aww hell. (Score 2) 177 177

>People tend to be quite attached to their arms.

Well, at least until the accident...

In reality though, most rides these days seem to go out of their way to make sure that there's nothing actually dangerous within reach of anyone in the cars. Even if you slip out of your seat and stand up, etc. Sure, you'd have to be a grade-A dumbass to do such a thing, but even grade-A dumbasses getting themselves dismembered on your ride tends to make or bad publicity.

Comment: Re:Operating in Africa (Score 3, Insightful) 24 24

Probably also a generation or two of "we're here to help" medical programs not being hideously abused, as was done in various population-control endeavours and other programs. Involuntary sterilization under the guise of vaccinations? Really? That's the sort of horror story that can take generations to fade, and it seems like every time we start building back some trust among the population, someone decides to abuse it yet again.

Comment: Re: Are we asking a question? (Score 1) 210 210

Software failures will scale up similarly. If you propose for example that, on any single PC, a Linux crash is 10x more likely than a hardware failure, then they're be dealing with dozens of crashes per day - and that would have to be some pretty stable software. What's your crash to hardware-failure ratio?

Comment: Why such short employment (Score 4, Insightful) 381 381

Perhaps we should ask why the average employment length is so short? I really doubt it's because the employee's skills are no longer needed, and it's probably not because the employee thinks a different work environment will be substantially more pleasant.

I suspect the usual culprit is an industry culture that doesn't give regular raises to employees to ensure that they remain appropriately compensated. If the only way I can get paid what I'm worth is to get a job at a different company, then what do realistically expect me to do?

Comment: Re:*I* own my overtime (Score 5, Insightful) 381 381

2) News flash, most industries have competition "across the street", yet they still manage to train their employees. The trick is to ALSO pay them a decent wage. If it's worth it for the competition to hire them out from under you, then you're under-paying them. Training isn't a form of compensation, it's a capital investment that also incurs maintenance expenses.

The job market is a big place, and there's probably only a handful of jobs that demand all the skills you require. Why should I spend MY precious time training for your job, when that job will filled long before my training is complete?

Comment: Re:too late (Score 1) 131 131

How about reasonable maximum data retention laws that apply to *everyone*, government, industry, and private individuals alike?

Probably with a "loophole" that data may be retained about individuals who explicitly consent to it, but opt-in cannot be mandatory for public institutions, nor can refusal to opt in be grounds for denial of services or introduction of bureaucratic runaround. That should let gMail continue to store your old emails.

Comment: Re:Infinity (Score 1) 1067 1067

Except that there's nothing in the concept of infinity that is specific to sets, so cardinality is not really relevant unless we're specifically discussing infinite sets. Which we're not. We're discussing the limit of a single value that increases without bound as an input condition approaches a critical value. I'm sure you could rephrase that in terms of set theory, but that doesn't imply a fundamental dependence.

And frankly, if you've hung around Slashdot long you should realize that a rather large percentage of the community doesn't have a really firm grasp of much mathematics beyond basic arithmetic. That doesn't mean they're not interested in the concepts being discussed though, and nothing is gained by belittling either them or those who offer them simplified explanations.

Comment: Tug boats (Score 4, Insightful) 59 59

Of course, the "rest stops" with their stockpiles of fuel and parts will probably be massive structures, so we'll also need "tug boats" to transfer the satellites from their original orbit to one that can dock with the rest stop, and then return it to it's designated orbit again after repair and refueling. Still far less energy-intensive than sending up a replacement satellite though. And if only refueling is needed then it's probably easier still to outfit the tug with a refueling waldo that can mate with a standardized fuel receptacle on the satellite - then the tug only has to make a single trip from the rest stop/fuel depo to whatever wonky orbit the satellite is in, and the satellite itself need never move at all.

Comment: Re:Infinity (Score 1) 1067 1067

It's not a number in the normal sense of the term, but using it as such is a simple and convenient shorthand for the far more complex and subtle mathematical concepts being expressed by the statement. In fact it's so radically simplified that even a layperson can kind of vaguely wrap their head around it, while you'll probably need a PhD in mathematics to really understand the underlying concepts.

Comment: Re:Infinity (Score 1) 1067 1067

You seem to be discussing asymptotes, which have a bit more subtle meaning. An asymptote is a line that a function gets infinitely close to without ever touching. Essentially the further you follow the asymptote the more it resembles the graphed function, but they will never be quite the same. 5/x gets two lines because it has two asymptotes: a horizontal asymptote at y=0, since the function gets infinitely close to y=0, but never actually reaches it no matter how large x gets, and a vertical asymptote at x=0 since the function gets infinitely close to x=0, but never actually reaches it no matter how large y gets.

Asymptotes don't themselves have anything to do with division by zero though - for example the well-behaved function x^2/(x^2+1) has a horizontal asymptote at y=1, since the function will get infinitely close to y=1 but never actually reach it, but it doesn't have a vertical asymptote since it's well-defined for all values of x.

Asymptotes don't even have to be aligned to an axis - for example, rather than a horizontal asymptote, the function y=x + 1/x gets a diagonal asymptote at y=x: the function will never quite touch that line, but the further you get from x=0 the closer the two resemble each other.

Comment: Re:Infinity (Score 1) 1067 1067

No, it's very context dependent. The usual way to deal with divide-by-zero and other discontinuities is to use the calculus limit operation, the "creeping up on it" I referred to. You can think of it as looking at a graph and, if the function behaves nicely except at that one point, taking the value that it looks like it should have if there weren't an infinitesimal gap present.

(lim x->0 ... is read as "the limit as x approaches zero of...")

lim x->0 1/x = does not exist (positive or negative infinity, depending on the direction you approach it from)
lim x->0 1/x^2 = +inf (the same from either side)
lim x->0 Ax/Bx = A/B
lim x->0 sin(1/x)/x = does not exist (oscillates smoothly between positive and negative infinity with an infinite frequency)

Comment: Re:Infinity (Score 1) 1067 1067

Ah, thought of one with a definite discontinuity: x/abs(x)
lim x->0+ x/abs(x) = 1
lim x->0- x/abs(x) = -1

Now absolute values may not get used a lot in normal calculations, but you may get the same effect if, for example, you're using square roots and only considering the positive result, as is extremely common in computations since standard data types can't hold an ambiguous value:
i.e. sqrt(x^2) = abs(x), rather than the mathematically correct +/-x

Comment: Re:Infinity (Score 1) 1067 1067

> What is wrong with presenting x/x as "1" at zero? When would that ever cause a problem in an application?

Probably nothing, assuming you've got a special case within your evaluation function that checks for encountering the discontinuity and returns the limit. That doesn't mean your function has a value at that point, only that you can fake it in a consistent manner that, in most applications, will result in a graceful workaround of what, in most contexts, is an annoying mathematical anomaly. But as I said such discontinuities can also be indicative of extreme behavior in the components - if this were a piece of engineering design software for example, hiding the discontinuity might conceivably result in a design with unsuspected vulnerablities.

Also, if you are getting such a well-behaved discontinuity, there's a good chance you could simply rearrange/simplify your equation so that the discontinuity is never encountered at all. E.g. algebraically x/x = 1, so why are you ever performing the division at all?

I hope it's also obvious that that is not something that can be gracefully generalized - without knowing the surrounding function there's no way to estimate what the limit at 0/0 might be (lim x->0 7x/3x = 7/3), or even if it has a limit at all.

Comment: Re:Infinity (Score 1) 1067 1067

How about x / x^2? Approaches -inf from the left, and +inf from the right. I'm afraid I can't think of an example that approaches different definite values offhand, but I remember solving far too many back when I was taking Calculus.

And like I said, yes, if you have a single definite two-sided limit on a discontinuity, then for most practical applications you'll probably be fine using the limit as the actual value. Though there's always the risk that you got that nice well-defined limit due to, for example, two counteracting forces approaching infinity, or counterbalanced resonance responses - in which case your practical application will quite likely rip itself to pieces long before you hit the actual discontinuity in your apparently nice smooth function.

Comment: INF versus MAX_INT (Score 1) 1067 1067

Except that, like NaN (Not a Number), INF propagates meaningfully. Once you get an INF all future calculations using that number can only result in INF or NaN (or possibly 0 after dividing a normal number by INF, depending on the implementation. But that's probably okay).

MAX_INT/MIN_INT do not share that property, they're perfectly normal numbers at the limits of representation. The only sign you get of an error is that you have inconsistent data. If you have an INF or NaN showing up in your results it's pretty obvious that there's an error somewhere. MAX_INT though - do a little math on it and it will no longer be obvious that there was ever an error, especially if your valid data may be approaching the limits of your integer range.
Some specific failure cases:
+INF / +INF = NaN ----- MAX_INT / MAX_INT = 1 (You've just performed an undefined operation that completely removes any ability to make a reasonable approximation, where's the warning?)
+INF * 0 = NaN ----- MAX_INT*0 = 0 (same problem, you've done something that can't even be approximated, and it just disappears?!?)
0.0 / 0.0 = NaN ----- 0 / 0 = ??? (again, a completely undefined operation, what should you do?)
+INF / 7 = +INF ----- MAX_INT / 7 = some perfectly normal number (really!?!)
+INF + 1 = +INF ----- MAX_INT + 1 = MIN_INT (getting into some pretty esoteric theoretical mathematics to justify that...)

I agree it would be nice if there were a way to represent +INF, -INF, and NaN in integers, but doing so would greatly complicate integer calculations, which are extremely straightforward in silicon (well, division is a *little* complicated, but not remotely as complicated as floating point addition). And without silicon-level support you'd need to add branching conditionals to EVERY integer calculation, completely killing performance, as well as disrupting lots of traditional integer exploits such as rollover, bitwise operations, and others that are widely deployed as dramatically performance-boosting hacks.

"Oh my! An `inflammatory attitude' in alt.flame? Never heard of such a thing..." -- Allen Gwinn, allen@sulaco.Sigma.COM

Working...