acer

32348 Reputation

29 Badges

19 years, 330 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

Please put your followup details in Comments to this Question, rather than spreading the issue across additional, disjoint Questions.

@juju1234 There were some major changes to 2D Input in Maple 2017, and there have been a few reports of bugs in the results of using the Matrix palette.

I have not been able to recreate the problem, however, using the same steps that you've described. I've tried Maple 2017.0, 2017.1, and 2017.2 (and your document matched one of those...).

If you don't want to have to keep saving/re-opening then you could try entering your Matrix (even in 2D Input mode) using either the Matrix(...) or the <...> constructors. I suspect that then you would be able to go back and edit the input line's Matrix entries without this issue.

@vv I believe that the delayDotProduct is not the cause of the posted error. The posted error appears to be in the handling of the parameters a and b used in the operator for `=`. I suspect a problem in Typesetting:-Parse or possibly ToInert.

As the OP mentioned, changing the names of the parameters in the problematic operator resolved the error. I saw the same, with even changing just parameter a to say aa.

I don't know exactly how it is becoming confused. It's possible that one of the earlier instances of parameters named a is being reused by mistake somehow, during parsing. Just a guess.
 

restart;

with(GroupTheory):

goodQgr := (sgr, gr) -> GroupTheory:-CustomGroup(GroupTheory:-LeftCosets(sgr, gr),
  `.` = ((a, b) -> GroupTheory:-LeftCoset(Representative(a) . Representative(b), sgr)),
  `/` = ((a) -> GroupTheory:-LeftCoset(Representative(a)^(-1), sgr)),
  `=` = ((a, b) -> GroupTheory:-Elements(a) = GroupTheory:-Elements(b))):

badQgr := proc (sgr, gr) options operator, arrow; GroupTheory:-CustomGroup(GroupTheory:-LeftCosets(sgr, gr), `.` = (proc (a, b) options operator, arrow; GroupTheory:-LeftCoset(Representative(a).Representative(b), sgr) end proc), `/` = (proc (a) options operator, arrow; GroupTheory:-LeftCoset(1/Representative(a), sgr) end proc), `=` = (proc (a, b) options operator, arrow; GroupTheory:-Elements(a) = GroupTheory:-Elements(b) end proc)) end proc

proc (sgr, gr) options operator, arrow; GroupTheory:-CustomGroup(GroupTheory:-LeftCosets(sgr, gr), `.` = (proc (a, b) options operator, arrow; GroupTheory:-LeftCoset(Representative(a).Representative(b), sgr) end proc), `/` = (proc (a) options operator, arrow; GroupTheory:-LeftCoset(1/Representative(a), sgr) end proc), `=` = (proc (a, b) options operator, arrow; GroupTheory:-Elements(a) = GroupTheory:-Elements(b) end proc)) end proc

gr := QuaternionGroup():

#Generators(gr);

goodqgr := goodQgr(Subgroup({Generators(gr)[1]^2}, gr), gr);

_m353100040

badqgr := badQgr(Subgroup({Generators(gr)[1]^2}, gr), gr);

_m353078944

AreIsomorphic(goodqgr, DirectProduct(CyclicGroup(2), CyclicGroup(2)));

true

AreIsomorphic(badqgr, DirectProduct(CyclicGroup(2), CyclicGroup(2)));

Error, (in =) invalid keyword expression

Feq := proc (a, b) options operator, arrow; GroupTheory:-Elements(a) = GroupTheory:-Elements(b) end proc; betterQgr := proc (sgr, gr) options operator, arrow; GroupTheory:-CustomGroup(GroupTheory:-LeftCosets(sgr, gr), `.` = (proc (a, b) options operator, arrow; GroupTheory:-LeftCoset(Representative(a).Representative(b), sgr) end proc), `/` = (proc (a) options operator, arrow; GroupTheory:-LeftCoset(1/Representative(a), sgr) end proc), `=` = Feq) end proc

proc (sgr, gr) options operator, arrow; GroupTheory:-CustomGroup(GroupTheory:-LeftCosets(sgr, gr), `.` = (proc (a, b) options operator, arrow; GroupTheory:-LeftCoset(Typesetting:-delayDotProduct(Representative(a), Representative(b)), sgr) end proc), `/` = (proc (a) options operator, arrow; GroupTheory:-LeftCoset(1/Representative(a), sgr) end proc), `=` = Feq) end proc

betterqgr := betterQgr(Subgroup({Generators(gr)[1]^2}, gr), gr);

_m342777244

AreIsomorphic(betterqgr, DirectProduct(CyclicGroup(2), CyclicGroup(2)));

true

kernelopts(version);

`Maple 2017.2, IBM INTEL NT, Jul 19 2017, Build ID 1247392`

 


 

Download areiso.mw

@tomleslie Agreed the question makes little sense as written.

Perhaps he wants,

  convert(a, rational)

or,

  convert(a, rational, exact)

