1. once stdlib is live (merged to master and published), make the default branch be develop

   • all PRs, etc, should be made against develop

2. replace jshint with eslint

   • add to test command
   • support reformatting ala go fmt
   • move eslint config files/modules to this repo (will need to do audit to ensure up-to-date)

3. add NPM style guide with versioning info

4. determine how to handle internal @stdlib links in READMEs

   • e.g., @stdlib/math/constants/float64-two-pi
   • replace internal module references

5. create an docs/install.md for developers

   • julia
   • R
   • python
   • golang
   • boost

6. determine a browser testing strategy

   • could run into memory issues if all numeric tests are run for all functions, etc.
   • one possibility is to loop through all files and run each individually (browserify, testling, and repeat)
   • may have to punt browser testing to individual repos (!)

7. std polyfills?

   • object-keys
   • typed-array
   • ...

8. how to handle modules with CLIs?

   • will want some sort of CLI test framework to test stdin, stdout, args, etc.

9. how to handle browser tests for non-browser fcns

   • e.g., fs functions like fs/exists, or cwd

10. migrate JSDoc; use one of

    • dox

    • mrdoc (aka doxx)

    • docco

    • jsdoc

    • documentation.js

      • see turf-www and turf

    • jsdoc-parse

    • dmd

    • jsdox

    • dokker

    • jsdoc-to-markdown

    • yuidoc

    • groc

    • jsduck

    • esdoc

    • docker.js

    • doctrine

    • doclets

    • mkdocs

    • docpress

    • ...

11. debug eval sources

    • node-inspector
    • source maps

12. add CONTRIBUTING.md

13. determine strategy for generic validation fcns

14. lint filenames

    • eslint plugin

15. consider changing isNumber to isNumeric

16. prngs

    • pcg
    • sfmt
    • randamu
    • gsl
    • collection of lcgs
    • Lehmer LCG
    • lcgs
    • better rngs for JavaScript
    • d3-random
    • gauss-random
    • lcg-random
    • randy
    • randgen
    • random.js
    • seed-random
    • random-js
    • seedrandom
    • modulo bias
    • diehard tests
    • dieharder
    • RNGTest.jl
    • ziggurat
    • Matlab's randn
    • Gaussian random number generators
    • V8's previously poor implementation
    • xorshift+
    • chrome thread
    • thenextweb
    • hackaday
    • betable post
    • estimating pi
    • xorshift scratch
    • randint
    • rc4 encryption

17. Makefile target to run test fixtures

    • detect script type; e.g., R, python, Julia, Golang, C, C++, or JS

      • can be as simple as filename extension
      • of course, may also want to use a shell script to run tests (.sh)
      • for files without an extension, assume executable

    • run the script

      • may want to chmod the script, so do not need to know the system alias for the runner environment (e.g., Julia => julia) and can leverage internal shebang

    • if part of CI, would allow continuous testing against an updated fixture space and would also allow continuous testing that fixture runners work

18. should utils/function-name support generator functions?

    • a separate function?

19. replace require statements of external compute modules

20. tests for top-level tools; e.g., JSDoc templates, etc

21. deploy plato complexity report to gh-pages

    • similar to JSDoc source docs

22. clean-up cpp test runners

    • powm1
    • riemann-zeta

23. type-of should check for toStringTag support

24. update utils/tools

25. generic is-finite util should include note about how differs from global isFinite

26. create better examples for constants

    • e.g., how and why and in what contexts a constant may be used
    • e.g., float64-max-exponent => useful for randomly generating numbers across the entire range of possible numbers (sort of, as only 16 decimals => logspace)

27. investigate textlint

28. project stats

    • use ndu to visualize dependency size

    • use disc to visualize browserify output

    • could do something akin to issue stats but locally and/or only including project modules/repos

    • later project stats can be displayed in a separate webpage

      • see visualcinnamon.com for inspiration

29. FIX: security vulnerability when using rm -rf in Makefile rules

    • due to using environment variables. If one is improperly set, could be catastrophic. Safe delete?

      • consider trash and trash-cli

        • No, as Sindre does not provide backwards compatibility. Will need to roll our own.

30. Makefile does not list top-level examples; is this intentional?

