Five-Dollar Words for Programmers, Part Two: Orthogonal

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

Ben Tremblay — Fri, 05 Jun 2009 00:43:40 GMT

So ... thank you. Now I can refer to this post when pointing to how my discourse / deliberative system (It's dialectical ... and dialogical, too!) is <i>orthogonal</i> to canonical forum software. I.e.: "<b> two aspects of a system are orthogonal if one can be varied without changing the value of the other</b>"

consider yourself tweeted

--bentrem

p.s. yes, my link points to something substantial

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

Pro developer — Tue, 24 Mar 2009 00:10:49 GMT

Do you know that signals can be represented as vectors. Infact they are vectors. And hence the Fourier series and transform are applicable because of the property of orthogonality. Its the beauty of science. I read communication books quiet often and am quite baffled by the way the writers use the concept of orthogonality there.

Indeed, I studied a fair amount of linear algebra during my undergraduate degree. It has been a long time since I looked at the transforms from the signal space to the frequency space though. I remember hardly any of it.

But indeed, the fact that one can form an orthonormal basis for signals is the key to the decomposition of the signal. -- Eric

Future Breaking Changes, Part Two

Fabulous Adventures In Coding — Thu, 06 Sep 2007 18:29:51 GMT

Last time I mentioned that one of the subtleties of programming language design is weighing the benefit

Subtleties of C# IL codegen

Fabulous Adventures In Coding — Fri, 17 Aug 2007 19:36:25 GMT

It must be CLR week over at The Old New Thing because it's been non-stop posts about C# lately. Raymond's

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

John — Mon, 16 Jan 2006 07:51:10 GMT

If you can't remove unreachable targetted labels because they are targeted, why don't you just remove the code which targets the label too? If the label is truly unreachable, then code which targets it is redundant.

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

Eric Lippert — Fri, 04 Nov 2005 17:28:06 GMT

First off, as mentioned above, that code is not even legal C#. Returning from a finally is forbidden in C#.

But suppose it were legal. Then the reachability analysis would be (assuming that the try is reachable)

goto foo -- beginning is reachable, end is unreachable
return true -- beginning is reachable, end is unreachable
foo: -- label is targetted but unreachable
return false -- unreachable

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

Kyle Lahnakoski — Fri, 04 Nov 2005 04:53:19 GMT

Referring to

try {
goto foo;
} finally {
return true;
}
foo:
return false;

I do not see how the "goto foo" is reachable. It's return is obviously overridden by the finally clause.

Considering the Finally clause as a subroutine, and having it called before all exit points in the try and catch clauses, should make the reachability analysis trivial.

A quick inspection of Soot code, JimpleBodyBuilder::createTryCatchFinally(), appears to do just this.

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

Eric Lippert — Tue, 01 Nov 2005 20:21:48 GMT

That's essentially what we do. Code that is unreachable is stripped totally from the tree before code generation, except for targetted labels which are turned into nops. We then do an additional reachability check on the generated basic blocks and remove unreachable untargetted blocks.

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

Stuart Ballard — Tue, 01 Nov 2005 17:02:59 GMT

Could you just convert unreachable code *always* to nops in your "early" pass through the tree, and then have a pass later that removes unnecessary nops?

re: Five-Dollar Words for Programmers, Part Two: Orthogonal

Eric Lippert — Sun, 30 Oct 2005 17:37:38 GMT

Right -- no matter what happens, that try block has got to be left somehow, and its got to go somewhere, so we'll probably be generating a no-op somewhere for it to go, and we're back in the situation that we're already in. My musings are more along the lines of whether there's a cleaner way to represent this situation in the implementation. I'm working on code that removes the unreachable portions of the bound tree earlier and its a conceptual pain in the rear that I can't remove unreachable targetted labels. I think though that I'm going to live with it since as you say, there's not really a good alternative.