The relatively very small imarginary components in the computed eigenvalues of C are merely floating-point computational artefacts of using an algorithm for general (non-hermitian) Matrices. Maple does not "know" that your C is hermitian.

If one instead does Eigenvalues(Matrix(C,shape=hermitian)) then purely real results are returned.

> infolevel[LinearAlgebra]:=1:
> Eigenvalues(C);
Eigenvalues:   "calling external function"
Eigenvalues:   "CLAPACK"   hw_zgeevx_
             [                                              -16  ]
             [0.956982330395369285 - 0.128946438434221290 10    I]
             [                                                   ]
             [                                              -16  ]
             [0.268572763565393391 - 0.260648346513817324 10    I]
             [                                                   ]
             [                                              -16  ]
             [-1.10288545306076191 + 0.549243554846528987 10    I]
 
> Eigenvalues(Matrix(C,shape=hermitian));
Eigenvalues:   "calling external function"
Eigenvalues:   "CLAPACK"   hw_zhpevd_
                            [-1.10288545306076191]
                            [                    ]
                            [0.268572763565393335]
                            [                    ]
                            [0.956982330395368730]

acer

That is quite untrue, that ArrayTools:-Copy does the same as N:=M.

> M:=Matrix(1,1,[[17]]):
> N:=Matrix(1,1):
> ArrayTools:-Copy(1,M,0,1,N,0,1);
> NS:=M:
> evalb(M=N);
                                     false
 
> evalb(M=NS);
                                     true

But you can still use the N, after that Copy application, for comparsion with M.

> LinearAlgebra:-Equal(M,N);
                                     true

Also, evalm is unjustified here. For one thing, it makes a switch from an Array or Matrix to a lowercase array (which is a different structure, with last_name_eval, etc). And using evalm() is just as bad as using lowercase copy() for this task, as far as efficiency goes, since it entails creation of new structures with each iteration of the loop.

A much better way is to create N just once outside the loop, and then use a tool like ArrayTools:-Copy to get the latest entries into N or to reinitialize it with entries from M.

If I understood, you might also be able to use a hardware datatype for your problem, and get even better efficiency (esp. if using ArrayTools:-Copy, but likely elsewhere too with care).

acer

That is quite untrue, that ArrayTools:-Copy does the same as N:=M.

> M:=Matrix(1,1,[[17]]):
> N:=Matrix(1,1):
> ArrayTools:-Copy(1,M,0,1,N,0,1);
> NS:=M:
> evalb(M=N);
                                     false
 
> evalb(M=NS);
                                     true

But you can still use the N, after that Copy application, for comparsion with M.

> LinearAlgebra:-Equal(M,N);
                                     true

Also, evalm is unjustified here. For one thing, it makes a switch from an Array or Matrix to a lowercase array (which is a different structure, with last_name_eval, etc). And using evalm() is just as bad as using lowercase copy() for this task, as far as efficiency goes, since it entails creation of new structures with each iteration of the loop.

A much better way is to create N just once outside the loop, and then use a tool like ArrayTools:-Copy to get the latest entries into N or to reinitialize it with entries from M.

If I understood, you might also be able to use a hardware datatype for your problem, and get even better efficiency (esp. if using ArrayTools:-Copy, but likely elsewhere too with care).

acer

I believe that you are mistaken. The extra ' right-quotation mark was meant to denote matrix transposition, and so was not wrong syntax. That was all discussed in the earlier replies in this thread.

acer

I believe that you are mistaken. The extra ' right-quotation mark was meant to denote matrix transposition, and so was not wrong syntax. That was all discussed in the earlier replies in this thread.

acer

Yes, just read my first response in this same thread.

This is mentioned in the What's New for Maple 12, for Array/Matrices/Vectors.

acer

Yes, just read my first response in this same thread.

This is mentioned in the What's New for Maple 12, for Array/Matrices/Vectors.

acer

And that is a shame, because as far as efficiency goes you've almost certainly chosen a suboptimal structure and method. Every time you add an element you create a new list, which involves overhead for creation, possibly simultaneous storage, and eventual garbage collection (memory management). For example, it can make a task that optimally uses linear storage have quadratic memory use, with potential for worse effects in performance due to memory management needs. It is perhaps one of the more famous of less desirable programming techniques (in Maple).

