The documentation for pick() doesn't mention the second parameter count.

Sampling data like firstNames, lastNames etc. should be separated out from the core code. This would improve the maintainability and also the user would have more control over the data.

It seems like this is really useful for generating fake user profiles.

It also seems like having Mrs as a Male and John as a Female is (all political landscape nonsense aside) not very useful.

How would it be best accomplished to having consistent gender info?

I was thinking that passing a gender to the first name and title method would work well.

var gender = chance.gender()
  , first = chance.first({ gender: gender })
  , prefix = chance.prefix({ gender: gender })
  ;

What do you think?

chance.string({ length: -1 })

will loop forever.

I'm working on a project that requires a color formatted as 0xFFFFFF
I could easily replace E with 0x or make my own generator but I think this would fit in pretty well with the format option in the ´.color()´ function. I don't know what it could be called but I'm sure this format of color has a name.

I've been using chance for a couple of weeks now and I'm finding that I'm having code like the following:

var statuses = [ 200, 200, 200, 200, 200, 200, 304, 404, 404, 403, 403, 500 ];
console.log(chance.pick(statuses));

I'm doing this because in the above case I'm wanting to simulate more 200's than anything else and more 404/3's than the remming options. This is a "poor" attempt at creating "weighted" pick.

I'm wondering... If there is any desire to better support weighted chance.pick and if so what it would look like?

The documentation does not mention that guid() accepts a version option.

Although it's pretty intuitive I think you should explicitly mention how to run the tests since someone might be unfamiliar with using bower for the required dependencies in order to run tests. Maybe just add it to the README file under it's own section.

chance.latitude min and max parameters do not work

http://screencast.com/t/j8JmVoo9T2q

When running generators from the new CLI feature, they are not very random. Here is the output of calling "chance word" several times in a row:

vapik
teogefe
suvaflud
ut
gibgewuga
cim
gendadel
ate
rizjefjo
ro
cim
cof
cim
mi
gibgewuga
gibgewuga
gendadel
ut
teogefe
alogikfur

You can see "gibgewuga" is repeated 3 times, as is "cim". "gendadel" and "teogefe" are repeated twice.

It looks like this is not specific to "word", but rather systemic. Similar results occur with "chance name":

Madge Scott
Flora Vaughn
Elsie Wallace
Victoria Huff
Ricky Russell
Rodney Thornton
Bobby Swanson
Ida Carlson
Dennis Atkins
Emily Bass
Mina Sims
Bettie Quinn
James Hamilton
Esther Young
Anne Weaver
Rodney Thornton
Anne Weaver
Bernice Dunn
Lura Guzman
Curtis Norris
Jesus Kim
Jesus Kim
Bernice Dunn
Bernice Dunn
Francis Ward
Bernice Dunn
Emily Bass
Esther Young
Bettie Quinn

I haven't investigated yet, but I assume this is related to not having a true source of entropy at startup. For the CLI to be useful, I think it needs a better source of entropy. I'm sure even the CPU tick time would give better results.

Great looking library!

I'm building some D3 visualizations, and they require generating random structured data.
Here's one using random trees:

http://codepen.io/Kallin/full/vzgnF/

I was thinking of encapsulating the generation code into a more generic lib, then saw chance.js and thought maybe it would work well in there. Interested in me making a pull request to add some tree-generation? Could be other structures in the future as I explore more of D3. Let me know, I can try putting together a pull request!

I seem to be getting an error when using chance.date() under node.

var Chance = require('chance');
var chance = new Chance();
console.log(chance.date());

/Users/sidwood/code/nwo/node_modules/chance/chance.js:792
        var year = parseInt(chance.year(), 10),
                            ^
ReferenceError: chance is not defined
    at Chance.date (/Users/sidwood/code/nwo/node_modules/chance/chance.js:792:29)
    at Object.<anonymous> (/Users/sidwood/code/nwo/error.js:45:20)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:901:3

We just did a big project involving ios notifications and it would have been amazing to have been able to generate device tokens without have the backend time having to go through the trouble of finding out what they look like and/or how to create them.

Since the default seed value is just new Date().getTime(), allowing users to pass in date objects as a seed value when instantiating saves time.

last
chance.last()
Generate a random last name

  Chance.first();
  => 'Mame'

Currently chance.coordinates() gives you something like '12.1237121, 64.123123'. However, usually coordinates are stored as an array in [lat, lon] format. In all of my test cases, I have to write chance.coordinates().split(', ').

I think this should be the default format, but wanted to get some opinions before I do a PR

Add a generator to return GA tracking codes (e.g. UA-1234567-1).

See here for more information.

http://www.random.org/integers/? as demonstrated in Advanced section on http://chancejs.com/ should be changed to https://www.random.org/integers/

Any chance of splitting this library into multiple packages / modules?

I'd like to see something like http://lodash.com/custom-builds

I would like to be able to specify an option to auto-clamp a value between min and max when doing chance.bool.

Came across this library in DailyJS, great library for backend dev for generating stub data. 👍 👍

A litttle suggestion on wording in doc:
The section "hidden" could have been named "Internal functions", with some disclaimer:

"Calling them directly is not forbidden but caller risks incompatibility on future updates."

It would be awesome if we could generate strings/characters that are unambiguous.

Example of ambiguous characters:

0 O D Q 
1 I L J
8 B 
5 S
2 Z

This isn't a complete list but a good place to start.

chance.name({prefix:true});

TypeError: this.prefix is not a function
name = this.prefix() + ' ' + name;

It seems that you call this.prefix() instead of this.name_prefix()

Allow config parameter to name, first, last to take gender as an option and generate names. Eg.

chance.first({gender: 'Male'})

Suffixes would be a nice addition to the name generator - things like Sr, Jr, etc. could be added.

I realize that this is my mistake for even passing these parameters, but I thought I'd bring it up anyway.

Due to a mistake, I was calling what boiled down to:

var s = chance.integer( {min : 1, max : 0.5} );

Which results in an infinite loop, due to the section appropriately commented with // Probably a better way to do this... ;)

Funnily I see #54 when I was just checking out the list of open issues.

I know this is out of scope of chance.js, just wondering if there are any existing library using chance.js for dummy json generation.

I find myself often needing to generate json according to some known data model (schema), but the lack of block/loop in most random data generator means I need to handcraft the generator function everytime.

It looks like there's a bug in chance.n() where if you pass 0 for n, it will still return an array with 1 item in it.

I noticed this while working with the CLI:

$ chance string --length 79 --pool "10000"

TypeError: Object 10000 has no method 'charAt'
at Chance.character (...\node_modules\chance\chance.js:147:21)

It helps to use pool.toString() in the generator, which I would recommend because it allows people to pass in numbers as the pool straight away.

However, on the CLI, other issues arise, even when using pool.toString():

$ chance string --length 79 --pool 01
1111111111111111111111111111111111111111111111111111111111111111111111111111111

Because 01 is parsed as a number by minimist, only 1 will be supplied as the pool, which isn't what I intended here. Quotes don't help either:

$ chance string --length 79 --pool "01"
1111111111111111111111111111111111111111111111111111111111111111111111111111111

I don't know yet how to approach this.

I have several tests using chance that were working up to a few days ago. I updated my node_modules and now I am facing the same email() being generated over and over... I will try to investigate this further to provide more details, but it seems that 0.6.4 broke something, at least on windows.

Update: just tested with 0.6.2, everything working as it should.

Can we have random UA generator in Chance as well? The one I prefer is random-ua.

PS: Kudos to the awesomeness! Love the product.

When I run npm install on any version above 0.6.4 (i.e. 7.x up) I get the following build error

[email protected] postinstall: `lodash compat -o test/lib/lodash/lodash.build.js`

This is an exploratory issue.

See #37 for a bit of background.

Toying with the concept of declaring global.chance in Node which includes an already instantiated Chance object.

Mocha does this which made me think it was an alright idea (it should go without saying global declaration is something which must be used extremely judiciously!).

It would significantly simplify a lot of server-side test setups by removing the need to declare Chance in every file that utilizes it.

However, I basically talked myself out of it by reasoning that, while Mocha does it, Mocha is used basically only for testing.

While Chance is probably mostly used for testing, some folks may be using it in their applications for generating stuff.

I know I'm using it in a few production apps to generate miscellaneous things. A global chance wouldn't harm anything in my case, but I'm concerned it may for others.

