MaplePrimes Commons General Technical Discussions

Reversion of series: Looking for "ambiverts"

by: rcorless 710 Product: Maple

September 23 2021

1 5

Dear all,

Reversion of series---computing a series for the functional inverse of a function---has been in Maple since forever, but many people are not aware of how easy it is. Here's an example, where we are looking for "self-reverting" series---which I called "ambiverts". Anyway have fun.

https://maple.cloud/app/5974582695821312/Series+Reversion%3A+Looking+for+ambiverts

PS There looks to be some "code rot" in the branch point series for Lambert W in Maple, which we encounter in that worksheet. Or, I may simply have not coded it very well in the first place (yeah, that was mine, once upon a time). Checking now. But there is a workaround (albeit an ugly one) shown in that worksheet.

Two remarks about discrete distributions in Maple...

by: sand15 807 Product: Maple 2021

June 08 2021

1 0

... and two suggestions to the development team

POINT 1
In ?DiscreteValueMap (package Statistics) it's given an example concerning rhe Geometric distribution along with this comment:
"The Geometric distribution is discrete but it necessarily assumes integer values, so (bold font is mine) it also does not have a DiscreteValueMap"

This sentence seems to indicate that "because a distribution is discrete over the set of integers, it cannot have a DiscreteValueMap", some sort of logical implication...

But my feeling is that the Geometric distribution (or any other discrete distribution) does not have a DiscreteValueMap because this attribute has just not been specified when defining the distribution.

restart:
with(Statistics):

GeomRV := RandomVariable(Geometric(1/2)):
f := unapply(ProbabilityFunction(GeomRV, n), n):

AnotherGeomRV := Distribution(
      'ProbabilityFunction'=f,
      'Support'=0..infinity,
      'DiscreteValueMap'=(n->n),
      'Type'=discrete
):
DiscreteValueMap(AnotherGeomRV , n);

Thus having the set of natural numbers as support doesn't imply that DiscreteValueMap cannot exist.

Suggestion 1: modify the ?DiscreteValueMap help page so that it no longer suggests that some discrete distributions cannot have a .DiscreteValueMap

______________________________________________________________________________________

POINT 2
I think there exists a true problem with the definition of discrete distributions in Maple: the ProbabilityFunction of a (discrete) random variable) takes non zero values outside their definition set.
For instance

ProbabilityFunction(GeomRV, Pi);  # something non null

To ivercome this problem I defined a new Geometric distribution this way (not entirely satisfying):

restart:
with(Statistics):

GeomRV := RandomVariable(Geometric(1/2)):
f := unapply(ProbabilityFunction(GeomRV, n), n):
g := n -> (1-ceil(n-floor(n)))*f(n)    # (1-ceil(n-floor(n))) = 1 if n in Z, 0 otherwise

AnotherGeomRV := Distribution(
      'ProbabilityFunction'=g,
      'Support'=0..infinity,
      'DiscreteValueMap'=(n->n),  # is wanted
      'Type'=discrete
):
ProbabilityFunction(AnotherGeomRV, 2);
                 1/8
ProbabilityFunction(AnotherGeomRV, Pi);
                  0

PS: None of the statistics based upon the ProbabilityFunction (Mean, Variance, ... ) is correctly computed with the previous construction. This could be easily overcome by completing this definition, just as its done in Maple, for all the requires statistics, for instance

AnotherGeomRV := Distribution(
      ....
      'Mean'=1   # or more generally (1-p)/p form Geometric(p)
):

Suggestion 2: modify the way discrete distributions are defined in Maple in order to avoid ProbabilityFunction to return wrong values.

Math exams: Maplesoft needs to take print/export...

by: erik10 766

March 15 2021

10 15

I am a high school Teacher in Denmark, who have been using Maple since version 12, more than 12 years ago. I suggested it for my school back then and our math faculty finally decided to purchase a school license. We are still there. We have watched Maple improve in a lot of areas (function definitions, context panels, graphically etc., etc ). Often small changes makes a big difference! We have been deligted. We we are mostly interested in improvements in GUI and lower level math, and in animations and quizzes. I have also been enrolled as a beta tester for several years yet.

One of the areas, which is particually important is print and export to pdf, because Danish students have to turn in their papers/solutions at exams in pdf format! I guess the Scandinavian countries are ahead in this department. They may quite possible be behind in other areas however, but this is how it is.

Now my point: Maplesoft is lacking terrible behind when regarding screen look in comparison with print/export to pdf.

I am very frustrated, because I have been pinpointing this problem in several versions of Maple, both on Mapleprimes and in the beta groups. Some time you have corrected it, but it has always been bouncing back again and again! I have come to the opinion that you are not taking it seriously? Why?

Students may loose grades because of missing documentations (marking on graphs etc.).

I will be reporting yet another instance of this same problem. When will it stop?

Erik

Wirtinger derivatives in Maple 2021

by: ecterrab 14400 Product: Maple

March 14 2021

6 0

Wirtinger Derivatives in Maple 2021

Generally speaking, there are two contexts for differentiating complex functions with respect to complex variables. In the first context, called the classical complex analysis, the derivatives of the complex components ( abs , argument , conjugate , Im , Re , signum ) with respect to complex variables do not exist (do not satisfy the Cauchy-Riemann conditions), with the exception of when they are holomorphic functions. All computer algebra systems implement the complex components in this context, and computationally represent all of as functions of z . Then, viewed as functions of z, none of them are analytic, so differentiability becomes an issue.

In the second context, first introduced by Poincare (also called Wirtinger calculus), in brief z and its conjugate are taken as independent variables, and all the six derivatives of the complex components become computable, also with respect to . Technically speaking, Wirtinger calculus permits extending complex differentiation to non-holomorphic functions provided that they are ℝ-differentiable (i.e. differentiable functions of real and imaginary parts, taking as a mapping ).

In simpler terms, this subject is relevant because, in mathematical-physics formulations using paper and pencil, we frequently use Wirtinger calculus automatically. We take z and its conjugate as independent variables, with that , , and we compute with the operators , as partial differential operators that behave as ordinary derivatives. With that, all of , become differentiable, since they are all expressible as functions of z and .

Wirtinger derivatives were implemented in Maple 18 , years ago, in the context of the Physics package. There is a setting, , that when set to true - an that is the default value when Physics is loaded - redefines the differentiation rules turning on Wirtinger calculus. The implementation, however, was incomplete, and the subject escaped through the cracks till recently mentioned in this Mapleprimes post.

