1. I use both Maple and Matlab
2. I also install (a stripped down version of) Maple as the "symbolic toolbox" for Matlab using the executable MapleToolbox2022.0WindowsX64Installer.exe, which lives in C:\Program Files\Maple 2022. This gives me acces to (some) symbolic computation capability from within Matlab.
3. This installation process has been working for as long as I remember, certainly more than 10 years
4. With Maple 2022 and Matlab R2022a, this installation process ran with no problems and I can perform symbolic computation within Matlab
5. However, although the Matlab help lists the Maple toolbox as supplemental software (as in all previous releases), I can no longer acces help for Maple from within Matlab - I just get a "Page not found" message
6. The relevant Maple "help" is at the same place within the Matlab folder structure which is C:\Program Files\MATLAB\R2022a\toolbox\maple\html
7. I have just spoken to support at Matlab and they claim tha this must be a Maple (or Maple toolbox installer issue) - so nothing to do with them!
8. Has anyone else had a similar problem andd found a workaround?

Maple 2022:

It appears that one can use push_back() with an empty DEQueue(), but not push_front().

Since the queue is double-ended and empty, this doesn't make much sense to me. So should this be considered a "bug"?

See the attached

Download DEQueue_Prob.mw

Under certain special circumstances it seems that Maple is converting floats to rationals - I noticed this in Maple 2021 when a^0.5 evaluated to sqrt(a). Prior to Maple 2017, a^0.5, evaluates to a^0.5.

Can anyone think of a reason for this change?

I'm not quite sure why it bothers me, but it does

See the attached for Maple 2016 and Maple 2017.

Download odd2017.mw

Download odd2016.mw

Background

This 'quirk' of Maple behaviour cropped up when I was considering solutions for the question posted here

https://www.mapleprimes.com/questions/232433-Extract-From-Record

where the OP had "poorly structured" data which meant it was a bit "awkward" to access required fields. A number of more-or-less satisfactory solution were proposed, and the OP seems happy

The Issue

One possible way to solve the original problem would be to restructure the data as a DataFrame. The "natural" way to do this would be to use numeric row indexes.. Note that these row indexes are not contiguous, and are in no particular order. However using this approach means that accessing fields from the dataframe is not consistent.

Sometimes the supplied row label is interpreted as a 'label', sometimes it is interpreted as the "row number". It appears that the latter interpretation is preferentially used

I can't make up my mind whether to call this a "bug" or not, but I can see the inconsistent interpretation resulting in chaos.

Before submitting an SCR I'd like to know if anyone else sees this as a bug

Consider the code

  restart;
  prettyprint=1:
#
# data
#
  S := [`206` = Record(mu = 508.001018040,  sigma = 125.002863204708),
          `4` = Record(mu = 1008.001018040, sigma = 167.707232430134),
          `2` = Record(mu = 1208.001018040, sigma = 141.512246146314),
          `5` = Record(mu = 808.001018040,  sigma = 117.156800098735)
       ]:
#
# Construct the above as a dataframe - note row labels are numbers!
#
  DF:= DataFrame( Matrix([seq( [rhs(j):-mu, rhs(j):-sigma], j in S)]),
                  rows= [seq( parse( lhs(j) ), j in S)],
                  columns=[mu, sigma]
              );
  DF[206, mu];
  DF[2, mu];  ## Errr No!
  DF[5, sigma];
               [           mu             sigma      ]
               [                                     ]
               [206  508.001018040   125.002863204708]
               [                                     ]
         DF := [ 4   1008.001018040  167.707232430134]
               [                                     ]
               [ 2   1208.001018040  141.512246146314]
               [                                     ]
               [ 5   808.001018040   117.156800098735]

                         508.001018040

                         1008.001018040

                        117.156800098735

Note that DF[2, mu] outputs the entry from the second row - not the one from the row labelled with the number 2

I imagina a similar issue would occur with numeric column indexes, although I haven't tried this
     

There seems to be an "issue" when using a indexed name (say x[4]) as the loop index in a seq() mul() or add() command - the indexed name is assigned once the command exits!!

This never(?) happens if the loop index is not an indexed name. A bug??

See the attached which illustrates the issue for the add() command, where x[4] is assigned on exit from add(). The same thing happens if add() is replaced with seq() or mul()

Download aBug.mw