On 11/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
To give an idea of the scale (at least for MoGo), 70k simulations/move (with
the best parameters) against gnugo 3.6/level 8 gives 89% in 9x9, 68% in
13x13, 32% in 19x19.
This is still not assessment of scalability. Each of those 70k
Dogs can play Go? No. They can't. Dogs also cannot search for files
on your computer. Why are my CPU cycles being wasted to animate a dog
who may or may not pretend to know something that I don't? Is it
purely to annoy? If so, hats off.
On 12/14/06, Chrilly [EMAIL PROTECTED] wrote:
I
My understanding of Araki's message was that he wants to input
human-annotated games into his learning machine. My point was that
humans writings are not very precise (especially when using a
non-native language).
On 12/14/06, Chrilly [EMAIL PROTECTED] wrote:
If you had such annotated
I haven't really paid much attention to the previous few emails, but
if it is an effort at making a weak player (as the thread started
out), I shouldn't have to. Why not just randomly chose (with a
programmable distribution) between making a move based on a simulation
and a completely random
Kinda like how the discussion is on this mundane stuff instead of the
interesting stuff?
On 1/4/07, Don Dailey [EMAIL PROTECTED] wrote:
On Thu, 2007-01-04 at 13:16 -0800, David Doshay wrote:
I just hope that someday the extra skill required as mentioned
below is applied to computer programs,
What if instead of
territoryBonus = 1/1000 * territory
You use something like this:
territoryBonus = 1/1000 * territory * percentageOfTheWayThroughTheGame
On 1/9/07, Sylvain Gelly [EMAIL PROTECTED] wrote:
and if it doesn't, then there's a simple formula
for getting a lot more
Christian, can you close that 47% / 53% gap and still retain most of
the win by margin by saying that only moves which are less than (5.5
- someFudgeFactor) are inferior?
On 1/9/07, Christian Nilsson [EMAIL PROTECTED] wrote:
I've been experimenting a bit in the area of humanizing :) the
... when someone sucks, we usually don't distinguish
how much they suck so even if they improve a lot, we still think they
suck. And if you suck no one cares how much.
He's right. I suck and no one cares.
___
computer-go mailing list
Seems like a silly title. Any game of perfect information that has a
clear rule set can be solved. Plus, some would argue that any Go
already is solved (write simple algorithm and wait 1 billion years
while it runs). A better question is, Can Computer Go Surpass Human
Go? But again, clearly
Have you trawled through http://senseis.xmp.net/?GoBlogs?
I have (briefly). But I haven't found anything. Maybe there aren't any
bloggers out there that are also Computer Go programmers?
Mick Reiss, but he updates very rarely.
http://www.reiss.demon.co.uk/webgo/compgo.htm
Are there more experimental results coming? Have you tried going
higher than 100 yet? How much memory do you need at 100 during the
course of a 30 minute game?
On 1/19/07, Don Dailey [EMAIL PROTECTED] wrote:
I'm not sure it matters, because as I reported earlier you
can delay node expansion
So if we assume 10 Hz in the brain and 4GHz on silicon, we need to do
25000 neuron-equivalent operations per cycle on silicon.
On 1/24/07, terry mcintyre [EMAIL PROTECTED] wrote:
Moravec estimates that the computer which beat a grandmaster
was equivalent to 1/30 of the processing capacity of a
Oh no you didn't!
On 1/24/07, alain Baeckeroot [EMAIL PROTECTED] wrote:
Le mercredi 24 janvier 2007 19:56, Stuart A. Yeates a écrit:
Since no one has mentioned bounding memory, a complete lookup table (a
complete table of correct moves, perfect-hashed by board state) should do
the trick.
Since no one has mentioned bounding memory, a complete lookup table (a
complete table of correct moves, perfect-hashed by board state) should do
the trick.
cheers
stuart
You're going to need more than 300MHz to do that lookup.
___
computer-go mailing
Sooo... Anybody write or optimize any cool computer Go algorithms lately?
On 1/24/07, Thomas Johnson [EMAIL PROTECTED] wrote:
Turing Machines have an infinite tape -- I'm glad you set us straight on
that.
-Tom
On 1/24/07, Don Dailey [EMAIL PROTECTED] wrote:
On Wed, 2007-01-24 at 21:11
I second Mark Boon's comment.
On 1/26/07, Mark Boon [EMAIL PROTECTED] wrote:
Am I the only one who got tired of this rather pointless discussion a
hundred messages ago? I also can't help feeling that the tone of the
discussion tends to get such that it can easily be mistaken for lack
of respect
I personally would love to see more experimental results and less
feelings and intuitions on this list.
On 1/26/07, Don Dailey [EMAIL PROTECTED] wrote:
On Fri, 2007-01-26 at 11:32 -0800, terry mcintyre wrote:
- Original Message From: Don Dailey [EMAIL PROTECTED]
May I ask the
Don,
I put new player (StonedAgain) on cgos and although it didn't
establish a rating, it won very few games. So I'm going to try and
make it do basically the same thing as some other program on cgos and
see what happens. I'll try to replicate GenericMC_1, (which you
discussed on this list
that are position super ko.
So I think your description is correct except possibly the
simple ko situaiton.
- Don
On Sat, 2007-02-03 at 14:22 -0500, Chris Fant wrote:
Don,
I put new player (StonedAgain) on cgos and although it didn't
establish a rating, it won very few games. So I'm going
3000
On 2/3/07, Don Dailey [EMAIL PROTECTED] wrote:
On Sat, 2007-02-03 at 19:43 -0500, Chris Fant wrote:
I don't see how my bots are going to get ratings if all the existing
logged-in bots are rated much higher than the level that mine appear
to be performing at. We need more low-quality
It seems that some of my games are being lost on time after only a
single move (for instance
http://cgos.boardspace.net/public/SGF/2007/02/06/465927.sgf)
But my engine is never being told that a game has started and it needs
to generate a move. And after this happens, my engine is no longer
with lag but
this is
unlikely to cause your problem.
Quoting Chris Fant [EMAIL PROTECTED]:
It seems that some of my games are being lost on time after only a
single move (for instance
http://cgos.boardspace.net/public/SGF/2007/02/06/465927.sgf)
-Magnus
To who it may concern:
ggexp appears to be losing all of it's games on time.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
played:
1087 games
295 losses
8 of these were time losses.
When playing black ggexp played
1036 games
341 losses
17 losses
So I don't see that it's losing all it's games
on time.
- Don
On Tue, 2007-02-06 at 08:00 -0500, Chris Fant wrote:
To who
, Christoph Birk wrote:
On Wed, 7 Feb 2007, Chris Fant wrote:
Your paper does not mention suicide. Prohibiting single-stone suicide
during playout gave me a nice increase in playout rate and strength.
Does you program allow multiple-stone suicide during playout?
myCtest does NOT allow
The only think I can suggest which perhaps hasn't been tried is to
only consider the score in the evaluation if NONE of the playouts
resulted in a loss.
On 2/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
It's a *weighted* average of all moves. UCT tree search doesn't explore
bad moves
I thought that the memory boundedness was completely fixed by not
expanding a UCT node until it has been visited X number of times.
Just increase X until you are no longer memory bound. I don't recall
anyone reporting a loss in playing strength by doing this.
On 2/8/07, Don Dailey [EMAIL
When I added code to by bot to prohibit single-stone suicide in the MC
playouts, I saw about a 200 ELO point gain plus an increase in pps due
to the shorter games. I did not need to limit game length to 2x board
area.
When I added code to also prohibit multi-stone suicides in the MC
playouts, I
In our work on MoGo we found that there could be a decrease of the
strength of the MC/UCT program while using a stronger simulation
policy. It is why in MoGo it is more the sequence idea, than the
strength idea. Our best simulation policy is quite weak compared to
others we tested.
Could you
Okay, I found the bug. There was actually two. I won't bore you with
the details. Sorry for wasting everyone's time.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
The following code did not hurt the strength against self-play in over
2000 games at boardsize 8x8 (faster games) with 10k playouts per move:
moveEval[m] = (float)wins[m]/nGames[m] +
points[m]/(nGames[m]*Board-Spaces*100)
where points[m] is accumulated only for wins.
Does anyone know what find-union algorithms Lukasz is referring to
in the README file?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Here is a completed game of Go between two random players... on a very
large board.
For ascetics, the eyes have been filled after both players passed.
http://fantius.com/RandomGo1600x1200.png
Sorry, no SGF available :)
___
computer-go mailing list
I like the idea of taking away the edges. In fact, the engine that
generated this board are capable of doing that. But not as a torus.
I simply wrap left-right and wrap up-down. This is cleaner, IMO. Go
is so pure. I don't like the non-pureness of the edges.
On 2/20/07, Don Dailey [EMAIL
Actually, I think what I did is equivalent to a torus. I just never
thought of it that way.
On 2/20/07, Chris Fant [EMAIL PROTECTED] wrote:
I like the idea of taking away the edges. In fact, the engine that
generated this board are capable of doing that. But not as a torus.
I simply wrap
How would it look like without filling eyes?
(Something like goboard-kaya-wood-yellow...)
Without filling eyes, it looked a little speckled which gave it an
imprecise feel.
___
computer-go mailing list
computer-go@computer-go.org
Is there any chance you would take the whole lattice and renormalize it
repeatedly this way?
I have used a 5-block shape like a cross.
http://fantius.com/0.bmp (the initial image)
http://fantius.com/1.bmp
http://fantius.com/2.bmp
http://fantius.com/3.bmp
http://fantius.com/4.bmp
On 2/20/07, Chris Fant [EMAIL PROTECTED] wrote:
Is there any chance you would take the whole lattice and renormalize it
repeatedly this way?
I have used a 5-block shape like a cross.
http://fantius.com/0.bmp (the initial image)
http://fantius.com/1.bmp
http://fantius.com/2.bmp
http
But it was not what I was trying to ask for. The renormalization I was
suggesting would make each successive lattice smaller by a factor of
3 in each direction at each step.
http://fantius.com/0.bmp
http://fantius.com/1.bmp
http://fantius.com/2.bmp
http://fantius.com/3.bmp
If you looked for these images within that last 15 minutes, you would
not have found them. They are there now.
I started with 726x726 since that is a power of 3.
___
computer-go mailing list
computer-go@computer-go.org
On 2/21/07, Chris Fant [EMAIL PROTECTED] wrote:
If you looked for these images within that last 15 minutes, you would
not have found them. They are there now.
I started with 726x726 since that is a power of 3.
I meant 729x729
___
computer-go
Marbles are always spherical. Playing Go with marbles is comical.
On 2/21/07, Sylvain Gelly [EMAIL PROTECTED] wrote:
my favorite line:
In Go all marbles are identical...
My English prevent me to understand the subtlety here.
Is there any relation to the type of stone meaning of marble?
Can you please replace each 3x3 block of pixels with a single
pixel? My mind can't do the transformation visually. I really do
want each lattice to be smaller than the previous, but at the
same pixel scale.
What I am looking for is how much the renormalized lattice looks
like a piece of the
It is pretty clear to me that, if the analogy to MC simulations in
magnets
is of any value, the temperature of the Go game you show is hotter than
optimal.
If the temperature were at the transition temperature, then each of the
renormalized lattices would look just like a piece that size cut
Perhaps someone wants to implement MC algoritm in a
small processor and create am array of PICs or
something running MC. :-P (some really cheap PICs runs
up to 200mhz these days...) or those programmables
chips GPUs? I don't remember the name.
MPMC = Massive Parallel Monte Carlo
Yes, I'd love
The difference is small, and only the renormalizations that would show
any real differences.
Or you could create a chart that tracks board size and average chain
size and see if there is any association between the two. Do you
agree that that is also a sensible test, David?
Perhaps someone wants to implement MC algoritm in a
small processor and create am array of PICs or
something running MC. :-P (some really cheap PICs runs
up to 200mhz these days...) or those programmables
chips GPUs? I don't remember the name.
MPMC = Massive Parallel Monte Carlo
Yes, I'd
Are these the result of one random playout or are they from one
MC player playing against another (each using many playouts to
determine its move)?
One MC playout. At 100 playouts per move, generating a 1000x1000
graphic would take something like 95 years to compute, assuming you
did not
I don't understand. I think everyone is thinking too visually. What
does straight mean in the context of go? Only liberties are
meaningful. It is isotropic if you stop visualizing the shape and only
consider the graph.
I think straight would mean that when moving from one node to an
adjacent
Interesting.
I'm currently trying to find some correlation between playing strength
and average chain size. I'm using random player as a baseline and
then doing very weak MC as the stronger player. To get anything more
than two chains at the end of almost every game, you have to go up to
about
Maybe this would make a good Go card:
http://gizmodo.com/gadgets/peripherals/nvidia-ships-128core-graphics-cards-for-highend-film-editors-graphics-pros-apple-excited-241478.php
___
computer-go mailing list
computer-go@computer-go.org
I have found this slide on Google.
http://www.lri.fr/~sebag/Slides/Venice/Kocsis.pdf
However I cannot find any explanation for it.
Does anyone know what Discounted UCB is?
Yes, this guy does:
http://aurora.mlhci.sztaki.hu/www/index.pl/kocsis
___
On 3/9/07, Nick Apperson [EMAIL PROTECTED] wrote:
This is definately the direction things are headed. Processors are going to
eventually have tons of cores. The main problem with the design you
mentioned though is that the overhead of having all those processors would
almost not make it worth
I can't even get the download to start. Anyone want to host it
temporarily for us Computer-Go people?
On 3/9/07, Yamato [EMAIL PROTECTED] wrote:
A week ago, I announced the release of Grid Cosmos in the Japanese
Computer Go mailing list, and Japanese researchers could download and play it
and
On 3/10/07, Chris Fant [EMAIL PROTECTED] wrote:
8086 instruction set. Anything less and you will have accidentally
left something out that you need.
Well, let me modify that statement. My point is that there's no point
in designing a go-specific instruction set. One should use a proven
I just want to weigh in on C# here since someone asked about it
earlier in this thread. I recently switched from C++ to C#. I was
not an expert at utilization of the STL, but I made do. Moving to C#
has increase the rate at which I can try new things by at least 10x.
I wish I would have done
I was able to replicate the success (and with more iterations,
failure) of the all-as-first heuristic. But I have not been able to
see an improvement when I prohibit multi-stone suicides (I always
prohibit single-stone suicides). Forgive me, but I am only interested
in your response if you have
I would say the two best things about C# are the IDE and the garbage
collection. Perhaps Java has as-good or better in both regards. I
don't know. I have never been a Java guy. I became familiar with the
.NET platform due to my job.
I think it is fair to say that I ported my C++ code. Some
If you allow multi-stone suicide, it will probably avoid a test
that may be expensive in your program, and so it may turn out to
be a net improvement in strength per second - especially if your
testing proves that it doesn't hurt in any measurable way.
Doing that test does make my C# engine
Yes, it plays better when allowing multi-stone suicides but still
prohibiting single-stone suicides. I'm still wondering if anyone else
has tried this.
On 3/15/07, Don Dailey [EMAIL PROTECTED] wrote:
On Thu, 2007-03-15 at 19:38 -0400, Chris Fant wrote:
If you allow multi-stone suicide
The latter. But only exploring multi-stone suicides. Never
single-stone suicides.
On 3/16/07, steve uurtamo [EMAIL PROTECTED] wrote:
Yes, it plays better when allowing multi-stone suicides but still
prohibiting single-stone suicides. I'm still wondering if anyone else
has tried this.
i
Some of the initial confusion I personally have about MC and UCT
stemmed from the fact that I did not see the separation between the
tree search and the leaf evaluation. UCT provides direction for the
tree search and MC provides an increasingly accurate evaluation of the
leaves. Because of that
I remember it as
./myProg 21
to send myProg's stderr to stdout.
On 3/26/07, Don Dailey [EMAIL PROTECTED] wrote:
My people have asked about sending stderr to the display when
running the cgos tcl client. Several people on CGOS use the
perl client because of this.
I think it can be done by
I vote for 5 minutes per side in the name of faster ratings, faster
testing and faster games for casual observers to observe. Plus,
computers are getting faster every day and 9x9 Go algorithms are
getting better every day so it seems reasonable to speed-up the time
controls from what it was when
Can someone please re-send that list of fast/small random number
generators? I can't seem to find it. Thanks.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Once upon a time, I did analysis of the inaccuracy of pseudo liberties.
Searching quickly, I found:
http://computer-go.org/pipermail/computer-go/2005-October/003839.html
For any interested, I did come up with a variant of pseudo liberties
that was a lot closer to real liberties. My post about
As far as I know, pseudo-liberties are only used for detecting a
capture or detecting atari. If this method you suggest has some value
beyond that, then I'm interested to learn more about it. But the
message that you linked seems to leave out a lot of details. You give
conclusions, but I
Just out of curiosity, how did you calculate these numbers?
On 3/31/07, Gunnar Farneback [EMAIL PROTECTED] wrote:
The remaining list up to 19x19 will come when the computations are done.
Maximum number of pseudoliberties for a single string on square
boardsizes up to 19x19:
1x1 0
I like it. Thanks.
Does the new cgos have a standby player that fills in when an odd
number of engines are logged-in?
On 4/2/07, Don Dailey [EMAIL PROTECTED] wrote:
I now have a primitive but working prototype of a graphical game
viewer for CGOS. Although it's primitive, it's quite nice
Also, I am hoping someone will be interested enough to build
a better client, perhaps in java or C. I will assist with
information on the protocol - additions to the protocol if
needed, etc. It's really very trivial and simple.
In case anyone is thinking about doing this, a browser-based
I like to think that MoGo deliberately beats such people by half a
point, so as to annoy them more :-)
Sylvain, I think it would be quite humorous if you could tune KGS MoGo
to do exactly that without hurting its win rate too much. Perhaps one
way would be to evaluate playouts normally near
That would be hard because you cannot expect your opponent to
cooperate. It would be pretty much impossible to force the
opponent into a 1/2 point loss.
I'm pretty sure that anything drastic in this regard would
weaken the program.
Didn't you just say you were going to try to make Lazarus do
Or maybe it was 1 hour before, and then realise that it is difficult.
I also think it is quite difficult, because in the tree the opponent level
will try to be far from 0.5 and give you points to make you miss your
goal...
Ahh, true. The opponent levels would need goal=win while the self
I have this idea that perhaps a good evaluation function could
replace the play-out portion of the UCT programs.
I thought about something similar but only for initializing the
counters: introduce 10 fake playouts and estimate the number of
wins by a function returning something in [0, 10].
I doubt it matters, because any
such trick I can think of, could be massaged into a form where the engine
would converge anyway.
It all comes down to the terminology we're using being not so precise
or universally accepted.
And we can be sure that as the hardware improves, engine writers
The results are that in order to keep the same winning rate, you have to
increase the number of simulations by something a little larger than linear
in the board area. From 9x9 to 13x13, you need something like 3 times more
simulations for the same winning rate. Same thing from 13x13 to 19x19. As
Most people on DGS play many concurrent games, I'd recommend that MoGo
follow the same strategy.
Then you need multiple dedicated computers.
It is also possible to have shorter time controls.
DGS was brought up because of it's long time controls.
* In uct_t::do_playout(), when two passes in a row then you break and
score the game at that point. However I don't see anything to stop the
two passes happening anywhere in the tree, which would upset accuracy.
They can happen anywhere in the tree, pass is just another move.
I do not see why
But there is another way to make it pay off more reasonably. After you
make a move, kill all the siblings and start thinking as if you were
the opponent. Then when it's your turn again, prune the tree again
to the relevant branches. Then you will get a modest improvement.
This is what my
Now I don't feel so bad -- my UCT prog also sucks ass, only slower.
On 4/13/07, Darren Cook [EMAIL PROTECTED] wrote:
I've been trying the libego program out of the box, and am up to
200,000 UCT playouts, but still gnugo 3.6 on level 6 is winning 10 out
of 10. ...
If 200,000 play-outs is
You can:
a) Guess your opponents next response, and assume they will make this
move. Fire off a search from the resultant position. If you guess
correctly, then you save X seconds. But if you only guess correctly p
% of the time, you expect to gain pX seconds of extra thinking time
per move.
b)
Don has stated a couple of times that option (A) worked better for
him. I chose option (B) without testing option (A) because I did not
want to have to decide how many seconds to use to guess the opponent
move before starting to think about my next move.
There is no need to spend any extra
Like most of the UCT programs (I believe), Orego adds one tree node per
Monte Carlo run. At present, this node includes data from the run that
created it. Thus, after the first run, my tree looks like this:
ROOT: 1/1 wins
CHILD A: 1/1 wins
Ignoring the other children, I eventually do another
I have been wondering about this: If it pays off not to expand a node
until it has been visited 100 times, why not bite the bullet and make
those 100 simulations in one go? That should save a bit of time
traversing the tree up and down. Of course, it means that they all do
get a full 100
The first letter of the score is always the winner.
On 5/4/07, Joshua Shriver [EMAIL PROTECTED] wrote:
I grabbed the CGOS viewer today to watch some games, really nifty :)
Though I was wondering, what does W+Resign mean? White resigned or
that white won by resignation? One game in particular
I'm contemplating making the change you suggest. The following is my
one concern.
Suppose, to keep the example simple, that there are only two choices
at each ply. My tree is originally
ROOT 0
meaning that there is just one node with no playouts.
In the first playout, my first move is A, so
How much improvement should one see in a UCT program after adding a
transposition table?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
John corrected me. It turns out we do add the playouts from the
possible moves (we didn't used to in my original implementation, but
he changed that). The difference with what Jason described is that we
do not use the playout count from the destination node. Instead, we
keep counters at the
It seems that e-mail at my university does not work any more. I have
received none of the replies to my message of yesterday, but I could
read them on the web archives of the list. So I have registered from
another address, and will answer to the questions I have read on the web.
In section
Thanks for the great paper. And thanks for sharing it before it's published.
Now I know what directions to take my engine in next.
Time for Team MoGo so share some more secrets :)
___
computer-go mailing list
computer-go@computer-go.org
I first thought I would keep my ideas secret until the Asmterdam
tournament, but now that I have submitted my paper, I cannot wait to
share it. So, here it is:
http://remi.coulom.free.fr/Amsterdam2007/
Comments and questions are very welcome.
I'd like to propose a potential direction of
On 5/17/07, Chrilly [EMAIL PROTECTED] wrote:
I have now also finished a first version of UCT-Suzie (in parallel the Peter
Woitke works on the Alpha-Beta Version). UCT-Suzie uses a hashtable, mainly
because I found the programming of the tree too complicated. The Monte-Carlo
part uses some simple
After search, when actually making a move:
1) Make a copy of the board
2) Compute the Zobrist hash of the current position from scratch
3) Check for superko violations (against a stack of previous Zobrist hashes
for positions in the real game,)
4) If there is a violation, go back to the copy and
But then you have an engine which does not converge to perfect play
given infinite resources.
I assume that you're joking, given: a) a current lack of infinite resources,
and b) a current lack of convergence of any kind.
No, but I can rephrase for those spooked by the concept of infinity:
There has been much talk of a 19x19 CGOS and I have had people offer
systems to run it on. I think Dave Dyer also would let us run a 19x19
version.
...
I still have this horrible fear that 9x9 would suffer if several
programs moved over to 19x19. Or perhaps BOTH would suffer from a lack
I think that this version is sufficiently fast that it will move in
time on most modern systems.
You could also throw out the result when an anchor loses on time.
___
computer-go mailing list
computer-go@computer-go.org
Favorite line:
If the index equals the win rate of the move, the algorithm quickly
focuses on the most promising path.
On 5/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I just received the June issue of Scientific American and
found a 1.5 page article on Computer Go and UCT.
I've
On 5/24/07, John Tromp [EMAIL PROTECTED] wrote:
Question for native English speakers: do you think this technique is best
described by progressive unpruning or progressive widening?
I'm no native speaker, but I think using the word selectivity may be
most descriptive.
Does regressive
Wow, 48-cores in a second-generation chip. The future is not far now.
On 6/15/07, terry mcintyre [EMAIL PROTECTED] wrote:
Azul Systems has released a compute appliance with 768 cores and 768
gigabytes of RAM,
happily driving your Java applications faster than ever before:
I get lots of spam in my yahoo inbox but gmail almost perfectly
filters all the spam out of my inbox.
On 6/17/07, terry mcintyre [EMAIL PROTECTED] wrote:
Spam is so prevalent that I've pretty well given up and assumed that one
will get lots of it. Fortunately,
yahoo is pretty good about
1 - 100 of 196 matches
Mail list logo