What do you want it to look like?

@Volker Lehner I suggest that you switch your GUI settings (preferences) so that by default you get "1D Maple Notation" input instead of "2D Input", and a "Worksheet" instead of a "Document".

Manual editing of 2D Input is awkward and buggy.

Please upload the document, so that we could examine it. Use the green up-arrow in the Mapleprimes editor.

@tomleslie I interpreted Christopher's comment as being general, and so was my answer. As such, both are accurate.

You'd already made your points about the fitting periodic data/functions in your answer. It might not be the case here, but in general your claim is wrong that local vs global solutions don't come into it. A nonlinear fitting problem could have both a globally optimal fit (according to some metric) as well as a one or more inferior locally optimal fit (by same metric), both of which could be accompanied by their respective equivalently good fits at periodic intervals.

@Christopher2222 The issue is that the Statistics:-Fit command utilizes local optimization solvers, and for a nonlinear problem the local minima may exist which are not (even very close to) the global mimimum. What is so wonderful about the DirectSearch package is that not only does it contain global optimization solvers but it also contains curve-fitting/regression front-ends which utilize those solvers. And those curve-fitting commands also have a healthy choice of metric (ie. defn of residuals by several formula, allowing for various concepts of "best fit").

@itsme 

I notice that site has already been updated (both comments and functionality chart) since you first posted this, and following the discusions above. (I too wonder why comments were deleted.)

These seem to work, as of Maple 2017.0 ,

is(`Or`(k::posint, k::negint, k = 0)) assuming k::integer;

                              true

is(`Or`(k::negint, k::nonnegint)) assuming k::integer;

                              true

is(`Or`(k::posint, k::nonposint)) assuming k::integer;

                              true

@Carl Love Quite a bit of the time seems to be spent in convert(...,listlist) and in the Matrix constructor.

Does this produce the same result, just with listlist until the the subtraction?

It gets me about a factor of six better timing.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id := [seq([seq(0,j=1..i-1),1,seq(0,j=i+1..n)],i=1..n)];
MF:= {seq(Id+Id[d,..], d= remove(p-> ormap(evalb, p =~ N), Sn))}:
MA:= {seq(seq(M[p,..], M= MF), p= Sn)}:
Ones:= Matrix((n$2), 1):
MA:= {seq(Ones - rtable(M,subtype=Matrix), M= MA)}:
time() - st;

Assuming that I haven't inadvertantly broken it, on my machine this seems to indicate that about half the time here is spent in producing Matrices from the listlists.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id := [seq([seq(0,j=1..i-1),1,seq(0,j=i+1..n)],i=1..n)];
MF:= {seq(Id+Id[d,..], d= remove(p-> ormap(evalb, p =~ N), Sn))}:
MA:= {seq(seq(M[p,..], M= MF), p= Sn)}:
MA:= eval(MA,[1=0,0=1]):
time() - st;
MA:= {seq(rtable(1..n,1..n,M,subtype=Matrix), M= MA)}:
time() - st;

@Carl Love At a brief glance (because the OP hasn't yet supplied actual re-usable code) I wonder whether there might be a problem in the float-range, eg. double-precision under evalhf during computation, or perhaps even single-precision during rendering. If the former is the case then it might be that UseHardwareFloats:=false of raising Digits>16 (to prevent evalhf) might help. It looks like increased working precision might be useful for the example just on numerical grounds. But that's just a wild guess based on eye-balling it briefly.

@_Maxim_ Yes, all valid types are properties.

I agree about the documentation of properties. (btw, who would know to use AndProp versus And or `and`, just by reading the help pages?!)

This problematic behavior of `and` -- the unwanted evalb of `=` and `<>` -- is a kernel thing. Perhaps it's fixable. I know it can catch out even expert users. I'll submit another bug report on it.

For use with `is` or `assuming` , you could try using `And` instead.

@John Fredsted I would say that using the `<>` angle-bracket constructor and/or Matrix/Vector indexing is shorter and (as a unified approach) more easy to use overall than some bunch of commands like Augment, Stack, AddRow, DeleteRow, AddColumn, DeleteColumn, etc. But I'd also say that clear, simple examples of the related functionality are not found in help pages that are well referenced.

What I'd like to see are more representative examples on the help page to which Kitonum referred.

Also, it's always been the case the there are not enough cross-references (and help aliases) for the rtable_indexing help page. Perhaps that page is over-complicated. Perhaps that Matrix and Vector Construction Shortcuts page should also include simple example of indexing, so that removal of certain rows and columns is shown next to to examples of adding them. After all, Matrix indexing provides a short cut for DeleteRow and DeleteColumn.

It's unfortunate that the two pages mentioned above don't have cross-references to each other.

While I'm griping, I find it not useful that the See Also references from help pages are ordered alphabetically rather than by relevance/importance.

First 271 272 273 274 275 276 277 Last Page 273 of 592