@John Fredsted It's a bug in DifferentialGeometry (not the interface), that it does not correctly reset the prompt through a call to the interface.

pagan also showed the convert to list and `+`,... in a recursive solution in an answer made in 2009. I see nothing new in Omer's answer.

@Carl Love Sure, thanks. I deliberately kept the explciit seq call, with its index, to try and make it more clear for the OP.

@MAHMOUDHM And I deleted that duplicate of this question. Please add your additional details here, rather than spam the site with duplicate posts.

@Carl Love  Over the past few years I have submitted several request/bug reports about the need for more examples of the great power of this very popular command, but sadly to little avail. Another vote up.

@MortenZdk  Where does the documentation suggest demoting Digits for the purpose only of controlling the format of display of floats!?

Can you modify that `exportplot` procedure to assign the temp filename string (fully qualified) to a global variable, or to return that string?

acer

@Østerbro  Sorry I am away and will not have maple/computer access until Aug 13. 

What you want can be done. E.g. using convert unit_free to separate and simplify the unit terms and the the other process to handle the rest.

@Adam Ledger Please upload any edited revision of your worksheet in a new Comment on this thread (use a new filename, say), rather than in a whole new Post. That way Carl's comments will still be associated with it.

@Carl Love If it is expected behavior that numcpus can only be set once per session then certainly the help page for the kernelopts command should mention that fact (and on the same help page some other key should be used to illustrate the way that kernelopt's return value is the previous value for the given key, etc).

@Carl Love When doing some experiments a few years ago I recall noticing that I could only get the kinds of expected performance difference if I set kernelopts(numcpus) once per restart, before doing other computations. I was likely doing this on 64bit Linux.

However I have not tried that recently. And the computations I was doing were likely hardware double-precision under evalhf or Compiled procedures running in Threads:-Task (or, less likely, double-precision LinearAlgebra) all inplace on float[8] rtables with no garbage collection.

I may even have set kernelopts(numcpus) from the Startup Region of a Document. I don't recall the full details. But I did see the expected performance scaling, from 1 up to the number of physical cores.

I don't know what's going on with Threads:-Mul or Threads:-Add however, even on a given platform, including the case of exact computations that includes garbage collection.

@Østerbro Your latest objection is not related to units specifically, but would also occur for some other examples without units.In large part the problem comes from incomplete specification of exactly what you do and do not want to see. Additionally, some of what you are now claiming sees to me to contradict earlier descriptions.

I suggest that you try to formulate a proper and precise description of what is meant by intermediate steps and intermediate results. I can understand that intermiate results should all be unique. But why not object earlier to unitless examples that exhibit some of your present problems. Please describe exactly what you want to see.

You could try the following,

Display:= proc(e::uneval) 
uses T= Typesetting; 
local 
     pre:= subsindets(e, uneval(name), eval, 1), 
     r:= eval(pre), 
     Ty_pre:= T:-Typeset(e) 
;    
     if indets(pre, And(name, satisfies(u-> u<>eval(u)))) = {} then 
          print(r); 
     else 
          print(( 
               Ty_pre =  
               evalindets(                    
                    subs("⁢"= "*", Ty_pre),  
                    specfunc(string, T:-mi), 
                    proc(n) 
                    local pn:= eval(parse(op(n)));
                         if pn::numeric then
                              T:-mn(sprintf("%a", pn));
                         else Typesetting:-Typeset(Typesetting:-EV(pn));
                         end if;  
                    end proc 
               )) = 
               evalf(r) 
          ) 
     end if; 
     r 
end proc:

And if that doesn't satisfy your goal then you could try this weaker variant,

Display:= proc(e::uneval) 
uses T= Typesetting; 
local 
     pre:= subsindets(e, uneval(name), eval, 1), 
     r:= eval(pre), 
     Ty_pre:= T:-Typeset(e) 
;    
     if indets(pre, And(name, satisfies(u-> u<>eval(u)))) = {} then 
          print(r); 
     else 
          print(( 
               Ty_pre =  
               evalindets(                    
                    subs("⁢"= "*", Ty_pre),  
                    specfunc(string, T:-mi), 
                    proc(n) 
                    local pn:= eval(parse(op(n)));
                      if pn::numeric then
                           T:-mn(sprintf("%a", pn));
                      elif type(pn, numeric &* 'specfunc'('anything',Units:-Unit)) then
                           Typesetting:-Typeset(Typesetting:-EV(pn));
                      else n;
                      end if;  
                    end proc 
               )) = 
               evalf(r) 
          ) 
     end if; 
     r 
end proc:

Your XP machine seems to be 4 physical cores without hyperthreading capability, while your new Windows 7 machine seems to be 4 physical cores with hyperthreading capability (which you utilize in your run using 8 cores).

With your XP machine your are comparing using 2 physical cores versus using 4 physical cores. But on your newer Windows 7 machine your are comparing using 4 virtual cores (from 8 available on 4 physical cores, since presumably you did not disable hyperthreading for that run) versus 8 virtual cores. On the Windows 7 machine it's quite possible that the OS distributed the load evenly amongst the 4 physical cores, in the run that used only 4 cores.

There was a time when hyperthreading performance was poor enough that it negatively impacted some parallel computations. But even with newer machines where that degradation is less severe the comparison between 2-physical-cores/4-physical-cores versus 4-phyical-cores/8-virtual-cores should not be expected to demonstrate the same performance ratios. Keep in mind that there are usually more ways in which virtual cores can have to contend for the same resources, but hyperthreading performance is a complicated topic.

acer

@Østerbro I'm not around so much these days, taking some summer vacation. But I'll have a look.