From: MassiveProng on
On Tue, 20 Feb 2007 15:12:05 -0000, "T Wake"
<usenet.es7at(a)gishpuppy.com> Gave us:

>
>"Ken Smith" <kensmith(a)green.rahul.net> wrote in message
>news:erf1cd$39q$3(a)blue.rahul.net...
>> In article <ereol0$8ss_011(a)s883.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfbahciv(a)aol.com> wrote:
>> [....]
>>>Tell me which newsgroup should be deleted. The poster didn't say.
>>
>> I think it was alt.the.big.whiners
>
>and alt.unable.to.ignore.threads
>
Or

alt.too.many.dopes.in.usenet.that.dont.really.know.much

Or

alt.google.tards.r.us
From: MassiveProng on
On Tue, 20 Feb 2007 17:21:00 +0000, Eeyore
<rabbitsfriendsandrelations(a)hotmail.com> Gave us:

>
>
>Phil Carmody wrote:
>
>> MP support was nothing special in those days at all
>
>Massive Pong gets around one heck of a lot doesn't he ?
>

If that were true, you'd have been ponged upside da haed by now.
From: MassiveProng on
On 21 Feb 2007 02:22:17 +0200, Phil Carmody
<thefatphil_demunged(a)yahoo.co.uk> Gave us:

>MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> writes:
>> On Mon, 19 Feb 07 14:18:38 GMT, jmfbahciv(a)aol.com Gave us:
>> >'Secure and safe' and 'world-wide access from any computer' are
>> >orthogonal.
>>
>> You're an idiot. You prove with each and every post you make that
>> you are over a decade behind the rest of the world.
>
>The funny thing is that if you take her words literally,
>she's right. Unfortunately, what she thinks she's said, and
>the simplest non-strict interpretation of the above words,
>is indeed wrong.
>
>Such is the fun when BAH uses words she doesn't understand
>the meaning of!
>
>Yet again...

100% secure links are an everyday instance now. Hell, I make
hardware based IP encryption devices that require the same device on
the other end. You will NEVER beat that.

Our company owner told us that when the company first started out, a
Navy high-up tech type stated that we would never send classified data
over the internet.

Been going on just fine, and quite secure for years now.
From: Ken Smith on
In article <87649xkojl.fsf(a)nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote:
>kensmith(a)green.rahul.net (Ken Smith) writes:
>> >However, the task in hand is an LLL which basically has n^3
>> >written all over it. You're always doing everything with
>> >everything.
>>
>> "LLL" ????????????
>>
>> I assume the interactions are nonlinear too. This makes near imposible to
>> find a different attack on the data.
>
>Lenstra-Lenstra-Lovasc. It's a way of finding a very short
>vector that is a linear combination of the vectors in a matrix.
>If you've every done Gramm-Schmitt ortho-normalisation, it's
>like that but you have to do it over and over again.

After a bit of reading, I am glad to say I've never needed to do this.


>If each entry is a million digits long, and you've got a 25*25
>matrix, that's a horribly large amount of data.

Lucky for you big RAMs are now easy to come by. Since the references have
to ripple up the digits of the numbers and between values, you are truly
screwed as far as only reading in part of it.

I would also think that since you are doing divide like operations,
processing a single value will require an extra space about equal to it in
length and a bunch of CPU time.

[....]
>Fortunately my footprint has just shrunk (the numbers decrease in
>length as you work towards a solution), I'm down to 420MB, and
>I'm not swapping any more. Of course, I couldn't run a second
>process without interfering, but we've already been there...

Maybe you can't but I could. I've got 2G or RAM. This would leave enough
room for me to run an ascii tic-tak-toe game while it churns away.


>> This sounds like one of those "raster to vector" conversion sorts of
>> tasks. In them, you need to follow the color boundary.
>
>Except every point in the grid needs to be touched eventually.

In vector to raster, you need to explore the whole space at least once.
Any group of pixels you didn't look at may hide another line. In the one
I wrote many years ago, I started at the X=0, Y=0 point and expanded down
and right. I only followed lines back into the area already looked at and
spliced new bits onto the ends that were extensions of lines already
found. It let me avoid keeping it all in RAM but it was not the fastest
way to go.


--
--
kensmith(a)rahul.net forging knowledge

From: Ken Smith on
In article <ereobj$8ss_010(a)s883.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv(a)aol.com> wrote:
>In article <ercret$dg2$1(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>In article <erc8n2$8ss_006(a)s942.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfbahciv(a)aol.com> wrote:
>>>In article <877iufp05h.fsf(a)nonospaz.fatphil.org>,
>>> Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote:
>>[....]
>>Unfortunately the hardware in the x86 series of processors makes it hard
>>to do a general purpose VM that doesn't thrash a lot. If the problem is
>>too big to fit in real memory, doing the disk I/O in the program instead
>>of letting the VM take over usually make for a faster result.
>
>A solution is to invent a software GETSEG if the hardware can't
>give help.

You can usually work out before hand what needs to be in memory when.
This way, the swapping action is always the best one instead of pot luck.
A simple case is when you are sorting a huge file. The first step is to
sort the biggest hunks that will fit into RAM, after that the code is a
classic merge operation. For each part it is fairly easy to see what
needs to be in RAM.






--
--
kensmith(a)rahul.net forging knowledge