Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #3738

Re: algorithm analysis Big-O

From Willem <willem@turtle.stack.nl>
Newsgroups comp.programming
Subject Re: algorithm analysis Big-O
Date 2013-09-15 08:16 +0000
Organization Stack Usenet News Service
Message-ID <slrnl3ar7o.p6s.willem@turtle.stack.nl> (permalink)
References <25bf7834-1bb1-4702-9e18-0bd691958ec8@googlegroups.com> <O90Zt.29906$sr1.508@en-nntp-04.dc1.easynews.com> <864f4a00-4b92-4b20-a849-e4f6ce90c06b@googlegroups.com> <slrnl39dqe.v0j.willem@turtle.stack.nl> <EA9Zt.70244$rp1.25539@en-nntp-13.dc1.easynews.com>

Show all headers | View raw


Richard Damon wrote:
) On 9/14/13 3:21 PM, Willem wrote:
)> I disagree.  For constant savings in machine time, I would agree with you,
)> but the consideration 'the dataset will never be very large' has turned
)> out to be false so often (with disastrous results) that I would never
)> rely on it.
)
) Sometimes, there is an upper limit in "size" imposed on the system by
) things much harder to change than the software. In this sort of
) environment I have no problems using a method that might not scale well
) when far past the environmental limits. As an example, a system which
) naturally has no mass store, assuming that all data will fit in
) addressable ram is reasonable. Assuming that the amount of ram will be
) fixed at the first design probably is not.

And then your code gets reused on a new embedded system with 16 times
the amount of RAM, and suddenly the orbital calculations take so long
that the capsule misses the burn window.

Of course, that will never happen because they will exhaustively test
the software on the new hardware... right?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

algorithm analysis Big-O gdotone@gmail.com - 2013-09-14 06:32 -0700
  Re: algorithm analysis Big-O Johann Klammer <klammerj@NOSPAM.a1.net> - 2013-09-14 16:50 +0200
  Re: algorithm analysis Big-O malcolm.mclean5@btinternet.com - 2013-09-14 08:45 -0700
  Re: algorithm analysis Big-O Richard Damon <Richard@Damon-Family.org> - 2013-09-14 12:29 -0400
    Re: algorithm analysis Big-O malcolm.mclean5@btinternet.com - 2013-09-14 11:12 -0700
      Re: algorithm analysis Big-O Willem <willem@turtle.stack.nl> - 2013-09-14 19:21 +0000
        Re: algorithm analysis Big-O Richard Damon <Richard@Damon-Family.org> - 2013-09-14 23:12 -0400
          Re: algorithm analysis Big-O Willem <willem@turtle.stack.nl> - 2013-09-15 08:16 +0000
            Re: algorithm analysis Big-O Richard Damon <Richard@Damon-Family.org> - 2013-09-22 19:04 -0400
              Re: algorithm analysis Big-O Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-09-23 02:32 +0100
          Re: algorithm analysis Big-O malcolm.mclean5@btinternet.com - 2013-09-17 15:07 -0700
    Re: algorithm analysis Big-O Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-09-14 20:27 +0100
    Re: algorithm analysis Big-O blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-09-15 18:09 +0000
      Re: algorithm analysis Big-O Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-09-15 20:47 +0100
        Re: algorithm analysis Big-O blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-09-15 20:42 +0000
          Re: algorithm analysis Big-O Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-09-16 00:56 +0100
            Re: algorithm analysis Big-O blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-09-19 20:26 +0000
  Re: algorithm analysis Big-O Öö Tiib <ootiib@hot.ee> - 2013-09-14 11:08 -0700
  Re: algorithm analysis Big-O Robert Wessel <robertwessel2@yahoo.com> - 2013-09-14 13:43 -0500
  Re: algorithm analysis Big-O Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-09-14 21:01 +0100

csiph-web