31. move test fixture runners into sub-directories based on language

    • e.g., ./fixtures/julia/*

32. add Saucelabs with zuul (?)

33. gh-pages

34. possible issue for float64-set-high-word

    • attempted to debug, but was able to get the right return value; so not sure what happened and why
    • NOTE: this seems to be a recurring bug; builds continue to occasionally fail on Windows
    • may be useful: browser-repl

35. module to identify equations in README files

    • parse
    • generate svg
    • generate html
    • commit
    • insert into readme (replace anything already existing)
    • similar to Makefile test targets, include a target to filter and selectively update README equations

36. jsdoc HTML template

    • needs a total refactor

    • browserify pipeline

      • mathjax

    • see documentation.js and turf

37. tailor Mathjax config

38. a project reference manager?

    • something akin to bibtex; i.e., a centralized list of references which can be globally referenced (e.g., IEEE754, as the Wikipedia reference, etc)
    • an individual module, when created, would get the global link included in the README
    • an individual module could override a reference by including a different link, but having the same "tag" in its README
    • academic markdown and citations
    • scholdoc
    • scholarly markdown
    • scholarly markdown guide
    • R markdown
    • Citeproc JSON
    • citeproc-js
    • bibjson
    • multimarkdown
    • tidying Markdown reference links
    • ...
    • separate bib doc(s), which can be readily converted to JSON (e.g., TOML or YAML), thus allowing comments (or maybe even a JSDoc like syntax and something akin to typedefs)
    • in Markdown, use citation markup strategy similar to scholarly markdown
    • given a Markdown file, create a list of two things: the unique citation identifiers used throughout the text and any citations included in the links section
    • ignore internal links to other Markdown sections
    • if an id is found in bib docs, use that reference
    • will want canonical way to reference project modules, which may be tricky, as modules may move, etc; this is important for automating "see also" type sections
    • otherwise, leave the existing ref as is
    • as part of this, should be able to lint (although remark does this already)
    • once finished, save to disk
    • does require a separate build step, but can be automated pre-push or via watch
    • how would we distinguish (in markup) between just wanting a link and wanting a full-blown reference citation? => maybe if within a references section, similar to links

39. consider standard-version

    • changelog-standard

40. add to contribution guidelines

    • bluebird
    • optimization killers
    • HTML5 Rocks
    • v8-perf
    • chrome devtools

41. in all tests (and examples), replace Math.random with a seeded lcg

    • for tests, be sure to record the seed so that failed tests can be debugged
    • could have seed be an environment variable, so could be set in CI environment
    • module to get a seed; one method used could be to check env var

42. investigate nbind

    • could be useful for, say, Boost bindings

43. check if codecov will accept multiple coverage reports

    • would like the ability to distinguish Linux, Windows, and browser coverage reports
    • temporary git tags?

44. make Travis and Appveyor build badges the same dimensions

    • currently, Appveyor includes a logo
    • could use shields.io

45. consider using svgo to minimize eqn svgs

46. *.cpp vs *.cc for C++ files?

    • use *.cpp and *.hpp

47. find inspiration for the JS style guide from C++ core guidelines

    • include ESLint rules for each (where applicable) guideline
    • include references (e.g., perf, fast elements, etc)

48. add code climate badge

49. consider using things like shellcheck for linting files other than JavaScript

    • markdown linting

      • alex

      • retext-readability

      • retext-lint-code

        • uses eslint

    • js code in markdown linting

50. on src doc build for gh-pages, also do the same for develop; e.g., /docs/src/develop, which could map to http://a.b.c/docs/src/develop

    • would allow a "preview" alongside current prod

51. investigate whether bit operators would be better for is-even and is-odd

52. browserify transform to load all "man" pages (e.g., readmes or actual man pages)

    • allow help docs to be loaded into a browser for interactive environments
    • store in local storage (?) or in-memory

53. load modules into a REPL

    • man pages can be READMES (or not; may require separate usage.txt tailored to REPL env)

      • can these be dynamically compiled/transformed at runtime, or will startup time be too slow

        • dynamic would be nice, as then would not need to maintain a separate collection of man docs

          • need some way of determining which modules are exposed in the REPL (could possibly parse the context files a la browserify, find require statements, and build), finding their READMEs, transforming, and then building a hash table for printing in the REPL

    • help(blas.copy) (or help("blas.dcopy") or ? blas.dcopy (like Julia))

      • with maps, should be able to use function reference (symbol) as key

    • refs

      • docs
      • ultra-repl
      • repl-start
      • node-repl
      • app-specific-repl
      • repl over tcp
      • repl using curl

    • ASCII charts

      • should be able to create an isomorphic API with browser charts
      • ability to open chart in browser
      • sparkly
      • jstrace/chart
      • bashplotlib
      • node-cli-graph
      • ASCIIPlots.jl
      • asciiplot
      • node-clear
      • ansi-escapes
      • node-charm
      • gvz

    • ASCII tables

    • should be able to load a REPL context in a browser

      • meaning, should be able to fairly seamlessly have a session in a terminal which is "transferred" to a browser context, including shell history and, say, charts (ASCII to an SVG equivalent)

    • black-screen terminal emulator

54. README to man doc (see above)

    • cannot directly print a raw README, as will contain markup
    • will need to transform into plain text
    • writing manual pages
    • formatted man page
    • ubuntu
    • linux
    • man-n

55. utility which scans the project for package.json files and validates the file using a defined schema

    • can be used as part of a build step to ensure package.json files are properly formatted, valid, and have requisite information

56. build utility to scan all project dirs for camelcase file names

    • add to build step, but first requires some modification (e.g., JSDoc generated HTML files)

57. refactor module CLIs to match CLI snippet

58. add the engines field to module package.json files

59. consider adding a license prefix to each file

    • julia

60. intro how-tos

    • gifs

61. evaluate using inch for src code documentation evaluation

62. gitter

63. investigate xonsh

64. list-modules Makefile recipe

    • can be used in conjunction with dep analysis to see which modules are not required by a file, etc.

65. should etc config files be placed in subdirectories?

    • would require updating Makefile targets

66. list-required-modules Makefile recipe

    • should analyze require graph (ala browserify) to determine dependencies
    • should work for a single file or a directory
    • for directory, may want to dedupe (flat array), a tree result which states which modules require which modules (similar to a node dependency graph), or, for every found module, the deps for that module (array of arrays)
    • see automation/package.json item below

67. investigate npm-publish-please and np (Sindre)

    • not sure a separate tool is necessary, but may find inspiration

68. REPL startup file, similar to startup.m

    • either command-line option or via a REPL config file
    • could possibly use configstore, or something similar, to cache the config

69. doctest

    • jsdoctest
    • jsdoced.js
    • markdown-doctest
    • mocha-doctest
    • comment-to-assert
    • doctestjs

70. to browser (see tools/simple-http-server)

    • bpipe
    • bcat
    • hcat => could be inspiration for piping data to a chart
    • scat
    • browser-run
    • budo
    • simple-html-index
    • http-server
    • ecstatic
    • glance
    • wzrd
    • serve-static

71. cross-platform open browser

    • biased-opener
    • opener
    • browser-launcher
    • browser-launcher2
    • opn and opn-cli
    • node-open
    • open-url

72. ability to run examples in a browser => Makefile target examples-browser

    • can use simple-http-server
    • packify

73. build step which runs examples in browsers and catches any errors

    • could possibly listen on window.onerror to trap uncaught exceptions
    • setup similar to testling, but without needing TAP output; basically, do any errors occur or not
    • will probably need source maps, otherwise will be difficult to debug
    • as a half-way measure, could intercept console method calls, pipe back to server, and then keep a rolling log cache; when an error is received, could stop running examples and print the cache

74. drop options requirement for tools/http-server

    • make the function polymorphic where it may accept just an options arg, a requestListener arg, or both args

75. review CoC for more community oriented policies

    • add note about right to delete offending comments, etc; e.g., Chakra core

76. add JSDoc style guide to JavaScript style guide

    • include annotations

      // Strict equality:
      // returns 3.141592653589793
      
      // Approximate equality (use roundn(x) and then strict equal):
      // returns ~3.14
      
      // Deep equal:
      // returns {'a':[1,2,3]}
      
      // Deep equal (mutation):
      // x => [ 1, 2, 3, 4, 5 ]
      
      // Deep equal:
      /* returns
           {
             "a": [1,2,3],
             "b": {"beep":"boop"}
           }
      */
      
      // Deep approximately equal:
      /* returns
           {
             "a": [~1,~2,~3],
             "b": {"beep":"boop"}
           }
      */
      
      // Wild card continuation:
      /* returns
            [
              "beep",
              "boop",
              ...
            ]
      */
      
      // Deep equal (matrices):
      /* returns
           x[':'] = [ 0 0
                      0 0 ]
      */
      
      // Deep approximately equal (matrices):
      /* returns
           mat[':'] = [ ~3.14       0
                            0   ~3.14 ]
      */
      
      // Wildcard (matrices):
      /* returns
           A[':'] = [...]
      */
      
      // Deep equal (ndarrays):
      /* returns
           x[':,:,0'] = [ 0 0
                          0 0 ]
      
           x[':,0,:'] = [ 0 0
                          0 0 ]
      
           x['0,:,:'] = [ 0 0
                          0 0 ]
      */
      
      // Type equality:
      // returns <boolean>
      
      // Type equality:
      // returns <string[]>
      
      // Type equality (instanceof):
      // returns <RegExp>
      
      // Type equality (instanceof):
      // returns <RangeError>
      
      // Type equality instanceof):
      // returns <Foo>
      
      // Wildcard (string):
      // returns '...'
      
      // Wildcard (array):
      // returns [1,...,10]
      
      // Wildcard (object):
      // returns { "a": ... }
      
      // Options:
      // returns true || false
      
      // Options:
      // returns <Error> || null
      
      // Formatted (string) (?):
      // returns => printf('%f', ?)
      
      // Wildcard:
      // returns ...
      
      // Throws:
      // throws <TypeError>
      
      // Output to terminal:
      // => 'beep'
      
      // Insert figure:
      // => <figure data=?>
      
      // Insert figure:
      // => plot(x, y)
      

      var fs = require( 'fs' );
      fs.readFile( '/path/to/beep.js', onRead );
      function onRead( error, data ) {
        if ( error ) {
          throw error;
        }
        console.log( data.toString() );
        // returns '...'
      }

      $ node ./bin/cli
      # => '...'
      # => '...'

      $ node ./bin/cli
      # => e.g., 2016-05-24 08:42.34 Beep boop blah blah.

    • examples of modules, functions, constants, regexps, etc.

    • need a convention for client-side and server-side only examples

      • could use @browseronly and @nodejsonly special annotations, akin to @private and @public