Long intro. This post is to present the completion of Wirtinger calculus in Maple, distributed for everybody using Maple 2021 within the Maplesoft Physics Updates v.929 or newer. Load Physics and set the imaginary unit to be represented by

The complex components are represented by the computer algebra functions

(1)

They can all be expressed in terms of and

(2)

The main differentiation rules in the context of Wirtinger derivatives, that is, taking and as independent variables, are

[%diff(Im(z), z) = -(1/2)*I, %diff(Re(z), z) = 1/2, %diff(abs(z), z) = (1/2)*conjugate(z)/abs(z), %diff(argument(z), z) = -((1/2)*I)/z, %diff(conjugate(z), z) = 0, %diff(signum(z), z) = (1/2)/abs(z)]

(3)

Since in this context is taken as - say - a mathematically-atomic variable (the computational representation is still the function ) we can differentiate all the complex components also with respect to

[%diff(Im(z), conjugate(z)) = (1/2)*I, %diff(Re(z), conjugate(z)) = 1/2, %diff(abs(z), conjugate(z)) = (1/2)*z/abs(z), %diff(argument(z), conjugate(z)) = ((1/2)*I)*z/abs(z)^2, %diff(conjugate(z), conjugate(z)) = 1, %diff(signum(z), conjugate(z)) = -(1/2)*z^2/abs(z)^3]

(4)

For example, consider the following algebraic expression, starting with conjugate

(5)

Differentiating this expression with respect to z and taking them as independent variables, is new, and in this example trivial

(6)

(7)

Switch to something less trivial, replace by the real part

(8)

To verify results further below, also express in terms of

(9)

New: differentiate with respect to and

(10)

(11)

Note these results (10) and (11) are expressed in terms of , not . Let's compare with the derivative of where everything is expressed in terms of z and . Take for instance the derivative with respect to z

(12)

To verify this result is mathematically equal to (10) expressed in terms of take the difference of the right-hand sides

(13)

One quick way to verify the value of expressions like this one is to replace and simplify and are real

(14)

(15)

The equivalent differentiation, this time replacing in by ; construct also the equivalent expression in terms of and for verifying results

(16)

(17)

Since these two expressions are mathematically equal, their derivatives should be too, and the derivatives of can be verified by eye since and are taken as independent variables

(18)

(19)

Eq (18) is expressed in terms of while (19) is in terms of . Comparing as done in (14)

(20)

(1/2)*(a-I*b)/(a^2+b^2)^(1/2)-(a+I*b)*(a-I*b)+a^2+b^2-(1/2)*(a-I*b)/((a+I*b)*(a-I*b))^(1/2) = 0

(21)

(22)

To mention but one not so famliar case, consider the derivative of the sign of a complex number, represented in Maple by . So our testing expression is

(23)

This expression can also be rewritten in terms of and

z/(z*conjugate(z))^(1/2)+z^2/conjugate(z)

(24)

This time differentiate with respect to ,

%diff(signum(z)+z*signum(z)^2, conjugate(z)) = -(1/2)*z^2/abs(z)^3-z^3*signum(z)/abs(z)^3

(25)

Here again, the differentiation of , that is expressed entirely in terms of and , can be computed by eye

%diff(z/(z*conjugate(z))^(1/2)+z^2/conjugate(z), conjugate(z)) = -(1/2)*z^2/(z*conjugate(z))^(3/2)-z^2/conjugate(z)^2

(26)

Eq (25) is expressed in terms of while (26) is in terms of . Comparing as done in (14),

-(1/2)*z^2/abs(z)^3-z^3*signum(z)/abs(z)^3+(1/2)*z^2/(z*conjugate(z))^(3/2)+z^2/conjugate(z)^2 = 0

(27)

-(1/2)*(a+I*b)^2/(a^2+b^2)^(3/2)-(a+I*b)^4/(a^2+b^2)^2+(1/2)*(a+I*b)^2/((a+I*b)*(a-I*b))^(3/2)+(a+I*b)^2/(a-I*b)^2 = 0

(28)

(29)

Download Wirtinger_Derivatives.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Maple Calculator – now with steps!

by: Karishma 805 Product: Maple Calculator

March 01 2021

8 0

I’m very pleased to announce that the Maple Calculator app now offers step-by-step solutions. Maple Calculator is a free mobile app that makes it easy to enter, solve, and visualize mathematical problems from algebra, precalculus, calculus, linear algebra, and differential equations, right on your phone. Solution steps have been, by far, the most requested feature from Maple Calculator users, so we are pretty excited about being able to offer this functionality to our customers. With steps, students can use the app not just to check if their own work is correct, but to find the source of the problem if they made a mistake. They can also use the steps to learn how to approach problems they are unfamiliar with.

Steps are available in Maple Calculator for a wide variety of problems, including solving equations and systems of equations, finding limits, derivatives, and integrals, and performing matrix operations such as finding inverses and eigenvalues.

(*Spoiler alert* You may also want to keep a look-out for more step-by-step solution abilities in the next Maple release.)

If you are unfamiliar with the Maple Calculator app, you can find more information and app store links on the Maple Calculator product page. One feature in particular to note for Maple and Maple Learn users is that you can use the app to take a picture of your math and load those math expressions into Maple or Maple Learn. It makes for a fast, accurate method for entering large expressions, so even if you aren’t interested in doing math on your phone, you still might find the app useful.

Pythagorean Triples Ternary Tree

by: Fereydoon_Shekofte 223 Product: Maple 18

February 26 2021

1 0

I make a maple worksheet for generating Pythagorean Triples Ternary Tree :

Around 10,000 records in the matrix currently !

You can set your desire size or export the Matrix as text ...

But yet ! I wish to understand from you better techniques If you have some suggestion ?

the mapleprimes Don't load my worksheet for preview so i put a screenshot !

Pythagoras_ternary.mw

Pythagoras_ternary_data.mw

Pythagoras_ternary_maple.mw

Maple Evaluation Order Example

by: Valerie 132 Product: Maple 2020

February 08 2021

3 4

The order in which expressions evaluate in Maple is something that occasionally causes even advanced users to make syntax errors.

I recently saw a single line of Maple code that provided a good example of a command not evaluating in the order the user desired.

The command in question (after calling with(plots):) was

animate(display, [arrow(<cos(t), sin(t)>)], t = 0 .. 2*Pi)

This resulted in the error:

