rand(1:1000)

[StefanKarpinski]

This should maybe sample from the array of values represented by the range?

[JeffBezanson]

Useful, but starts to get kind of opaque if you want to know what rand(x) does. It could be another function, like pick or choose, that takes a container and a distribution. a[randi(end)] is even clearer, but we might not want to tie this to indexing. Not sure.

[ViralBShah]

Not so sure about this. What is the motivation, since the way to otherwise do that with randi is about as short as well. Although I do like the idea of having pick where it picks a value at random from a given array, with an optionally specified distribution to sample the random location from.

(v, loc) = pick(a, dist)

[StefanKarpinski]

The motivation is that I can't ever recall what randfoo function I need to use and how to call it. I want a single more consistent interface to generating random numbers: rand(distribution, dimensions...) and when distribution is some kind of collection-like object, it makes sense to sample a value from it. That would apply to using an array as much as a range.

[JeffBezanson]

I like the general idea, but then there is confusion between picking a random index from some distribution and using that to select from a collection, versus using the collection itself as the distribution. But maybe it would be ok given the generally more consistent interface.

[StefanKarpinski]

If you're going to use an array as some kind of distribution, you need more information than just an array of numbers to know what it means. For example, is the array a PDF or a CDF? To disambiguate that, you'd want to write rand(PDF([0.25,0.5,0.25])) or rand(CDF([0.25,0.75])) anyway.

[StefanKarpinski]

I've come to the opinion that we should scrap the Matlab-compatible random number interface as the primary interface and do something more consistent like what @dmbates and @johnmyleswhite have done in distributions.jl. We can have Matlab-compatibility and R-compatibility modules that can be imported to make porting code from those two systems easier. But we should encourage a more consistent, better-designed interface as the way to write new code. If it's consistent enough, it will be so easy to learn that even people really deeply entrenched in Matlab or R will pick it up quickly.

[johnmyleswhite]

Agreed. When I have some time I've been planning to write up documentation for distributions.jl so that people realize how much is already in there.

-- John

On Aug 9, 2012, at 12:06 PM, Stefan Karpinski wrote:

I've come to the opinion that we should scrap the Matlab-compatible random number interface as the primary interface and do something more consistent like what @dmbates and @johnmyleswhite have done in distributions.jl. We can have Matlab-compatibility and R-compatibility modules that can be imported to make porting code from those two systems easier. But we should encourage a more consistent, better-designed interface as the way to write new code. If it's consistent enough, it will be so easy to learn that even people really deeply entrenched in Matlab or R will pick it up quickly.

—
Reply to this email directly or view it on GitHub.

[JeffBezanson]

I'm fine with that. The matlab interface in particular is so simple you can write it on top of anything. Is it possible to have the matlab functions available at the prompt by default, or are there conflicts?

[StefanKarpinski]

That's a good question. I'm not sure. It would be nice if there were no collisions, but I still may not want to have the Matlab function available since that would encourage their use instead of discouraging it.

[johnmyleswhite]

There aren't conflicts, but why not put all of the Matlab stuff into a module that essentially provides a Matlab compatibility mode? That could be used not just for RNG's, but also for lots of other things like file operations, etc.

[StefanKarpinski]

There aren't conflicts, but why not put all of the Matlab stuff into a module that essentially provides a Matlab compatibility mode? That could be used not just for RNG's, but also for lots of other things like file operations, etc.

+1

[JeffBezanson]

I don't know; not all cases are similar. The rand functions in matlab are obviously insufficient and in some cases spuriously inconsistent, but for many other kinds of functions it's just a matter of picking a name, and we might as well be compatible. You need to port code anyway, so we should offer one good way to do things and be compatible to the extent that it doesn't interfere with that. A compatiblity module is a pretty marginal kind of thing. We also don't want to go down the road of making every little thing work differently if you import that module.

[timholy]

Maybe everyone knows this, but in case not: Matlab has two sets of random number functions. The broader set is in the statistics toolbox:
http://www.mathworks.com/help/toolbox/stats/bqt29ct.html

Presumably you're talking mostly about the ones that come with core Matlab.

[johnmyleswhite]

Looking back at this, I should point out that we already have a function sample that could be used for this purpose and is consistent with R's function for doing what Stefan wanted.

From what I understand, we're only concerned with the core Matlab names since the other names struck a few of us as pretty ugly.

[ViralBShah]

I think this is tempting, but it is not a good idea to have a compatibility layer. We can just use a different name, like random instead of rand, and leave rand as is for comfort to matlab users.

-viral

On 10-Aug-2012, at 3:13 AM, John Myles White [email protected] wrote:

There aren't conflicts, but why not put all of the Matlab stuff into a module that essentially provides a Matlab compatibility mode? That could be used not just for RNG's, but also for lots of other things like file operations, etc.

—
Reply to this email directly or view it on GitHub.

[timholy]

@johnmyleswhite Nonsense, wblcdf and ncx2pdf just roll off the tongue...didn't Verdi use those names in a couple of arias?

[JeffBezanson]

Done by #2070.