77. @stdlib/regexp/extname, */dirname export circular references; prob best to clone the regexp and bind to exported object

    • requires porting utils-copy

78. for browser REPL, use a virtual filesystem

    • fs and other filesystem methods should remain the same
    • difference is that files are not written to disk, but to, say, IndexedDB
    • would allow for an "isomorphic" REPL and the ability to run all tests and examples on both the server and client
    • filer
    • os.js
    • filesystem API
    • emscripten
    • idb.filesystem.js
    • filer.js
    • browserFS
    • browser-sync-stream

79. Add Markdown style guide, including notes about comment annotations, equations, etc.

80. Add note about ES2015 features in JS style guide

    • Backwards compatibility is important
    • Only use if can polyfill
    • Must provide a polyfill
    • No compile steps

81. Function matrix across different environments (equivalents)

    • matlab
    • python
    • julia
    • go
    • r

82. Add type specs to @stdlib/types/ folder

    • abstract-ndarray
    • abstract-complex
    • etc.

83. Add git hooks to Makefile

    • on pull, check deps to see if any missing, removed, or out-of-date; if so, clear and reinstall (?)
    • will prob want a way to undo setting of hooks (i.e., a reset)
    • intro to git hooks
    • git pre-push

84. Python linting

    • pylint
    • pycodestyle
    • pyflakes
    • prob combo of pylint and pycodestyle

