http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php

I especially like the last one.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

On Thu, 20 Aug 2009 16:03:50 -0700, Darren New <dne### [at] sanrrcom> wrote:

>I especially like the last one.

It's the same as what you do with deadlines isn't? When asked how long a job
will take you never say what you really think. 
-- 

Regards
     Stephen

Post a reply to this message

Stephen wrote:
> On Thu, 20 Aug 2009 16:03:50 -0700, Darren New <dne### [at] sanrrcom> wrote:
> 
>> I especially like the last one.
> 
> It's the same as what you do with deadlines isn't? When asked how long a job
> will take you never say what you really think. 

That's just good planning :)

Hofstadter's law: It will always take longer than you expect, even when 
you account for Hofstadter's law.

...Chambers

Post a reply to this message

> http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php
>
> I especially like the last one.

I like the second one too.

I think in any industry where you have complex projects that need to be 
finished by a deadline there will always be less-than-optimal hacks to get 
it "finished".  Usually if you had more time there would be a number of 
things you could do better.

We had a similar situation with an LCD for a car whereby we needed to make 
the red colour more "red" near the end of the project, it would have take a 
huge amount of time and money to make a new mask set for the actual panel, 
so we just put a few red LEDs in the backlight...  To this day if you buy a 
certain model of car you will get an LCD with white and *red* LEDs in the 
backlight to make up for the poor glass performance, I doubt anyone else has 
that curious design :-)

Post a reply to this message

It burns! IT BURNS!! >_<

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php
>
> I especially like the last one.

I prefer the penultimate one - the idea of the comedy developer face in the
corner of the screen getting all grr! when the frame rate drops - made me
chuckle.

Post a reply to this message

Bill Pragnell wrote:

> I prefer the penultimate one - the idea of the comedy developer face in the
> corner of the screen getting all grr! when the frame rate drops - made me
> chuckle.

Not so much a coding trick as an interesting application of 
psychology... but bizare, all the same. ;-)

Post a reply to this message

> Surely it is impossible to work under such conditions...

Not impossible, but it should make you realise that developing software for 
profit is quite different than doing it as a hobby.

Post a reply to this message

scott wrote:
>> Surely it is impossible to work under such conditions...
> 
> Not impossible, but it should make you realise that developing software 
> for profit is quite different than doing it as a hobby.

It certainly makes me realise that I prefer safe languages over 
efficient ones any day of the week. :-P

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Bill Pragnell wrote:
>
> > I prefer the penultimate one - the idea of the comedy developer face in the
> > corner of the screen getting all grr! when the frame rate drops - made me
> > chuckle.
>
> Not so much a coding trick as an interesting application of
> psychology... but bizare, all the same. ;-)

Well, it had to be coded, didn't it? :)
He should have made the angrier faces steadily greener! I guess that would have
taken the edge off the psychology.

Post a reply to this message

Invisible wrote:
> It burns! IT BURNS!! >_<
> 
> 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...

Heisenbugs are always lots of fun. ;)

-- 
~Mike

Post a reply to this message

Invisible schrieb:
> It burns! IT BURNS!! >_<
> 
> 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. Last project I was working on, 
"let's just ship the device with debug output X enabled by default" was 
quite a common suggestion during troubleshooting. We managed to keep it 
a joke though - the customer would not have been amused.

And some issues we did indeed fix using the "if you're falling through a 
hole, don't do it" kind of approach, because the errors occurred so 
infrequently that we just had no chance of ever finding the root cause.


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.

Post a reply to this message

Invisible schrieb:
> It certainly makes me realise that I prefer safe languages over 
> efficient ones any day of the week. :-P

You can get such issues with "safe" languages, too: All you need is some 
race conditions that kick in when performance is particularly good, but 
don't if performance is bogged down a deal by debug output.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> 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...

  That was a relatively common problem in C and C++ years ago, but nowadays
