This should not normally occur, and there is not something extra and special that one needs to do to enable this functionality.

Note that Fedora 14 is not listed as an officially supported 64bit Linux platform for Maple 15. But perhaps we might have some luck with figuring it out.

I see a few possibilities about what may be the cause: the external shared library actually is not being found, or the `SmallFactors` symbol is not being resolved within it, or some other dependency is not being resolved when that `SmallFactors` symbol is dlopen'd, or there is some mismatch in dependent libraries expected by that shared lib and whatever is on your OS.

Let's try and find out what precisely is the error when the define_external is made. In the routine from which that error is issued, there is a try..catch in the source code. Any error from the define_external call is caught and rethrown in the form you quoted. So let's try and see what the original (caught) error message is.

Could you please issue this command in your Maple, and report back with whatever that produces,

define_external('SmallFactors','MAPLE','LIB'="libmodLA.so");

Can you successfully run any other examples from help-pages of any commands in the LinearAlgebra[Modular] package? Is there a `processor` (or `processor32`) executable in any bin.XXXX subdirectory of your Maple installation, and if so could you run it from a terminal shell and report whatever it says? If there's no such executable, then could you say what CPU your machine has, with the exact model number?

acer

The original list mentioned `maptype` and `typematch` which, while important, don't come up as often as several of the other listed commands. If those are in, then maybe `foldl`, `foldr`, and `curry` could be in too.

acer

I feel that (in Maple, at least) the significant difference between parameters (inside a proc) and arguments (to that proc) lies more in how you expect to use them than it does in some special coding practice. There are always exceptions, of course, but my preference is to manage parameters as formal arguments.

There are a few minor sins which I think this helps avoid. (The severity of the sin varies with circumstance and context, of course.)

• One of those is declaing globals in a proc, when it's not necessary.
  [We've seen the worksheets here, that have procs each with 2 formal parameters and a dozen declared globals. And at worst the results are confusion as to which `x` is which, debugging nightmares, slow code, and certainly no evalhf'ability.]
