[UR] true "real" type, not a IEEE754 one. #9
Comments
|
Back to rust, apparently its an implementation issue, not about libnum |
remexre
pushed a commit
to remexre/num
that referenced
this issue
Jun 1, 2017
Add a method `pointer(&str)` to `Value`. Deprecate `lookup(&str)`. Bump version to 0.7.1. Closes rust-num#9
remexre
pushed a commit
to remexre/num
that referenced
this issue
Jun 1, 2017
feat(value): implement RFC6901 JSON Pointer Add a method `pointer(&str)` to `Value`. Deprecate `lookup(&str)`. Bump version to 0.7.1. Closes rust-num#9 Notes: * It should be possible to add a `pointer_mut(&str)` method to Value. This would allow to add and modify values. (Maybe even a delete method) I failed to add such a method because of borrow checker. * Should [RFC6902 JSON Patch](https://tools.ietf.org/html/rfc6902) be implemented or is this something for a separate crate? (Patch is based on Pointer)
|
I don't plan to add such a new type under the rust-num org. Of course, anyone is welcome to explore this in their own crate... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thursday Jan 23, 2014 at 10:09 GMT
For earlier discussion, see rust-lang/rust#11749
This issue was labelled with: I-enhancement in the Rust repository
IEEE754 number are not real. Almost none typical mathematical transformation can be applied without loosing precision and changing bit. Most of compiler did nothing with such type, and --fast-math behaviour can't be predicted.
I propose to add a real type, with needed precision and range added as type parameter.
This precision should be absolute, because relative precision make problem around zero. An in real world, sensor have absolute error specification most of the time. System specification use also use absolute number. Relative precision match well floating point implementation (but not around zero) but that's all. With range, relative precision could be calculated if needed.
With precision and range for input and output, any transformation could be evaluated, and loss of precision could be accepted or not. Typical Math became available. There is no more limitation as for IEEE754 number.
Underlying layout could be 64 bits floating point number, but compiler could choose 32 bits or fixed point number, because it has all information in hand to do the job.
The text was updated successfully, but these errors were encountered: