FAQ: Difference between revisions

Jump to navigation Jump to search
57 bytes removed ,  5 March 2013
Line 526: Line 526:
would produce value 9999999999999990000, which is close to the maximum possible value for the uint64 type, but can't be at the moment input directly, doing uint64(9999999999999990000), due to the mentioned error of rounding.
would produce value 9999999999999990000, which is close to the maximum possible value for the uint64 type, but can't be at the moment input directly, doing uint64(9999999999999990000), due to the mentioned error of rounding.


Alternatively, one may compute symbolically (numbers processed as text), which doesn't, in theory, restrict the maximum value for integer numbers or the precision of floating point numbers. E.g., the ''symbolic'' package, when it works, has a vpa() function for variable-precision arithmetic. Note that arbitrary-precision arithmetic must be implemented '''in software''' which makes it much slower than hardware floats.
Alternatively, one may use arbitrary precision arithmetic, which has as much precision as is practical to hold in your computer's memory. The ''symbolic'' package, when it works, has a vpa() function for arbitrary precision arithmetic. Note that arbitrary precision arithmetic must be implemented '''in software''' which makes it much slower than hardware floats.


At present, however, the symbolic package is almost useless, since even when you get it to compile and not crash, it cannot handle any array type, which hardly helps for an array-oriented language like Octave. If this limitation is not important to you, attempt to use the symbolic package. If you would like to get this fixed, [http://octave.1599824.n4.nabble.com/Internal-Precision-Symbolic-tp4645257p4645594.html Jordi Gutiérrez Hermoso has volunteered] to fix the package for 5000 USD, which can be obtained from a kickstarter compaign.
At present, however, the symbolic package is almost useless, since even when you get it to compile and not crash, it cannot handle any array type, which hardly helps for an array-oriented language like Octave. If this limitation is not important to you, attempt to use the symbolic package. If you would like to get this fixed, [http://octave.1599824.n4.nabble.com/Internal-Precision-Symbolic-tp4645257p4645594.html Jordi Gutiérrez Hermoso has volunteered] to fix the package for 5000 USD, which can be obtained from a kickstarter compaign.

Navigation menu