Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find out maintained repository #2

Open
wants to merge 69 commits into
base: master
Choose a base branch
from

Conversation

niccokunzmann
Copy link

sloisel#72

@orangeduck and @GerHobbelt you both put in a lot of work.

I am creating this pull-request to see, if we can have a single repository coming out as the maintained one, if you both are willing to join forces.

GerHobbelt and others added 30 commits December 3, 2012 01:09
Conflicts:
	tools/unit2.js
	workshop.php
a javascript implementation of Newton solver, which is ported from GSL
(GNU Scientific Library) 's globally convergent Newton method
(gsl-1.15\multiroots\gnewton.c)

This Newton solver has been successfully used to implement a simple
geometric constraint solver in project Rena
(https://github.com/kaige/Rena)
This replaces calls to javascript's Function() with calls to the new numeric.compile(), which is a wrapper that closures in the numeric object so that methods on it can be used inside compiled code. The motivation here is to allow using numeric without globally exporting the `numeric` symbol.
2. bug fixed in the benchmark page
the performance of SOR solver is not as good as CG and BiCGSTAB, but similar to ccsLUPSolve.
in practice, CG and BiCGSTAB should always be the best options.
2. test added, doc updated
This avoids relying on automatic semicolon insertion, to make the code
cleaner and avoid pitfalls.  The svd module in particular had many
unterminated lines, likely due to its Python heritage.  The insertion places
were identified by JSHint.
Many places in numeric.js create new functions using the Function(...)
constructor.  Such functions do not have access to the local scope.
Therefore they bind to the global "numeric" object, which might not exist,
or might belong to a different version of numeric.js, or might be something
different altogether.  Since we are careful enough to have a local variable
in most places, it appears prudent to make sure that we pass this to
functions created from source strings as well.
Due to how prettyPrint was implemented, 100 would always be rendered as 1e2. Fixed that particular error. Still leaves open the issue of rendering 10000 as 1e4, for example.
This warning was being logged to the console whenever there was a doubled
semicolon after a return statement, because there is an unreachable (empty)
statement between the semicolons.

Regularize the usage of semicolons in generated code to avoid producing these
warnings.
GerHobbelt and others added 28 commits September 9, 2016 23:24
# Conflicts:
#	src/numeric.js
#	src/svd.js
# Conflicts:
#	src/numeric.js
#	tools/build.sh
# Conflicts:
#	documentation.html
#	src/documentation.html
#	src/numeric.js
…t the UMD library file (CommonJS+AMD+Browser support)
…anually from latest github repo sources, sans minification for easier debugging.
… pages (also note: iterative.js is now part of numeric-latest.js so there's no need to include it).
@orangeduck
Copy link
Owner

I'm probably not the guy to maintain numeric since I'm not using the library any more and don't have that much free time at the moment - so if @GerHobbelt is more interested then definitely go with him. Saying that - I am sure I could find some time to try and merge in these commits to my repo if people are using my fork as canonical version and it will be seen as something useful to the community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.