I think what your asking is if anyone knows how to apply the
transformation matrix that was used to derive you pca components in
reverse to get back to the original coordinate system. Something like
what is done in a decorrelation stretch?
Hopefully someone more knowledgeable than I can elaborate, but the
general idea is as follows;
if the i.pca is capable of divulging the eigenvectors, you can use
r.mapcalc to apply them in reverse. else;
r.covar -> m.eigensystem -> mapcalc -> "do something with your
principal components" -> mapcalc (inverse rotation) -> "original
coordinate system"
You can take a look at the bottom of the r.covar page for more info.
The big "if" is on the status of m.eigensystem. I tried the link to
the manual page and it is broken so I'm unsure of it's status.
m.eigensystem has not been ported from GRASS 5 to GRASS 6.
It is available from the GRASS 5 source code:
grass-5.4.0/src.contrib/CERL/misc/m.eigensystem/
While it is written in Fortan77 I see no reason why it couldn't be
compiled with g77 or gfortran and run with modern versions of GRASS.
The GRASS raster/imagery engines and file formats have not changed since
GRASS 5 so there shouldn't be many problems.
On Thursday 24 January 2008, Markus Neteler wrote:
HamishB wrote:
> Michael Perdue wrote:
>> I think what your asking is if anyone knows how to apply the
>> transformation matrix that was used to derive you pca components in
>> reverse to get back to the original coordinate system. Something like
>> what is done in a decorrelation stretch?
>> Hopefully someone more knowledgeable than I can elaborate, but the
>> general idea is as follows;
>>
>> if the i.pca is capable of divulging the eigenvectors, you can use
>> r.mapcalc to apply them in reverse. else;
>>
>> r.covar -> m.eigensystem -> mapcalc -> "do something with your
>> principal components" -> mapcalc (inverse rotation) -> "original
>> coordinate system"
>>
>> You can take a look at the bottom of the r.covar page for more info.
>> The big "if" is on the status of m.eigensystem. I tried the link to
>> the manual page and it is broken so I'm unsure of it's status.
>
> m.eigensystem has not been ported from GRASS 5 to GRASS 6.
>
> It is available from the GRASS 5 source code:
> grass-5.4.0/src.contrib/CERL/misc/m.eigensystem/
>
> online:
>
> http://freegis.org/cgi-bin/viewcvs.cgi/grass/src.contrib/CERL/misc/m.eige
>nsystem/
>
>
> While it is written in Fortan77 I see no reason why it couldn't be
> compiled with g77 or gfortran and run with modern versions of GRASS.
> The GRASS raster/imagery engines and file formats have not changed since
> GRASS 5 so there shouldn't be many problems.
>
> FWIW ./configure still checks for f2c.h
On Thursday 24 January 2008, Markus Neteler wrote:
On Jan 24, 2008 7:25 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> On Thursday 24 January 2008, Markus Neteler wrote:
> > I have added m.eigensystem to GRASS Addons SVN with a slightly
> > updated Makefile. Grab here:
> > http://trac.osgeo.org/grass/browser/grass-addons/m.eigensystem
> >
> > or from SVN
> > http://trac.osgeo.org/grass/wiki/DownloadSource
> > -> Subversion GRASS Addons source code repository
> >
> > Markus
>
> Nice. Is this scheduled to be included as a standard module, or is that
> pending some user tests?
I could still reproduce the manual page examples
The question is if we want to introduce Fortran code again in the
main repository.
Markus
Good that the examples still work. Is there a general feeling toward _not_
introducing Fortran code back into the dev branch?
On Thu, 2008-01-24 at 14:58 -0800, Dylan Beaudette wrote:
On Thursday 24 January 2008, Markus Neteler wrote:
> On Jan 24, 2008 7:25 PM, Dylan Beaudette <dylan.beaudette@gmail.com> wrote:
> > On Thursday 24 January 2008, Markus Neteler wrote:
> > > I have added m.eigensystem to GRASS Addons SVN with a slightly
> > > updated Makefile. Grab here:
> > > http://trac.osgeo.org/grass/browser/grass-addons/m.eigensystem
> > >
> > > or from SVN
> > > http://trac.osgeo.org/grass/wiki/DownloadSource
> > > -> Subversion GRASS Addons source code repository
> > >
> > > Markus
> >
> > Nice. Is this scheduled to be included as a standard module, or is that
> > pending some user tests?
>
> I could still reproduce the manual page examples
>
> The question is if we want to introduce Fortran code again in the
> main repository.
>
> Markus
Good that the examples still work. Is there a general feeling toward _not_
introducing Fortran code back into the dev branch?
+1. More trouble that it's worth. Please add C port to the TODO list.
On Thu, 2008-01-24 at 14:58 -0800, Dylan Beaudette wrote:
> On Thursday 24 January 2008, Markus Neteler wrote:
> > On Jan 24, 2008 7:25 PM, Dylan Beaudette <dylan.beaudette@gmail.com>
wrote:
> > > On Thursday 24 January 2008, Markus Neteler wrote:
> > > > I have added m.eigensystem to GRASS Addons SVN with a slightly
> > > > updated Makefile. Grab here:
> > > > http://trac.osgeo.org/grass/browser/grass-addons/m.eigensystem
> > > >
> > > > or from SVN
> > > > http://trac.osgeo.org/grass/wiki/DownloadSource
> > > > -> Subversion GRASS Addons source code repository
> > > >
> > > > Markus
> > >
> > > Nice. Is this scheduled to be included as a standard module, or is
> > > that pending some user tests?
> >
> > I could still reproduce the manual page examples
> >
> > The question is if we want to introduce Fortran code again in the
> > main repository.
> >
> > Markus
>
> Good that the examples still work. Is there a general feeling toward
> _not_ introducing Fortran code back into the dev branch?
+1. More trouble that it's worth. Please add C port to the TODO list.
Hmm..
While I agree in principle that having code from more than 1 lang can be a
pain to manage, I do like the approach used in R where numerous langs are
supported.
Since I cannot do the re-write, and the functionality seems worth the effort I
would vote 0 .
Getting someone familiar with what the Fortran code is actually doing would be
important if we considered re-writing it...
Am Donnerstag, den 24.01.2008, 17:23 -0800 schrieb Dylan Beaudette:
On Thursday 24 January 2008, Brad Douglas wrote:
> On Thu, 2008-01-24 at 14:58 -0800, Dylan Beaudette wrote:
> > On Thursday 24 January 2008, Markus Neteler wrote:
> > > On Jan 24, 2008 7:25 PM, Dylan Beaudette <dylan.beaudette@gmail.com>
wrote:
> > > > On Thursday 24 January 2008, Markus Neteler wrote:
> > > > > I have added m.eigensystem to GRASS Addons SVN with a slightly
> > > > > updated Makefile. Grab here:
> > > > > http://trac.osgeo.org/grass/browser/grass-addons/m.eigensystem
> > > > >
> > > > > or from SVN
> > > > > http://trac.osgeo.org/grass/wiki/DownloadSource
> > > > > -> Subversion GRASS Addons source code repository
> > > > >
> > > > > Markus
> > > >
> > > > Nice. Is this scheduled to be included as a standard module, or is
> > > > that pending some user tests?
> > >
> > > I could still reproduce the manual page examples
> > >
> > > The question is if we want to introduce Fortran code again in the
> > > main repository.
> > >
> > > Markus
> >
> > Good that the examples still work. Is there a general feeling toward
> > _not_ introducing Fortran code back into the dev branch?
>
> +1. More trouble that it's worth. Please add C port to the TODO list.
Hmm..
While I agree in principle that having code from more than 1 lang can be a
pain to manage, I do like the approach used in R where numerous langs are
supported.
Just a comment, I have in my mind for years now:
introducing FORTRAN again would be great benefit to GRASS (really never
understood why it was excluded), since fortran90 is a very common (and
easy) language in geo sciences! Some things are really a pain in c.
gfortran is available and is perfectly working together with gcc (other
compiler collections also have a fortran compiler working together with
c). Especially the modular architecture of GRASS should it make possible
to avoid compiling problems, isn't it?
Andreas
Since I cannot do the re-write, and the functionality seems worth the effort I
would vote 0 .
Getting someone familiar with what the Fortran code is actually doing would be
important if we considered re-writing it...
The question is if we want to introduce Fortran code again in the
main repository.
are the results of f2c human-readable? Or for conversion to C would it
need a rewrite by hand?
I've never found f2c results very useful to create "real" C code. If you want its results to remotely look like standard GRASS code, you would have to rework the results so much that you could have written the code directly from scratch.
Then again, my f2c trials date from a long time ago...