85. R linting

    • lintr: no apparent CLI

86. Julia linting

    • lint.jl: no apparent CLI

87. doc viewer

    • modify SimpleHTTPServer to only serve READMEs converted to HTML
    • for equations, instead of SVG, use MathJax
    • could also insert live figures (main, margin)
    • an extension would be to make the code samples interactive
    • gateway to running benchmarks, tests, and examples in-browser
    • how would we annotate for reactive documents? inline comments? spans?
    • how would we annotate asides/notes? maybe not necessary for standard module READMEs. Possibly via spans.

88. remark-insert-svg-equation plugin

89. remark-insert-svg-figure plugin

    • requires codifying a comment markup syntax, which can take inspiration from how equations are documented in Markdown

90. make init target

    • can setup makie
    • if have make list-cli-modules, can use npm link to install cli utils
    • setup git hooks
    • install deps
    • run tests, test-coverage, benchmarks, lint, etc

91. add a run.sh file in test/fixtures, which would provide a common entry point for running test fixture runners. Currently, need to know the lang to run. And while the name is the same runner.*, the procedure for running the scripts is not. A common entry point would abstract away the differences.

92. JS style guide

    • update rule re: parentheses in arithmetic ops
    • add note about ordering vars based on character length
    • declare functions using function declarations; also include another note about anon functions
    • use strict section should add notes re: node vs browser
    • use self section should include note about dynamic scoping of this variable
    • status code example has a bug (send should be status)
    • examples should use native built-ins, rather than implicitly rely on modules such as request and express
    • comments: "compared to multi-line"
    • all style guide code should be runnable
    • add note about module order (external before internal, etc)
    • add note about not using /** unless JSDoc
    • add note that module description should propose action (e.g., "Test ..."), while function descriptions should be in active tense (e.g., "Tests ...")
    • add note about file naming conventions (no uppercase, use of snake-case) => need to put in separate style-guide, as not JS specific
    • see #79
    • add rule to JavaScript style guide about not using built-in functions, especially math functions, linking to various accuracy issues and highlighting that browsers often sacrifice accuracy for speed
    • add rules about not using Number, String, and Boolean constructors
    • add rule about using source URL directives in eval'd code
    • add rule about including decimals when working with numbers; e.g., 3.0
    • principal of least abstraction => part of "The Stdlib Way" (inspired by The Unix Way)

93. README link to "live" (e.g., gh-pages) docs (badge)

    • may also apply in reverse, going from "live" to source

94. check that JSDoc annotations include @throws

95. include READMEs in namespace dirs

96. need a convention for defining README examples which are for illustration purposes only and not meant to be run

    • e.g., an example which is path dependent and cannot be known ahead of time, as it depends on user environment, etc.

97. proposal: add stdlib field to package.json

    • allowing setting whether a module is browser-only, nodejs-only, etc and whether a module is suitable for a REPL context, etc.

98. proposal: add @sync and @async JSDoc annotations to document synchronous and asynchronous functions, respectively

99. investigate bpkg as a package manager for bash scripts

    • could be useful for test runners, etc.

100. investigate starscope

101. review

     • datasets
     • math/base/blas
     • math/base/random
     • math/base/special
     • math/base/tools
     • math/base/utils
     • math/constants
     • math/generics/statistics
     • math/generics/utils
     • namespace
     • plot
     • regexp
     • repl
     • streams
     • tools
     • utils

102. v8-profiler and node-inspector

103. analyzing the dependency network => should be able to perform a similar analysis internally

104. sine browser example

     • could do something similar for other trigonometric functions

105. benchmarking

     • chuhai
     • benchmark.js
     • substack benchmark module
     • matcha

106. stability badges

     • may be good to have stability badges for methods / modules in order to indicate if a particular API is experimental, stable, locked, or otherwise

107. makie (and make) target to initialize a module (copy files from snippets to a destination directory)

108. Add a FAQ.md and link to it in the issues template

     • e.g., => Promise support? No.

109. rename docs directory to doc?

110. more datasets => some are not that interesting; others possibly

111. write own deep-equal algo

     • when complete, replace any use of chai for testing

112. evaluate bithound

113. utils/copy

     • should preventExtensions, seal, and freeze be extended to objects beyond Object, Array, and class instances?
     • WeakMap support (?) => not convinced this is viable due to weakly held references; i.e., getting a list of keys requires maintaining a separate list.
     • WeakSet support (?) => see WeakMap above
     • Symbol support => requires the ability to get primitive value
     • structured-clone-algorithm
     • ArrayBuffer support
     • Blob support
     • FileList support
     • ImageData support
     • ImageBitmap support
     • File support

114. research pull-streams

115. see makefile for the frontend for possible inspiration for frontend tasks

116. should float64-signbit return a boolean (like Julia) or a 1 or 0?

117. make recipe for checking dep licenses

     • read-package-tree
     • licensee.js
     • make part of pre-push git hook
     • as part of public docs, can generate a list of deps and their licenses; can do the same for stdlib/lib/** modules, so that all licenses for the individual mods/deps can be viewed together

118. investigate test-all-versions

119. node-cpp

120. rr: record and replay framework

121. Investigate the concept of markembed for embedding content in Markdown files

122. Use cases for remark plugins:

     • reference management
     • conversion to RST
     • conversion to HTML
     • figure (static) insertion (similar to equations)
     • appending/removing sections en masse

123. tangle

124. GitHub issues as a blog

125. reviews

     • is-empty-array => should this just be a method off of isArray?

126. update the test-istanbul target to run each test individually, output lcov.info to a reports dir, concatenate all lcov results, and then generate a HTML report. See istanbul.

     • for CI, push concatenated lcov to coverage service

127. adventures / workshoppers

     • regex-adventure
     • workshopper-adventure
     • demo-workshopper
     • adventure
     • learnyounode
     • workshopper-exercise
     • stream-adventure
     • functional-javascript
     • p2p-workshop

128. build script which reruns the latest commit on develop each day => helps ensure, even in the absence of fresh commits, that we are testing the environment, etc. Would need to be a cron job triggered from a remotely hosted service.

129. plot svg components should have factory methods

130. readme-tester

131. Annotations overlay,

     • x values with text

132. Evaluate check-build

133. Evaluate rewind

134. iterables

135. vmd

136. when browserifying @stdlib/plot should ignore electron-prebuilt!!!!

     • may want to have a separate view method entirely; one that is catered to browser context

137. function-plot

138. see webtorrent-desktop for electron inspiration

139. constant function? similar to identity function but as a factory?

140. svg components: move methods/render.js to render/index.js

141. sparkline rug plot

142. review steam and leaf unicode plot

143. add unicode sparklines to namespace => requires abstract interface

144. refactor plot electron renderer

145. ability to "plot" tables?

146. heatmap

147. Should plot autoRender be "opt-in", rather than "opt-out"?

148. remarkjs for Markdown slide shows for workshop slides?

     • markdown-to-slides
     • cleaver

149. Visual intro to machine learning

150. Refactor make workshops recipes

151. mbtaviz and Github org

152. add FAQ with answers to things like, "Why JavaScript?"

153. Investigate hyperterm

154. For AI inspiration, see here and here

155. trymodule

156. testron

157. cssstats

158. math-input and mathquill

159. For Nightingale's rose dataset, generate an SVG figure with code, rather than use a static image

1. randn

2. abstract-ndarray

3. terminal sparklines

   • toJSON => needs chart spec

   • colors

     • ansi-256-colors
     • would require escaping to work in the browser
     • ansi_up
     • ansi-to-html
     • but could also detect env and use ansi escape when in terminal mode and use HTML elsewhere (?) => no, too brittle.
     • maybe this should just be a user concern

   • support ndarrays

     • dimension, only 1d?

4. basic stream utilities

   • make utils/debug a standard stream (cli name option; does this module need split and join?)
   • split => tests
   • join => example
   • map!!!!!!
   • cat
   • rand
   • from-array
   • duplex-json-stream
   • related => into-stream
   • concat-stream => this is essentially an end sink stream
   • pump (?)
   • end-of-stream
   • something akin to stream-combiner2
   • duplexer2
   • mississippi
   • to-console or maybe to-log (provide own logger, with default being console using util-inspect) => write stream which writes each chunk to console (either normal or object mode); if object mode, use util-inspect and allow setting of depth
   • debug as a transform stream => could provide name and then toggle debugging based on name!
   • tap-stream and inspect-stream; see also sculpt#tap
   • guide to node streams
   • vstream => instrumented streams
   • through2-concurrent
   • log
   • ndjson

5. kmeans/dbscan

6. blas routines

7. all built-in Math methods

8. kde

   • scipy
   • smith
   • kde in python
   • fast computation of kernel estimators
   • lecture
   • scikit-learn
   • wikipedia

9. hist

   • Matlab deprecates hist and histc
   • histogram
   • histcounts

10. csv/tsv/dsv

    • d3-dsv
    • node-csv
    • csv-parse
    • csv-spectrum
    • csv-parser
    • paratext
    • read-csv (file) vs from-csv (stream) vs parse-csv (string or buffer) => some overlap between these

11. simple server

1. plot cli (requires split)
2. rects
   • x
   • y
   • orientation: vert, horz
   • width calc'd via x[i+1]-x[i]
3. xAxis, yAxis -> true/false; whether to create or not
5. validation; instead of a sep validator folder, when providing an object, just set the props to validate; also allows moving etc files to prop folders
6. line -> area
7. readme
8. xExtendedTicks?

2. include links to survey in main README
3. as a REPL exercise, simulation (randn, hist, plot normal pdf)

1. is-finite (generic)

   • may need to describe how different from built-in

2. is-infinite (generic)

3. is-nan (generic)

4. is-even (generic)

5. is-odd (generic)

6. incrspace

7. linspace, logspace, incrspace as generators (?)

   • should support option to return data of a specified type; e.g., float32, etc.
   • returned value should be compliant with abstract-ndarray

8. is-browser

9. is-node

10. is-worker

11. blas routines

12. is-plain-object (?)

13. is-object

14. svg2png without promises and cleaner

    • svgexport

16. utils-deep-get

17. utils-deep-set

18. stream module (e.g., flow-split, flow-join, flow-mean) => /utils /math etc

19. hdbscan

20. number theory fcns (see starred repo)

21. str manip utils

22. Avogadro's number

23. round to number of sig figs

    • see MFX
    • see Julia

24. testing for

    • sin
    • ln
    • exp
    • sqrt
    • tan

25. fibo

    • lookup

26. scalbn

    • cppreference
    • how would the FLOAT_RADIX be supplied?

27. int32-to-uint32

28. fast pow

    • may need to research

29. port upsearch to fs

    • requires is-* modules

30. is-electron

    • renderer
    • electron-is

31. global var detection

32. feature detection utils

33. port https-server

34. pipe viewer

    • node-pv
    • blog

35. downloads-folder along with tmpdir, homedir, etc

36. next-tick

    • polyfill

37. linux utility equivalents

    • cat, mv, rm, ls, touch, etc.
    • allow for swapping out when using browser virtual filesystem, allowing isomorphic apps (although, filesystem data would prob not be copied to browser)

38. file-type

    • break into separate mods is-pdf-file, etc.

39. move is-uri main regex to separate module? Would allow for capturing parts of the scheme. Needs evaluating.

40. kmeans as an EventEmitter

41. bring debug in-house

42. colorscales

43. datasets

44. utility to convert R DESCRIPTION files to JSON => would streamline getting test fixture R dependencies

    • R docs
    • debian control files
    • debian-control-parser
    • readcontrol

45. accumulators

    • boost src
    • boost docs
    • handystats

46. discretize

47. gmm

48. incrmkurtosis (windowed)

49. incrmskewness (windowed)

50. buffer-indexof and buffer-split => see issues

51. base math swap (assume array-like) and generics swap (check for array-like)

52. online stats

53. escape-regexp

54. hex to ascii

55. arc4 cipher as a stream

56. float64-to-hex

    • double-hex
    • raw fields of float
    • binary scientific notation
    • converting floats
    • Python float.hex
    • hex floating-point constants

57. object inspector; also, Node.js utils.inspect

58. object diffing

59. random/uuid; various versions

60. custom error classes

61. S&P 500 dataset

1. units

   • unit-parser
   • boost

2. Interesting mod => potrace

3. Bugs in the built-in Math object:

   • V8 sin/cos
   • V8 trig fcns
   • V8 not obeying IEEE 754-2008
   • Mozilla discussion on V8 sin/cos
   • V8 replaced a trig lookup table and then computes tan as sin/cos
   • Browser math accuracy issues
   • ES6 accuracy of special functions
   • V8 exp accuracy
   • spreadsheet showing trig results across browsers
   • V8 pow accuracy
   • Mozilla pow accumulation of errors
   • V8 hyperbolic trig accuracy
   • TC39 testing of Math built-ins
   • ES6 shim accuracy issues
   • V8 Math.random
   • V8 fixes Math.random
   • V8 finally returns pseudorandom numbers
   • Webkit switched to weak PRNG for speed
   • V8 deopts if Math.floor provided -0
   • V8 deopts if Math.ceil provided 0
   • V8 Math.round returns wrong results

• Square root without division
• Reciproot Algorithm: correctly rounded?
• reciproot implementation
• glibc sqrt
• IPython: A System for Interactive Scientific Computing
• IPython: Sloan Grant

1. when testing numeric code, would be interesting to test against multiple platforms (ala test fixtures); e.g., Julia, Python, R, Go, Boost, etc.

   • ability to run against multiple versions of alternative platforms

   • compare results for each alternative platform version

     • would allow flagging regressions or improvements in the implementations of other platforms

   • would be part of a comprehensive CI before publishing

     • suppose could also be done at the individual module level during separation

   • generate plots showing results across all platforms

2. a tool which reports which paths are not imported by a file

   • use case is ensuring that modules which should be exported by an aggregate file are exported

3. for JSDoc docs, ability to run benchmarks for any given method

   • UI button to run benchmark

   • per method/module/etc (similar to having a button to view source)

   • would allow users to test the relatively speed of pathways within a function; e.g., for erf, how fast do particular input values compare to other input values?

     • note: naive benchmarks would only provide a single value => erf(10); but this approach is flawed. Need to cover a range of values; otherwise, you could be testing a special case!
     • would allow another avenue for crowdsourcing benchmarks

4. if every module wrapped as a stream, then, via linking, terminal becomes a REPL

   • ability to invoke with arg

     $ erf 5
     # => <number>
     $ erf 5 19 13 1
     # => <number>\n<number>\n... (could have option to specify delimiter)

   • ability to pipe

     $ cat x.txt | erf
     # => ...

   • may want to prefix with stdlib-<fcn> to avoid conflicts with built-ins

     • tools script could crawl the project and auto create aliases and links

5. for modules like generic stats functions which may accept a variety of inputs requiring tailored implementations, instead of dynamic code generation, another possibility is to dynamically compile static code and write to disk

   • would allow static analysis
   • easier debugging, as can set breakpoints, etc. => some inspectors support using a pragma to allow debugging eval'd code, thus debugging is possible as is; nevertheless, visual inspection is easier if non-compiled
   • would allow for the use of JSDoc annotations, not possible when using dynamic code generation => can, but akin to documenting a "virtual" function
   • would lead, however, to a much larger codebase
   • in make init, could configure to "watch" and dynamically recompile generated files
   • to discover and identify compile targets, could add a "stdlib" field to a module's package.json with a configuration setting relevant to the type of compilation to perform (could lead to a proliferation of tailored settings, which is not necessarily a good thing)

Will need a tools directory in individual repositories to

• house Makefile dependencies

• include CI scripts

• house doc tools

  • JSDoc templates
  • JSDoc typedefs

1. Populate individual module contributors automatically by extracting author info from git commits?

   • main author could be populated based on highest number of commits? most changes? responsible for most lines of code?

     • most lines of code may be best heuristic as likely that the author is thus most knowledgeable/owns the most code
     • over time the main author could change...is this a problem? => prob not, as the new author should be most familiar with the relevant code

2. populate scripts similarly for all modules

3. augment keywords with universal project keywords

4. can add testling config, if needed

5. populate git urls based on destination repo

6. should be able to scan module code to determine dev and main deps and add them to the package.json based on what is installed in the main repo

   • dependency-check

     • uses node-detective

   • node-detective

     • apparently relies on outdated mods, but may still work

   • node-source-walk

     • uses more recent acorn version

   • if a dependency is already included in the package.json, keep that dependency, thus allowing local override of a dependency

     • how will that work in terms of dep install within the context of the larger project?
     • module-deps

7. can updating the version be automated?

1. Read license field in package.json and generate the appropriate license

1. Ideal vs reality

   • @stdmath/base/special/erf

     • @stdmath/base-special-erf

   • @stdmath/generics/special/erf

     • @stdmath/generics-special-erf

2. Under the @stdlib scope...

   • @stdlib/math-base-special-erf
   • @stdlib/math-base-core-float64-to-binary-string

3. References on root global

   • underscore
   • lodash
   • window.js
   • stackoverflow
   • insert-module-globals
   • TC39
   • symstem.global

Sample project structure.

|-stdlib |---lib |-----datasets |-------anscombes-quartet |-----math |-------base |---------blas |-----------scal |---------complex |-----------acos |-----------sin |---------dist |-----------norm |-------------cdf |-------------pdf |-----------poisson |---------random |-----------lcg |---------special |-----------erf |-----------erfc |-----------sin |---------tools |-----------evalpoly |-----------evalrational |---------utils |-----------is-even |-----------is-integer |-----------is-number |-----------is-odd |-------constants |---------e |---------pi |---------two-pi |-------fastmath |---------special |-----------cos |-----------sin |-------generics |---------core |-----------add |-----------mult |-----------subtract |-----------sum |---------dist |-----------norm |-----------poisson |---------linalg |---------random |-----------lcg |---------special |-----------erf |-----------erfc |---------statistics |-----------mean |-----------stdev |-----------variance |-----namespace |-----regexp |-------eol |-------regexp |-----repl |-----streams |-------math |---------mean |---------stdev |-------utils |---------split |---------join |-----tools |-----types |-------array |-------complex |-------dataframe |-------matrix |-------ndarray |-----utils |-------copy |-------deep-get |-------deep-set |-------error-reviver |-------error-to-json |-------is-array-like |-------is-function |-------left-pad-string |-------merge |-------pad-string |-------pluck |-------repeat-string |-------right-pad-string