acer

32622 Reputation

29 Badges

20 years, 43 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

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.

Carl, you wrote that the problem was also exhibited when the problematic subsection was not empty. When it was not empty did it have a title?

I could be wrong, but it seems to me that the problem occurs when the <Title> XML element of the file does not contain its usual <Text-field> child element. In that case the GUI cursor cannot be moved to the title of the subsection, it seems, nor can the pointer device point-and-sweep from there (so as to delete just that subsection).

One remedy seems to be to point-and-sweep from other elements around it (similar to what John suggests). Another that worked for me here is to edit the file in a text editor and insert <Text-field></Text-field> inside the empty <Title></Title>. Of course that can be onerous to locate, if deep in the middle of a document.

Do you recall anything special about how that problematic subsection was originally put into place or inserted or edited?

acer

@MortenZdk You're welcome. As I mentioned the help page Description for the Explore command explicitly describes the situation in your Question. If you want to get an explored parameter's values into a procedure call then make the parameter get passed in via the procedure's arguments. The are also several examples where that is done in the so-called example worksheet for Explore (see help topic examples,Explore ).

@Doug Meade This is not about single level evaluation of procedure locals.

You made the typographical mistake Optimization-NLPSolve instead of Optimization:-NLPSolve, and so your return value is the result of subtracting the list returned by NLPSolve from the name Optimization.

You would have to have previously loaded Optimization, in order for that (short syntax) NLPSolve call to have succeded.

@ThU In Maple 2016 the help page for the Explore command mentions this situation in its Description. The third bullet point of that Description reads as:

       Parameter values are used by re-evaluating the original expression
       or function call. The parameter names are not assigned values in this
       process. In consequence instances of the unassigned parameter names
       within a procedure body will not be evaluated. In order to use the
       values within a procedure the parameter name should occur in an
       argument to an explored function call.

Its last sentence's suggestion is what you gave as your second alternative.

I think that the current behaviour is not wrong, on general grounds of how Maple's evaluation model works. For one thing it would be undesirable if Explore tried to temprarily assign to global :-a, especially if an un-catchable error during evaluation (of f here) left :-a assigned as side-effect. Note also that the test depends('f(x)',a) returns false.

Even if Explore tried to use its own internally constructed, modified instance of f (ie. subs(a=value,eval(f)) ) that would likely need to be expensively done for each value of the parameter. And worse still, if parameter a appeared within another proc that was called within f then it still would not be workable.

Maple's evaluation model is worth learning, and while the Programming Manual is a good start though doesn't cover everything.

In the past I have seen requests (some on this site, one from Preben?!) for a facility that would allow something like the following to produce 5*x for both outputs below:

restart;

f := x->a*x:

use a=5 in
  f(x), a*x;
end use;
                                  a x, 5 x

Such a facility (were it to exist, presumably by some langage keyword other that use) would be best if it were at least as strong as try..catch..finally in its ability to allow temporarily instantiated values to be forcibly undone.

@JrebL When exploring plots it can be help to use the view plot option, so that the visible extent of the axes is common across the various plots. (Of course, this may require that you figure out in advance a view which will include all the plot features that you intend to see.)

You may also wish to try using the scaling plot option.

Eg,

Explore( plots[arrow]
         (
           [ Vector( [cos(delta), sin(delta)] ),
             Vector( [2,-1] )
           ],
           view=[-1..2,-1..1], scaling=constrained
         ),
         delta=-Pi..Pi
       );
First 300 301 302 303 304 305 306 Last Page 302 of 596