especially C++ compilers have got much better at debugging such things. For
example Visual C++, when compiling in debug mode, will add bounds checks to
all STL code and IIRC raw array accesses (although there are limits to the
latter, as it's quite difficult to check bounds when pointer arithmetic is
being performed). gcc has a precompiler constant which, when defined, turns
on similar checks to all STL code. Then you can use valgrind to catch the
rest.

  The only situation nowadays where you might end up having such heisenbugs
in C++ which are not caught by the compiler even in debug mode is if you
use dirty raw pointer arithmetic hacks, which is something you seldom really
have to do in clean good-quality code, not even if you aim for maximum
efficiency.

-- 
                                                          - Warp

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?

Post a reply to this message

>> It certainly makes me realise that I prefer safe languages over 
>> efficient ones any day of the week. :-P
> 
> You can get such issues with "safe" languages, too: All you need is some 
> race conditions that kick in when performance is particularly good, but 
> don't if performance is bogged down a deal by debug output.

Safe languages don't permit race conditions in the first place.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> 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...
> 
>   That was a relatively common problem in C and C++ years ago, but nowadays
> especially C++ compilers have got much better at debugging such things. For
> example Visual C++, when compiling in debug mode, will add bounds checks to
> all STL code and IIRC raw array accesses (although there are limits to the
> latter, as it's quite difficult to check bounds when pointer arithmetic is
> being performed). gcc has a precompiler constant which, when defined, turns
> on similar checks to all STL code. Then you can use valgrind to catch the
> rest.
> 
>   The only situation nowadays where you might end up having such heisenbugs
> in C++ which are not caught by the compiler even in debug mode is if you
> use dirty raw pointer arithmetic hacks, which is something you seldom really
> have to do in clean good-quality code, not even if you aim for maximum
> efficiency.

Maybe you're right, I don't know. I just find it makes me kind of 
nervous working with something which can break just because you changed 
the order of a few statements in a way which, conceptually, shouldn't 
change anything.

(Notice that guy who said he couldn't just add a new integer field to a 
data structure because it would break a few thousand other functions? 
Does that sound like good abstraction you to?)

Still, I guess that's why I'm not a games developer...

I was also puzzled when I looked at Gentoo and discovered just how many 
C programs break horribly just because they were written for IA-32 and 
got recompiled for AMD64.

Post a reply to this message

> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? Does 
> that sound like good abstraction you to?)
>
> Still, I guess that's why I'm not a games developer...

It's not because it's a game, it's because it's being made for profit. 
Writing any software as a hobby is very different than writing it to try and 
make money.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Safe languages don't permit race conditions in the first place.

  And then you wonder why safe languages are so slow.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> (Notice that guy who said he couldn't just add a new integer field to 
>> a data structure because it would break a few thousand other 
>> functions? Does that sound like good abstraction you to?)
>>
>> Still, I guess that's why I'm not a games developer...
> 
> It's not because it's a game, it's because it's being made for profit. 
> Writing any software as a hobby is very different than writing it to try 
> and make money.

 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.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Safe languages don't permit race conditions in the first place.
> 
>   And then you wonder why safe languages are so slow.

I wonder why everybody _assumes_ they're going to be slow, yes.

Still, I guess it depends on where your priorities are - how fast the 
program runs vs how many years you have to spend in debug activities.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? 
> Does that sound like good abstraction you to?)

  That kind of code is crap.

  I have been programming for well over a decade on an "unsafe" language,
and I have never wrote a program which would break if you add something
to a class or struct.

  I have to admit, though, that not all programs I have ever written would
fully support 64-bit architectures. By this I don't mean they would not
compile as a 64-bit executable or that they would crash when compiled as
such and run. I mean that they would not necessarily fully utilize the
increased address space.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Safe languages don't permit race conditions in the first place.
> > 
> >   And then you wonder why safe languages are so slow.

