@Carl Love Yeah, the change should be in 2020.0 and later.

Best,
Erik.

@vs140580 Another option would be to use the command Iterator:-CartesianProduct. If you want to deal with the results one by one, you can use it like this:

m := 4; # or more
S := {0, 1, 2}; # or something else
for v in Iterator:-CartesianProduct(S $ m) do
  print(v); # v will be an Array with one result
end do;

Note that the Array in v will be reused between iterations; only its contents will change.

@Carl Love Thanks again, Carl, for all your time on this.

@epostma 

One more thing that I meant to add: I also looked up who introduced this bug. As is so often the case with these sorts of things, I found it was introduced in a change made more than a few years ago that rewrote some working code unnecessarily... submitted by one Erik Postma :(

@mmcdara Strictly speaking, the Gaussian family also has a specific sampler - it just happens to use the ziggurat algorithm, which could have been implemented as a generic algorithm, but isn't really. So I would say that all pre-defined distributions have a specific sampler implemented.

@Carl Love Thanks Carl - once I get around to fixing this, I'll be sure to re-run that worksheet. I expect they're all the same underlying bug; many of the distributions have their samples generated by sampling the normal distribution as one of the steps.

@mmcdara Ziggurat is used for the exponential and normal distributions.

For beta, it samples two gamma random variates.

For gamma, it looks a little tricky - I can't easily summarize it here. The general case involves generating a truncated normally distributed random variate and a uniform random variate and combining them in various ways... I'm sure if I looked into it for longer I'd recognize a commonly recommended algorithm but I haven't done that yet.

For Cauchy, it's interesting: if a hardware float value is requested (which is the common case, it usually happens when Digits <= 15), then there is a small procedure that uses 8 predefined constants (again - I haven't looked into it in detail but when I need to I'm sure I could recognize the algorithm). If a software float value is requested, those constants can't be pre-defined at arbitrarily high precision; it uses the inverse transformation method in that case.

Hi mmcdara,

Thanks for filing this report. I'll start investigating this shortly.

You ask about the Box-Mueller method. I can't say why it wasn't chosen (the person who implemented this code left Maplesoft long ago), but I'm not eager to switch over to it, if we can manage to fix this bug. The current method is a ziggurat algorithm (see e.g. https://en.wikipedia.org/wiki/Ziggurat_algorithm) which I think is a well-respected choice. The fallback algorithm for the tail appears to be the one that Marsaglia suggests, at least according to that wikipedia page.

Erik Postma
Manager of the mathematical software group
Maintainer of the Statistics package

I'd just like to add that we're looking into this issue; we've entered it into our internal systems. Thanks everyone for reporting and investigating it!

The previous post that _Maxim_ mentioned was removed exactly because it dealt with the same issue as this post, and this post had some comments and answers at that time whereas the other one didn't.

@Davisonm I've tried a few variations of that, but they don't work. The problem is that it's a very early stage of the evaluation process (called 'simpl') where the test is done that the argument to option object is an object, whereas it is a late stage of the evaluation process (the actual evaluation) where the module definition is turned into an object. So you somehow need to have the parent class undergo actual evaluation before the derived class undergoes simpl. I was unable to find a way to do this.

@tbfl1919 The file I found in your original post appears to still have the sine function in its definition of V__tot_AC; I tried reproducing the problem from your screenshot, but was unsuccessful (that is, I was successful in running the command). Are you using Maple 2017.3? If you execute the version() command, does Maple reply with 1265877? I was originally trying this in 2017.1, updated to 2017.3, and in both I received the correct result.

I'll attach the modified document: Analyse.mw

@tbfl1919 Hmmm... this unfortunately requires more invasive changes. The piecewise command is not well-supported by any of the units subpackages; this post made me realize this and I'll try to make some improvements here, as well, for the next version of Maple. This case is particularly tricky, because there is interaction with the int command, as well: for the condition to evaluate, it needs the units from the range of the integral.

I think the only solution here might, for now, be to extend the "cheating" approach I proposed in my previous post. So that means, we replace the integral int(f(t), t = T__1 .. T__2) by int(f(t*Unit(ms)), t = T__1/Unit(ms) .. T__2/Unit(ms)) * Unit(ms), where f(t) = V__tot(t)².

Similarly, for plotting, we need to do some surgery to the plot command, to something like the following: plot('combine(V__tot(t*Unit(ms))/Unit(V), units)', t=0..5)

As for converting the output unit to volts: I would suggest any of the following.

• Right click the end result; click Units / simplify.
• Right click the end result; click Units / convert / system / SI.
• Type combine(V__tot_rms, 'units')
• Type convert(V__tot_rms, 'units', 'V')

Let me know if any of these do not work for you.

@Markiyan Hirnyk I just verified this, and it looks like we're using a relatively old version of the geonames.org database. I meant to update it in March of this year and did something wrong.

I have an experimental version of today's data on my machine. It has the French regions as listed on that web page. For Finland, it's "Ahvenanmaa [Finnish] / Åland [Swedish]" that doesn't show up. This does indeed occur in the geonames database, but as a "dependent political entity" (feature code A.PCLD in their allCountries.txt file) rather than a "first order administrative division" (feature code A.ADM1). You can look it up as such even in current Maple:

  DataSets:-Builtin:-Reference("geonames")[Name = "Ahvenanmaan Laeani"];

returns that record.

I don't see any record that directly corresponds to the first line of the Finland table on the geonames web site. Note that that line is not hyperlinked; I expect that means they've added the entry to that web page but not that database.

For completeness, the full geonames database also contains an island (feature code T.ISL) and a group of islands (feature code T.ISLS) called Aland or Aland Islands. We don't include these in the database included in Maple.

I'll make an effort to include today's data in the next version of Maple. I expect we'll include new versions of this data every now and then.

@Carl Love For what it's worth, this option and the option of using piecewise are the two correct solutions, in my opinion.

Good catch - thanks guys! Note that convert(%, piecewise) returns the desired answer (same as Maple 12), so there is some hope that it should be possible to fix this relatively easily. I expect I might be able to include a test in the CDF command (or rather, the under-the-hood procedure that does the actual work) to see if the result has Heaviside and/or Dirac expressions, and is of the form int(...), and in that case apply the conversion. That seems like it should be a good idea.