[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] gradient improvement
From: |
Kai Antweiler |
Subject: |
Re: [glob2-devel] gradient improvement |
Date: |
Mon, 17 Apr 2006 23:05:52 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Jumbo Shrimp, linux) |
> If we want to rely on the fact that listedAddr is ordered for further
> optimization, we have to fork the cases. One who can call the optimized one,
> and
> one who can only call the less-optimized one. This would be smart actually.
I need this forking.
I have just implemented a new gradient algorithm and got a interesting
situation. It's getting good results - unless I use AICastor, in this
case it uses so much cpu that I can't even close glob2.
It's in current Map.cpp, if you want to see it yourself.
Put in "#define KAI" to test it.
I don't know why this happens, it should not.
Actually it cannot. In the worst, case there are only a few conditionals
more than in the simple version.
But it does happen.
--
Kai Antweiler
- Re: [glob2-devel] gradient improvement, (continued)
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/04
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/04
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/05
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/06
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/06
- Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/07
- Re: [glob2-devel] gradient improvement, Simon Schuler, 2006/04/05
- Re: [glob2-devel] gradient improvement,
Kai Antweiler <=
- Message not available
- Message not available
- Re: [glob2-devel] gradient improvement, Nuage, 2006/04/20
Re: [glob2-devel] gradient improvement, Kai Antweiler, 2006/04/09