Comments (7)
My intuition was that one third-party library for linear algebra will be enough in any language
This is how assumptions work. They always seem to make sense until they don't :)
In general I always try to make as few assumptions as possible, as every assumption creates a dependency. In this case we would create an artificial dependency "Every language will have only one implementation with linear algebra library". It seems like it makes sense (and it probably does), but why would we bring this unnecessary limitation?
Especially given that we are talking about our API, which should arguably be the most though-out component as that is exactly what users depend on and making backward incompatible changes in a well established API has never been an easy problem.
from m2cgen.
Ooops! I just typed my comment practically about the same as stated in this issue! I definitely should use F5
more often 😃 .
I would like to introduce option 3:
3. Adding parameter with_deps
to all existing methods which would be False
by default.
It will unify the dependence policy for all languages.
from m2cgen.
Having it as a parameter would require users to see possible values in documentation, whereas having it as a separate method is self-explanatory.
Moreover if with_deps
is boolean, it's not flexible enough to accommodate for use cases when we would want to implement support for multiple libraries.
If it's not boolean, we again have 2 options:
- One parameter
with_deps
with multiple values, likenumpy
etc. The disadvantage here is the necessity of reading documentation (for users) and validating the value (for us). - Multiple boolean parameters like
with_numpy
. The disadvantage here (except from need to read documentation for users) is the need to validate those multiple params, like only one of them could beTrue
.
Having dependency-specific methods still seems like a more clear and better API to me which doesn't require reading documentation or validating any parameters,
from m2cgen.
Moreover if with_deps is boolean, it's not flexible enough to accommodate for use cases when we would want to implement support for multiple libraries.
My intuition was that one third-party library for linear algebra will be enough in any language. In that case using with_deps=True/False
will be enough and easy to interpret.
I think that your approach with separate methods seems to be more general and I like it now. Also, it can benefit from class inheritance and allow to build different combinations of dependencies easier. And class naming schema Language[Dep1Dep2...]Interpreter
looks very clear to understand from the first glance.
from m2cgen.
Hi guys @krinart @izeigerman ! Have you come to any agreement? I can work on this issue.
from m2cgen.
Seems that two first steps have been done. I wonder do we really need to implement the third one, namely
potentially implement
PythonNumpyInterpreter
to use in cases where it would be beneficial.
?
To be honest, I don't see any particular reasons for that.
from m2cgen.
@StrikerRUS
Yeah, I agree. I see no benefits either. I think we should close this. Thank you!
from m2cgen.
Related Issues (20)
- The converted C model compiles very slow,how can i fix it?
- Unable to export LGBM model that uses `categorical_feature` HOT 2
- Convert ML model to c# HOT 2
- Issue with xgboost export in python: not same values splits HOT 1
- Getting predict_prob when convert m2cgen to different languages
- Feature Request: support for multioutput regression HOT 1
- Process ended with exit code -1073741571 (0xC00000FD) HOT 1
- Results dont match
- Add Fortran
- LightGBM models
- Unable to export code from XGBoost 1.7.5 models HOT 6
- How to use model for jpg photo?
- Issue while Exporting a LightGBM Model to C#
- XGBoost exported to C generates wrong indices for input array
- Logitraw objective function ignored for xgb.Booster
- Cannot export XGBClassifier model: TypeError: unsupported operand type(s) for /: 'float' and 'NoneType' HOT 4
- Memory overflow in program run after compilation of C code transformed by the xgboost model HOT 1
- Cannot export XGBClassifier model: TypeError: unsupported operand type(s) for *: 'int' and 'NoneType'
- XGBoost GCC Memory Allocation Error: cc1plus.exe: out of memory allocating 65536 bytes
- xgbmodel is larger than 500M, convert to c, always Segmentation fault
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from m2cgen.