@Jimmy I didn't notice before, that you had too many variables in your call, sorry.

Is idata suppose to be the dependent data, and V the independent data? If so, then what is `i`?

It's clear that `v` is an independent variable. But either `i` is some other parameter of the formula, or else your original formula was something implicit like i=f(v,i,i0,rs,n) and `i` is supposed to be your dependent variable. Is either of those your situation?

Also, your range for i0 goes from larger value to smaller value, and you'd want to fix that or else it would complain. And you could pass an extra (4th) argument to specify the variables, in this case the [v] say.

@Jimmy I didn't notice before, that you had too many variables in your call, sorry.

Is idata suppose to be the dependent data, and V the independent data? If so, then what is `i`?

It's clear that `v` is an independent variable. But either `i` is some other parameter of the formula, or else your original formula was something implicit like i=f(v,i,i0,rs,n) and `i` is supposed to be your dependent variable. Is either of those your situation?

Also, your range for i0 goes from larger value to smaller value, and you'd want to fix that or else it would complain. And you could pass an extra (4th) argument to specify the variables, in this case the [v] say.

@Jimmy Be careful and keep in mind why the change.

The key is that the first argument to NonlinearFit should be a formula, and the variables names in it should not be assigned (in particular, should not be assigned any Vector as value).

Next, the names which are assigned Vectors are the ones to use in the later 2nd and 3rd arguments to NonlinearFit.

So, if V and idata are the Vectors of data then the call to NonlinearFit might look something like,

NonlinearFit( i0*exp(1000*(v-i*rs))/(25.9*n)-1,
              V, idata, parameterranges = [i0 = 10^(-6) .. 10^(-8),
              rs = 1 .. 500, n = 1 .. 5],
              output = [residualsumofsquares, 
                        leastsquaresfunction]);

So, above the 1st argument (formula) has unassigned names `v` and `i` for the variables, and the 2nd and 3rd arguments are `V` and `idata` which are your data Vectors.

I think you'll find that your earlier attempts has some of that mixed up.

Make sure that you either restart after your earlier attempt, or unassign 'v' and 'i', or else you'll just have the same problem with Maple trying to stuff the Vectors into the formula (which is where your error came from).

nb. You can't easily assign to `I`, so I used `idata` instead.

@Jimmy Be careful and keep in mind why the change.

The key is that the first argument to NonlinearFit should be a formula, and the variables names in it should not be assigned (in particular, should not be assigned any Vector as value).

Next, the names which are assigned Vectors are the ones to use in the later 2nd and 3rd arguments to NonlinearFit.

So, if V and idata are the Vectors of data then the call to NonlinearFit might look something like,

NonlinearFit( i0*exp(1000*(v-i*rs))/(25.9*n)-1,
              V, idata, parameterranges = [i0 = 10^(-6) .. 10^(-8),
              rs = 1 .. 500, n = 1 .. 5],
              output = [residualsumofsquares, 
                        leastsquaresfunction]);

So, above the 1st argument (formula) has unassigned names `v` and `i` for the variables, and the 2nd and 3rd arguments are `V` and `idata` which are your data Vectors.

I think you'll find that your earlier attempts has some of that mixed up.

Make sure that you either restart after your earlier attempt, or unassign 'v' and 'i', or else you'll just have the same problem with Maple trying to stuff the Vectors into the formula (which is where your error came from).

nb. You can't easily assign to `I`, so I used `idata` instead.

Yes, that's what is meant by mutable in this context: that the value of an entry can be changed inplace, without a whole new structure being created.

The problem with faking mutability of lists is that code which alters entries many times (or code which does it, and which itself is intended on being called many times) will cause Maple to spend a great deal of resources doing unnecessary memory management. And that can wreck efficiency and the ability of the code to scale as well.

Maple fakes `list` mutability like this:

restart:

L:=[a,b,c,d,e];

                        [a, b, c, d, e]

addressof(L);

                           449181536

L[3]:=Q:

L;

                        [a, b, Q, d, e]

addressof(L); # ahah, it is not the same list!

                           449181776

One could also fake that by crude modification and reassignment to the same name,

restart:

L:=[a,b,c,d,e];

                        [a, b, c, d, e]

L:=subsop(3=Q,L);

                        [a, b, Q, d, e]

There is even a cut-off size for the mechanism.

restart:

L:=[seq(i,i=1..100)]:

L[3]:=Q:

L:=[seq(i,i=1..101)]:

L[3]:=Q:
Error, assigning to a long list, please use Arrays

But of course one can find texts and advice to just use something like the subsop trick, when the length is greater than 100. As if that were a good idea. Which it isn't. Just as allowing it for lengths less than 100 wasn't a terribly good idea either.

So, if you have to change the values of entries many times (or a few times in code which you expect to re-use many times) then you would probably be better off using a mutable structure such as a Vector/Matrix/Array.

acer

Yes, that's what is meant by mutable in this context: that the value of an entry can be changed inplace, without a whole new structure being created.

The problem with faking mutability of lists is that code which alters entries many times (or code which does it, and which itself is intended on being called many times) will cause Maple to spend a great deal of resources doing unnecessary memory management. And that can wreck efficiency and the ability of the code to scale as well.

Maple fakes `list` mutability like this:

restart:

L:=[a,b,c,d,e];

                        [a, b, c, d, e]

addressof(L);

                           449181536

L[3]:=Q:

L;

                        [a, b, Q, d, e]

