Are you sure that the current (serial, non-parallel) version of your code is well optimized?

Given (only) that overview of the problem I might guess that Grid would be easier, provided that you have enough memory to hold the multiple full instances of the whole problem instantiated at various parameter value sets. That would also alleviate your having to ensure that your code is Thread-safe.

But you might consider uploading your code here (green arrow in the editor). We have a little experience with optimizing code, though of course there are no promises. Feel free to contact me, if you'd prefer to not post your code publicly.

acer

@alex_01 I think that if you are having trouble understanding how to formulate an NLPSolve problem in Matrix-form then it would be better if you asked in a separate question (giving a full example that explains exactly what you are trying to do).

That way, the two threads remain clear to all late-comers.

@alex_01 I think that if you are having trouble understanding how to formulate an NLPSolve problem in Matrix-form then it would be better if you asked in a separate question (giving a full example that explains exactly what you are trying to do).

That way, the two threads remain clear to all late-comers.

@Joe Riel For this particular problematic file, the two characters are in stranges places. Doesn't one appear between otherwise conjoined numerals 2 and a 4, in a text section?

I think that the GUI should be able 1) to remove such when pasting, 2) not save with such, and 3) remove such when re-opening. Right now it seems to just halt all further reading/parsing and give up, when re-opening, which is weak.

@Joe Riel For this particular problematic file, the two characters are in stranges places. Doesn't one appear between otherwise conjoined numerals 2 and a 4, in a text section?

I think that the GUI should be able 1) to remove such when pasting, 2) not save with such, and 3) remove such when re-opening. Right now it seems to just halt all further reading/parsing and give up, when re-opening, which is weak.

It's disturbing how often instances of this problem get reported here. I count 4 or 5 times in the past couple of months. Which raises the question of how often it occurs and is not reported here.

I wonder how it occurs, whether the cause is preventable and, if not, why the GUI itself cannot accomplish a repair more reliably.

acer

It's disturbing how often instances of this problem get reported here. I count 4 or 5 times in the past couple of months. Which raises the question of how often it occurs and is not reported here.

I wonder how it occurs, whether the cause is preventable and, if not, why the GUI itself cannot accomplish a repair more reliably.

acer

@alex_01 In order for the debugger to be invoked when LPSolve gets called all one needs to do is,

stopat(Optimization:-LPSolve);

and then call Optimization:-LPSolve on some example.

@alex_01 In order for the debugger to be invoked when LPSolve gets called all one needs to do is,

stopat(Optimization:-LPSolve);

and then call Optimization:-LPSolve on some example.

@alex_01 You are very welcome, though you are giving me too much credit. All I did was run the first example of ?LPSolve under the debugger, and walked through until it came to the routine that did the conversion.

What you might find most interesting is that your R and ER appear "as is" inside `A` the Matrix of inequalities. You can also see this visually, if you set N=3 and print `A`. So it may illustrate the principal -- in Matrix form, there are just numeric coefficients, and no variables appearing explicitly by (symbolic) name.

@alex_01 You are very welcome, though you are giving me too much credit. All I did was run the first example of ?LPSolve under the debugger, and walked through until it came to the routine that did the conversion.

What you might find most interesting is that your R and ER appear "as is" inside `A` the Matrix of inequalities. You can also see this visually, if you set N=3 and print `A`. So it may illustrate the principal -- in Matrix form, there are just numeric coefficients, and no variables appearing explicitly by (symbolic) name.

If memory is a concern then in the non-inline case your code doesn't need to create all the A[i] up front, does it? Couldn't it form and export them one at a time, to limit the total allocation necessary at any given time?

Also, if you're just rotating, why not try this for efficiency,

  - copy orig plot's data to temp Array

  - rotate temp Array data, inplace

  - wash, rinse, repeat

see here for code to rotate temp Array inplace (maybe, forget if you have MESH or GRID).

acer

If memory is a concern then in the non-inline case your code doesn't need to create all the A[i] up front, does it? Couldn't it form and export them one at a time, to limit the total allocation necessary at any given time?

Also, if you're just rotating, why not try this for efficiency,

  - copy orig plot's data to temp Array

  - rotate temp Array data, inplace

  - wash, rinse, repeat

see here for code to rotate temp Array inplace (maybe, forget if you have MESH or GRID).

acer

@PatrickT There is an old Maple joke, that it would be much easier to get better numerics out of Maple if only they were to remove all the symbolics.

There is also another joke, which goes similarly but with the words symbolics and numerics exchanged.

@PatrickT There is an old Maple joke, that it would be much easier to get better numerics out of Maple if only they were to remove all the symbolics.

There is also another joke, which goes similarly but with the words symbolics and numerics exchanged.