1429 Reputation

18 Badges

14 years, 118 days

Social Networks and Content at Maplesoft.com

Maple Application Center
I am the manager of the Mathematical Software Group, working mostly on the Maple library. I have been working at Maplesoft since 2007, mostly on the Statistics and Units packages and on contract work with industry users. My background is in abstract algebra, in which I completed a PhD at Eindhoven University of Technology. During my studies I was always searching for interesting questions at the crossroads of math and computer science. When I came to Canada in 2007, I had nothing but a work permit, some contacts at Maplesoft (whom I had met at a computer algebra conference a year earlier), and a plan to travel around beautiful Canada for a few months. Since Maplesoft is a company that solves more interesting math and computer science related questions than just about anywhere else, I was quite eager to join them, and after about three months, I could start.

MaplePrimes Activity

These are replies submitted by epostma

@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)2.

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.

@Carl Love I'll put adding an implementation of selectremove, and selectremove on my backlog. No promises about when it'll be done - it might require some kernel work to make it possible to provide implementations of this (I haven't checked).


Hi Bill,

Thanks for letting us know about this issue. We were already aware of it, and we're working with our data provider, Quandl, to get this working again as soon as possible. (The fix should be server side only, as far as we can see.)

What appears to happen is that a data cap is incorrectly applied at some point - so you may see it working at some times, and not working at other times, without any real dependency on the Maple version you're using (as Christopher2222 already pointed out).

I'll post an update when the issue is resolved.

Erik Postma
Manager of the mathematical software group

Another option would be to use the Student[MultivariateCalculus] package:

L := Line((x-2)/3=(y-1)/4, (y-1)/4=(z-3)/3);

This shows a point on the line and the direction vector as well, and a caption. If you prefer to not see (some of) those, you can use options to the GetPlot command to disable them.

This happens because Sample tries to use evalhf to determine the probabilities for all numbers in a reasonable range. What ends up happening is, roughly:

r := RandomVariable(NegativeBinomial(3, 0.1));
p := MakeProcedure(ProbabilityFunction, r, numeric);
numbers := Array(0 .. 169, i -> i, datatype=float);
map[inplace,evalhf](p, numbers);

This requires evaluating evalhf(p(169)), which doesn't work: there's an overflow, because GAMMA(172) cannot be stored in an IEEE double variable. In theory, you could simplify GAMMA(3+t)/t! to a polynomial and just evaluate that instead, but that won't work for cases where the first parameter is not an integer (which we allow). Instead, I'm testing a fix that tests whether the sum of the resulting probabilities in the Array 'numbers' is close to 1, and if it isn't, retry without 'evalhf'. Unfortunately, it looks like it may be a while until this fix is in a released version of the product.

I will add that another workaround is using the option 'method = custom' in the sample call: Sample(r, 10000, method=custom). (The default for the negative binomial distribution is the discrete method.) For more details, see the help page for Statistics[Sample].

Erik Postma
Math group manager, Maplesoft.

1 2 3 4 5 6 7 Last Page 2 of 21