Error, (in plots/arrow) invalid input: plottools:-arrow expects its 3rd argument, pv, to be of type {Vector, list, vector, complexcons, realcons}, but received 0.5000000000e-1*(cos(t)^2+sin(t)^2)^(1/2)

This error indicates that the issue in the animation is the arrow command

arrow(<cos(t), sin(t)>)

on its own, the above command would give the same error. However, the animate command takes values of t from 0 to 2*Pi and substitutes them in, so at first glance, you wouldn't expect the same error to occur.

What is happening is that the command

arrow(<cos(t), sin(t)>)

in the animate expression is evaluating fully, BEFORE the call to animate is happening. This is due to Maple's automatic simplification (since if this expression contained large expressions, or the values were calculated from other function calls, that could be simplified down, you'd want that to happen first to prevent unneeded calculation time at each step).

So the question is how do we stop it evaluating ahead of time since that isn't what we want to happen in this case?

In order to do this we can use uneval quotes (the single quotes on the keyboard - not to be confused with the backticks).

animate(display, ['arrow'(<cos(t), sin(t)>)], t = 0 .. 2*Pi)

By surrounding the arrow function call in the uneval quotes, the evaluation is delayed by a level, allowing the animate call to happen first so that each value of t is then substituted before the arrow command is called.

Maple_Evaluation_Order_Example.mw

What to take care of when entering a tetrad

by: Freddy Baudine 70 Product: Maple 2020

October 27 2020

6 1

In the study of the Gödel spacetime model, a tetrad was suggested in the literature [1]. Alas, upon entering the tetrad in question, Maple's Tetrad's package complained that that matrix was not a tetrad! What went wrong? After an exchange with Edgardo S. Cheb-Terrab, Edgardo provided us with awfully useful comments regarding the use of the package and suggested that the problem together with its solution be presented in a post, as others may find it of some use for their work as well.

The Gödel spacetime solution to Einsten's equations is as follows.

>

(1)

>

((`Defined as spacetime tensors representing the NP null vectors of the tetrad formalism `*`see <a href='http://www.maplesoft.com/support/help/search.aspx?term=Physics,tetrads`*`,' target='_new'>?Physics,tetrads`*`,</a> `*l[mu]*`, `)*n[mu]*`, `*m[mu]*`, `)*conjugate(m[mu])

(2)

Working with Cartesian coordinates,

>

(3)

the Gödel line element is

>

(4)

Setting the metric

>

Physics:-g_[mu, nu] = Matrix(%id = 18446744078354506566)

$[metric = {(1, 1) = -1, (2, 2) = -1, (3, 3) = (1/2)*exp(2*q*y), (3, 4) = exp(q*y), (4, 4) = 1}, spaceindices = lowercaselatin_is]$

(5)

The problem appeared upon entering the matrix M below supposedly representing the alleged tetrad.

>

Matrix(%id = 18446744078162949534)

(6)

Each of the rows of this matrix is supposed to be one of the null vectors . Before setting this alleged tetrad, Maple was asked to settle the nature of it, and the answer was that M was not a tetrad! With the Physics Updates v.857, a more detailed message was issued:

>

`Warning, the given components form a`*null*`tetrad, `*`with a contravariant spacetime index`*`, only if you change the signature from `*`- - - +`*` to `*`+ - - -`*`.
You can do that by entering (copy and paste): `*Setup(signature = "+ - - -")

(7)

So there were actually three problems:

1.	The entered entity was a null tetrad, while the default of the Physics package is an orthonormal tetrad. This can be seen in the form of the tetrad metric, or using the library commands:

>

Physics:-Tetrads:-eta_[a, b] = Matrix(%id = 18446744078354552462)

(8)

>

(9)

>

(10)

2.

The matrix M would only be a tetrad if the spacetime index is contravariant. On the other hand, the command IsTetrad will return true only when M represents a tetrad with both indices covariant. For instance, if the command IsTetrad is issued about the tetrad automatically computed by Maple, but is passed the matrix corresponding to with the spacetime index contravariant, false is returned:

>

Physics:-Tetrads:-e_[a, `~μ`] = Matrix(%id = 18446744078297840926)

(11)

>

(12)

3.	The matrix M corresponds to a tetrad with different signature, (+---), instead of Maple's default (---+). Although these two signatures represent the same physics, they differ in the ordering of rows and columns: the timelike component is respectively in positions 1 and 4.

The issue, then, became how to correct the matrix M to be a valid tetrad: either change the setup, or change the matrix M. Below the two courses of action are provided.

First the simplest: change the settings. According to the message (7), setting the tetrad to be null, changing the signature to be (+---) and indicating that M represents a tetrad with its spacetime index contravariant would suffice:

>

(13)

The null tetrad metric is now as in the reference used.

>

Physics:-Tetrads:-eta_[a, b] = Matrix(%id = 18446744078298386174)

(14)

Checking now with the spacetime index contravariant

>

Physics:-Tetrads:-e_[a, `~μ`] = Matrix(%id = 18446744078162949534)

(15)

At this point, the command IsTetrad provided with the equation (15), where the left-hand side has the information that the spacetime index is contravariant

>

(16)

Great! one can now set the tetrad M exactly as entered, without changing anything else. In the next line it will only be necessary to indicate that the spacetime index, , is contravariant.

>

$[tetrad = {(1, 1) = -(1/2)*2^(1/2), (1, 3) = (1/2)*2^(1/2)*exp(q*y), (1, 4) = (1/2)*2^(1/2), (2, 1) = (1/2)*2^(1/2), (2, 3) = (1/2)*2^(1/2)*exp(q*y), (2, 4) = (1/2)*2^(1/2), (3, 2) = -(1/2)*2^(1/2), (3, 3) = ((1/2)*I)*exp(q*y), (3, 4) = 0, (4, 2) = -(1/2)*2^(1/2), (4, 3) = -((1/2)*I)*exp(q*y), (4, 4) = 0}]$

(17)

The tetrad is now the matrix M. In addition to checking this tetrad making use of the IsTetrad command, it is also possible to check the definitions of tetrads and null vectors using TensorArray.

>

(18)

>

Matrix(%id = 18446744078353048270)

(19)

For the null vectors:

>

(20)

>

[0 = 0, 1 = 1, 0 = 0, 0 = 0, Matrix(%id = 18446744078414241910)]

(21)

From its Weyl scalars, this tetrad is already in the canonical form for a spacetime of Petrov type "D": only

>

(22)

>

(23)

Attempting to transform it into canonicalform returns the tetrad (17) itself

>

Matrix(%id = 18446744078396685478)

(24)

Let's now obtain the correct tetrad without changing the signature as done in (13).

Start by changing the signature back to

>

(25)

So again, M is not a tetrad, even if the spacetime index is specified as contravariant.

>

`Warning, the given components form a`*null*`tetrad, `*`with a contravariant spacetime index`*`, only if you change the signature from `*`- - - +`*` to `*`+ - - -`*`.
You can do that by entering (copy and paste): `*Setup(signature = "+ - - -")

(26)

By construction, the tetrad M has its rows formed by the null vectors with the ordering . To understand what needs to be changed in M, define those vectors, independent of the null vectors (with underscore) that come with the Tetrads package.

>

and set their components using the matrix M taking into account that its spacetime index is contravariant, and equating the rows of M using the ordering :

>

[l[`~μ`] = Vector[row](%id = 18446744078368885086), n[`~μ`] = Vector[row](%id = 18446744078368885206), m[`~μ`] = Vector[row](%id = 18446744078368885326), mb[`~μ`] = Vector[row](%id = 18446744078368885446)]

(27)

>

${Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], Physics:-Tetrads:-e_[a, mu], Physics:-Tetrads:-eta_[a, b], Physics:-g_[mu, nu], Physics:-gamma_[i, j], Physics:-Tetrads:-gamma_[a, b, c], l[mu], Physics:-Tetrads:-l_[mu], Physics:-Tetrads:-lambda_[a, b, c], m[mu], Physics:-Tetrads:-m_[mu], mb[mu], Physics:-Tetrads:-mb_[mu], n[mu], Physics:-Tetrads:-n_[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}$

(28)

Check the covariant components of these vectors towards comparing them with the lines of the Maple's tetrad

>

l[mu] = Array(%id = 18446744078298368710), n[mu] = Array(%id = 18446744078298365214), m[mu] = Array(%id = 18446744078298359558), mb[mu] = Array(%id = 18446744078298341734)

(29)

This shows the null vectors (with underscore) that come with Tetrads package

>

Physics:-Tetrads:-l_[mu] = Vector[row](%id = 18446744078354520414), Physics:-Tetrads:-n_[mu] = Vector[row](%id = 18446744078354520534), Physics:-Tetrads:-m_[mu] = Vector[row](%id = 18446744078354520654), Physics:-Tetrads:-mb_[mu] = Vector[row](%id = 18446744078354520774)

(30)

So (29) computed from M is the same as (30) computed from Maple's tetrad.

But, from (30) and the form of Maple's tetrad

>

Physics:-Tetrads:-e_[a, mu] = Matrix(%id = 18446744078297844182)

(31)

for the current signature

>

(32)

we see the ordering of the null vectors is , not used in [1] with the signature (+ - - -). So the adjustment required in M, resulting in , consists of reordering M's rows to be

>

Matrix(%id = 18446744078414243230)

(33)

>

(34)

Comparing with the tetrad computed by Maple ((24) and (31), they are actually the same.

References

[1]. Rainer Burghardt, "Constructing the Godel Universe", the arxiv gr-qc/0106070 2001.

[2]. Frank Grave and Michael Buser, "Visiting the Gödel Universe", IEEE Trans Vis Comput GRAPH, 14(6):1563-70, 2008.

Download Godel_universe_and_Tedrads.mw

Workaround for the problem of installing MapleCloud...

by: ecterrab 14400 Product: Maple 2020

September 24 2020

9 8

Hi,
Some people using the Windows platform have had problems installing MapleCloud packages, including the Maplesoft Physics Updates. This problem does not happen in Macintosh or Linux/Unix, also does not happen with all Windows computers but with some of them, and is not a problem of the MapleCloud packages themselves, but a problem of the installer of packages.

I understand that a solution to this problem will be presented within an upcoming Maple dot release.

Meantime, there is a solution by installing a helper library; after that, MapleCloud packages install without problems in all Windows machines. So whoever is having trouble installing MapleCloud packages in Windows and prefers not to wait until that dot release, instead wants to install this helper library, please email me at physics@maplesoft.com.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

integration example

by: acer 31926 Product: Maple

May 06 2020

5 2

There is an interesting preprint here, on a method for integration of some pseudo-elliptic integrals.

It was mentioned in a (sci.math.symbolic) usenet thread, which can be accessed via Google Groups here.

Inside the paper, the author mentions that the following is possible for some cases -- to first convert to RootOf form.

>

restart;

>	kernelopts(version);

>	ig:=((-3+x^2)(1-6x^2+x^4)^(-1/4))/(-1+x^2);

(x^2-3)/((x^4-6*x^2+1)^(1/4)*(x^2-1))

>	int(ig,x);

int((x^2-3)/((x^4-6*x^2+1)^(1/4)*(x^2-1)), x)

>	infolevel[int] := 2:

>	S:=simplify([allvalues(int(convert(ig,RootOf),x))],size):

Stage1: first-stage indefinite integration

Stage2: second-stage indefinite integration

Norman: enter Risch-Norman integrator

Norman: exit Risch-Norman integrator

int/algrisch/int: Risch/Trager's algorithm for algebraic function

int/algrisch/int: entering integrator at time 9.029

int/algrisch/int: function field has degree 4

int/algrisch/int: computation of an integral basis: start time 9.031

int/algrisch/int: computation of an integral basis: end time 9.038

int/algrisch/int: normalization at infinity: start time 9.039

int/algrisch/int: normalization at infinity: end time 9.048

int/algrisch/int: genus of the function field 3

int/algrisch/int: computation of the algebraic part: start time 9.059

int/algrisch/int: computation of the algebraic part: end time 9.060

int/algrisch/int: computation of the transcendental part: start time 9.063

int/algrisch/transcpar: computing a basis for the residues at time 9.068

int/algrisch/residues: computing a splitting field at time 9.068

int/algrisch/transcpar: basis for the residues computed at time 9.103

int/algrisch/transcpar: dimension is 2

int/algrisch/transcpar: building divisors at time 9.300

int/algrisch/transcpar: testing divisors for principality at time 9.605

int/algrisch/goodprime: searching for a good prime at time 9.606

int/algrisch/goodprime: good prime found at time 9.704

int/algrisch/goodprime: searching for a good prime at time 9.704

int/algrisch/goodprime: good prime found at time 9.762

int/algrisch/areprinc: the divisor is principal: time 10.084

int/algrisch/areprinc: the divisor is principal: time 11.833

int/algrisch/transcpar: divisors proven pincipal at time at time 11.833

int/algrisch/transcpar: generators computed at time 11.834

int/algrisch/transcpar: orders are [1 1]

int/algrisch/transcpar: check that the candidate is an actual antiderivative

int/algrisch/transcpar: the antiderivative is elementary

int/algrisch/transcpar: antiderivative is (1/2)*ln((RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)^3*_z^3-RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)^2*_z^4+RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)^2*_z^2-3*_z^3*RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)+RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)*_z-5*_z^2+1)/((_z+1)*(_z-1)*_z^2))+(1/2)*RootOf(_Z^2+1)*ln((RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)^2*RootOf(_Z^2+1)*_z^4+RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)^3*_z^3-RootOf(_Z^2+1)*RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)^2*_z^2+3*_z^3*RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)-5*RootOf(_Z^2+1)*_z^2-RootOf(_Z^4*_z^4-_z^4+6*_z^2-1 index = 1)*_z+RootOf(_Z^2+1))/((_z+1)*(_z-1)*_z^2))

