I guess it might depend on how much you find that you have to program for computations which are not automatically handled (efficiently enough, or at all) in those larger programs.

One big attraction of CUDA, as I understand it, is its general purpose nature as far as numerical scientific programming goes. It's not just using the GPU for graphics calculations. One can do numeric pdes on it, or whatever, provided someone's written the code.

I do not yet know whether Maple's external-calling mechanism can simply call out to a program compiled within CUDA to run on the GPU. It would be great if it did, and good even if it took a little extra effort. It'd be even better if one could cobble together a pseudo-automated process like this to make use of it on "numeric-typed" Maple procedures.

acer

If I were going to buy a new computer then (since I enjoy scientific programming and computing) I'd consider getting an NVIDIA video card that allowed general computation via the GPU. See CUDA. I'd likely consider a card capable of double precision for such GPU computation, such as the 260 chipset or higher.

acer

Hi Bryon,

Are you going you planning on importing the existing mapleprimes posts (all of them) into the new system?

acer

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

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