octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC2014] Looking for a mentor


From: Mogrob Sanit
Subject: Re: [GSoC2014] Looking for a mentor
Date: Thu, 13 Mar 2014 08:33:06 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 12/03/2014 20:13, Philip Nienhuis wrote:
> mfasi wrote
>> On 11/03/2014 22:40, Philip Nienhuis wrote:
>>> mfasi wrote
>>>> Hi all,
>>>>
>>>> I am a little bit sorry for spamming the maintainers list, but I was
>>>> suggested to do so on IRC - and I am in good company. As the subject
>>>> says,
>>>> I am looking for a mentor to apply for the Google Summer of Code 2014.
>>>> The
>>>> topic I am interested in is the implementation of some matrix functions
>>>> in
>>>> Octave (project 
>>> *
>>>> Improve logm, sqrtm, funm
>>> *
>>>> ), as I already have a little experience on the domain. Further
>>>> information on my 
>>>> public application draft <http://wiki.octave.org/User:Mfasi>  
>>>> . Thank you!
>>>
>>> Have you found a mentor yet?
>>> I regret I am too little proficient in linear algebra to help you out,
>>> although I wrote the existing funm.m in the OF linear-algebra package.
>>> While
>>> that works OK for my aims (relatively small (n < 100), well conditioned,
>>> positive semi-definite symmetric matrices) I'd love to see a more robust
>>> funm.m implementation. But be warned: as Higham wrote in his email to our
>>> maintainers list, writing a robust funm.m from scratch is no easy task.
>>>
>>> Just some remarks:
>>>
>>> As to logm(), AFAIK that one has already been optimized by "Tommy Guy"
>>> some
>>> years back, along the lines set out by Higham (IIRC Tommy Guy implemented
>>> some of Higham's methods). I am not aware of things left out (maybe
>>> complex?).
>>>
>>> As you can see in the OF linear-algebra package, some matrix functions
>>> (trig
>>> and hyperbolic) have been implemented, by invoking expm(), in the thfm.m
>>> function in that same package. funm.m delegates those trig and hyperbolic
>>> matrix functions to thfm.m. 
>>> It would be wise to keep that structure intact.
>> <snip>
>> Hi Philip,
>>
>> I have not found a mentor yet, and the fact that you are the only one
>> that has answered on that topic so far let me think you are the only one
>> that could be interested. Moreover, the fact of being the author of the
>> actual funm () makes you one of the most recommended people to mentor
>> this project. In conclusion, I hope you will change your mind about it.
>> :-D
> 
> Fist of all, my math skills do lag a bit behind on my programming skills,
> and there's no reason to boast about the latter either ;-)
> 
> Seriously, the only thing I can help you with is in coding itself. As to
> linear algebra we'd have to rely on the other specialists here.
> 
> 
>> Talking about serious stuff, I think you are absolutely right about the
>> behaviour of the current funm () function. The basic weakness, as far as
>> I can see, is that it uses a special case of the definition by means of
>> the Jordan decomposition, and I would expect it to be not accurate when
>> the eigenvectors are very ill-conditioned and to have sometimes a
>> non-predictable outcome when the Jordan blocks have size bigger than
>> one, as you pointed out in the source comments. Maybe it will be a
>> little slow for very big matrices, requiring the computation of the
>> diagonal decomposition, but I am not sure that this can be completely
>> eliminated. AFAIK, the best approach for general functions should be the
>> Schur-Parlett recurrence, that basically computes the matrix function on
>> the diagonal block of the Schur decomposition and then builds back the
>> matrix using Sylvester equations. It is robust in general but there are
>> some issues that have to be addressed to get a good implementations.
> 
> I expect that about any method with "Schur" in the name will be better than
> the straightforward diagonalization that funm-as-it-stands invokes :-)
> 
> Have you already looked at Higham's stuff? (it's GPL-ed and available on his
> web site).
> 
> 
>> On the other hand, according to the documentation, the logm () function
>> is implemented using some Padé approximants, so I guess it should work
>> for complex in general, but you are probably right when dealing with
>> branch points and branch cut. I will try to look at the logm () code to
>> shed some light on the question.
> 
> TommyGuy has put quite some effort in it.
> 
> Anyway, good luck,
> 
> Philip
> 
> 
> 
> --
> View this message in context: 
> http://octave.1599824.n4.nabble.com/GSoC2014-Looking-for-a-mentor-tp4662648p4663039.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
> 

Ok, I will not nag you more on the mentoring stuff, though I have not
found a mentor yet.

In his matrix function toolbox, Higham proposes two version of funm (),
one that uses diagonalization and one that works with a weak version of
the Schur-Parlett scheme. It is still quite simple to understand but
should suffer from some issues when the eigenvalues have multiplicity
greater than one or when they are very closed.

On the other hand, TommyGuy's implementation of the matrix logarithm is
indeed a not-so-naive one, and as far as I have understood uses the
scaling and squaring method. It seems also very robust, as I have tried
to get inaccurate results, but I have not been able to do so. :-)

Best,
Massimiliano


reply via email to

[Prev in Thread] Current Thread [Next in Thread]