int/algrisch/int: computation of the transcendental part: end time 12.040

int/algrisch/int: exiting integrator for algebraic functions at time 12.041

>

S[1];

(1/2)*ln(-((x^4-6*x^2+1)^(3/4)*x+(x^4-6*x^2+1)^(1/2)*x^2+(x^4-6*x^2+1)^(1/4)*x^3+x^4-(x^4-6*x^2+1)^(1/2)-3*(x^4-6*x^2+1)^(1/4)*x-5*x^2)/((x+1)*(x-1)))+((1/2)*I)*ln((-(x^4-6*x^2+1)^(3/4)*x+(I*x^2-I)*(x^4-6*x^2+1)^(1/2)+(x^3-3*x)*(x^4-6*x^2+1)^(1/4)-I*x^2*(x^2-5))/((x+1)*(x-1)))

>

S[2];

(1/2)*ln(-((x^4-6*x^2+1)^(3/4)*x+(x^4-6*x^2+1)^(1/2)*x^2+(x^4-6*x^2+1)^(1/4)*x^3+x^4-(x^4-6*x^2+1)^(1/2)-3*(x^4-6*x^2+1)^(1/4)*x-5*x^2)/((x+1)*(x-1)))-((1/2)*I)*ln((-(x^4-6*x^2+1)^(3/4)*x+(-I*x^2+I)*(x^4-6*x^2+1)^(1/2)+(x^3-3*x)*(x^4-6*x^2+1)^(1/4)+I*x^2*(x^2-5))/((x+1)*(x-1)))

>	simplify( diff(S[1],x) - ig ), simplify( diff(S[2],x) - ig );

>

Download int_pe.mw

Maple Companion Update

by: Karishma 805 Product: Maple Calculator

May 06 2020

11 0

I’m extremely pleased to introduce the newest update to the Maple Companion. In this time of wide-spread remote learning, tools like the Maple Companion are more important than ever, and I’m happy that our efforts are helping students (and some of their parents!) with at least one small aspect of their life. Since we’ve added a lot of useful features since I last posted about this free mobile app, I wanted to share the ones I’m most excited about.

(If you haven’t heard about the Maple Companion app, you can read more about it here.)

If you use the app primarily to move math into Maple, you’ll be happy to hear that the automatic camera focus has gotten much better over the last couple of updates, and with this latest update, you can now turn on the flash if you need it. For me, these changes have virtually eliminated the need to fiddle with the camera to bring the math in focus, which sometimes happened in earlier versions.

If you use the app to get answers on your phone, that’s gotten much better, too. You can now see plots instantly as you enter your expression in the editor, and watch how the plot changes as you change the expression. You can also get results to many numerical problems results immediately, without having to switch to the results screen. This “calculator mode” is available even if you aren’t connected to the internet. Okay, so there aren’t a lot of students doing their homework on the bus right now, but someday!

Speaking of plots, you can also now view plots full-screen, so you can see more of plot at once without zooming and panning, squinting, or buying a bigger phone.

Finally, if English is not you or your students’ first language, note that the app was recently made available in Spanish, French, German, Russian, Danish, Japanese, and Simplified Chinese.

As always, we’d love you hear your feedback and suggestions. Please leave a comment, or use the feedback forms in the app or our web site.

Visit Maple Companion to learn more, find links to the app stores so you can download the app, and access the feedback form. If you already have it installed, you can get the new release simply by updating the app on your phone.

3D plot size option

by: acer 31926 Product: Maple 2019

January 23 2020

4 7

The ideas here are to allow 3D plotting commands such as plot3d to handle a `size` option similarly to how 2D plotting commands do so, and for the plots:-display command to also handle it for 3D plots.

The size denotes the dimensions of the inlined plotting window, and not the relative lengths of the three axes.

I'd be interested in any new problems introduced with this, eg. export, etc.

>

restart;

>

#
# Using ToInert/FromInert
#
# This might go in an initialzation file.
#
try
  __ver:=(u->:-parse(u[7..:-StringTools:-Search(",",u)-1]))(:-sprintf("%s",:-kernelopts(':-version')));
  if __ver>=18.0 and __ver<=2019.2 then
    __KO:=:-kernelopts(':-opaquemodules'=false);
    :-unprotect(:-Plot:-Options:-Verify:-ProcessParameters);
    __KK:=ToInert(eval(:-Plot:-Options:-Verify:-ProcessParameters)):
    __LL:=[:-op([1,2,1,..],__KK)]:
    __NN:=:-nops(:-remove(:-type,[:-op([1,..],__KK)],
                          ':-specfunc(:-_Inert_SET)'))
          +:-select(:-has,[:-seq([__i,__LL[__i]],
                                 __i=1..:-nops(__LL))],
                    "size")[1][1];
    if :-has(:-op([5,2,2,2,1],__KK),:-_Inert_PARAM(__NN)) then
      __KK:=:-subsop([5,2,2,2,1]
                     =:-subs([:-_Inert_PARAM(__NN)=:-NULL],
                              :-op([5,2,2,2,1],__KK)),__KK);
      :-Plot:-Options:-Verify:-ProcessParameters:=
      :-FromInert(:-subsop([5,2,2,3,1]
                  =:-subs([:-_Inert_STRING("size")=:-NULL],
                          :-op([5,2,2,3,1],__KK)),__KK));
      :-print("3D size patch done");
    else
      :-print("3D size patch not appropriate; possibly already done");
    end if;
  else
    :-print(sprintf("3D size patch not appropriate for version %a"),__ver);
  end if;
