Despite the new error messages you mention, I believe that one of those approaches will still be needed.

The "procedure form" of Maximize is somewhat prone to doing that (Test-1) especially if a procedure to compute the objective gradient (and constraint jacobian, if constraint procs are supplied) is not explicitly supplied. A "known" bug.

As for your Test-2 and Test-3 attempts, it might be nice to have your .xls data, to figure out what went wrong. (Could it be that that `ln` call is producing a non-real?)

acer

Try with `cos`, since there is no `cosine`.

acer

Try with `cos`, since there is no `cosine`.

acer

I realized that was your line of thinking, when I posted. And that is why I mentioned the 'parameters' option. Have a look at it. It might help you pull out the dsolve call (which is heavy machinery), and allow you to specify the w1_1, w1_2, and w1_3 as parameters. At the very least, you can pull out the diff calls.

acer

Why are those (unchanging) diff calls inside the loop? They don't need to be done 70000 times, right? Not the main culprit, perhaps, but it's often good to look at such aspects.

Do you really need Digits=16, which is just one digit of working precision above the cuttof between fast double-precision and slower "software" precision.

Can you replace that Normalize call with something that acts in-place? (Either a Compiler:-Compile'd in-place proc of your own, or exisiting call to Norm and a call to VectorScalarMultiply with its inplace option, etc).

Does the dsolve,numeric call really need to be inside the loop, or could it too be called just once up front with its new 'parameters' option to handle the changing w1? See the ?dsolve,numeric,IVP help-page.

That's all presupposing that you don't want to change the basic approach.

acer

Yes, VerifyTools can be useful.

It's a pity that some packages which can sometimes be useful (such as VerifyTools, EqualEntries, PiecewiseTools, etc) are undocumented.

I should submit an SCR that VerifyTools is not protected (and then put on the list of undocumented protected names).

acer

Yes, VerifyTools can be useful.

It's a pity that some packages which can sometimes be useful (such as VerifyTools, EqualEntries, PiecewiseTools, etc) are undocumented.

I should submit an SCR that VerifyTools is not protected (and then put on the list of undocumented protected names).

acer

Round-brackets also provide for some distinct aspects of rtable selection/subindexing.

While it's unfortunate that some help-pages themselves inadequately cover the functionality of their topic commands, it can be more unfortunate if relevant help-pages are missing adequate cross-referencing or are too hard to find.

For example, there should be better cross-referencing from ?Matrix, ?Vector, and ?rtable to ?selection and ?rtable_indexing. I will submit an SCR for that.

acer

Round-brackets also provide for some distinct aspects of rtable selection/subindexing.

While it's unfortunate that some help-pages themselves inadequately cover the functionality of their topic commands, it can be more unfortunate if relevant help-pages are missing adequate cross-referencing or are too hard to find.

For example, there should be better cross-referencing from ?Matrix, ?Vector, and ?rtable to ?selection and ?rtable_indexing. I will submit an SCR for that.

acer

1) vertical bars around a name don't act as quotes.

2) See the help-page on concatenation.

3) Read the manuals, in general.

As for this other thread,

4) For an lowercase array (or table) use evalm to see its contents. See the last_name_eval help-page.

5) Use Array instead of array, since the latter is deprecated.

acer

1) vertical bars around a name don't act as quotes.

2) See the help-page on concatenation.

3) Read the manuals, in general.

As for this other thread,

4) For an lowercase array (or table) use evalm to see its contents. See the last_name_eval help-page.

5) Use Array instead of array, since the latter is deprecated.

acer

And yet it seems a safe bet that you have gotten there by luck and exhaustive search. True understanding will serve you better in the long run. Hence I suggest a good read of the relevant manual pages.

Note that in your code fragment, the last || and `` don't accomplish much of anything; they just append `` (empty name) to the end.

> for i from 1 to 3 do
>   i, `a_`||i
> end do;
                                    1, a_1
 
                                    2, a_2
 
                                    3, a_3

acer

And yet it seems a safe bet that you have gotten there by luck and exhaustive search. True understanding will serve you better in the long run. Hence I suggest a good read of the relevant manual pages.

Note that in your code fragment, the last || and `` don't accomplish much of anything; they just append `` (empty name) to the end.

> for i from 1 to 3 do
>   i, `a_`||i
> end do;
                                    1, a_1
 
                                    2, a_2
 
                                    3, a_3

acer

It's often better to ask separate (entirely more general) questions in a new thread. That way both topics and their answers are less confusing.

Exporting as a Maplet does nothing except save the code to a file with extension .maplet. It won't actually be a Maplet, or ever cause a Maplet to be run, unless the code you first write uses the routines in the Maplets package.

acer

It's often better to ask separate (entirely more general) questions in a new thread. That way both topics and their answers are less confusing.

Exporting as a Maplet does nothing except save the code to a file with extension .maplet. It won't actually be a Maplet, or ever cause a Maplet to be run, unless the code you first write uses the routines in the Maplets package.

acer