Re: puzzle

spinoza1111@xxxxxxxxx wrote:

For, I used the phrase "close to" as regards O(n).

O(n*n) == O(n*n/2), of course. But it's also the case for practical
applications that n*n/2 < n*n.


Sure, given the choice between an algorithm that costs n*n steps and one that
costs n*n/2 steps of the same size, the latter is a better choice in terms of
cost, but I don't known anyone other than you that would call such an
algorithm "close to" O(n).  When there are linear and O(n log n) algorithms
that are also simpler to implement, what is the practical use case for your
algorithm?


Read the literature on O(x), for Chrissake. See for example Skiena, The
Algorithm Design Manual
(http://www.amazon.com/exec/obidos/tg/detail/-/0387948600/qid=1118630635/sr=8-3/ref=pd_csp_3/103-4992382-6347852?v=glance&s=books&n=507846).

You don't UNDERSTAND O(x) UNTIL you know when to use O(n^2) in the
pragmatic sense where n is small and known to be small for practical
applications.

You are right that it can be ok to use a suboptimal algorithm for when you know for a fact that the data size will be small, but generally you would only
do so because the faster algorithm is more complex or more work to implement.
This is not the case with your algorithm.

BTW, in my experience it is much more common for programmers to use an overly bad algorithnm when it matters than a overly good algorithm when it doesn't.

What's interesting is that you have in the corporate style lectured me
on the real world in a private email.

Huh? You sent me a private e-mail. I merely replied back to you. If anyone is guilty of "corporate style lecturing" (whatever that is), it is you.

The resentment here is of ability to explain, complementary to the
inability to read shown by O'Dwyer who read a claim for O(n) when I
said "close to".


When you are taking about the O() notation, there is no such thing as "close
to".  Something is either O(n) or it is not.  O'Dwyer probably assumed that
you knew that.

It's obvious from the original post that I understand,

Actually, it really was not all that obvious.

OK, I don't "understand", I don't have the *verstehen* you demand. 

You appear to have "misread" me.  I just meant that it was not obvious
from what you posted *previously* that you understood the O() notation.

Let's not be peers. Let's not work together. I'd rather write and
publish 26000 lines of my OWN goddamn code and have it work than work
with people who don't in my humble opinion know their trade. I am
willing that they have jobs far away from me and I wish them success in
all their future endeavors.

But, IF I form a company, and IF I hire some guy who manifests this
form of *verstehen*, I WILL fire his ass.


Geez.  You have a really thin skin.

You seem to take everything personally. It is your algorithm that was being criticized, not you. In the professional software world, it is really important to be able to recognize when a particular algorithm is bad, drop
it and go on to another one. If you insist on wrapping everything up into your own sense of ego, then it is much harder to reach your technical
goals.

- Christopher
.

Relevant Pages

  • Re: Am I the only one with doubts about .NET for commercial apps?
    ... With an algorithm it's relatively easy to ... > I spend relatively little time thinking about coding. ... For some applications that's true. ...
    (microsoft.public.dotnet.general)
  • Re: 3DES Number of security bits
    ... My question is about the strength of 3DES algorithm. ... The parity bits do not become part of the expanded key. ... The thinking is that because of the small block size, the work required to break three-key 3DES is less than its 168-bit key would imply and is much closer to the 112-bits associated with two-key 3DES. ... The main issue at this point is that 128-bit AES is faster and is likely to be more robust than 3DES, so dragging 3DES into new applications seems pointless unless the new applications must interoperate with legacy applications. ...
    (sci.crypt)
  • Re: Experience with the Sliding DFT, anyone?
    ... It is somewhat similar to the Goertzel algorithm. ... applications, but I have been using it for musical applications, ... would get from a regular DFT or FFT. ...
    (comp.dsp)
  • Re: Experience with the Sliding DFT, anyone?
    ... It is somewhat similar to the Goertzel algorithm. ... applications, but I have been using it for musical applications, ... Do you have a ref for the original sliding DFT paper? ... It is just the standard recursive algorithm to compute a running sum ...
    (comp.dsp)
  • Re: What about turbos?
    ... what percent of the applications (especially from the applications which are built ... focus on "labour saving" languages and language features. ... And the decoupling of algorithm and implementation is not necessarily "a ... Why do we need to be "efficient" in days when memory and CPU power is ...
    (borland.public.delphi.non-technical)