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ë
------------------------------------------------------------------------------
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