• Using a procedure without knowing why.
  [We've seen this too on mapleprimes: it starts off simple, and then somehow quotes get added because they seem to help, and then before you know it you're creating a procedure which you only ever call once. At this point, the central threads of purpose may have been lost. NB. This case in point is not even close to the extreme, which is something like,

  fexpr:=unapply(expr,x);
  plot(fexpr(x),x=a..b);  # and fexpr is never again used

• Having to do a full restart,or even just have Maple do more "work", just to make changes to an example. Or put another way: the less re-calculation required in order to re-run with different parameter values, the better. And re-creating a new instance of the whole procedure, just to use different parameter values, is certainly more re-calculation. (Yes, I realize that there may be other quite different memory management reasons why one has to do a full restart. But it still be be decent practice to not force the requirement...)

So I might try something like this:

restart:

U := proc(c, s) if s=1 then log(c); else (c^(1-s)-1)/(1-s); end if; end proc:

Parameters1 := [ s = 2 ]:
U(c, subs(Parameters1,s));

                              1    
                            - - + 1
                              c    

# And now, without having to re-create any procedure,

Parameters1 := [ s = 1 ]:
U(c, subs(Parameters1,s));

                             ln(c)

As a very minor quibble -- if I may offer more opinion on coding style -- I suggest trying to use different names for formal parameters than are expected to be used as supplied arguments. Fr example, to help keep thing straight in our heads,

restart:

U := proc(C, S) if S=1 then log(C); else (C^(1-S)-1)/(1-S); end if; end proc:

Parameters1 := [ s = 2 ]:
U(c, subs(Parameters1,s));
                              1    
                            - - + 1
                              c    
Parameters1 := [ s = 1 ]:
U(c, subs(Parameters1,s));
                             ln(c)

The formal parameters of procedure U are now named differently, and may help avoids some confusion, but the way that U gets called and the final form results are the same.

acer

See testeq

acer

Oftentimes, one can simply `print` the procedure, and copy & paste to your favourite editor.

Or you could use `ToInert` and `FromInert` which can potentially be demanding. (Eg, figure out the need for subsop([5,1,1,2,1]=... in this.)

The first example below works ok. But the second example is a problem, because you'd need to know or figure out that `i` is the first declared local, otherwise it's hard to match only the right thing.

restart:

p := proc() local i,y; y:=(i=30); end proc;

                p := proc() local i, y; y := i = 30 end proc;

FromInert(subsindets(ToInert(eval(p)),
                     specfunc(Or(specfunc(anything,_Inert_LOCAL),
                                 identical(_Inert_INTPOS(30))),
                              _Inert_EQUATION),
                     z->subs(30=50,z)));

                   proc() local i, y; y := i = 50 end proc;

p := proc() local i,j,y,x; y:=(i=30); x:=(j=30); end proc;

      p := proc() local i, j, y, x; y := i = 30; x := j = 30; end proc;

FromInert(subsindets(ToInert(eval(p)),
                     specfunc(Or(specfunc(anything,_Inert_LOCAL),
                                 identical(_Inert_INTPOS(30))),
                              _Inert_EQUATION),
                     z->subs(30=50,z)));

        proc() local i, j, y, x; y := i = 50; x := j = 50; end proc;

As a last resort, if you are using the commandline interface and have quit the session without having savelib'd your procedure `p`, you could try the session history file.

$ "C:/Program Files (x86)/Maple 15/bin.win/cmaple.exe"
    |\^/|     Maple 15 (IBM INTEL NT)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2011
 \  MAPLE  /  All rights reserved. Maple is a trademark of
   Waterloo Maple Inc.
      |       Type ? for help.
> interface(historyfile);
                        "C:\Users\Rubrum/.maple_history"

I suspect that in Maple 12 the result of the above command might be like ".maple_history" and be relative (implicitly) to currentdir().

acer

See fnormal

Eg,

> restart:

> z := 2e-15*x - 3e-15*x*y + 5*x^2*y:

> fnormal(z,10,1e-15);

                    -15         -15          2  
                2 10    x - 3 10    x y + 5 x  y

> fnormal(z,10,1e-14);

                                2  
                             5 x  y

> fnormal(z); # session defaults

                                2  
                             5 x  y

acer

The first thing to note is that success should not necessarily be measured by virtue of *all* the computed optimizing parameter values being very close to your original generating function. That's because the effects of some terms may swamp out the effects of others, the latter of which are hence somewhat free to vary. A reasonable gauge of success is to compare plots, instead.

Statistics:-NonlinearFit uses a "local optimization" method, and so the result may be locally optimal but not globally optimal. In other words, there may be other local optima which are better than the local optimum that is found.

There are two basic ways deal with this. 1) get and install a global optimization package such as DirectSearch or GlobalOptimization, or 2) supply a judicious/lucky set of initial values for the parameters.

Sometimes you can use ExponentialFit or LogarithmicFit to help guide you in choosing initial values for some of the parameters. For example,

fitting101.mw

acer

You mentioned other "forms", like an ellipse.

restart:

L := [[.241, 0.2e-2], [.241, 0.3e-2], [.242, 0.], [.243, 0.5e-2],
      [.246, -0.3e-2], [.246, 0.6e-2], [.247, 0.6e-2], [.248, -0.4e-2],
      [.248, 0.6e-2], [.25, -0.5e-2], [.252, -0.6e-2], [.253, 0.6e-2],
      [.254, 0.6e-2], [.255, 0.6e-2], [.261, -0.9e-2], [.261, 0.5e-2],
      [.265, -0.1e-1], [.266, 0.4e-2], [.269, 0.3e-2], [.271, -0.11e-1],
      [.272, -0.11e-1], [.272, 0.2e-2], [.278, -0.11e-1], [.279, -0.11e-1],
      [.28, -0.11e-1], [.28, -0.2e-2], [.283, -0.1e-1], [.284, -0.9e-2],
      [.284, -0.6e-2]]:

P1:=plot(L, style=point, color=black):

K:=Statistics:-Fit(a*(x-x0)^2-b*(x-x0)*(y-y0)+c*(y-y0)^2-1,
                   Matrix(L), Vector(nops(L)),[x,y],
                   initialvalues=[a=0,b=0,c=0,x0=0.26,y0=0]);

                                                       2                             
          K := 3163.59634684427 (x - 0.262991041730829) 

               + 9227.98709575456 (x - 0.262991041730829) (y + 0.00246191128098791)
                                                                  
                                                           2                             
               + 19957.6913974776 (y + 0.00246191128098791)  - 1              


