acer

32343 Reputation

29 Badges

19 years, 328 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

Here are two ways it could be done.

They use slightly different ways to access the stored values/fields. You could even make it do both of these ways.

One point is that as an object you get the new type, Person, for free without having to utilize TypeTools:-Add and a proc that tests, say, a Record approach.

The definition of the object is centralized. Changing it only requires editing that defintion (and, naturally, wherever the constructor gets called, if you alter the kinds of arguments the constructor accepts.)

restart;

Person:=module()
    option object;
    local ModulePrint, R;
    export ModuleApply::static:=proc()
      Object(Person, _passed);
    end;
    export ModuleCopy::static:=proc(new::Person, proto::Person,
                                    name::string, age::nonnegint)
      if nargs=4 then
        new:-R := Record(':-name'=name,':-age'=age);
      else
        error "invalid arguments"; end if;
    end proc;
    export `?[]`::static:=proc(a, idx::list)
        if idx=[] then
          [a:-R:-name, a:-R:-age][];
        elif nops(idx)=1 then
          a:-R[idx[1]];
        else error "too many indices, %1", [idx][];
      end if;
    end proc;
    ModulePrint:=proc(a)
      # or whatever you want
      'Person'(R:-name,R:-age);
    end proc:
  end module:

P1 := Person("john doe 1", 99):

P2 := Person("john doe 2", 80):

P1;

_m139837426773472

P2;

_m139837426775168

type(P1, Person), type(P2, Person);

true, true

P1[];

"john doe 1", 99

P2[];

"john doe 2", 80

P1[name], P2[name]

"john doe 1", "john doe 2"

P1[age], P2[age];

99, 80

P1[name, age];

Error, (in ?[]) too many indices, [name, age]

foo:=proc()"joe doe 1";
   Person("john doe 1", 99);
end proc:

boo:=proc()
   Person("john doe 2", 80):
end proc:

S1:=foo();
S2:=boo();

_m139837429143520

_m139837429160672

type(S1, Person), type(S2, Person);

true, true

S1[name], S2[name]

"john doe 1", "john doe 2"

S1[age], S2[age];

99, 80

 

# Another way

restart;

Person:=module()
    option object;
    local ModulePrint, lname, lage;
    export ModuleApply::static:=proc()
      Object(Person, _passed);
    end;
    export ModuleCopy::static:=proc(new::Person, proto::Person)
      if nargs=4 then
        (new:-lname,new:-lage) := args[3], args[4];
      else
        error "invalid arguments"; end if;
    end proc;
    export name::static:=proc(a)
      a:-lname;
    end proc;
    export age::static:=proc(a)
      a:-lage;
    end proc;
    ModulePrint:=proc(a)
      # or whatever you want
      'Person'(lname,lage);
    end proc:
  end module:

P1 := Person("john doe 1", 99):

P2 := Person("john doe 2", 80):

P1;

_m139837426773408

P2;

_m139837426775040

type(P1, Person), type(P2, Person);

true, true

name(P1), name(P2);

"john doe 1", "john doe 2"

age(P1), age(P2);

99, 80

foo:=proc()"joe doe 1";
   Person("john doe 1", 99);
end proc:

boo:=proc()
   Person("john doe 2", 80):
end proc:

S1:=foo();
S2:=boo();

_m139837429174080

_m139837429191200

type(S1, Person), type(S2, Person);

true, true

name(S1), name(S2);

"john doe 1", "john doe 2"

age(S1), age(S2);

99, 80

 

Download person_object_2.mw

Here is some additional computation (Maple 2019.1, 64bit Linux), involving attempts at eigen-conditioning approximation.

problematic_evals.mw

There are a few possibilities worth investigating: 1) the software float functions sw_xxxxxx are from an older (generic, netlib) clapack, and it's possible translations to C from newer lapack might differ, 2) machine-epsilon in the software-float sw_xxxxxx functions is defind according to Digits, but it's possible that some other hard-coded values or iteration limits could be adjusted beneficially, 3) ill-conditioning might be bad enough that things are really difficult, 4) there may now be additional choices than zgeevx. 

@Carl Love I was alluding to the fact that the initially constructed multivariate polynomial F with integer coefficients might be a POLY DAG, and that sort could turn that into a SUM DAG. See Appendix 1 of the Programming Manual which has a few notes. I mentioned dismantle only because it can illustrate that effect.

The purpose of the POLY DAG is to allow efficient computation (see web searches and results indicating development work at SFU CECM by Monagan, Pearce, et al.).

I don't know precisely how interface(prettyprint) versus lprint may differ in all cases. But AFAIK behavior under printing is a consequence of these DAG structures (and not a motivation for structural changes).

@Mac Dude