> I wonder why everybody _assumes_ they're going to be slow, yes.

  Well, if every access to a shared variable is thread-safe, it is going
to be slower than non-locked access.

-- 
                                                          - Warp

Post a reply to this message

>> (Notice that guy who said he couldn't just add a new integer field to a 
>> data structure because it would break a few thousand other functions? 
>> Does that sound like good abstraction you to?)
> 
>   That kind of code is crap.
> 
>   I have been programming for well over a decade on an "unsafe" language,
> and I have never wrote a program which would break if you add something
> to a class or struct.

That one did kind of strike me as "this can't be good".

Still, C is a language where, if you so desire, you can make your code 
depend on the exact size of a struct, the endianness of machine words, 
and all kinds of other things to make your code extra fragile. I suppose 
some people would consider this a "feature"...

>   I have to admit, though, that not all programs I have ever written would
> fully support 64-bit architectures. By this I don't mean they would not
> compile as a 64-bit executable or that they would crash when compiled as
> such and run. I mean that they would not necessarily fully utilize the
> increased address space.

Not taking advantage of new features is to be expected; breaking because 
of them even if you aren't using them seems to be like poor design. 
Still, heaps and heaps of C programs seemed to not like being recompiled 
that way...

Post a reply to this message

>>>> Safe languages don't permit race conditions in the first place.
>>>   And then you wonder why safe languages are so slow.
> 
>> I wonder why everybody _assumes_ they're going to be slow, yes.
> 
>   Well, if every access to a shared variable is thread-safe, it is going
> to be slower than non-locked access.

Locks aren't the only way to implement safe shared variables.

Something like STM with optimistic locking can impose a very small 
overhead. Smaller than locking.

Personally, I'd accept a 1% speed hit if it means I don't have to spend 
decades hunting down weird bugs than vanish when you try to debug them. 
But that's just me...

Post a reply to this message

scott wrote:
> I like the second one too.

That didn't really seem hacky to me, actually. It was the obvious solution. 
Certainly the people who coded the hash in the first place knew there was a 
chance a collision would come up.  The failure there was having the program 
generating the hashes not checking that there was a collision.

> I think in any industry where you have complex projects that need to be 
> finished by a deadline there will always be less-than-optimal hacks to 
> get it "finished".  Usually if you had more time there would be a number 
> of things you could do better.

I had a friend who worked in theater production before programming. It 
always ticked him off when the boss gave a "deadline" and he'd bust butt, 
only to hear that it was more a "this is when we'd like it" than a deadline.

For him, if you didn't stop working and ship whatever you had at the 
deadline, it wasn't a deadline. When the curtain goes up in front of a bunch 
of ticketholders? That's a deadline.

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.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> Safe languages don't permit race conditions in the first place.

Nonsense.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> Something like STM with optimistic locking can impose a very small 
> overhead. Smaller than locking.

What makes you think you don't get race conditions with STM?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Warp wrote:
>   That was a relatively common problem in C and C++ years ago, but nowadays
> especially C++ compilers have got much better at debugging such things. 

How does it handle uninitialized variables? Data flow analysis? That's often 
where I find heisenbugs come from, more than random walks off the ends of 
arrays.  That, or accessing memory that has already been freed.

Me, right now, I'd be happy not spending 3 days trying to figure out what to 
change such that the program that gets downloaded during 'make' that 
generates the makefile it later invokes whose every compilation line is 100% 
macros most nested at least 5 deep in definitions no longer tries to strip 
the symbols off a library that's actually a text file, with the comment 
"just in case" printed out above it.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> (Notice that guy who said he couldn't just add a new integer field to a 
> data structure because it would break a few thousand other functions? 
> Does that sound like good abstraction you to?)

I think that was a few thousand callback functions. I.e., when an event 
happened, it called you with "process_your_event(int1, int2, voidp)" and 
you'd have to recode all those headers.

(Honestly, I think that would be rather easy, myself.)

