2011/10/10 Carnë Draug <carandraug+...@gmail.com>:
> On 4 October 2011 14:52, Olaf Till <olaf.t...@uni-jena.de> wrote:
>> On Tue, Oct 04, 2011 at 03:01:08PM +0300, Fotios wrote:
>>> Στις 2011-10-04 14:31, ο/η Olaf Till έγραψε:
>>> >On Tue, Oct 04, 2011 at 01:18:11AM +0100, Carnë Draug wrote:
>>> >>On 4 October 2011 00:48, Fotios<fotios.kaso...@gmail.com> wrote:
>>> >>>Here is the deriv function with an added demo and minor correction.
>>> >>>
>>> >>>/Fotios
>>> >>This was supposed to be sent to the octave-forge. After talking to
>>> >>Fotios #octave, this function was renamed jacobs (there's already a
>>> >>deriv function) and added to the optim package.
>>> >>
>>> >>Carnë
>>> >I think such a function is really useful for the optim package, even
>>> >if it is intended to be used elsewhere. But in the current form, the
>>> >usefulness seems to be limited by the restriction that the passed
>>> >function 'f' is expected to compute exactly as many elements as there
>>> >are parameters. In most standard optimizations we either deal with
>>> >gradients of a scalar valued 'objective function' or with Jacobians of
>>> >a model function which usually returns more elements than there are
>>> >parameters. So I suggest that this restriction should be removed.
>>> >
>>> >If the above should be agreed, there are some minor issues, some of
>>> >them 'cosmetic':
>>> >
>>> >1. Since I currently try to standardize the interface to some of the
>>> >optimization function, could we change the order of argumets to
>>> >
>>> >'jacobs (x, f, ...)'
>>> >
>>> >?
>>> >
>>> >2. I think the "jacobs: ..." in the error messages is not necessary,
>>> >since the m-file in which the error originates is reported by Octave.
>>> >
>>> >3.
>>> >
>>> > if (abs (h)>= 1e-2)
>>> > warning ("jacobs: H is too big and the result should not be trusted");
>>> > endif
>>> >
>>> >How do you come to this value (1e-2) ? If there is a reason, there
>>> >should be probably a comment there explaining it.
>>> >
>>> >4. For the same reason as in 1., and for interfacing with some
>>> >optimization functions, can we
>>> >
>>> >- make the third argument a structure with a field 'h',
>>> >
>>> >- accept a further field 'fixed': a logical vector indicating for
>>> > which elements of 'x' no gradients are to be computed, but zero is
>>> > returned instead?
>>> >
>>> >
>>> >If there should be agreement about the main issue (dimension of 'f'),
>>> >I could suggest a patch for all the above, if you want me to.
>>> >
>>> >Olaf
>>>
>>> I absolutely agree with your general comment regarding optimization
>>> since the design variables are typically more than the objective
>>> functions - keep in mind though that i have not tried the function
>>> for mid-scale optimization problems and that i would argue about how
>>> useful it could be in that case.
>>
>> Well, some of the optimization functions use some routine for finite
>> differencing, so using 'jacobs.m' instead has the potential to be
>> better. But I agree that the used objective or model functions would
>> have to be suitably programmed for this. May be it would be useful for
>> that if someone wrote a class for overloading "<", ">", "<=", ">=",
>> "max", "min" and maybe others ...
>>
>> Anyway I have made a respective change, allowing arbitrary
>> dimensionness for 'f', as you can see in the patch.
>>
>>> Regarding the interfacing comments
>>> you can apply all of your suggestions. There is no good reason for
>>> the 1e-2 warning since it always depends both on h and on the value
>>> of the 3rd derivative, BUT since log(|Df(h)-exact|) depends linearly
>>> on log(h) i though i had to prevent naive users from increasing h or
>>> at least warn them about the accuracy of the approximation (it is
>>> just a sloppy educational guess - after some testing - coded there
>>> with students in mind that can be removed as well). I could even
>>> suggest removing the user control over the step size h (demo needs
>>> to be removed) since this approach costs more (with respect to
>>> memory) compared to fd and the only gain from using it comes from
>>> the fact that you can get eps exact derivatives.
>>
>> So I just changed the warning text to 'not allowed', sinces as you say
>> one cannot be sure that it is really 'too big'. Consequently, larger
>> values are reduced to the maximum value (1e-3 instead of 1e-2, to be
>> able to use ">" instead of ">=").
>>
>>>
>>> /Fotis
>>
>> I attach the patch, but as it is not very readable, also the new
>> version of the function.
>>
>> All tests still pass and the demo works (after a slight change).
>>
>> Do you think I can submit it so?
>
> Hi Fotos
>
> just bringing this up again as the upgrade made by Olaf has not been
> comitted yet.
>
> Carnë
>
I just made this commit so it doesn't get lost.
Carnë
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
