       Re: optimization

• To: mathgroup at smc.vnet.net
• Subject: [mg96534] Re: [mg96523] optimization
• From: Bob Hanlon <hanlonr at cox.net>
• Date: Mon, 16 Feb 2009 06:54:12 -0500 (EST)

```A simplification

u = Array[a, {3, 2}];

MapThread[Equal, {Map[Apply[Plus, #] &, u], Table[1, {Length[u]}]}] ==

True

Another simplification

largo = Flatten[u];

True

Fix error

{a(1,1)>0,a(1,2)>0,a(2,1)>0,a(2,2)>0,a(3,1)>0,a(3,2)>0}

Note that the semi-colon suppresses all of the first expression (i.e., the constraints that the rows sum to 1). You intended

Nested tables can be written as a single Table

Table[Table[a[k, i], {k, 1, 5}], {i, 1, 3}] ==
Table[a[k, i], {i, 3}, {k, 5}]

True

You don't need to Flatten prior to using Total

Total[Flatten[u]] == Total[u, 2]

True

You have a circular definition for u (u defined in terms of u)

paso2[individuo_, centro_, m_] := Module[
{largo, a, u},
u = Array[a, {Length[individuo], Length[centro]}];
largo = Flatten[u];
NMinimize[{Total[
Table[
EuclideanDistance[individuo[[k]], centro[[i]]]*u[[k, i]]^m,
{i, Length[centro]}, {k, Length[individuo]}], 2],

Bob Hanlon

---- Francisco Gutierrez <fgutiers2002 at yahoo.com> wrote:

=============
Dear Friends:I have the following optimization function:
in Mathematica 7.
However, this function is obviously not capturing the restriction that u[i,j]+u[i,k]==1For example, u[1,1]+u[1,2] should sum up to 1this restriction corresponding to the following piece of code: Flatten[MapThread[Equal,{Map[Apply[Plus,#]&,u],Table[1,{Length[u]}]}]
How can I solve this?In general, what I am doing wrong so as to not repeat the error?ThanksFrancisco Guti=E9rrez

--- On Thu, 2/12/09, Albert Retey <awnl at gmx-topmail.de> wrote:

From: Albert Retey <awnl at gmx-topmail.de>
Subject: [mg96534] [mg96523] [mg96389] Re: Reposted, Reformatted Re: "mapping" functions over l=
ists, again!
To: mathgroup at smc.vnet.net
Date: Thursday, February 12, 2009, 6:42 AM

Hi,

> This is a repost of an earlier post, as there were problems with the emai=
l
> formatting for some people. I have composed this one in Notepad, and cut =
and
> pasted to Outlook. Hope it works better.

it does work better :-)

> This is a list of lists, the lowest level lists containing pairs of {real=
,
> complex}. The individual lists are not all the same length, and the total
> number of lists can vary, and I need to preserve the list structure.
>
> So I think the most succinct way of expressing my problem is, what form d=
oes
> fxn take if I want to Map it across my lists of {real,complex} so that it
> returns {fxn1[real],fxn2[complex]} or even {real,fxn[complex]}?

If I understand correctly what you try to achieve I think the easiest
solution will be to use replacement only, it will preserve the structure
and can be set up to handle the pairs as you want. Basically I see two
approaches, which also can be combined. The first one looks simpler, but
only works if the structure of your data doesn't change (the sizes of
the list of list can of course be arbitrary):

Replace[shortTestdata, {r_, c_} :> {f1[r], f2[c]}, {2}]

the trick is to restrict the replacement to the correct level. If you
are working with data where the level at which the pairs appear can be
arbitrary, you can pick the parts to be treated with a more elaborated
rule, like this:

shortTestdata /. {r_ /; Element[r, Reals],c_ /; Element[c, Complexes]}:>
{f1[r], f2[c]}

(/. is short for ReplaceAll). This version should work with arbitrary
structured lists of arbitrary depths. I think using the Element-Function
to decide what kind of number you are looking at is in your case closer
to what you want to achieve than to look at the Head, which has some
implications, as you have learned from other posts.

Finally you could combine the two approaches:

Replace[shortTestdata, {r_ /; Element[r, Reals],c_ /; Element[c,
Complexes]}:> {f1[r], f2[c]}, {2}]

this could make sense if you have a well structured list, but the pairs
could be either of the form {reals,reals}, {real,complex},
{complex,complex} and you want to treat these cases differently.

You should be aware that other approaches might be faster, but these
will for sure be more elaborate and error prone than the code above.

hth,

albert

```

• Prev by Date: Re: Shortest Path Problem
• Next by Date: Stirling 1st problem in Infinite sums