Skip to content

hat matrix in gwr

3 messages · Eda Laze, Myers, Joshua, Roger Bivand

Original
Myers, Joshua
# 
freeze, although it may take a while to complete the run.  

A few thoughts:

I would make sure you are running the most up-to-date version of spgwr
(and dependent packages) and R.  

Also, I am not an R expert, but it may be that storing the hat matrix is
taking up a lot of memory and causing R to freeze.  It is a long-shot,
but start a clean workspace and try the gwr run again.  Roger, though,
is the one that is more likely to know what is wrong than anyone else.

In addition, make sure you aren't over-fitting your models.  Too many
variables in gwr can cause many problems, not the least of which is the
time it takes to complete the run.


-----Original Message-----
From: r-sig-geo-bounces at stat.math.ethz.ch
[mailto:r-sig-geo-bounces at stat.math.ethz.ch] On Behalf Of Eda Laze
Sent: Thursday, November 05, 2009 8:27 AM
To: r-sig-geo at stat.math.ethz.ch
Subject: [R-sig-Geo] hat matrix in gwr

Hello,

I am currently using *gwr to make a spatial analysis. Dataset has 3055
observations. As read, this is a considerable number for gwr R to run.
 However, so far, I have suceeded to get local R2 (SDF), etc.

The problem is to get "hatmatrix". When I add "hatmatrix=TRUE" to the
code
(which I get localR2 with), R freezes. I must get hat matrix to
calculate
Moran'I and AICc to compare models.

Could be this a case of large number of observations, or do I miss
anything
else. Furthermore, I could get once AICc with the same dataset and code,
but
not anylonger.

Any feedback is more than welcome. Thank you.


_______________________________________________
R-sig-Geo mailing list
R-sig-Geo at stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
#
On Thu, 5 Nov 2009, Eda Laze wrote:

            

      
      
      
    

        
Without more information, feedback will not be forthcoming. You should 
provide your sessionInfo() with package version and platform details, 
and the package version of what you claim worked "before". If you inspect 
the CVS source by browsing on sourceforge:

http://r-spatial.cvs.sourceforge.net/viewvc/r-spatial/spgwr/

or the ChangeLog on:

http://cran.r-project.org/web/packages/spgwr/ChangeLog

you will see that a number of changes were made in June this year to bring 
gwr() more into line with GWR3 and the forthcoming GWR4. Since then, if 
hatmatrix=TRUE, a number of extra steps followed, but the computation of 
the hatmatrix was unchanged.

You have not included your verbatim code either, so it is possible that 
you are mistaken if the arguments are not named, and have changed order 
between releases.

You may also find that you should not be using all of your data to fit the 
GWR model with hat matrix, a sample may be sufficient.

You may consider avoiding using GWR in any case, as its appropriateness is 
questionable given many results on forcing problems in coefficient 
estimates (the local coefficients are highly correlated, magnifying any 
collinearity problems in the input data.

Finally, R does not "freeze", what may happen is that your computer starts 
using virtual memory (a temporary disk area) and runs very slowly - 
depending on OS, this may vary. When hatmatrix=TRUE, operations on nxn 
matrices are carried out, so you do need to provide the necessary 
resources and on Windows try to set memory resources to make best use of 
what you have. If you really need a hatmatrix with a 3K by 3K size, get 
more RAM or a different OS, it isn't a good idea, and all bets are off 
test results anyway (for collinear GWR output).

So, run without hatmatrix and check the correlation of the local 
coefficients with cor() and pairs() first.

Hope this helps,

Roger

            

      
      
      
    

        
And *do* follow the R posting guide and send messages "text only", you 
should change the settings of your email client. There are many offenders 
here. There are two reasons for "test only" - HTML mail is harder to scan 
for spam (hence the deletion), and HTML mail is much larger in size, so 
increasing the burden on server capacity, that is, the CO2 footprint of 
this list.