 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> somebody schrieb:
> > http://www.slipperybrick.com/2007/09/airline-seatbelt-engine-straps/
> I cannot imagine this to be genuine: At the speed at which aircraft
> engines operate, these straps would either /be/ torn to pieces, or /do/
> tear the blades to shreds.
> The blades don't look that good either, so I'd expect the engine to just
> disintegrte impressively anyway next time it is operated at full throttle.
Genuine and genuine. It depends on your definition of "genuine".
It *is* a genuine photograph in the sense that it's an unmanipulated
photo of an actual situation (ie. not staged for this photo in question).
What is "not genuine" is just the false impression it gives. In other
words the real reason for the straps to be there may not be immediately
obvious to the viewer, thus the viewer gets confused and the wrong
impression, making this *perception* "not genuine".
The real explanation for the straps is quite simple: They keep the blades
in place for transport of the engine, so that they don't rotate freely
during transport. The engine in this photo has probably just been readied
to be transported to maintenance or scrapping.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-8-2009 9:54, Warp wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> I would think that a good optimizing compiler would translate something
>> like "x = -x;" to equally efficient code...?
>
> Out of curiosity, I tested how gcc compiles this function with maximum
> optimizations (-O3 -ffast-math -march=native):
>
> void negate(double* values, unsigned amount)
> {
> for(unsigned i = 0; i < amount; ++i)
> values[i] = -values[i];
> }
>
> The relevant part of the asm output was:
>
> xorl %eax, %eax
> .L7:
> fldl (%edi,%eax,8)
> fchs
> fstpl (%edi,%eax,8)
> addl $1, %eax
> cmpl %eax, %esi
> ja .L7
>
> So it is loading the values into the FPU one by one, negating them there
> and then storing them back into RAM.
For comparison, how would you code the bit reversal routine?
Then explain why that would be faster?
Will that differ on 32 and 64 bit architectures?
Will the result differ for exceptional cases: NaN, inf, subnormal
numbers and 0? If so which implementation is more 'correct'?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Sat, 22 Aug 2009 04:00:17 -0400 schrieb Warp:
> Genuine and genuine. It depends on your definition of "genuine".
>
> It *is* a genuine photograph in the sense that it's an unmanipulated
> photo of an actual situation (ie. not staged for this photo in
> question).
Indeed:
http://www.snopes.com/photos/airplane/airchina.asp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Pesth schrieb:
>> It *is* a genuine photograph in the sense that it's an unmanipulated
>> photo of an actual situation (ie. not staged for this photo in
>> question).
>
> Indeed:
>
> http://www.snopes.com/photos/airplane/airchina.asp
That's indeed a more credible background story (though I don't doubt
many people would think otherwise, and readily believe the Air China story).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Wouldn't this make it scientifically impossible to deliver a working
> product?
The more complex a project is, the greater the likelihood of bugs appearing.
The more bugs there are, the more likely they are to be hard to find.
Some bugs are so infrequent, and so well hidden, that it would take the
equivalent of dozens (or hundreds) of man-years to find them. True,
"with enough eyes all bugs are shallow," but sometimes the requisite
number of eyes is just infeasible.
And it's perfectly possible to deliver a working product that has bugs
in it ;)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 21 Aug 2009 15:08:27 +0100, Invisible wrote:
>> Yeah, it's kind of fun developing software for devices where
>> occasionally the only way to get any helpful debug information out of
>> the thing is by switching an LED on or off, and errors might just as
>> well be hardware-related.
>
> Wouldn't this make it scientifically impossible to deliver a working
> product?
Clearly not, since such products exist. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Of course, games trying to hit the christmas season, or cars going into
> production, all count as actual deadlines, as do trade show demos in the
> computer business.
You just have to ask yourself in each case, what are the consequences of
missing the deadline. That should tell you how much of a "real" deadline it
is...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If it's part of operating the phone, sure. If it's an add-on game or
> something, probably less so. When you're trying to cut battery usage so
> you turn off the receiver half-way thru getting a packet because you can
> tell from the first half that you're not interested in the second half,
> that's squeezing out performance.
I guess they didn't bother with such things in the iPhone :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> I especially like the claims of "every time we added debug code, the
>>>> bug went away". Surely it is impossible to work under such
>>>> conditions...
>>>
>>> Well, I tell you that's pure reality.
>>
>>> Yeah, it's kind of fun developing software for devices where
>>> occasionally the only way to get any helpful debug information out of
>>> the thing is by switching an LED on or off, and errors might just as
>>> well be hardware-related.
>>
>> Wouldn't this make it scientifically impossible to deliver a working
>> product?
>
> I'm not sure what you mean by this.
>
> If you're saying, "wouldn't this make it impossible to prove that the
> product is working properly", then yes: Such a proof is impossible for
> virtually /every/ real-life product. Welcome to real-world software (and
> hardware) development.
>
> If you're saying, "if you can't get any debug information out of the
> device except for an LED, how can the product be of use anyway?", then
> you're missing the fact that there might be other interfaces to the
> outside world, which just happen to be unavailable for debugging
> information (e.g. they're not initialized yet when the error occurs, or
> the interface protocol provides no means to introduce any "side channel").
No, what I'm saying is "if adding debug code alters all the bugs, how
does that not make it scientifically impossible to remove all the bugs?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> From what I've seen, only games programmers go to the extremes of using
> obscure and elaborate low-level hackery to squeeze every last femtosecond
> of performance out of the machine. Other programmers usually don't have
> such ardent performance limits to worry about. (Usually.)
>
> Which is not to say that all codebases that aren't games are beautifully
> written... just that games typically have ludicrous performance
> requirements and insane release schedules.
Imagine writing software for an mp3 player or phone, not only do you have an
insane release schedule, you also need to fit in with the development teams
and testing schedules for the electronics and mechanical parts. It's not as
easy as you think, no mass-produced product has the luxury of weeks of spare
time to optmise.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
