Correct me if I'm wrong, but digital signals are digital. That means either the data got there or it didn't. There is no marginal signal loss such that a larger pipe would help.

On top of that, unless the internal workings of whatever's being connected and the sending unit possess the same size pipes, it's completely irrelevant. All that'd happen is the excess would get emitted as heat, no?

I wish I had the lack of scruples necessary to sell this kind of shit. I'm fairly good at sales, but only if I actually believe what I'm selling is legit. 3 minutes into the selling cycle and I'd start laughing at the buyer. Then start mocking their obviously tiny peener and lack of intelligence for even considering something like this.

Correct on all counts. The only thing that matters is the cable's resistance to noise. That's done by twisting the wires inside the cable in various tight and complex ways, & it's rated by category (hence, "CAT-5"). Gigabit ethernet is pretty picky as I understand it (but I got out of deep hardware before it became common on copper, so WTF do I know?), but it's more a matter of using more of the wires than the earlier stuff.

In other words, this is just about the dumbest thing I've ever seen in hi-fi, and in the nearly 30 yrs I've been in the hobby, I've seen some hum-dingers.

You know how space probes have to radio back data over millions of miles with 10-watt transmitters? I wonder why Monster Cable never advertises how NASA uses their products. It must be necessary, to avoid distortions that would make the whole operation useless.

Seriously - we need to come up with a packaged product that can be used to blow the dust of their intratubes. Only by regularly cleaning the tubes can one ensure absolutely optimal perfomance. And only our product ensures that your tubes are completely clean. The specially-designed nozzle introduces a mini-vortex, not unlike a tornado, that creates an incredibly powerful harmonic, thusly dislodging all the stuck bytes that are slowing down the flow.

We can do this. We can market this. We can become millionaires.

Trouble is, you don't have to be a genius to measure things, and unlike sound "quality," speed can actually be measured.

Still, I bet a lot of users who bought Vista could get their performance improved greatly by a program that replaces their DRM drivers with ones that always report "yeah, it's legit" without even checking.

Their MP3 sound quality would also improve tremendously, since Vista intentionally plays static over any MP3 that doesn't have a DRM certificate attached.

Yeah, but if we have that Billy Mays guy who sells Oxi-Clean sell this, we'll make loads of money on infomercials.

[GEEK]

it's actually much simple using the extension syntax:

ListOfFools.Where(f => f.Moneys.Count>0)

though I think you're modelling your fools wrong. they might have more than one Account, but they shouldn't have a collection of Money, so it'd more likely be:

Fools.Where(f => f.Money>0)

now, we want to part the fools from they're money, so we really want two results, Fools and Money, so...

// gen list of fools w/ money
List Fools2 = Fools.Where(f => f.Money>0);

// how much total to collect
Real Money = Fools.Where(f => f.Money>0).Sum(f => f.Money);

// part fools from money
foreach(Fool f in Fools2)
{
f.Money = 0;
}

[/GEEK]

I *almost* had the lambda, but couldn't quite beat it out of my brain at 6 am (when I posted it), so I went with the pseudo-SQL instead.

Actually, I think monies must be a collection, because each money object has a lot of info in it (denomination, color, president, boolean counterfeit, etc.) But I guess it could go either way. I tend to "atomize" things, I guess a result of my "3rd normal form" DB background. Things that don't fit neatly into tables still make me itch.

I also "hid" the rest of the program in the "SoonParted" method, secure in the knowledge that my development team (i.e. you) would use the signature to tidy up behind me. I'm special that way :).

Hey, if I can't threadjack my own stories, what good is it having a website?

Mr Fred,

I will absolutely bow to your lambda knowledge as I have enough fun getting Access to do what I want it to.

That being said, I think the assumption that fools have no money isn't correct. It's odd, but they get money and are quite flamboyant with it. Kind of like the person still living in a singlewide, but driving a pimped out truck costing over $50K.

So, I'm thinking you'd want a list of fools that still have money, the amount of said money to collect, and then rank them by their propensity to waste said money. That way we'd get an ordered list of monied fools that allows us to practice our techniques on the easiest fools and then, as we get better, go after fools of a somewhat smarter type.

oh no, scope creep! :-)

[GEEK]

re: SoonParted implementation. we set that up as a custom extension.
(how do I put in a tab? it eats the spaces and removed my HTML)

public static class FoolishStuff
{
public static void SoonParted(this Fool f, Real amt)
{
if (f.Money>amt)
f.Money -= amt;
else
f.Money = 0;
}
}

the "this" in front of the first parameter allows us to express it this way elsewhere in the code.

foreach(Fool f in Fools2)
{
f.SoonParted(100.00); // or whatever the cables cost
}

nice, huh?

[/GEEK]

I'm attempting to read the geek, but it looks like that gets it down pretty well. Targets are presented in manageable categories that can then be approached quickly and easily.

It is scope creep, though. Mostly because the original parameters were poorly defined. That's why all parties that need to use the final tool should be consulted prior to writing a true design spec, no?

I'd probably implement it this way:

(you don't use tabs, you use escaped spaces... ampersand-n-b-s-p-semicolon. it's not fun, but it works)

public AMCGLTD.FoolsAndMoney.Commands
  public static List<Money>SoonParted(List<Fools>)
{
    List ml = new List<Money>();
    List parted = new List<Money>();
    foreach (Fool f in Fools)
    {
     ml.AddRange(f.Monies);
     f.Monies = parted;

    }
     return ml;

}

Thing is, I **still** get twisted up by the whole "pass by reference" model, so I'm pretty sure the above will not separate the fools from their money, but will instead separate the fools from their money and then destroy it. Which only performs half the desired work.

If it did work the way I think it should (as apposed to how Mr. wossname Scandinavian requires it to), I'd then be able to do this:

using AMCGLTD.FoolsAndMoney.Commands;
...

List fml = SoonParted(from f in listOfFools where f.moneys.count > 0 select f);

which is, after all, what the title of the post says ;)

If it blew up as I expect it will, I'd go the less elegant but guaranteed effective route of creating new money objects identical to those in the fool's pocket, adding those, then destroying the fool's money. Call it the "serial immortality" model of separation. It also makes oogly code, so I shan't implement it here.

You'll probably be able to infer more about my current style of programming from the pseudo-snippet above than I'd care to reveal to anyone else. I'm strongly considering UML courses to help me extract myself from the problems this sort of "custom solution for custom problem" style causes.

But it does put food on the table, after a fashion. :)

On reflection (as it were), I'm just about certain the above would generate a compile error, because I just remembered LINQ doesn't return List objects, it returns ... gah, I can't remember what it returns, some sort of "Timmeh!!!" object that's *ALMOST* a List. It'd take me 2 or 3 more compile passed to get something that'd make .net happy, but it would eventually work.

What I am happy with is that it's encapsulated enough that someone who actually knows what they're doing could do a "peek-and-shriek", charge me a whole bunch of $, and give me something that works nicely without altering the rest of my code.

Progress, of a sort, I suppose! :)