acer

And that is a shame, because as far as efficiency goes you've almost certainly chosen a suboptimal structure and method. Every time you add an element you create a new list, which involves overhead for creation, possibly simultaneous storage, and eventual garbage collection (memory management). For example, it can make a task that optimally uses linear storage have quadratic memory use, with potential for worse effects in performance due to memory management needs. It is perhaps one of the more famous of less desirable programming techniques (in Maple).

acer

The name "meter" is appearing in full, I believe, because no symbol was supplied when defining the new unit in Alejandro's example code. The first argument to AddUnit will be the new unit name rather than the new symbol. I believe that you were getting that `meter` because the output was all in terms of full unit names and not unit symbols.

> restart:
> with(Units):
> AddUnit(tonF,context=ENG,conversion=1000*kgf,symbol=tonF);
> AddSystem('ENG', Units:-GetSystem(SI), 'tonF');
> UseSystem('ENG');

> convert(2.*Unit(tonF),units,kgf);
                                  2000. [kgf]
 
> convert(2.*Unit(tonF),units,N);
                                19613.30000 [N]
 
> convert(2000.*Unit(kgf/m^2), units, tonF/m^2);
                                          [tonF]
                              2.000000000 [----]
                                          [  2 ]
                                          [ m  ]

An alternative approach might be to simply specify an another context in which to take `tonf`.

> restart:
> convert(2000.*Unit(kgf/m^2), units, tonf/m^2); # unspecified context, i.e. default context
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]
 
> convert(2000.*Unit(kgf/m^2), units, tonf[standard]/m^2); # the standard context and defn
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]
 
> Units:-AddUnit(tonforce,context=metric,conversion=1000*kgf,symbol=tonf);

> convert(2000.*Unit(kgf/m^2), units, tonf/m^2); # 'metric' is not yet the default context
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]
 
> convert(2000.*Unit(kgf/m^2), units, tonf[metric]/m^2); # ...but it can already be forced
                                      [tonf[metric]]
                          2.000000000 [------------]
                                      [      2     ]
                                      [     m      ]
 
> Units:-UseContexts(metric,SI); # now make 'metric' the default context

> convert(2000.*Unit(kgf/m^2), units, tonf/m^2); # see below, about suppressing the [metric] bit
                                      [tonf[metric]]
                          2.000000000 [------------]
                                      [      2     ]
                                      [     m      ]
 
> convert(2000.*Unit(kgf/m^2), units, tonf[standard]/m^2); # can still force the standard defn
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]

> Units:-GetUnit(tonf[metric]);
tonforce, context = metric, default = false,
 
                 9806650 metre[SI] gram[SI]
    conversion = --------------------------, prefix = false, symbol = tonf,
                                  2
                        second[SI]
 
    symbols = {tonf}, spelling = tonforce, plural = tonforces,
 
    spellings = {tonforce, tonforces}, abbreviation = none, abbreviations = {}
 
> Units:-GetUnit(tonf[standard]);
tonforce, context = contexts:-standard, default = false,
 
                 8896443230521 metre[SI] gram[SI]
    conversion = ------------- ------------------, prefix = false,
                    1000000                 2
                                  second[SI]
 
    symbol = tonf, symbols = {tonf}, spelling = tonforce, plural = tonforces,
 
    spellings = {tonforce, tonforces}, abbreviation = none, abbreviations = {}

Also, if you don't want to bother with UseContexts to set a new default context, you can specifiy it when redefining the tonforce unit. That also gets rid of the indexed [metric] bit in the symbol that gets printed.

> restart:

> Units:-AddUnit(tonforce,context=metric,conversion=1000*kgf,default=true,symbol=tonf);

> convert(2000.*Unit(kgf/m^2), units, tonf/m^2);
                                          [tonf]
                              2.000000000 [----]
                                          [  2 ]
                                          [ m  ]

acer

The name "meter" is appearing in full, I believe, because no symbol was supplied when defining the new unit in Alejandro's example code. The first argument to AddUnit will be the new unit name rather than the new symbol. I believe that you were getting that `meter` because the output was all in terms of full unit names and not unit symbols.

