Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #3738
| 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> |
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
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