addressof(L); # ahah, it is not the same list!

                           449181776

One could also fake that by crude modification and reassignment to the same name,

restart:

L:=[a,b,c,d,e];

                        [a, b, c, d, e]

L:=subsop(3=Q,L);

                        [a, b, Q, d, e]

There is even a cut-off size for the mechanism.

restart:

L:=[seq(i,i=1..100)]:

L[3]:=Q:

L:=[seq(i,i=1..101)]:

L[3]:=Q:
Error, assigning to a long list, please use Arrays

But of course one can find texts and advice to just use something like the subsop trick, when the length is greater than 100. As if that were a good idea. Which it isn't. Just as allowing it for lengths less than 100 wasn't a terribly good idea either.

So, if you have to change the values of entries many times (or a few times in code which you expect to re-use many times) then you would probably be better off using a mutable structure such as a Vector/Matrix/Array.

acer

@Jimmy You cannot use `v` for the assigned data Vector name as well as the independent variable name in the fitting formula.

Try using `V` for the data Vector, and `v` in the formula as the first argument to NonlinearFit. Or the other way around. Just not the same name for both.

@Jimmy You cannot use `v` for the assigned data Vector name as well as the independent variable name in the fitting formula.

Try using `V` for the data Vector, and `v` in the formula as the first argument to NonlinearFit. Or the other way around. Just not the same name for both.

@marram Well, you could also look at those module locals. See here for tips.

I don't have your archive, so can only guess as to the exact contents. Maybe something like,

showstat(Involutive::`Involutive/InvolutiveBasis`)

kernelopts(opaquemodules=false):
print(Involutive:-`Involutive/InvolutiveBasis`);

@marram Well, you could also look at those module locals. See here for tips.

I don't have your archive, so can only guess as to the exact contents. Maybe something like,

showstat(Involutive::`Involutive/InvolutiveBasis`)

kernelopts(opaquemodules=false):
print(Involutive:-`Involutive/InvolutiveBasis`);

@marram Yes, you can use `print`, `showstat`, or `eval` to see various contents (names saved to the archive).

But you still need to know what is inside it. It may be a module of the same name a the file itself, in which case `exports` can be used. But it doesn't have to be so. Other name of module or procedure could be in the archive. That's one aspect in which `march` and LibraryTools are useful, in allowing you to browse or list the saved names.

@marram Yes, you can use `print`, `showstat`, or `eval` to see various contents (names saved to the archive).

But you still need to know what is inside it. It may be a module of the same name a the file itself, in which case `exports` can be used. But it doesn't have to be so. Other name of module or procedure could be in the archive. That's one aspect in which `march` and LibraryTools are useful, in allowing you to browse or list the saved names.

I wanted to make some changes to it.

For example I realize now that I can get rid of the 2nd function call Show() and roll it all into the single call Resize().  Which would be an improvement in terms of convenience.

But there are other issues.

The result of Resize() goes into a new and separate region, and isn't tied to the input region in which the Resize() call is made. That means that running it twice can insert a duplicate, I believe, which is unsatisfactory. (This might be one of the points made by this thread's Asker!?)

One way to mitigate the above issue is to have Resize() insert both the plotting command call (the argument to Resize) in the inserted region's input section as well as the resulting sized plot in the output section. That way, both those things are tied together. In fact, as long as the output is never deleted then the particular size of the plot should survive re-execution. One could even delete the input line containing the Resize() call, at that point.

In other words, if you entered Resize(plot(sin(x),x=-3..3),...) then what would be inserted is an input line containing plot(sin(x),x=-3..3) along with its output which is the sized plot.

Finesses to the above idea include allowing for one to choose between 1D and 2D Math for the inserted plotting command input. (It's easy to offer both, but difficult or impossible to guess/deduce with certainty what is wanted.)

acer

I wanted to make some changes to it.

For example I realize now that I can get rid of the 2nd function call Show() and roll it all into the single call Resize().  Which would be an improvement in terms of convenience.

But there are other issues.

The result of Resize() goes into a new and separate region, and isn't tied to the input region in which the Resize() call is made. That means that running it twice can insert a duplicate, I believe, which is unsatisfactory. (This might be one of the points made by this thread's Asker!?)

One way to mitigate the above issue is to have Resize() insert both the plotting command call (the argument to Resize) in the inserted region's input section as well as the resulting sized plot in the output section. That way, both those things are tied together. In fact, as long as the output is never deleted then the particular size of the plot should survive re-execution. One could even delete the input line containing the Resize() call, at that point.

In other words, if you entered Resize(plot(sin(x),x=-3..3),...) then what would be inserted is an input line containing plot(sin(x),x=-3..3) along with its output which is the sized plot.

Finesses to the above idea include allowing for one to choose between 1D and 2D Math for the inserted plotting command input. (It's easy to offer both, but difficult or impossible to guess/deduce with certainty what is wanted.)

acer

@herclau Only a subset of the Maple language can be Compiled.

While it's likely that there are some relatively easy and straightforward optimizations possible for your code, I suspect that making it close to optimally fast (via the Compiler, probably) would entail a major rewrite of your code. It might even end up in a mixed for, with various Compiled and non-Compiled parts.

Some people feel that such editing and tuning is more convenient with 1D Maple notation source. You might reach a larger audience of people willing to contribute if you posted it as 1D input in a Worksheet.

Do you have any idea how fast it could be, optimizally? Do you have a timing benchmark of the same problem run in a 3rd party compiled program?