> restart:
> with(Units):
> AddUnit(tonF,context=ENG,conversion=1000*kgf,symbol=tonF);
> AddSystem('ENG', Units:-GetSystem(SI), 'tonF');
> UseSystem('ENG');

> convert(2.*Unit(tonF),units,kgf);
                                  2000. [kgf]
 
> convert(2.*Unit(tonF),units,N);
                                19613.30000 [N]
 
> convert(2000.*Unit(kgf/m^2), units, tonF/m^2);
                                          [tonF]
                              2.000000000 [----]
                                          [  2 ]
                                          [ m  ]

An alternative approach might be to simply specify an another context in which to take `tonf`.

> restart:
> convert(2000.*Unit(kgf/m^2), units, tonf/m^2); # unspecified context, i.e. default context
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]
 
> convert(2000.*Unit(kgf/m^2), units, tonf[standard]/m^2); # the standard context and defn
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]
 
> Units:-AddUnit(tonforce,context=metric,conversion=1000*kgf,symbol=tonf);

> convert(2000.*Unit(kgf/m^2), units, tonf/m^2); # 'metric' is not yet the default context
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]
 
> convert(2000.*Unit(kgf/m^2), units, tonf[metric]/m^2); # ...but it can already be forced
                                      [tonf[metric]]
                          2.000000000 [------------]
                                      [      2     ]
                                      [     m      ]
 
> Units:-UseContexts(metric,SI); # now make 'metric' the default context

> convert(2000.*Unit(kgf/m^2), units, tonf/m^2); # see below, about suppressing the [metric] bit
                                      [tonf[metric]]
                          2.000000000 [------------]
                                      [      2     ]
                                      [     m      ]
 
> convert(2000.*Unit(kgf/m^2), units, tonf[standard]/m^2); # can still force the standard defn
                                          [tonf]
                              2.204622622 [----]
                                          [  2 ]
                                          [ m  ]

> Units:-GetUnit(tonf[metric]);
tonforce, context = metric, default = false,
 
                 9806650 metre[SI] gram[SI]
    conversion = --------------------------, prefix = false, symbol = tonf,
                                  2
                        second[SI]
 
    symbols = {tonf}, spelling = tonforce, plural = tonforces,
 
    spellings = {tonforce, tonforces}, abbreviation = none, abbreviations = {}
 
> Units:-GetUnit(tonf[standard]);
tonforce, context = contexts:-standard, default = false,
 
                 8896443230521 metre[SI] gram[SI]
    conversion = ------------- ------------------, prefix = false,
                    1000000                 2
                                  second[SI]
 
    symbol = tonf, symbols = {tonf}, spelling = tonforce, plural = tonforces,
 
    spellings = {tonforce, tonforces}, abbreviation = none, abbreviations = {}

Also, if you don't want to bother with UseContexts to set a new default context, you can specifiy it when redefining the tonforce unit. That also gets rid of the indexed [metric] bit in the symbol that gets printed.

> restart:

> Units:-AddUnit(tonforce,context=metric,conversion=1000*kgf,default=true,symbol=tonf);

> convert(2000.*Unit(kgf/m^2), units, tonf/m^2);
                                          [tonf]
                              2.000000000 [----]
                                          [  2 ]
                                          [ m  ]

acer

I thought that doing so (without quoting) didn't work if the unit name had been assigned and one were using the palette for 2D Math input in Document mode (or maybe some other combination). Do you mean only for the preset unit palette entries, or also for using the generic unit palette entry which is useful for compund units.

acer

I thought that doing so (without quoting) didn't work if the unit name had been assigned and one were using the palette for 2D Math input in Document mode (or maybe some other combination). Do you mean only for the preset unit palette entries, or also for using the generic unit palette entry which is useful for compund units.

acer

If this is the situation, then quoting the m with single (uneval) right-quotes should be ok for regular input.

It would be nice if palette entry of units checked for assignment of the given unit name(s) at the current scope, and inserted an uneval-quoted name inside the Unit() call (or its 2D Math equivalent) if already assigned,

acer

If this is the situation, then quoting the m with single (uneval) right-quotes should be ok for regular input.

It would be nice if palette entry of units checked for assignment of the given unit name(s) at the current scope, and inserted an uneval-quoted name inside the Unit() call (or its 2D Math equivalent) if already assigned,

acer