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

I considered that he was thinking of context-sensitive menus, where unfortunately the capitalization does not match that of the actual commands, and where the appearance of individual choices comes and goes depending on the "selection".

I've see it happen before, that somene thinks that clickable Maple is the primary form of using Maple. (...although, maybe that's not what's happened here. Package exports are another possibility.)

acer

I considered that he was thinking of context-sensitive menus, where unfortunately the capitalization does not match that of the actual commands, and where the appearance of individual choices comes and goes depending on the "selection".

I've see it happen before, that somene thinks that clickable Maple is the primary form of using Maple. (...although, maybe that's not what's happened here. Package exports are another possibility.)

acer

You can add your own context menu item for 3D numeric Arrays.

acer

You can add your own context menu item for 3D numeric Arrays.

acer

Have you read the ?evalf,Sum help-page?

acer

Robert's already explained why the original example is a bug: simplify should only return the input -- simplified or not -- for valid input. There is nothing technically invalid about an expression containing both a name and its indexed form.

But while not wrong per se, it's not a great idea to use both an indexed name and its base name in the same expression. Even if you don't intend to assign to the base name yourself , some other routine that you use might do an equivalently unfortunate action.

Consider,

> subs(x[1]=y,x+x[1]); # ok
                                    y + x

> subs(x=y,x+x[1]); # oops, it hits both
                                  y[1] + y

There are quite a few routines which will not handle such mixed expressions well. Another example,

> convert(x[1]+x^2,sqrfree,{x,x[1]});
Error, (in content/content) invalid arguments

That last one causes this,

> fsolve({x[1]+x+1,x[1]+x^2});
Error, (in content/content) invalid arguments

Now, some routines have been made clever in this regard. They might carefully substitute in other dummy names for all indexed names, up front, and then resubstitute at the end. Or whatever. But that safety is not universal. I''ve found that dsolve, simplify, and solve are sometimes better at it.

While on this topic: these names indexed by [] are usually called "indexed names". They are of type name(indexed). They are not subscripted except in 2D Math (input and output!). Not everyone uses 2D Math output. If you do, then perhaps that's why you have refered to indexed names as subscripted names. Atomic identifiers are another form of subscripted names in 2D Math.

The big difference between indexed names as subscripted names, and atomic identifiers, is that only in the former is the subscript readily changed. This is a contentious area. For DEs, people may not need the subscript to itself be mutable, in which case an atomic identifier may be more suitable. But atomic identifiers are awkward to use.

acer

Robert's already explained why the original example is a bug: simplify should only return the input -- simplified or not -- for valid input. There is nothing technically invalid about an expression containing both a name and its indexed form.

But while not wrong per se, it's not a great idea to use both an indexed name and its base name in the same expression. Even if you don't intend to assign to the base name yourself , some other routine that you use might do an equivalently unfortunate action.

Consider,

> subs(x[1]=y,x+x[1]); # ok
                                    y + x

> subs(x=y,x+x[1]); # oops, it hits both
                                  y[1] + y

There are quite a few routines which will not handle such mixed expressions well. Another example,

> convert(x[1]+x^2,sqrfree,{x,x[1]});
Error, (in content/content) invalid arguments

That last one causes this,

> fsolve({x[1]+x+1,x[1]+x^2});
Error, (in content/content) invalid arguments

Now, some routines have been made clever in this regard. They might carefully substitute in other dummy names for all indexed names, up front, and then resubstitute at the end. Or whatever. But that safety is not universal. I''ve found that dsolve, simplify, and solve are sometimes better at it.

While on this topic: these names indexed by [] are usually called "indexed names". They are of type name(indexed). They are not subscripted except in 2D Math (input and output!). Not everyone uses 2D Math output. If you do, then perhaps that's why you have refered to indexed names as subscripted names. Atomic identifiers are another form of subscripted names in 2D Math.

The big difference between indexed names as subscripted names, and atomic identifiers, is that only in the former is the subscript readily changed. This is a contentious area. For DEs, people may not need the subscript to itself be mutable, in which case an atomic identifier may be more suitable. But atomic identifiers are awkward to use.

acer