SwiftyNSDictionary is a library that can help you convert values stored in a NSDictionary into non-objective-c types safely.
As we all know that Objective C containers such as NSArray,NSDictionary cannot store non-object types.
Because of this the evil NSNull borns which causes lots of chaos. This library is to help get values safely without considering
Objective-C types.
About
It requires minimum swift version is 3.0.
Issues are welcomed.
Usage
We have functions that get values stored for a key: String, and cast to types which are widely used safely.
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
npm test
Launches the test runner in the interactive watch mode.
See the section about running tests for more information.
npm run build
Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
npm run eject
Note: this is a one-way operation. Once you eject, you can’t go back!
If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.
Instead, it will copy all the configuration files and the transitive dependencies (webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.
You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.
Pwn2Own: Metasploit modules created for / used in Pwn2Own competitions I have participated in
fuzzing: proof of concept or fuzzing testcases that have an assigned CVE identifier but weren’t exploitable (or I just didn’t have time to dig further and make them exploitable)
tools: a few of my tools which might be useful for other hackers
pedigree.csv: a CSV file containing all my trophies, aka CVE and ZDI identifiers assigned to my vulnerabilities, my Metasploit modules that have been integrated into the framework, etc (basically my vulnerability CV)
All information, code and binary data in this repository is released to the public under the GNU General Public License, version 3 (GPLv3).
For information, code or binary data obtained from other sources that has a license which is incompatible with GPLv3, the original license prevails.
For more information check https://www.gnu.org/licenses/gpl-3.0.en.html or the LICENSE file in the root of this repository.
Please note that Agile Information Security Limited (Agile InfoSec) relies on information provided by the vendor / product manufacturer when listing fixed versions, products or releases. Agile InfoSec does not verify this information, except when specifically mentioned in the advisory text and requested or contracted by the vendor to do so.
Unconfirmed vendor fixes might be ineffective, incomplete or easy to bypass and it is the vendor’s responsibility to ensure all the vulnerabilities found by Agile InfoSec are resolved properly. Agile InfoSec usually provides the information in its advisories free of charge to the vendor, as well as a minimum of six months for the vendor to resolve the vulnerabilities identified in its advisories before they are made public.
Agile InfoSec does not accept any responsibility, financial or otherwise, from any material losses, loss of life or reputational loss as a result of misuse of the information or code contained or mentioned in its advisories. It is the vendor’s responsibility to ensure their products’ security before, during and after release to market.
PRIMA is a package for solving general nonlinear optimization problems without using derivatives.
It provides the reference implementation for Powell’s renowned derivative-free optimization methods, i.e., COBYLA, UOBYQA, NEWUOA, BOBYQA, and LINCOA.
The “P” in the name stands for Powell,
and “RIMA” is an acronym for “Reference Implementation with Modernization and Amelioration”.
Professor Powell carefully implemented his derivative-free optimization methods into publicly available solvers,
which are genuine masterpieces. They are widely used by engineers and scientists. For instance,
see Section 1 of a recent paper on Powell’s solvers
as well as the Google searches of COBYLA
and BOBYQA.
However, Professor Powell’s implementation was done in Fortran 77.
The code is nontrivial to understand or maintain, let alone extend.
For many practitioners, this has become an obstacle to exploiting these solvers in their
applications. Even worse, it has hindered researchers from exploring the wealth left by Professor
Powell. By all means, it is
necessary to make the solvers available in languages other than Fortran
promptly, first wrapping Powell’s code, which is the objective of PDFO,
and then providing native and modernized implementations, which is the mission of PRIMA.
Before he passed, Professor Powell had asked me and
Professor Nick Gould to maintain his solvers.
This is an honorable mission. To make the solvers more accessible, I started PRIMA.
It is a project similar to the translation, interpretation, and annotation of Euclid’s
Elements. It will make Powell’s solvers easily understandable to everyone, not only the experts.
Few people remember who translated Elements,
but it is a job that must be done.
PRIMA aims to provide the reference implementation of Powell’s methods in modern languages,
including modern Fortran (F2008 or newer), C/C++, Python, MATLAB,
Julia, and R. It will be a faithful implementation, in the sense that the code will be
mathematically equivalent to Powell’s, except for the
bug fixes and improvements made intentionally.
The focus is to implement these methods in a structured and modularized way so that they
are understandable, maintainable, extendable, fault-tolerant, and future-proof.
The code will have no GOTO (of course)
and will use matrix-vector procedures instead of loops whenever possible.
In doing so, PRIMA codes the algorithms in a way that we would present them on a blackboard.
Such an implementation will enable us to get a deeper understanding of Powell’s methods and
pave the way for new developments based on them.
There do exist “translations” of Powell’s Fortran 77 code in other languages. For example,
NLopt contains a C version of COBYLA, NEWUOA, and BOBYQA,
but the C code in NLopt is translated from the Fortran 77 code straightforwardly, if
not automatically by f2c, and hence inherits the style, structure,
and probably bugs of the original Fortran 77 implementation.
Note, however, that
Py-BOBYQA is a true translation of BOBYQA
to Python, with significant improvements.
How
The mission of PRIMA is nontrivial due to the delicacy of Powell’s algorithms and the unique style
of his code. To ensure the faithfulness of PRIMA,
the modern Fortran version was started by refactoring Powell’s code into the free form via a small
MATLAB tool.
However, such refactored code is far from what is desired, because it inherits completely
the structure and style of Powell’s code except for the layout. Significant modifications are needed
to reorganize (indeed, to rewrite) the code. To maintain the faithfulness and quality of the
reference implementation, extensive tests are conducted after each and every tiny modification,
using the CUTEst problems via MatCUTEst.
The tests do not only verify the faithfulness of the implementation but also check that the solvers
behave properly even if they are invoked with improper inputs or encounter failures of function
evaluations.
Stress tests are also conducted
periodically to verify that the solvers work correctly without running into errors when applied to
excessively large problems.
The tests are automated by
GitHub Actions.
As of August 2023, more than
45,000 “workflows” have been successfully run by GitHub Actions. Normally, each workflow consists of ~ 5
(sometimes more than 200)
randomized tests,
each test taking from tens of minutes to several hours (the maximum
is 6 hours, after which the test will be canceled automatically). In other words,
PRIMA has been verified by more than 200,000 hours (or more than 20 years) of randomized tests.
Code must be battle-tested before becoming software.
Current status
Modern Fortran
After almost three years of intensive coding, the modern Fortran version of
PRIMA was finished by December 2022.
It can be compiled using CMake as follows.
git clone --depth 1 https://github.com/libprima/prima.git
cd prima
cmake -S . -B build -DCMAKE_INSTALL_PREFIX=install
cmake --build build --target install
This should create the primaf library for Fortran usage, located in the install/lib/ directory
to be used with the module files in install/include/prima/mod/.
In case CMake fails to find your Fortran compiler,
you can indicate it by specifying -DCMAKE_Fortran_COMPILER=/path/to/your/Fortran/compiler.
Similarly, set -DCMAKE_C_COMPILER=/path/to/your/C/compiler for your C compiler if needed.
Examples on how to use the library from an external code are available in fortran/examples/.
Below is an illustration with COBYLA.
A C binding to the Fortran library is available in the c/ folder.
In the same way as the Fortran library, it can be compiled using CMake,
which should also create the primac library for C compilation, located in install/lib/ to be used with the prima.h header in install/include/prima/.
Examples on how to use the library from an external code are available in c/examples/.
Below is an illustration with COBYLA.
A pure MATLAB version of NEWUOA is implemented. It was
generated straightforwardly (indeed, automatically) from an earlier version of the
modern Fortran code (with the help of Mr. Galann Pennec). The other four solvers will be
implemented in MATLAB similarly.
Interfaces for using the modern Fortran implementation in other languages will be available later.
Given the modern Fortran version, native implementations in other languages
become much easier, because we now have a structured and modularized implementation as a reference.
My team will implement the methods in other languages in this way.
For instance, see the MATLAB version of NEWUOA
and the Python version of COBYLA
(included in SciPy since 1.16.0).
This is the main motivation for developing the modern Fortran version first —
to provide a modernized reference implementation for the development in other languages.
Bug fixes
PRIMA has fixed some serious issues in the original Fortran 77 implementation of Powell’s methods.
Note that all of them are problems in the Fortran 77 code rather than flaws in the algorithms.
The examples given below are bugs or requests sent to SciPy,
NLopt,
nloptr,
OpenTURNS,
etc., which are reputable packages that wrap/interface the original Fortran 77 implementation
of Powell’s solver. Inevitably, they suffer from the bugs in the Fortran 77 code.
The Fortran 77 solvers may get stuck in infinite loops.
Fortran 77 COBYLA may not return the best point that is evaluated; sometimes, the returned point can have a
large constraint violation even though the starting point is feasible.
Thanks to the improvements introduced into the new implementation, PRIMA
generally produces better solutions with fewer function evaluations compared with Powell’s Fortran 77 implementation.
This makes PRIMA preferable if function evaluations are expensive,
which is typically the case for derivative-free optimization problems.
However, if function evaluations are not the dominant cost in your application (e.g., a function
evaluation takes only milliseconds), the Fortran 77
solvers are likely to be faster, as they are more efficient in terms of memory usage and flops
thanks to the careful and ingenious (but unmaintained and unmaintainable) implementation by Powell.
Below are the performance profiles
of the PRIMA solvers compared with Powell’s implementation in terms of the number of function evaluations,
the convergence tolerance being $\tau = 10^{-6}$.
Roughly speaking, performance profiles plot the percentage of test problems solved against the budget,
which is measured relative to the cost of the most efficient solver in the comparison.
A higher curve indicates a better solver.
See Benchmarking Derivative-Free Optimization Algorithms
(J. J. Moré and S. M. Wild)
for more information.
NEWUOA on unconstrained CUTEst problems of at most 200 variables
BOBYQA on bound-constrained CUTEst problems of at most 200 variables
LINCOA on linearly constrained CUTEst problems of at most 200 variables and 20000 constraints
COBYLA on nonlinearly constrained CUTEst problems of at most 100 variables and 10000 constraints
UOBYQA on unconstrained CUTEst problems of at most 100 variables
Among numerous honors, Powell was one of the two recipients of the first
Dantzig Prize
from the Mathematical Programming Society (MOS) and Society for Industrial and Applied Mathematics (SIAM).
This is considered the highest award in optimization.
A “fun” fact
In the past years, while working on PRIMA, I have spotted a dozen of bugs in reputable Fortran compilers
and three bugs in MATLAB. Each of them represents days of bitter debugging, which finally led to the conclusion
that it was not a problem in my code but a flaw in the Fortran compilers or in MATLAB. From a very unusual angle, this reflects how intensive
the coding has been.
The bitterness behind this “fun” fact is exactly why I work on PRIMA: I hope that all
the frustrations that I have experienced will not happen to any user of Powell’s methods anymore.
I hope I am the last one in the world to decode a maze of 244 GOTOs in 7939 lines of Fortran 77 code —
I did this for three years and I do not want anyone else to do it again.
Acknowledgment
PRIMA is dedicated to the memory of the late Professor Powell with gratitude for his inspiration and
for the wealth he left to us.
I am profoundly grateful to Professor Ya-xiang Yuan for his everlasting encouragement and support.
During the years working on PRIMA, due to the gap in my publication record, I needed a lot of
support from the optimization community and beyond.
Thank you for help, known or unknown to me, explicit or implicit, without which I would not have survived.
The development of PRIMA would have been a mission impossible without the groundwork laid by the PDFO
package of Tom M. Ragonneau and Zaikun Zhang.
PDFO is Chapter 3 of Ragonneau’s thesis co-supervised by Zaikun Zhang
and Professor Xiaojun Chen,
with financial support from the Hong Kong Ph.D. Fellowship Scheme (ref. PF18-24698).
Last but not least, I am deeply grateful to the contributors
from the open-source community.
Citing PRIMA
PRIMA has taken me significant energy and time. I will be delighted if it is useful to you. All I need is a citation / acknowledgment,
which is crucial for the sustainability of the project, as software development is not well recognized in academia despite
its importance and the significant efforts it requires.
Note that PRIMA contains bug fixes and improvements that do not exist in Powell’s Fortran 77
implementation of the solvers. Results produced by PRIMA are surely different from Powell’s original solvers,
even though the algorithms are essentially the same. Therefore,
it is important to point out that you are using PRIMA rather than the original solvers if you want your results to be reproducible.
It is wrong to pretend that PRIMA is just Powell’s original solvers.
If you use PRIMA, please cite it as follows. The citation will be pointed to my paper on PRIMA when I finish it.
@misc{Zhang_2023,
title = {{PRIMA: Reference Implementation for Powell's Methods with Modernization and Amelioration}},
author = {Zhang, Z.},
howpublished = {available at http://www.libprima.net, DOI: 10.5281/zenodo.8052654},
year = {2023}
}
In addition, Powell’s methods can be cited as follows.
[2] M. J. D. Powell, A direct search optimization method that models the
objective and constraint functions by linear interpolation,
In Advances in Optimization and Numerical Analysis, eds. S. Gomez and J. P. Hennart,
pages 51–67, Springer Verlag, Dordrecht, Netherlands, 1994
[3] M. J. D. Powell, UOBYQA: unconstrained optimization by quadratic
approximation, Math. Program., 92(B):555–582, 2002
[4] M. J. D. Powell, The NEWUOA software for unconstrained optimization
without derivatives, In Large-Scale Nonlinear Optimization, eds. G. Di Pillo
and M. Roma, pages 255–297, Springer, New York, US, 2006
[5] M. J. D. Powell, The BOBYQA algorithm for bound constrained
optimization without derivatives, Technical Report DAMTP 2009/NA06,
Department of Applied Mathematics and Theoretical Physics, Cambridge
University, Cambridge, UK, 2009
LINCOA seeks the least value of a nonlinear function subject to
linear inequality constraints without using derivatives of the objective
function. Powell did not publish a paper to introduce the algorithm.
The paper [6] introduces the PDFO package
rather than PRIMA. Nevertheless, it provides probably the most accessible introduction to Powell’s methods.
Charityware
PRIMA is charityware, distributed for free under its
license.
If you appreciate it, you may consider making a donation to a charity that you trust
(in addition to citing & acknowledging PRIMA).
This is only a suggestion, not an obligation.
The inspiration comes from Vim, with which Zaikun Zhang typed all his PRIMA code.
PRIMA is a package for solving general nonlinear optimization problems without using derivatives.
It provides the reference implementation for Powell’s renowned derivative-free optimization methods, i.e., COBYLA, UOBYQA, NEWUOA, BOBYQA, and LINCOA.
The “P” in the name stands for Powell,
and “RIMA” is an acronym for “Reference Implementation with Modernization and Amelioration”.
Professor Powell carefully implemented his derivative-free optimization methods into publicly available solvers,
which are genuine masterpieces. They are widely used by engineers and scientists. For instance,
see Section 1 of a recent paper on Powell’s solvers
as well as the Google searches of COBYLA
and BOBYQA.
However, Professor Powell’s implementation was done in Fortran 77.
The code is nontrivial to understand or maintain, let alone extend.
For many practitioners, this has become an obstacle to exploiting these solvers in their
applications. Even worse, it has hindered researchers from exploring the wealth left by Professor
Powell. By all means, it is
necessary to make the solvers available in languages other than Fortran
promptly, first wrapping Powell’s code, which is the objective of PDFO,
and then providing native and modernized implementations, which is the mission of PRIMA.
Before he passed, Professor Powell had asked me and
Professor Nick Gould to maintain his solvers.
This is an honorable mission. To make the solvers more accessible, I started PRIMA.
It is a project similar to the translation, interpretation, and annotation of Euclid’s
Elements. It will make Powell’s solvers easily understandable to everyone, not only the experts.
Few people remember who translated Elements,
but it is a job that must be done.
PRIMA aims to provide the reference implementation of Powell’s methods in modern languages,
including modern Fortran (F2008 or newer), C/C++, Python, MATLAB,
Julia, and R. It will be a faithful implementation, in the sense that the code will be
mathematically equivalent to Powell’s, except for the
bug fixes and improvements made intentionally.
The focus is to implement these methods in a structured and modularized way so that they
are understandable, maintainable, extendable, fault-tolerant, and future-proof.
The code will have no GOTO (of course)
and will use matrix-vector procedures instead of loops whenever possible.
In doing so, PRIMA codes the algorithms in a way that we would present them on a blackboard.
Such an implementation will enable us to get a deeper understanding of Powell’s methods and
pave the way for new developments based on them.
There do exist “translations” of Powell’s Fortran 77 code in other languages. For example,
NLopt contains a C version of COBYLA, NEWUOA, and BOBYQA,
but the C code in NLopt is translated from the Fortran 77 code straightforwardly, if
not automatically by f2c, and hence inherits the style, structure,
and probably bugs of the original Fortran 77 implementation.
Note, however, that
Py-BOBYQA is a true translation of BOBYQA
to Python, with significant improvements.
How
The mission of PRIMA is nontrivial due to the delicacy of Powell’s algorithms and the unique style
of his code. To ensure the faithfulness of PRIMA,
the modern Fortran version was started by refactoring Powell’s code into the free form via a small
MATLAB tool.
However, such refactored code is far from what is desired, because it inherits completely
the structure and style of Powell’s code except for the layout. Significant modifications are needed
to reorganize (indeed, to rewrite) the code. To maintain the faithfulness and quality of the
reference implementation, extensive tests are conducted after each and every tiny modification,
using the CUTEst problems via MatCUTEst.
The tests do not only verify the faithfulness of the implementation but also check that the solvers
behave properly even if they are invoked with improper inputs or encounter failures of function
evaluations.
Stress tests are also conducted
periodically to verify that the solvers work correctly without running into errors when applied to
excessively large problems.
The tests are automated by
GitHub Actions.
As of August 2023, more than
45,000 “workflows” have been successfully run by GitHub Actions. Normally, each workflow consists of ~ 5
(sometimes more than 200)
randomized tests,
each test taking from tens of minutes to several hours (the maximum
is 6 hours, after which the test will be canceled automatically). In other words,
PRIMA has been verified by more than 200,000 hours (or more than 20 years) of randomized tests.
Code must be battle-tested before becoming software.
Current status
Modern Fortran
After almost three years of intensive coding, the modern Fortran version of
PRIMA was finished by December 2022.
It can be compiled using CMake as follows.
git clone --depth 1 https://github.com/libprima/prima.git
cd prima
cmake -S . -B build -DCMAKE_INSTALL_PREFIX=install
cmake --build build --target install
This should create the primaf library for Fortran usage, located in the install/lib/ directory
to be used with the module files in install/include/prima/mod/.
In case CMake fails to find your Fortran compiler,
you can indicate it by specifying -DCMAKE_Fortran_COMPILER=/path/to/your/Fortran/compiler.
Similarly, set -DCMAKE_C_COMPILER=/path/to/your/C/compiler for your C compiler if needed.
Examples on how to use the library from an external code are available in fortran/examples/.
Below is an illustration with COBYLA.
A C binding to the Fortran library is available in the c/ folder.
In the same way as the Fortran library, it can be compiled using CMake,
which should also create the primac library for C compilation, located in install/lib/ to be used with the prima.h header in install/include/prima/.
Examples on how to use the library from an external code are available in c/examples/.
Below is an illustration with COBYLA.
A pure MATLAB version of NEWUOA is implemented. It was
generated straightforwardly (indeed, automatically) from an earlier version of the
modern Fortran code (with the help of Mr. Galann Pennec). The other four solvers will be
implemented in MATLAB similarly.
Interfaces for using the modern Fortran implementation in other languages will be available later.
Given the modern Fortran version, native implementations in other languages
become much easier, because we now have a structured and modularized implementation as a reference.
My team will implement the methods in other languages in this way.
For instance, see the MATLAB version of NEWUOA
and the Python version of COBYLA
(included in SciPy since 1.16.0).
This is the main motivation for developing the modern Fortran version first —
to provide a modernized reference implementation for the development in other languages.
Bug fixes
PRIMA has fixed some serious issues in the original Fortran 77 implementation of Powell’s methods.
Note that all of them are problems in the Fortran 77 code rather than flaws in the algorithms.
The examples given below are bugs or requests sent to SciPy,
NLopt,
nloptr,
OpenTURNS,
etc., which are reputable packages that wrap/interface the original Fortran 77 implementation
of Powell’s solver. Inevitably, they suffer from the bugs in the Fortran 77 code.
The Fortran 77 solvers may get stuck in infinite loops.
Fortran 77 COBYLA may not return the best point that is evaluated; sometimes, the returned point can have a
large constraint violation even though the starting point is feasible.
Thanks to the improvements introduced into the new implementation, PRIMA
generally produces better solutions with fewer function evaluations compared with Powell’s Fortran 77 implementation.
This makes PRIMA preferable if function evaluations are expensive,
which is typically the case for derivative-free optimization problems.
However, if function evaluations are not the dominant cost in your application (e.g., a function
evaluation takes only milliseconds), the Fortran 77
solvers are likely to be faster, as they are more efficient in terms of memory usage and flops
thanks to the careful and ingenious (but unmaintained and unmaintainable) implementation by Powell.
Below are the performance profiles
of the PRIMA solvers compared with Powell’s implementation in terms of the number of function evaluations,
the convergence tolerance being $\tau = 10^{-6}$.
Roughly speaking, performance profiles plot the percentage of test problems solved against the budget,
which is measured relative to the cost of the most efficient solver in the comparison.
A higher curve indicates a better solver.
See Benchmarking Derivative-Free Optimization Algorithms
(J. J. Moré and S. M. Wild)
for more information.
NEWUOA on unconstrained CUTEst problems of at most 200 variables
BOBYQA on bound-constrained CUTEst problems of at most 200 variables
LINCOA on linearly constrained CUTEst problems of at most 200 variables and 20000 constraints
COBYLA on nonlinearly constrained CUTEst problems of at most 100 variables and 10000 constraints
UOBYQA on unconstrained CUTEst problems of at most 100 variables
Among numerous honors, Powell was one of the two recipients of the first
Dantzig Prize
from the Mathematical Programming Society (MOS) and Society for Industrial and Applied Mathematics (SIAM).
This is considered the highest award in optimization.
A “fun” fact
In the past years, while working on PRIMA, I have spotted a dozen of bugs in reputable Fortran compilers
and three bugs in MATLAB. Each of them represents days of bitter debugging, which finally led to the conclusion
that it was not a problem in my code but a flaw in the Fortran compilers or in MATLAB. From a very unusual angle, this reflects how intensive
the coding has been.
The bitterness behind this “fun” fact is exactly why I work on PRIMA: I hope that all
the frustrations that I have experienced will not happen to any user of Powell’s methods anymore.
I hope I am the last one in the world to decode a maze of 244 GOTOs in 7939 lines of Fortran 77 code —
I did this for three years and I do not want anyone else to do it again.
Acknowledgment
PRIMA is dedicated to the memory of the late Professor Powell with gratitude for his inspiration and
for the wealth he left to us.
I am profoundly grateful to Professor Ya-xiang Yuan for his everlasting encouragement and support.
During the years working on PRIMA, due to the gap in my publication record, I needed a lot of
support from the optimization community and beyond.
Thank you for help, known or unknown to me, explicit or implicit, without which I would not have survived.
The development of PRIMA would have been a mission impossible without the groundwork laid by the PDFO
package of Tom M. Ragonneau and Zaikun Zhang.
PDFO is Chapter 3 of Ragonneau’s thesis co-supervised by Zaikun Zhang
and Professor Xiaojun Chen,
with financial support from the Hong Kong Ph.D. Fellowship Scheme (ref. PF18-24698).
Last but not least, I am deeply grateful to the contributors
from the open-source community.
Citing PRIMA
PRIMA has taken me significant energy and time. I will be delighted if it is useful to you. All I need is a citation / acknowledgment,
which is crucial for the sustainability of the project, as software development is not well recognized in academia despite
its importance and the significant efforts it requires.
Note that PRIMA contains bug fixes and improvements that do not exist in Powell’s Fortran 77
implementation of the solvers. Results produced by PRIMA are surely different from Powell’s original solvers,
even though the algorithms are essentially the same. Therefore,
it is important to point out that you are using PRIMA rather than the original solvers if you want your results to be reproducible.
It is wrong to pretend that PRIMA is just Powell’s original solvers.
If you use PRIMA, please cite it as follows. The citation will be pointed to my paper on PRIMA when I finish it.
@misc{Zhang_2023,
title = {{PRIMA: Reference Implementation for Powell's Methods with Modernization and Amelioration}},
author = {Zhang, Z.},
howpublished = {available at http://www.libprima.net, DOI: 10.5281/zenodo.8052654},
year = {2023}
}
In addition, Powell’s methods can be cited as follows.
[2] M. J. D. Powell, A direct search optimization method that models the
objective and constraint functions by linear interpolation,
In Advances in Optimization and Numerical Analysis, eds. S. Gomez and J. P. Hennart,
pages 51–67, Springer Verlag, Dordrecht, Netherlands, 1994
[3] M. J. D. Powell, UOBYQA: unconstrained optimization by quadratic
approximation, Math. Program., 92(B):555–582, 2002
[4] M. J. D. Powell, The NEWUOA software for unconstrained optimization
without derivatives, In Large-Scale Nonlinear Optimization, eds. G. Di Pillo
and M. Roma, pages 255–297, Springer, New York, US, 2006
[5] M. J. D. Powell, The BOBYQA algorithm for bound constrained
optimization without derivatives, Technical Report DAMTP 2009/NA06,
Department of Applied Mathematics and Theoretical Physics, Cambridge
University, Cambridge, UK, 2009
LINCOA seeks the least value of a nonlinear function subject to
linear inequality constraints without using derivatives of the objective
function. Powell did not publish a paper to introduce the algorithm.
The paper [6] introduces the PDFO package
rather than PRIMA. Nevertheless, it provides probably the most accessible introduction to Powell’s methods.
Charityware
PRIMA is charityware, distributed for free under its
license.
If you appreciate it, you may consider making a donation to a charity that you trust
(in addition to citing & acknowledging PRIMA).
This is only a suggestion, not an obligation.
The inspiration comes from Vim, with which Zaikun Zhang typed all his PRIMA code.
git clone https://github.com/cyneuro/neuroapi.git
cd neuroapi
sudo docker-compose up -d
Manual Start
Obtaining the code:
git clone https://github.com/cyneuro/neuroapi.git
cd neuroapi
If you don’t have neuron or anaconda installed use the scripts located in the nrn_install folder.
In the following example ubuntu is the user account. You MUST specify the full path of the install directory. TODO: realpath
cd neuroapi/nrn_install
mkdir /home/ubuntu/apps
./ubuntu_requirements.sh
./easy-conda-install.sh /home/ubuntu/apps
./easy-nrn-install.sh /home/ubuntu/apps
You will need to have NEURON installed and accessible by python for some of the functions.
cd neuroapi
pip install -r requirements.txt
python setup.py develop
neuroapi init
neuroapi run -h 0.0.0.0
Authentication
THIS IS NOT CURRENTLY ENABLED FOR THE FUNCTIONS CALL
To access protected resources, you will need an access token. You can generate
an access and a refresh token using /auth/login endpoint, example using curl
XomegaJS is a next generation MVVM framework for building powerful data oriented HTML5 single page applications (SPA). It largely mirrors the UI features that are available in our C#-based XomegaFramework, and is developed with TypeScript to provide type safety and compilation, promote reusability and ensure consistency across the application, which is especially valuable for large scale SPA projects.
XomegaJS uses Knockout, JQuery and other popular JavaScript frameworks to deliver highest quality functionality and speed up application development.
Features
XomegaJS provides rich base and utility classes for building presentation layer data objects that can be bound to the standard HTML controls, and then used to build view models and views from those. Some of the important features that the framework supports are as follows.
Data Properties encapsulate a data value (or multiple values) and metadata, such as editability, visibility, security access, required flag, possible values, modification tracking, and also formatting, validation and conversion rules for the values. Properties can notify listeners about changes in the value or the metadata, and can be bound to UI controls, which would reflect any changes in the data properties, and update the property value from the user input.
Data Objects contain data properties and nested child data objects, as well as its own overarching metadata, such as editability, security access level, modification tracking, and object-level validation rules. They also provide some CRUD support, and the ability to export/import its data to/from the service data contracts.
Data List Objects are special type of data objects that are optimized for working with tabular data. They provide additional list-related functionality, including notifications about collection changes, support for multi-property sorting and row selection, and tracking of the applied criteria.
Caching of reference data on the client allows you to quickly populate selection lists, and to look up a data item by a unique key using self-indexing look-up tables. It supports extensible cache loaders, and ability to store additional attributes with each item.
View Models provide base classes for models of presentation views. They support publishing of view-level events, such as Close, Save or Delete, as well as navigation between views with input and output parameters, and handling updates from the child views.
Search Views implement support for search screens with a results grid that may allow selection, and a criteria section with flexible search operators.
Details Views implement CRUD logic, validation and modification tracking for details screens.
Bindings for common HTML5 controls to Data Properties and Data Objects allows you to easily attach views to the view models and their underlying data objects.
Client-Side Validation takes care of running all standard and custom validations on your data objects, highlighting invalid fields with an error tooltip, and also displaying a list of all validation errors using proper field labels in the error text.
Error Handling provides a framework for reporting errors on the client side, and handling errors from the server side.
Getting Started
The easiest way to get started with XomegaJS is to install our free Visual Studio extension Xomega.Net, which provides preconfigured project templates for ASP.NET, WPF and SPA applications, and allows you to instantly generate complete and powerful search and details views right from your service model. Please check our web site for more details.
You can also run our Xomega.Examples applications to see the framework in action.
A more manual way involves adding XomegaJS NuGet packages to your Visual Studio project, and reading How To guides on our forum. Feel free to post your questions there if you don’t find the information you need.
And, of course, you can always download the code and build it manually. You’re welcome to post any issues, fork the code and create pull requests with any fixes or enhancements.
Additional Resources
Below are some tutorials and articles that can help you ramp up with the framework.
Tutorials
Complete Walkthrough – a comprehensive step-by-step guide to Model-Driven Development with Xomega.Net and Xomega Framework, which walks you through building full fledged web and desktop applications with Xomega, demonstrating common use cases along the way. Check the section related to SPA projects.
How-To Guides – individual step-by-step guides that cover various topics related to developing applications with Xomega Framework and Xomega.Net.
Articles
The following articles have been written for the C#-based XomegaFramework, but a lot of their principles also apply to XomegaJS.
ES_18_The Joint Dynamics of Sovereign Ratings and Government Bond Yields
Replication Code and Data for El-Shagi and von Schweinitz (JBF, 2018)
#################################
The files in these folders can be used to replicate the paper
“The joint dynamics of sovereign ratings and government bond yields”
by Makram El-Shagi and Gregor von Schweinitz
#################################
Please cite as
El-Shagi, M., & von Schweinitz, G. (2018). The joint dynamics of sovereign ratings and government bond yields. Journal of Banking & Finance, 97, 198-218.
#################################
The folder “Rating Data” contains the raw rating information obtained from www.countryeconomy.com.
This information can be used to construct further rating statistics
The folder “Replication codes” contains all codes to run the codes in the paper. To replicate, run
main_estimation.R: runs all estimations
main_TablesFigures.R: plots all Figures, collects all information for Tables.
Among others, the folder contains codes
run_BIC.R/coint_BIC.R: estimate the optimal degree of smoothing
estimate_smooth.R: estimate the linear yield regression and the ordered probit rating equation separately
estimate_coint.R: estimate a cointegration model of both equations
bootstrap_par.R: wild bootstrap to estimate uncertainty around estimated coefficients
IRF_yshock_bs.R: simulate IRFs accounting for asymmetric coefficients and long-run convergence
ObfuscateMe is a very simple APK obfuscator with a graphical user interface (GUI) that helps developers obscure their Android application code by refactoring class names, method names, and field variables. It was developed as part of my undergraduate project at the University of Bedfordshire.
The GUI allows users to easily select the APK, packages, classes, and methods to obfuscate, making the process more intuitive and user-friendly.
The goal is to make reverse engineering more difficult by renaming sensitive parts of the APK code, making it harder for unauthorized parties to understand the logic behind the app. Although it’s simple and easy to use, it also provides flexible options for obfuscation and blacklisting specific parts of the code from obfuscation.
Features ✨
APK Decompilation 🔍: Decompile APK files into readable smali code.
Obfuscation 🔏🌀: Refactor class names, method names, and field variables for enhanced security.
Blacklisting⚫📋/Whitelisting⚪📋: Select packages, classes, or methods that should not be obfuscated.
Recompilation & Signing 🔄🔐: Recompile the APK and sign it after obfuscation, ready for distribution.
Usage 📖
Select APK File: Choose the APK you want to obfuscate.
Select Packages: Use the graphical interface to select the packages that should be included in the obfuscation process. You can review the available packages in your APK and make selections easily.
Choose Obfuscation Options:
You can choose to obfuscate:
Classes
Methods
Field Variables
There are additional options like adding a prefix to obfuscated names or including a dynamic salt to ensure randomness.
Blacklist Selection:
You can choose specific classes, methods, or fields to exclude from obfuscation:
Manage Blacklist/Whitelist: The tool provides a tree view of the APK structure, allowing you to manually select or deselect parts of the code for obfuscation.
Class and Method Blacklisting: Entire classes and specific methods can be blacklisted from the obfuscation process to prevent them from being renamed.
Refactoring: After configuring your selections, the tool will refactor the chosen components. It will also generate a mapping file for future reference, showing the original and obfuscated names.
Recompilation & Signing: Once the obfuscation is complete:
Recompile the APK.
Optionally, sign the APK using either a custom key 🔑 or an auto-generated key to prepare it for distribution.
Setup 🚀
You can now download the ObfuscateMe setup from the releases page. The setup file allows for easy installation and execution of the tool. Here’s how to get started:
Download the Latest Release: Head to the releases page and download the latest setup file.
Run the Setup: Follow the installation instructions to install the tool on your machine.
Launch ObfuscateMe: Once installed, you can easily launch ObfuscateMe and start obfuscating your APKs.
Tools Used 🛠️
Special thanks to the following tools used in this project:
Uber APK Signer: For easy APK signing after the recompilation process.
Known Issues & Future Improvements 🛠️
While ObfuscateMe is simple and functional, a few areas require improvements:
Local Variable Obfuscation 🐛: Currently, variables declared within methods are not refactored. This leaves some sections of the code vulnerable.
Method Refactoring Conflicts 🔄: The tool may refactor methods with the same name in different classes, even if one of those classes is blacklisted. A more precise system to avoid refactoring conflicts between different classes is needed.
Performance Enhancements 🐢: As APK sizes grow, refactoring can become slower. Optimizing the tool for larger APKs is part of the future roadmap.
Screenshots 📸
Main Class
Main Class – Decompiling
Package Selection
Blacklisting
Recompile Class
Recompiling and Signing
Contribution 🤝
Feel free to fork the project, submit pull requests, or open issues if you encounter any bugs or have suggestions. I appreciate any contributions that help make ObfuscateMe better!
Note: Please use NetBeans IDE for development, as the GUI was generated using the NetBeans GUI builder, and it ensures smooth editing and customization of the interface.
ObfuscateMe is a great start for simple APK obfuscation needs, and while it still has room for improvement, it provides a solid foundation for anyone looking to protect their Android apps from reverse engineering. Thanks for checking out the project! 😊
,sd$b, db db db ,dS$b, ,oS$$b,
:$$7" `lb ,$P' ,$P' ^" ,$S" `"b, "$$P" `$b
$$ d$P d$P :$b, d$, `$b `$s :$m
,d$Sb, ,d$P ,$P" ,$P" `$b $$Sb, l$ l$ $$
d$" `"S$Pb' d$" d$b d$" d$b l$: S$ `"$$$P' ,S$ ,$'
"$b, `$b, dP "b dP "b ,$P' `$b d$$S ,$S
`"S$$$bdS$$P "S$@o,. ,dP "S$@o,. ,dP ,d$S' "$b, o, `$$" `P'
`"^ `^"S$$$$P `^"S$$$P "$P' `S$$P^ `'
,d$$, ,dS$b, ,oS$$b, ,d$$, ,dS$b, ,d$$,
d$" $P ,$S" `"b, "$$P" `$b d$" $P ,$S" `"b, d$" $P
"$b " d$, `$b `$m :$m "$b " d$, `$b "$b "
V$b, $$Sb, l$ l$ $$ V$b, $$Sb, l$ V$b,
`"$$b. $$ `"$$$P' ,S$ ,$' `"$$b, $$ `"$$$P' `"$$b.
, `"$b, `$b, d$$S ,$S , `"$b `$b, , `"$b,
d$P `$b, "$b, o, `$$" `P' d$P `$b, "$b, o, d$P `$b,
l$^ `$b `"S$$P^ `' l$^ `$b `"S$$P^ l$^ `$b
"$b, ,d$" "$b, ,d$" "$b, ,d$"
`"V$$$$$P' `"V$$$$$P' `"V$$$$P'
[ascii by lambi]
"Hello Boing" - Amiga Executable Graphics
Decrunch Party, May 2o15
Hi there!
This is my first ever prod for the Amiga and kind of a "Hello World" in
68000 assembly. It will run on any OCS+ Amiga with at least 0.5MB of RAM,
any version of Kickstart ROM will do.
Rendering takes about 29 seconds on an unexpanded Amiga 600.
I release this as an ALLien Senses prod just out of pure nostalgia. The
group itself remains inactive. It's awesome to finally release something
new after such a long time. :)
Special greetings go to Photon/Scoopex for his AsmSkool tutorials!
Portfolio link: https://siejak.pl/projects/hello-boing
Pouet link: http://www.pouet.net/prod.php?which=65657
Assemble with AsmOne.
You may do with the code whatever you wish but please credit me if you
use any of it in your own prod. :)
masterm 2015-05-19
<michal@siejak.pl>
www.siejak.pl
