Look,
I love C++ and I'd love to say look I told you all, C++ is the fastest,
but frankly it just doesn't work like that. When we come to a point where
every programmer writes the fastest possible code their language could
create then we have some kind of a comparison.
C++ has a philosophy
I've been (and still am) a die hard supporter of C++, but since I program in
C++ for work (we develop gamelike software) I get tired of C++ day in and
out. I'd also like to push myself to learn some new things.
Lisp seems to me like a language I could really come to respect. I run
linux (no
programming if you are prototyping use
whatever the hell you want. If you are finishing something off, don't waste
my time with any of those slow languages (that includes java and c#).
- Nick
On Nov 22, 2007 1:44 AM, Stefan Nobis [EMAIL PROTECTED] wrote:
Nick Apperson [EMAIL PROTECTED] writes
hahaha, good point... good point. Although I still will stick with C++, I
really ought to learn Lisp I think.
On Nov 22, 2007 2:43 AM, Raymond Wold [EMAIL PROTECTED] wrote:
Nick Apperson wrote:
But, to be fair, I totally agree that compiling python or ruby would give
you noticable speed
this only as a hobby and
have no aspirations (just for fun and pleasure) then by all means, you
will be much happier in a high level language.
- Don
Raymond Wold wrote:
Nick Apperson wrote:
But, to be fair, I totally agree that compiling python or ruby would
give
you noticable speed
their
code poorly. There is a saying I think... but yeah C++ is not made for
people that aren't really good programmers. No training wheels.
On Nov 22, 2007 11:51 AM, Petr Baudis [EMAIL PROTECTED] wrote:
On Thu, Nov 22, 2007 at 11:36:58AM +1800, Nick Apperson wrote:
Thanks for a great read
22, 2007 at 12:04:53PM +1800, Nick Apperson wrote:
right... well C++ does have this using virtual methods. I meant to add
that
part.
I'm sorry, I still don't get this - what do virtual methods have to do
with branch prediction? Can you elaborate, please
Actually, putting all the code in headers helps with function inlining more
than anything. The virtual function stuff is very complicated because
usually code can be linked in at runtime that adds new functionality (i.e. a
new derived class).
Make no mistake, virtual functions are VERY
I agree with you 100%. You embody the methodology behind C++. The only
problem I can see with adding something like that to C++ is that many times
the compiler can't determine at compile time if a value is violating the
contract. If the feature were added to C++, the programmer would have to be
Java and C# are both compiled at some point if the same loop is running
repeatedly. Java is usually compiled just in time which is to say as each
function is first run. I'm not sure how C# is executed, but I think it gets
compiled before execution.
In theory, ruby and python could also be
perhaps this is an obvious statement... The best language depends on the
way in which your program works. Having used C++ extensively, my program
designs naturally fit easily into that language. I'm sure a lisp programmer
would think of better solutions that would only work in lisp. As far as
of the language when it isn't really necessary.
Just my thoughts,
Nick
On Nov 14, 2007 8:46 PM, William Harold Newman [EMAIL PROTECTED]
wrote:
On Wed, Nov 14, 2007 at 04:44:25PM -0600, Nick Apperson wrote:
perhaps this is an obvious statement... The best language depends on
the
way in which your
idioms avaliable in C++. I
can understand why these people might prefer Java. I write lots of code in
C++ that saves me tons of development time that simply couldn't be written
in Java. So it really depends I think on what you use. For me, I'm more
productive in C++.
Nick Apperson: You write
I'd also say that Lisp seems like a great choice. I'm happy to see that C++
has been adding support for all the metaprogramming because that is what is
going to really matter in the future I think and it is why Lisp is such a
great language.
On Nov 13, 2007 2:13 PM, Chris Fant [EMAIL PROTECTED]
don't think that Java is a bad language for
everything, but for what I do with my skills, it is not what I'm most
productive with.
On Nov 13, 2007 2:36 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
Nick Apperson [EMAIL PROTECTED] writes:
Reference counting and copy on write.
Do you know
for metaprogramming, but I
don't know enough to really make that claim. I stray from Lisp mainly
because it isn't used as much as C++. But I do respect those that use it.
- Nick
On Nov 13, 2007 3:10 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
Nick Apperson [EMAIL PROTECTED] writes:
And I don't htink I
hahaha
one problem though... i can't easily determine the number of letters that
are inside the parenthesis...
maybe this is better:
paren type:open/parenspace type=normal/spaceletter
type=normal case=capitalX/letterletter type=normal
case=capitalM/letterletter type=normal
Are you a troll?
I'd recomend staying away from proprietary languages personally... for
obvious reasons. I don't think there is any language that doesn't sacrifice
some speed for garbage collection. But, speed is a relative thing. If you
don't directly use the heap in C++ (i.e. you use the
WARNING: This digresses into a rant by the end... You've been warned.
If you like to have your garbage collected for you then use one of the
management strategies present in C++. If you like delayed freeing, overload
new or use a library that does this. Really, the difference between C++ and
This is an exercise in proving that computers have more memory and
processing power than before I feel. To solve a game, very little
programming skill is necessary. The strategy for using processing power can
only be one of a limited set of possible strategies. A game that is not
solvable by
I think Java approaches the speed of C only in a few benchmarks. I
think if you had a competition by super-experts in any language to write
a very specific program, you would find that the Java program couldn't
approach the C program in speed.
For instance I would like someone to take Lukasz
I was thinking about going anyway. If some of you all are going to be
there, I would definately get there if it is possible. Not that I am at the
level of most of the people on this list...
On 4/13/07, Don Dailey [EMAIL PROTECTED] wrote:
On Fri, 2007-04-13 at 13:14 -0400, Chris Fant wrote:
heavy playouts should yeild a lower number of moves because moves are
slightly more efficient bringing the end of the game sooner. I'm actually
surprised it isn't a larger difference.
On 3/18/07, Don Dailey [EMAIL PROTECTED] wrote:
On Sun, 2007-03-18 at 22:33 -0400, John Tromp wrote:
I've
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 it because of how slow they are. And also, bus
perhaps since every command is numbered we could have a command that tells
the engine to abort a command by number. The engine can ofcourse reply with
a failure if it already processed the command and can not abort it. Genmove
still seems to be somewhat of an issue, but atleast this way defines
I think you are mostly correct. But, the problem is that GTP was designed
to block on the genmove command. This is a problem because genmove is
usually not quick to return. Therefore, there is no way with the current
scheme to be able to issue commands while an engine is thinking. It would
just a thought...
prefix all async commands with async_ so that it is clear. Also, that way
there can be a version of the command that is async and one that blocks and
an engine can support one or both. This could be useful for commands that
query on state (or estimated score or whatever). An
, get_current_best_move,
chat, etc.
If the engine doesn't support realtime gtp, they
will be answer after the gen_move response. one at a
time.
I don't know, perhaps I'm pushing too much the gtp
protocol... I don't think so, but perhaps
--- Nick Apperson [EMAIL PROTECTED] escribió:
I think you
if cache is your limiting factor that is usually shared. Also, if you are
using processors with hyperthreading, it is possible. Or if bus bandwidth
is your limiting factor... but if it is exactly 2x slower that is indeed
very odd. My money is on the fact that you have a bottleneck somewhere
The other thought (kind of silly) but just a pssing thought is that the
threads that are benchmarking are keeping a local copy of their count and
writing it back at the end (which is allowed) so you are actually getting
good performance, but you don't know it because the processors aren't
talking
C++ function objects have overhead?
This is news to me... Any decent compiler can optimize these as well as a
direct function call. Also because of the way that the code is generated
using templates (as in machine language isn't generated until the actual
call is reached), function bodies are
On 2/16/07, Petri Pitkanen [EMAIL PROTECTED] wrote:
2007/2/16, Nick Apperson [EMAIL PROTECTED]:
trouble. Also, the alternative is usually function pointers which have
atleast 50 times the overhead of a function object. Correct me if I'm
wrong.
- Nick
function objects really cannot be 50
.
Nic Schraudolph has done some interesting work on this, but as far as
I know he still hasn't published it. Maybe if we all sit on him we can
finally get him to finish it :-)
Erik
On 2/9/07, Nick Apperson [EMAIL PROTECTED] wrote:
Hey all,
I was thinking about our conversation and i decided
If it only did one playout you would be right, but imagine the following
cases:
case 1: White wins by .5 x 100, Black wins by .5 x 100
case 2: White wins by 100.5 x 91, Black wins by .5 x 109
the method that takes into account score would prefer the second case even
though it has a lower
question:
should if ( (bs + bt) - (ws - wt) komi ) then black_wins else
white_wins. be if ( (bs + bt) - (ws + wt) komi ) then black_wins else
white_wins. ? or maybe you meant if ( (bs + bt - ws - wt) komi ) then
black_wins else white_wins. ?
and floats are rounded down when converting to
Are you going to release the source for it? If you are, some of us might be
able to make some suggestions for how to port it to various platforms. Just
a thought. BTW, I know that I appreciate the work you are putting in and
I'm sure others are as well.
- Nick
On 2/3/07, Don Dailey [EMAIL
I believe this to be a good idea, but I couldn't get around some minor
problems. Essentially, because the local searches are coupled to one
another, it ends up exploding as you consider this coupling (scaling to
larger regions). You then have to trade accuracy or have more computing
power than
Hey all,
don't know if any of you are intereseted, but I am giveing out my GTP
wrappers written in C++. I hope to improve them and add more features with
time.
http://www.nicholasapperson.com/go/computer
Any feedback is always welcome.
- Nick
___
So I was thinking. I wonder if anyone has written a go engine that can play
using only the time that it takes their opponent to think. It seems some of
your monte carlo programs would be able to do this decently well. Has
anyone tried to see how much it hurts the ranking of a program? I would
ofcourse you are correct, P = 1.0 is just the random player. Obviously the
ELO as a function of P is going to be continuous. So, being really close to
P=1.0 will make for a player that is only very slightly better than random.
I think it is also interesting to consider a player worse than
I am writing my program to scale to n processors because I think that is the
direction hardware is headed. However, I think clever programming will do
more than computational power with go.
On 1/25/07, terry mcintyre [EMAIL PROTECTED] wrote:
So what would it take to get corporate sponsorship
I am thinking that God would use a much larger portion of the memory as code
space. Hardcoding lots of the programming. Reason being, there would be no
point in learning and go has so many special cases that it might be easier
to do it this way (for a being that has lots of time to program that
In my original question I stated minimum resources. I agree with you that
lots of memory could be highly useful: ... I would say a computer with
perfect software, 32 GB of RAM (so a lot) and a 300 Mhz processor (slow
processor) would be able to beat a human. (from my original post)
So it sounds
To do a complete lookup you would need more than 32 GB of memory, but I
think that the question was more about making programs smarter more than it
was about unlimited hardware. Infact, my question was what is the minimum
hardware. That said, 300 Mhz should be plenty to do a lookup. There are
actually, one more trip to Gateway Electronics (the local circuit parts
store) and my lookup table will be complete... suckers!
On 1/24/07, Don Dailey [EMAIL PROTECTED] wrote:
On Wed, 2007-01-24 at 21:11 +0100, alain Baeckeroot wrote:
Le mercredi 24 janvier 2007 19:56, Stuart A. Yeates a
of the larger branching factor.
On 1/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
- Oorspronkelijk bericht -
Van: Matt Gokey [EMAIL PROTECTED]
Datum: maandag, januari 22, 2007 9:59 pm
Onderwerp: Re: [computer-go] an idea... computer go program's rank vs
time
Nick Apperson wrote
This is a very good design in my opinion. I was about to ask why you used
an index instead of a pointer until I saw that you were using a pointer
actually. Using global data like this highlights one of the ways that C++
can blow away Java's requirement that everything must be allocated on the
especially because computers don't have to click the relevent move with a
mouse. They just think it and its done. Make a computer go program move
the mouse and click like the human or make a computer go program physically
place the stone on the board and if a computer can win in speed go, i'll
as you
did.
Sincerely,
Nick
On 1/12/07, Don Dailey [EMAIL PROTECTED] wrote:
On Fri, 2007-01-12 at 15:43 -0600, Nick Apperson wrote:
yeah, there are upper limits placed on computation rate by
thermodynamics. 19x19 is way beyond those as Dave pointed out. But,
even if you believe
oops, accidentally sent to just Don Dailey
-- Forwarded message --
From: Nick Apperson [EMAIL PROTECTED]
Date: Jan 13, 2007 5:11 PM
Subject: Re: [computer-go] Can Go be solved???... PLEASE help!
To: [EMAIL PROTECTED]
Here is a link for anybody that is interested in why I say 2
yeah, there are upper limits placed on computation rate by thermodynamics.
19x19 is way beyond those as Dave pointed out. But, even if you believe
that technology will improve and the most revolutionary change yet will come
to understanding of physics and that change will give us signifigantly
could be highly fruitful and I have been exploring.
- Nick
On 1/12/07, Vlad Dumitrescu [EMAIL PROTECTED] wrote:
Hi,
On 1/12/07, Nick Apperson [EMAIL PROTECTED] wrote:
yeah, there are upper limits placed on computation rate by
thermodynamics.
19x19 is way beyond those as Dave pointed out
well, i'm pretty sure that against a top player i would need around 20
stones to have much of a shot, but if I remember correctly, at the
professional level, a 17-18 stone free placement is needed to take the
entire board. A 9 stone handicap is not nearly enough to take the whole
board no matter
The japanese rules have problems and there have been cases where 2
professionals argue about the outcome of a game. They are not clearly
defined for obscure cases. In addition, they are not simple. Ing rules and
chinese rules are both reasonable sets of rules because there is no room for
54 matches
Mail list logo
