Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Content-Type: text/plain; charset="UTF-8"
Message-ID: <1481633.v4UOFUmKin@PointedEars.de>
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Reply-To: Thomas 'PointedEars' Lahn <cljs@PointedEars.de>
Organization: PointedEars Software (PES)
Date: Sat, 14 Sep 2013 12:10:56 +0200
User-Agent: KNode/4.10.5
Content-Transfer-Encoding: 8Bit
X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&.<b';Md8`dH6iqhT)6C^.Px|[=M@7=Ik[_w<%n1Up"LPQNu2m8|L!/3iby{-]A+#YE}Kl{Cw$\U!kD%K}\2jz"QQP6Uqr],./"?;=4v
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg==
Subject: Re: Strawmans prime sieve/filter
Newsgroups: comp.lang.javascript
References: <6e464d33-47e4-41b8-bfda-19511de92915@googlegroups.com> <l0jgv8$g2u$1@news.albasani.net> <a13c125d-e801-43e3-9e12-4355b40e22d2@googlegroups.com> <l0kcd7$ol$1@news.albasani.net> <3251928.WeJvBNZfad@PointedEars.de> <KIdkZJh1MhMSFwD1@invalid.uk.co.demon.merlyn.invalid> <10475868.RPHzNtd8jb@PointedEars.de> <l0trp1$ef5$1@news.albasani.net> <7523620.37GnReVopu@PointedEars.de> <0.966398b0a330b8f4cff2.20130914015540BST.87six8kyr7.fsf@bsb.me.uk> <26040281.ttGrEoHtI1@PointedEars.de> <0.7296b1b07acee9593ab0.20130914061641BST.87fvt8kmo6.fsf@bsb.me.uk>
MIME-Version: 1.0
Lines: 55
NNTP-Posting-Date: 14 Sep 2013 12:10:57 CEST
NNTP-Posting-Host: 6b6b03e6.newsspool4.arcor-online.net
X-Trace: DXC=Xn6@Kk?::fNgj[ZPFj7ehO4IUK<Cl32<A4Fo<]lROoRA8kF<OcfhCOK7EWL1O4@eWKDZm8W4\YJNLb@mF9jNikdE@hR_<@5eU4K3aPm:1?mT4M
X-Complaints-To: usenet-abuse@arcor.de
Xref: csiph.com comp.lang.javascript:21343

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> The algorithm differs in that properties of the object referred to by
>>>> “not_prime” (formerly: “comp”) are removed as they are no longer
>>>> needed. This *might* decrease the memory footprint (thus increase the
>>>> memory- efficiency), but it adds another step (thus decreases the
>>>> runtime- efficiency).
>>> You say above that this code is an optimised version of mine, but then
>>> you say it *might* decrease memory footprint,
>> I said the *deletion* might decrease the memory footprint.
> 
> Yes, I understood that.  My point is that you cite it as a potential
> benefit.

If a program uses less memory than another while doing the same thing or 
even more than the latter, that is a benefit.

>>> but that all the deleting decreases the runtime-efficiency.  In what
>>> sense has it been optimised?
>>
>> - it can store primes up to 2⁵³−1 (an Array instance can only hold 2³²−1
>>   elements)
>> - reduced memory usage (Object instead of Array)
>> - potentially faster (no extra Array.prototype.push() calls)
>> - post-increment replaced with pre-increment (maybe faster)
> 
> But it could also be slower and use exactly the same amount of memory.
> In fact that is the case in both engines I tested.  As posted, your
> "optimised" version did not finish in two minutes when run under nodejs,
> and was about 4 to 5 times slower than mine in rhino.  That does not
> match what I think of as optimised code.

If you think of optimization only in terms of runtime-efficiency, you are 
correct.

>>> On two test engines (rhino and nodejs) the deleting has a huge impact on
>>> the run time (a factor of four in rhino and way more in nodejs -- so
>>> much so I killed it before getting a time).
>>
>> Thanks.
> 
> For testing, or showing that deleting elements is slow?

Both.

Please trim your quotes to the relevant parts.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.