I suppose there are 3 options:

1. Do nothing, leave it as is, in Node you'll have to declare Chance in every file.
2. Declare an instantiated global.chance all the time
3. Accept a parameter with the constructor indicating whether to add global.chance so it could be require'd once per application and accessible everywhere.

I think (3) makes the most sense and would break the least things while providing the max advantage.

Anyone please ring in with comments for or against any approach, I'd love to hear them!

Chance is currently defining itself explicitly as the named module 'Chance' in AMD. This is less than ideal for a number of reasons:

1. It's inconsistent with the npm package which is called 'chance' instead of 'Chance' (which complicates writing code for consumption in both node and the browser)
2. It prevents referring to the library as anything but 'Chance' unless you also alias it with a map config in requirejs (effectively creating a global variable in requirejs by locking the 'Chance' module)
3. It's generally not in the spirit of requirejs and is even discouraged on their website (http://requirejs.org/docs/api.html#modulename)

Ideally, chance would use UMD (https://github.com/umdjs/umd) - specifically https://github.com/umdjs/umd/blob/master/returnExports.js - but for now an anonymous define would solve the issue.

I'm using chance to build stubs for test cases, and I'm using chance to generate fake user phone numbers. However, I also validate this using libphonenumber and can't seem to get it to accept any of the numbers generated by chance.phone({country: 'us'}). I also tried using phone and that only accepts half of them. Any idea why this would be?

Awesome project.

What about generating a credit card number (mostly for testing purpose I guess)?

Cheers.

Basically the title says all. country() is inside the documentation, but missing in source code.

P.S: I've just noticed you've added it 1 day ago. It's still missing on webpage/bower/npm, hope we'll see it soon.

It's a bit confusing to see pseudorandom strings formatted as UUIDs with essentially nonsensical values (ie: not specifying the variant/following the spec). While they work as arbitrary string identifiers, it might be slightly more in line with user expectations if the GUID creation followed a standard such as http://www.ietf.org/rfc/rfc4122.txt

consider generating a lookup table with sufficient entropy rather then constantly runtime probability lookups. Might be nice when generating larges amounts of objects.

It would be nice to config casing, alpha, symbols for strings as well.

I was wondering what should be the current behaviour when using weights of 0 with the weighted helper?

So currently when employing this function:

chance.weighted([a, b], [100, 0]);

It returns just undefined. Also I looked through the tests but I didn't see anything to do with weights of 0.

I assume that b should not be return at all. So before I make a contribution, I just wanted to confirm what the logic should be.

Thank you.

It would be nice if the object returned from require("chance"); was pre-initialized and did not require a separate line to initialize.

Currently, it works like this:

var Chance = require("chance");

var chance = new Chance();

I wish it would look like:

var chance = require("chance");

and if I ever needed to initialize a separate object, you could do this:

var otherChance = new chance.Chance();

This would be a breaking change from an API standpoint, but figured I would propose it anyways.

It would be nice to be able to specify a range limit for latitude/longitude. (ie: customize min/max)

Is this expected?

Cheers,
Nicolas

Hi, I've written a library that provides random data generators. Mine are more oriented towards standard programming concepts, but I have a piece of code that parses regular expressions and creates a random string generator based on that, so I thought you might be interested:

Here's the annotated source code and here's the generated JavaScript.

Run this a few times and see that negative numbers pop out sometimes.

'use strict';

var chance = new Chance()
  , dob
  ;

dob = chance.birthday({ type: chance.pick(['child', 'teen', 'adult', 'senior']) });
console.log(dob);

How about adding a url() generator that will generate a url string: "http://whatever.com/images/cat.jpg" etc.
Extension probably should be a parameter.

Moving from: marmelab/gremlins.js#38

non-ascii (utf-8) symbols, in some cases, can be reason of errors in page rendering or/and in business logic. So each app should be ready to handle non-ascii characters.

if I wanted to generate a name, I could pass in {gender: "male"} or {gender: "female"}, but chance.gender() returns either "Male" or "Female" - seems inconsistent.

Is the shuffle implemented with the fisher-yates / knuth method or with another method? In other words: is it "fair" or "skewed" (i.e. http://www.robweir.com/blog/2010/02/microsoft-random-browser-ballot.html)?