ellK:=plots:-implicitplot(K,x=0.24..0.3,y=-0.02..0.02):

plots:-display(P1,ellK);

One may need to experiment with the initial values (x0 and y0 being easiest to guesstimate), though a global solver might do well automatically, for other data sets.

There is more than just one way to fit an ellipse to a hull. Above, it fits the points themselves in usual least-squares distance kind of way. But for your original, smaller, data set you can get quite different results if instead you fit the midpoints of the line segments of the hull, or if you fit the original points and the midpoints, or if you fit by minimizing the sum of areas (sum of integrals integral) between line segments of the hull and the ellipse curve (there too: a choice between minimal distance to ellipse from each point, or distance taken orthogonally from each point on hull's line segment).

acer

noisycircle.mw

It's not clear that using the cross (orthogonal x and y coordinates) of two univariate normal distributions for the noise is best. It may be ok for the parametrized circle as the curve, on account of symmetry, but I suspect it might surprise if used for some other curves.

Here is some code that is reasonably fast and memory careful. The 2D plot data-structure for 30000 pts can be generated here in less than 1/10th of a second on an Intel i7.

(It could likely be done even faster, by using the Compiler on a procedure which populated the final `XY` Matrix. But that looks like overkill, especially when one considers how long `plot` takes to produce the `PLOT` structure, or how long the GUI takes to insert and display the graphic.)

But throwing up the plot onto the Worksheet takes much longer, or at least it does on Maple 12 for Linux 64bit. In Maple 15.01 it is quite fast on Windows 64bit, to insert the plot into a pre-made Plot Component. (Coincidentally, I had recently been preparing a blog post on plot insertion and rendering speeds in the Worksheet. This is a nice example to add there.)

In Maple 12, this looks really good at symbolsize=4 in the Worksheet. Also, it seemed to render more quickly for symbol=solidcircle which is interesting. But in Maple 12 the symbolsize=4 plot exported with right-click content-menu to a blank plot. In Maple 15 that same symbolsize (for the same solidcircle) appears much larger(!) and not nearly as nice. And in Maple 15, smaller symbol sizes produce a blank plot for me(!). I intend to submit bug reports.

Here's a screenshot of what it looks like in Maple 12.02,

And here's a screenshot of what it looks like in Maple 15.01. Once again: both have symbolsize=4 and symbol=solidcircle, this M12 plot exported as empty with right-click context-menu gif/jpeg driver, and in M15 no smaller symbol shows as nonempty even in the Worksheet.

Personally, I think that M12 offered the more sophisticated/professional appearance here, and it certainly had the more flexible symbol size functionality. All we need now is the best of both worlds: proper non-empty export using all drivers, small symbol size in the Worksheet, and the same good speed for inline plots as are obtained for Plot Component updating.

Now, what are some alternatives for adding noise a point on a parametrized curve in 2D? For any point, one could take an angle theta from a uniform distribution and a radius from a normal (or other) distribution. Or, should the normal of the curve at that point make an effect on the direction of the noise component? What would one expect, for an ellispse, say?

acer

Deliberately creating noisy data is not uncommon.

Generate points along the sin curve, stored in a Vector of x values and a Vector of y values. Generate a noise signal from a random distribution, generating a sample of noise values in a Vector. Add together the y-values Vector and the noise Vector. You are done. View with ScatterPlot, as one way to handle noisy experimental data.

So, just use Statistics:-Sample to generate noise, and add noise to pure signal. You can code it, I'm sure.

acer

The following has more visible brackets (which you didn't ask for), but the final result of 16 is accesible from `h` after the assignment, and it doesn't require that you encode the formula more than once when typing it in.

restart:

twostep:=proc(expr::uneval)
   (convert(expr,name) = 
    subsindets(expr,And(name,satisfies(t->type(eval(t),constant))),
               z->convert(eval(z),name)))
   = eval(expr):
end proc:

a:=1:
b:=3:
c:=5:

h:=twostep(a+b*c);

                     (a+b*c = 1 + 3 5) = 16

rhs(h);

                               16

lhs(h);

                        a+b*c = 1 + 3 5

h:=twostep(a+b.c);

                   (a+b . c = 1 + 3 . 5) = 16

twostep( sin(exp(a*x)+b)/c );

  /                    sin(exp(1 x) + 3)\   1                
  |sin(exp(a*x)+b)/c = -----------------| = - sin(exp(x) + 3)
  \                            5        /   5                


restart:

twostep:=proc(expr::uneval)
   (convert(expr,name) = 
    subsindets(expr,And(name,satisfies(t->type(eval(t),constant))),
               z->``(eval(z))))
   = eval(expr):
end proc:

a:=1:
b:=3:
c:=5:

h:=twostep(a+b*c);

                  (a+b*c = (1) + (3) (5)) = 16

rhs(h);
                               16

lhs(h);
                     a+b*c = (1) + (3) (5)

twostep( sin(exp(a*x)+b)/c );

/                    sin(exp((1) x) + (3))\   1                
|sin(exp(a*x)+b)/c = ---------------------| = - sin(exp(x) + 3)
\                             (5)         /   5                

See also here, and maybe also this or that craziness.

acer

You're asking for an absolute conversion, and getting a relative conversion.

In relative terms, if you increase a quantity by a single unit Celcius then the corresponding increase in terms of units Kelvin should not be done on the absolute scale! Ie, it is not a bug. Eg. 55*Unit(K)+Unit(degC) should only add one Unit(K) to get the result.

The `convert` command offers you the choice. You can use convert,units for a relative scale conversion, or you can use convert,temperature for an absolute scale conversion (which you seem to be wanting).

I posit that using an absolute scale conversion for arithmetic is not usual.

You can replace your 11*Unit(degC) with the call convert(11*Unit(degC), temperature, K) in your sequence of names=values.

Of course, you could alternatively adjust literally by -273.15, but for other units like degF, etc, you might prefer it error free and programatic. Speaking of avoiding human error, your other "correct" worksheet adjusted by 273, but it ought to be 273.15.

question to experts: Would it make sense for there to be a Units `context` of `temperature`, so that one could enter something like Unit(degC[temperature]) and have conversions be done on an absolute scale after issuing UsingContexts('temperature')? It could get messy, because one wouldn't want 1*Unit(degC) + 1*Unit(degC) to come out wrongly as 548.3*Unit(K). Conversion would have to be done only after combining. Is it unworkable, on account of some other problematic cases? Would it make any sense for Units:-AddUnit to allow a procedure instead of an algebraic expression for the 'conversion'?

acer

You might find this example of interest. And you can adjust it, so that the coloring scheme is based on the orientation as opposed to simply the x-y-z position. You could then make an animation from this, giving the effect of coloring that changes with the orientation.

Getting it to work using the built-in 3D plot rotation mechanism, is trickier. During other recent investigations of my own, I've been lamenting the lack of programatic access to the current orientation of a manually rotated plot. I would like to see the orientation angles be (new) properties of a Plot Component, that could be used with the GetProperty and SetProperty commands of the DocumentTools package.

acer

One does not need to assign, in order to use the value found.

The result from Optimization:-Minimize is a list of two things, and either can be accessed by simply indexing into that list (ie. 1st, or 2nd element).

sol := Optimization:-Minimize( (x-5)^2-x, x=-10..10 );
              sol := [-5.2500000000000, [x = 5.50000000000000]]

sol[2];
                           [x = 5.50000000000000]

sol[1];
                              -5.2500000000000

eval( (x-5)^2-x, sol[2] );
                              -5.25000000000000

eval( x, sol[2]);
                              5.50000000000000

acer

The initial parsing by HTTP:-Get in Maple 12 seems to be stripping out the `?`, retaining it for neither (what it considers as the table entry indexed by) "urlpath" nor "query". That's what it looks like, to me, in the Maple debugger.

So I tried repeating the "?" mark, wondering whether the url parser would not notice and so only strip one instance of the symbol and retain the duplicate. It seems to work, for this example. That is, in Maple 12.02 (Windows 7, 64bit),

HTTP[Get]("www.mapleprimes.com/recent/all??page=2");

acer