> I was also puzzled when I looked at Gentoo and discovered just how many 
> C programs break horribly just because they were written for IA-32 and 
> got recompiled for AMD64.

Yep. The problem with C is that it offers you the machine's capabilities and 
you pick which of them you want. In Ada, for example, you tell it the range 
of values you want to handle, and it picks the appropriate machine 
structure.  C is only portable to the extent you write multiple versions of 
the source code in the same file.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
>  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

... desktop ...

 > machine.


FTFY.

I take it you've never seen a program written for a cell phone, a set-top 
box, or an MP3 player?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I take it you've never seen a program written for a cell phone, a set-top 
> box, or an MP3 player?

  Does the iPhone count as one of those?-)

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Still, C is a language where, if you so desire, you can make your code 
> depend on the exact size of a struct, the endianness of machine words, 
> and all kinds of other things to make your code extra fragile. I suppose 
> some people would consider this a "feature"...

  Well, sometimes it is useful to be able to poke at memory directly.
For example, changing the sign of a floating point value is much faster
by flipping that one bit at the end of it than doing it with the FPU.
(Of course after this little trick your program will assume IEEE floating
point numbers. But for many purposes that suffices.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> How does it handle uninitialized variables? Data flow analysis?

  At least gcc gives "warning: 'x' is used uninitialized in this function"
when it sees for sure that this is so, and "warning: 'x' might be used
uninitialized in this function" when it can't be sure but it looks like that.

> That, or accessing memory that has already been freed.

  Hasn't happened to me in, like, a decade.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> (Notice that guy who said he couldn't just add a new integer field to
>> a data structure because it would break a few thousand other
>> functions? Does that sound like good abstraction you to?)
> 
> I think that was a few thousand callback functions. I.e., when an event
> happened, it called you with "process_your_event(int1, int2, voidp)" and
> you'd have to recode all those headers.
> 
> (Honestly, I think that would be rather easy, myself.)
> 

It looked like the problem was that the voidp was being free()ed in the
event handler, and the data they wanted to pass into the event handler
was something that couldn't/shouldn't be sent to free(). Maybe copying
that data out to a malloc block would have taken too much time, since it
was for controller inputs.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I take it you've never seen a program written for a cell phone, a set-top 
>> box, or an MP3 player?
> 
>   Does the iPhone count as one of those?-)

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.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

Warp wrote:
>   Hasn't happened to me in, like, a decade.

Me neither. It doesn't mean I like spending the time ensuring it doesn't 
happen. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:4a8dd657$1@news.povray.org...

> http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php
>
> I especially like the last one.

If you think programmers are bad:

http://www.slipperybrick.com/2007/09/airline-seatbelt-engine-straps/

(even if that's not genuine, I've seen enough similar "engineering" hacks).

Post a reply to this message

Invisible schrieb:
> Safe languages don't permit race conditions in the first place.

You're far off from reality there.

Any language that can access a file allows you to program a race 
condition. All you need to do is write two programs to access the same 
file intermittently in a suitable manner.

Any language that can /not/ access a file is useless in practice.

Thus, if safe languages don't permit race conditions in the first place, 
then it follows that safe languages must be useless in practice.

(Some other OS resources will probably qualify as building blocks for a 
race condition generator, too; in this sense, file access is only given 
an example.)

Post a reply to this message

Invisible schrieb:
>>> 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").

Post a reply to this message

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

Those, and embedded software developers.

Post a reply to this message

Warp schrieb:
>   Well, sometimes it is useful to be able to poke at memory directly.
> For example, changing the sign of a floating point value is much faster
> by flipping that one bit at the end of it than doing it with the FPU.
> (Of course after this little trick your program will assume IEEE floating
> point numbers. But for many purposes that suffices.)

I would think that a good optimizing compiler would translate something 
like "x = -x;" to equally efficient code...?

Post a reply to this message

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.

Post a reply to this message

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.

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> 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