The call ssystem("ls; pwd") works for me in the Command Line Interface (aka CLI, or tty interface) on Linux, but not in the Standard Java GUI.

I'll submit a bug report.

@nm By dividing by a specific algebraic expression (the lhs of vv's `*` equation) you have removed some information (related to presupposing that expression is not equal to zero), resulting in mathematically lost solutions.

You then describe that as being "ok".

@mmcdara Sorry, try with brackets around the anonymous operator defns, or utilize the syntax proc()...end proc.

Eg,

':-Mean'=(()->1/Pi)

etc.

@mmcdara I'm away from a working copy of Maple for one more week, so I'm afraid I cannot provide any implementation.

But I forgot to mention: For Median and Mean should you not be passing procedures, even in the case of constant values? Eg,

':-Mean'=()->1/Pi, ':-Median'=()->exp(-1)

 

Your problematic code does not follow any valid or documented calling sequence of the Statistics:-Distribution command, as far as I know.

Why not use a documented calling sequence? You could programatically generate the arguments passed to Distribution based on the attributes you've extracted (and your choice of parameter values, say). A table or piecewise or if-then could serve, keyed say upon the ParentName.

Perhaps you are simply experimenting and got curious. Otherwise you'd simply use Statistics:-Specialize on an original general instance, no?

edit: What I'm trying to get at is that it seem like a simple lookup scheme could convert the extracted ParameterName and Parameters attributes' values to the more conventional documented construction calling sequence.

@Mac Dude To be clear, I did not originally mean that a custom file would be created anew for each call (although that is an alternate approach which I was considering).

I meant that the single custom file would accept the full set of arguments that you are now passing to ssystem. This file would be written just once. Its first line would be, say,

#!/bin/tcsh

on Unix/Linux (and I don't know what on OSX). It could set its PATH and PYTHONPATH or other environment variables. It would pass along its arguments to a call to python.

 

 

Do you have a valid Maple license?

Stop posting duplicates of this question.

If you have additional details, add yhe here as a Reply/Comment on the original Question.

@adel-00 Sorry, I will be travelling for 3 weeks and have no Maple access.

Perhaps next time you could provide the correct expressions up front.

@mmcdara It's great that you found it, Statistics:-Specialize.

You last comment also has a struck-out fragment containing (mu, sigma) -> RandomVariable(Normal(mu, sigma)) . Please note that that is a procedure which generates new RVs from scratch, and not a tool for specializing/instantiating a given, extant RV (which was actually your Question). It might accomplish your goal, but it doesn't do precisely what you asked.

Please add your followup queries on this here, instead of as separate Questions.

@denitsastaicova Now you've changed your request. At first you asked how to use your given z1 to shade via colorscheme with zgradient. And now it seems as if you'd prefer a slightly different scaling and transition for the gradient of values than are in the z1 which you originally supplied.

You've subsequently added the information that what you really want is a way to visually discern the highest z1 values easily. Well, your problem there is in your choice of a zgradient from Black to RoyalBlue. But I didn't suggest that scheme... you did!

But there is another approach which can use any computed z1 in its own "zgradient" colorscheme to generate coloring data. That coloring data can then be extracted and re-used as a coloring replacement in a x1,y1 point-plot. See below for an example.

You can also adjust the scaling in the z1 to get a different pace of color gradient. (I've provided an additional example below.)

Or you can choose different colors for the gradient. Or you can use 1-~z1 to reverse your original color gradient. It's up to you which color gradient pleases you most. What I'm showing is that, yes, a 3rd list like z1 can indeed be used to denote the colorscheme zgradient in a point plot of x1 vs y1. I leave it to you to devise which z1 values and which colors for the gradient you want.

restart;

x1:=[seq(x,x=1..2,0.02)]:
y1:=[seq(y^3,y=1..2,0.02)]:
z1:=[seq(x1[i]/y1[i],i=1..51)]:

P:=plots:-pointplot([x1,y1],
                    gridlines=false,
                    symbol=solidcircle, symbolsize=15,
                    colorscheme=["zgradient",["Red"]]):

C:=indets(plots:-pointplot([x1,z1],
                           colorscheme=["zgradient",["Black","Blue"]]),
          specfunc({COLOR,COLOUR}))[1]:

subsindets(P,specfunc({COLOR,COLOUR}),()->C);

z2:=ListTools:-Reverse(1-~z1):

C2:=indets(plots:-pointplot([x1,z2],
                           colorscheme=["zgradient",["Black","Blue"]]),
          specfunc({COLOR,COLOUR}))[1]:

subsindets(P,specfunc({COLOR,COLOUR}),()->C2);

 

Download color_pointplot2.mw

First 209 210 211 212 213 214 215 Last Page 211 of 592