Comments (7)
Currently ApproxEq
is implemented only for some of primitives in approx
:
brendanzab/approx#6
from algebra.
I'm wondering if we should even have approximate traits... could we just accept that our structures won't match up to the ideal mathematical versions? Seems like most of out impls just use the Approx
versions...
from algebra.
Well I am also in favor to dedicate this crate to approximate algebra. In practice, exact computation usually comes with a significant impact in term of performance and memory needs. So in practice, algorithms using exact arithmetic will require an implementation that is very different from those using approximate arithmetic (for performance reasons). In the end, there is no point in keeping exact traits and approximate ones in the same crate since a single implementation will never mix them.
Another use of exact algebraic structures is with non-numerical objects, e.g., function spaces. Those can be left to another crate as well.
Also, if we dedicate this crate to approximate algebra, we could remove the ugly Approx
suffix from the trait names.
ApproxEq
is still a must-have though.
from algebra.
Well one problem that approximate stuff is that there is different kinds of innaccuracies:
- precision (floats)
- under/overflow (in debug without Wrapping)
- algebraic structure breaking values (Nan, Inf)
Under/overflow and structure breaking values can be mitigated with wrappers, but precision cannot.
If we focus on approximate algebra, then there should atleast be some way of telling why there is innaccuracy and maybe even measure it.
And the idea would be to have two separate crates: one for approximate and one for exact and then have them work together?
from algebra.
Agreed - there is that annoying question - how do you abstract over unsigned integers, integers, floats, fixed point, bignums, and composites of those... they all have different properties when it comes to precision/approximation :(
from algebra.
And the idea would be to have two separate crates: one for approximate and one for exact and then have them work together?
The two separate crates don't even have to work together. It makes no sense for an approximate value to be used in an exact context; and conversely, using a exact value in an approximate context would probably yield poor performances in practice (an algorithm using exact arithmetic must be designed specifically to take in account the performance impacts ).
I think the goal of this crate is just to describe some families of objects. We describe what is a group, a vector space, and expect them to be implemented for type that work well for approximate computations. For a specific algorithm, the choice of the actual type, depending on which precision/approximation properties it has, it left to the user.
So we could provide traits that allow the user to check which kind of inaccuracies should be expected from a given generic type. For example:
// Instead of this, we could use traits `Bounded`, `FixedPoint`, etc.
// with methods to retrieve their intrinsic characteristics.
enum InnacuracyCategory<S> {
Bounded(S, S),
ContainsInfinite,
ContainsNaN,
etc.
}
trait ApproximateValue: ApproxEq {
fn get_category(&self) -> InnacuracyCategory<Self>;
}
For a given generic type, the user is then free to combine traits describing algebraic properties, with traits describing inaccuracy properties in order to provide a robust implementation of an algorithm.
from algebra.
Oh, interesting thinking. I wonder if there would be a way to encode that statically...?
from algebra.
Related Issues (20)
- Merge with epsilonz/algebra.rs HOT 2
- Reorder trait names HOT 2
- Investigate other property APIs
- Better issue labeling scheme HOT 3
- Algebraic structures should automatically be implemented for types satisfying compontent properties HOT 12
- Upload to Crates.io HOT 2
- Add ApproxEq trait with asserts HOT 8
- Separate equality constraints from structure traits HOT 2
- Implement ring-like structures HOT 2
- Vector spaces HOT 6
- Abstract operators out of structural traits HOT 23
- Wrapper structs to use a richer structure as a lesser one HOT 1
- Identity traits and RFC 1214
- Quickchecks fail in debug mode because of overflows HOT 1
- Algebra and unsafe HOT 6
- Enable travis on pull requests.
- Wrapper struct for ops are annoying to use. HOT 7
- Discuss practical usages of algebraic structures in real world code HOT 3
- All operators should be parameterized for more general cases. HOT 2
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 algebra.