Στις 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. 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.
/Fotis
------------------------------------------------------------------------------
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-d2dcopy1
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