catch:
  :-print("3D size patch failed");
finally
  :-protect(:-Plot:-Options:-Verify:-ProcessParameters);
  :-kernelopts(':-opaquemodules'=__KO);
end try:

>

>	P := plot3d(sin(x)*y^2, x=-Pi..Pi, y=-1..1, size=[150,150], font=[Times,5], labels=["","",""]): P;

>	plots:-display(P, size=[300,300], font=[Times,10]);

>	# # inherited from the contourplot3d (the plot3d is unset). # plots:-display( plots:-contourplot3d(sin(x)y^2, x=-Pi..Pi, y=-1..1, thickness=3, contours=20, size=[800,800]), plot3d(sin(x)y^2, x=-Pi..Pi, y=-1..1, color="Gray", transparency=0.1, style=surface) );

>

# Some options should still act as 2D-plot-specific.
#
try plot3d(sin(x)*y^2, x=-Pi..Pi, y=-1..1, legend="Q");
print("Not OK");
catch:
if StringTools:-FormatMessage(lastexception[2..-1])
="the legend option is not available for 3-D plots"
then print("OK"); else print("Not OK"); error; end if; end try;

>

Download 3Dsize_hotedit.mw

If this works fine then it might be a candidate for inclusion in an initialization file, so that it's
automatically available.

Several contentious issues in the treatment of...

by: mmcdara 7631

December 18 2019

1 3

Hi,

This is more of an open discussion than a real question. Maybe it would gain to be displaced in the post section?

Working with discrete random variables I found several inconsistencies or errors.
In no particular order:

The support of a discrete RV is not defined correctly (a real range instead of a countable set)
The plot of the probability function (which, in my opinion, would gain to be renamed "Probability Mass Function, see https://en.wikipedia.org/wiki/Probability_mass_function) is not correct.
The ProbabiliytFunction of a discrte rv of EmpiricalDistribution can be computed at any point, but its formal expression doesn't exist (or at least is not accessible).
Defining the discrete rv "toss of a fair dice" with EmpiricalDistribution and DiscreteUniform gives different results.

The details are given in the attached file and I do hope that the companion text is clear enough to point the issues.
I believe there is no major issues here, but that Maple suffers of some lack of consistencies in the treatment of discrete (at least some) rvs. Nothing that could easily be fixed.

As I said above, if some think this question has no place here and ought to me moved to the post section, please feel free to do it.

Thanks for your attention.

>

restart:

>	with(Statistics):

Two alternate ways to define a discrete random variable on a finite set
of equally likely outcomes.

>	Universe := [$1..6]: toss_1_dice := RandomVariable(EmpiricalDistribution(Universe)); TOSS_1_DICE := RandomVariable(DiscreteUniform(1, 6));

(1)

Let's look to the ProbabilityFunction of each RV

>	ProbabilityFunction(toss_1_dice, x); ProbabilityFunction(TOSS_1_DICE, x);

piecewise(x < 1, 0, x <= 6, 1/6, 6 < x, 0)

(2)

It looks like the procedure ProbabilityFunction is not an attribute of RV with EmpiticalDistribution.
Let's verify

>	law := [attributes(toss_1_dice)][3]: lprint(exports(law))

Conditions, ParentName, Parameters, CDF, DiscreteValueMap, Mean, Median, Mode, ProbabilityFunction, Quantile, Specialize, Support, RandomSample, RandomVariate

Clearly ProbabilityFunction is an attribute of toss_1_dice.

In fact it appears the explanation of the difference of behaviours relies upon different definitions
of the set of outcomes of toss_1_dice and TOSS_1_DICE

>	LAW := [attributes(TOSS_1_DICE)][3]: exports(LAW): law:-Conditions; LAW:-Conditions;

[(Vector(6, {(1) = 1, (2) = 2, (3) = 3, (4) = 4, (5) = 5, (6) = 6}))::rtable]

(3)

From :-Conditions one can see that toss_1_dice is realy a discrete RV defined on a countable set of outcomes,
but that nothing is said about the set over which TOSS_1_DICE is defined.

The truly discrete definition of toss_1_dice is confirmed here :
(the second result is correct

ProbabilityFinction(toss_1_dice, x) = {0 if x < 1, 0 if x > 6, 1/6 if x::integer, 0 otherwise

>	ProbabilityFunction~(toss_1_dice, Universe); ProbabilityFunction~(toss_1_dice, [seq(0..7, 1/2)]);

(4)

One can also see that the Support of both of these RVs are wrong

(see for instance https://en.wikipedia.org/wiki/Discrete_uniform_distribution)

There should be {1, 2, 3, 4, 5, 6}, not a RealRange.

>	Support(toss_1_dice); Support(TOSS_1_DICE);

(5)

>

Now this is the surprising ProbabilityFunction of TOSS_1_DICE.
This obviously wrong result probably linked to the weak definition of the conditions for this RB.

>	# plot(ProbabilityFunction(TOSS_1_DICE, x), x=0..7); plot(ProbabilityFunction(TOSS_1_DICE, x), x=0..7, discont=true)

These differences of treatments raise a lot of questions :
    - Why is a DiscreteUniform RV not defined on a countable set?
    - Why does the ProbabilityFunction of an EmpiricalDistribution return no result
        if its second parameter is not set to one its outcomes.

All this without even mentioning the wrong plot shown above.

I believe something which would work like the module below would be much better than what is done

right now

>

EmpiricalRV := module()
export MassDensityFunction, PlotMassDensityFunction, Support:

MassDensityFunction := proc(rv, x)
  local u, v, N:
  u := [attributes(rv)][3]:
  if u:-ParentName = EmpiricalDistribution then
    v := op([1, 1], u:-Conditions);
    N := numelems(v):
    return piecewise(op(op~([seq([x=v[n], 1/N], n=1..N)])), 0)
  else
    error "The random variable does not have an EmpiricalDistribution"
  end if
end proc:

PlotMassDensityFunction := proc(rv, x1, x2)
  local u, v, a, b:
  u := [attributes(rv)][3]:
  if u:-ParentName = EmpiricalDistribution then
    v := op([1, 1], u:-Conditions);
    a := select[flatten](`>=`, v, x1);
    b := select[flatten](`<=`, a, x2);
    PLOT(seq(CURVES([[n, 0], [n, 1/numelems(v)]], COLOR(RGB, 0, 0, 1), THICKNESS(3)), n in b), VIEW(x1..x2, default))
  else
    error "The random variable does not have an EmpiricalDistribution"
  end if
end proc:

Support := proc(rv, x1, x2)
  local u, v, a, b:
  u := [attributes(rv)][3]:
  if u:-ParentName = EmpiricalDistribution then
    v := op([1, 1], u:-Conditions);
    return {entries(v, nolist)}
  else
    error "The random variable does not have an EmpiricalDistribution"
  end if
end proc:

end module:

>	EmpiricalRV:-MassDensityFunction(toss_1_dice, x);

piecewise(x = 1, 1/6, x = 2, 1/6, x = 3, 1/6, x = 4, 1/6, x = 5, 1/6, x = 6, 1/6, 0)

(6)

>	f := unapply(EmpiricalRV:-MassDensityFunction(toss_1_dice, x), x): f(2); f(5/2);

(7)

>	EmpiricalRV:-PlotMassDensityFunction(toss_1_dice, 0, 7);

>

Download Discrete_RV.mw

Are Maple's pseudo random number generators good...

by: mmcdara 7631

December 04 2019

2 3

I'm particularly interested in data analysis and more specifically in statistical analysis of computer code outputs.

One of the main activity of this very broad field is named Uncertainty Propagation. In a few words it consists in perturbing the inputs of a computational code in order to understand (and quantify) how these perturbations propagates through the outputs of this code.

At the core of uncertainty propagation is the ability to generate large numbers of "random" variations of the inputs. Knowing that these entries can be counted in tens, one sees that the first problem consists in generating "random" points in a space of potentially very large dimension.

Even among my mathematician colleagues an impressive number of them is completely ignorant of the way "random" numbers are generated. I guess that a lot of Mapleprimes' users are too. My purpose is not to give a course on this topic and the affording litterature is vast enough for everyone interested might find informations of any level of complexity.
Among those who have some knowledge about Pseudo Random Numbers Generators (PRNG), only a few of them know that a PRNG has to pass severe tests ("tests of randomness") before the streams of number it generates might be qualified as "reasonably random" and therefore this PRNG might be released.

One of most famous example of a bad PRNG is given by "randu" (IBM 1966, and probably used in Fortran libraries during more than 30 years), this same PRNG that Knuth qualified himself as the "infamous generator".

These tests of randomness are generally gathered in dedicated libraries and Diehard is probably tone of the most known of them.
Diehard has originally been developed by George Marsaglia more than twenty years ago and it's still widely ued today.

I recently decided, not because I have doubts about the quality of the work done by Maplesoft, to test the Maple's PRNG named "Mersenne Twister". First, because it can do no harm to publish quantitative information that allows everyone to know that it is using a proven PRNG; second, because the (very simple) approach used here can fill the gaps I have mentioned above.

Mersenne Twister (often dubbed mt19937) is considered as a very good PRNG; it is used in a lot of applications (including finance where it is not so rare to sample input spaces of dimensions larger than 1000... ok I know, mt19937 is often considered as a poor candidate for cryptography applications, but it's not my concern here).

I have thus decided to spend some time to run the Diehard suite of tests on a sequence of integers numbers generated by RandomTools[MersenneTwister].

>

restart:

DIEHARD tests suite for Pseudo Random Numbers Generators (PRNG)

Reference: http://webhome.phy.duke.edu/~rgb/General/dieharder.php

The installation procedure (Mac OSX) can be found here
    https://gist.github.com/blixt/9abfafdd0ada0f4f6f26
or here
    http://macappstore.org/dieharder/

For other operating systems, please search on the web pages.

dieharder [-h]   # for inline help
dieharder -l      # to get the lists all the avaliable tests

A description of the many tests can be found here:
    https://en.wikipedia.org/wiki/Diehard_tests
    https://sites.google.com/site/astudyofentropy/background-information/the-tests/dieharder-test-descriptions
    https://www.stata.com/support/cert/diehard/randnumb_mt64.out

General theory about PRNG testing can be found here (a reference among many):
    http://liu.diva-portal.org/smash/get/diva2:740158/FULLTEXT01.pdf

or here (more oriented to the NIST test suite)
    https://www.random.org/analysis/Analysis2005.pdf
    https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-22r1a.pdf

In a terminal window execute the following commands for an exhaustive testing ("-a" option).
The "-g 202" option means that the generator is replaced by a text format input file
(use dieharder -h for more details).

cd //..../Desktop/DIEHARD

dieharder -g 202 -f SomeAsciiFile -a > //..../Desktop/DIEHARD/TheResultFile.txt

Be carefull, the complete testing takes several hours (about 5 on my computer)

__________________________________________________________________________________

Maple's Mersenne Twister Generator

Maple help page : RandomTools[MersenneTwister][GenerateInteger]
(see rincluded references to the Mersenne Twister PRNG).

Note: in the sequel this generator will be dubbed mt19937

The Mersenne Twister is implemented in many softwares.
It is higly likely that this PRNG (and the others these softwares propose) have been intensively
tested with one of the existing PRNG testing libraries.
Unfortunately only a few editors have made public the results of these tests (probably because
the implementation in itself is rarely questioned... but a code typo is always a possibility).

One exception is ths software STATA.
A summary of the results can be found here
https://www.stata.com/support/cert/diehard/.
A complete description of the results of the tests passed is given here
https://www.stata.com/support/cert/diehard/randnumb_mt64.out

The classical pattern of the performances of mt19937 can be found here

http://www2.ic.uff.br/~celso/artigos/pjo6.ps.

and the table below comes from it (P means "Passed", F means "Failed"):

____________________________________________________________________________

In the Maple code below, a sequence of N UnsignedInt32 numbers is generated from the
Maple's Mersenne Twister and the result is exported in an ASCII file.
The Seed is set to 1 (SetState(state=1)) to compare, with a small value of N (let's say N=10)
the sequence produced by Maple's mt19937 with the the sequence of the same length generated
by Diehard's mt19937.
To generate this later sequence and save it in file Diehard_mt19937, just run in a terminan window
the command (-S 1 means "seed = 1", -t 10 means "a sequence of length 10"):
dieharder -S 1 -B -o -t 10 > Diehard_mt19937

About the value of N:

In http://webhome.phy.duke.edu/~rgb/General/dieharder.php it's recommend that N be at least
equal to 2.5 million; STATA used N=3 million.
Other web sources say this value is too small.
For N=10 million the Maple's mt19937 doesn't pass the tests successfully.
I used here N=50 million (the resulting ASCII file has size 537 Mo).

Name of the input file.

The file generated by Maple is named Maple_mt19937_N=5e7.txt

One important thing is the preamble of a licit input file.

This preamble must have 6 lines (the value 10 right to count must be set to the value of N).
A licit preamble is of the form.

#==================================================================

# some text indicating the generator used

#==================================================================

type: d

count: 10

numbit: 32

As Maple_mt19937_N=5e7.txt is generated from an ExportMatrix command, this preamble is added
by hand.

Running multiple Diehard tests

To run the same tests used to qualify STATA's Mersenne Twister, open a terminal window,
go to the directory that contains input file Maple_mt19937_N=5e7.txt and run this script:

for i in {0,1,2,3,4,8,9,10,11,12,13,14,15,16}; do

dieharder -g 202 -f Maple_mt19937_N=5e7.txt -d $i >> Diehard___Maple_mt19937_N=5e7

done ;

The results are then forked in the ASCII file Diehard___Maple_mt19937_N=5e7

>	with(RandomTools[MersenneTwister]):

>	dir := cat("/", currentdir(), "Desktop/DIEHARD/"): InputFile := cat(dir, "Maple_mt19937_N=5e7.txt"):

>	SetState(state=1); N := 5*10^7: st := time(): S := convert([seq(GenerateUnsignedInt32(), i=1..N)], Matrix)^+; time()-st;

$S := Vector(4, {(1) = ` 50000000 x 1 `*Matrix, (2) = `Data Type: `*anything, (3) = `Storage: `*rectangular, (4) = `Order: `*Fortran_order})$

(1)

>	st := time(): ExportMatrix(InputFile, S, format=rectangular, mode=ascii); time()-st;

(2)

Diehard's results

Full test suite (about 5 hours of computational time)

Command :
dieharder -g 202 -f Maple_mt19937_N=5e7.txt -a > Diehard___ALL___Maple_mt19937_N=5e7

The results are compared to those obtained for Diehard's mt19937.
Two ways are used :

  - 1 - In a first stage one generates a stream of PRN and store it in an ASCII file (just as we did with Maple).
         The whole suite of tests is then run on this file.
         Commands (-g 013 codes for mt19937):

         dieharder -S 1 -g 013 -o -t 50000000 > Diehard_mt19937_N=5e7.txt
         dieharder -g 202 -f Diehard_mt19937_N=5e7.txt -a > Diehard___ALL___Diehard_mt19937_N=5e7

  - 2 - The whole suite is run by invoking directectly mt19937 "online"
         Commands :
         dieharder -S 1 -g 013 -t 50000000 -a > Diehard___ALL___Online

A UNIX diff command has been used to verify that the two files Maple_mt19937_N=5e7.txt and
Diehard_mt19937_N=5e7.txt were identical (thet were).

Note that the Diehard doens't responds identically depending on the stream of random numbers comes from a file
or is generated online (this last [- 2 -] situation seems to give better results).-

Résumé (114 tests):
   - * - Maple's and Diehard's mt19937 respond exactly the same way when the stream of random
          numbers is read from an ASCII file (8 tests failed (******) and 6 weak (**)).
   - * - Diehard's mt19937 fails 0 test and is weak on 4 tests when the stream is generated online

>

restart:

>

dir := currentdir():
FromMapleFile     := cat(dir, "Diehard___ALL___Maple_mt19937_N=5e7"):
FromDiehardFile   := cat(dir, "Diehard___ALL___diehard_mt19937_N=5e7"):
FromDiehardNoFile := cat(dir, "Diehard___ALL___Online"):

printf("                           ======================|======================|======================|\n"):
printf("                          |   From Maple's file | From Diehard's File | Diehard online test |\n"):
printf("==========================|======================|======================|======================|\n"):
printf("          test       ntup | p.value   Assessment | p.value   Assessment | p.value   Assessment |\n"):
printf("==========================|======================|======================|======================|\n"):

for k from 1 to 9 do
  LMF := readline(FromMapleFile):
  LDF := readline(FromDiehardFile):
  LDNF := readline(FromDiehardNoFile):
end do:

while LMF <> 0 do
  if StringTools:-Search("|", LMF) > 0 then
    res := StringTools:-StringSplit(LMF, "|")[[1, 2, 5, 6]];
    printf("%-20s %3d | %1.7f ", res[1], parse(res[2]), parse(res[3]));
      if StringTools:-Search("WEAK" , res[4]) > 0 then printf("    **     |")
    elif StringTools:-Search("FAILED", res[4]) > 0 then printf(" ******   |")
    else printf(" PASSED   |")
    end if:
  end if:
  LMF := readline(FromMapleFile):

  if StringTools:-Search("|", LDF) > 0 then
    res := StringTools:-StringSplit(LDF, "|")[[5, 6]];
    printf(" %1.7f ", parse(res[1]));
      if StringTools:-Search(" WEAK" , res[2]) > 0 then printf("     **    |")
    elif StringTools:-Search(" FAILED", res[2]) > 0 then printf("   ****** |")
    else printf("   PASSED |")
    end if:
  end if:
  LDF := readline(FromDiehardFile):

  if StringTools:-Search("|", LDNF) > 0 then
    res := StringTools:-StringSplit(LDNF, "|")[[5, 6]];
    printf(" %1.7f ", parse(res[1]));
      if StringTools:-Search("WEAK" , res[2]) > 0 then printf("     **    |")
    elif StringTools:-Search("FAILED", res[2]) > 0 then printf("   ******    |")
    else printf("   PASSED |")
    end if:
    printf("\n"):
  end if:
  LDNF := readline(FromDiehardNoFile):

end do:

>

Download DIEHARD_test_of_MAPLE_MersenneTwister.mw

A lot of supplementary details are given in the attached file.
I let the readers discover by themselves if Maple's implementation of the Mersenne Twister PRNG is correct or not.
Beyond this exercise, I hope this work will be useful to people who could be tempted to test their own generator.

maple.ini (Windows) and .mapleinit (Linux)

by: struckmeier 70 Product: Maple

November 19 2019

9 3

After updating to Maple2019.2, the user initialization files maple.ini (Windows) and .mapleinit (Linux), which are placed into the user's home dierectories, are no longer read in upon startup. The behavior of Maple2019.1 was correct, the files were read.

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

E-Mail Address:
Password:
Remember Me:	Automatically sign in on future visits

Ask a Question

Create a Post