Anonymous user
Talk:Check Machin-like formulas: Difference between revisions
→Floating-point calculations
(→Floating-point calculations: Happy holidays!) |
|||
Line 21:
:For example, dividing one by seven with <tt>1%7</tt> by default produces the float point approximation <tt>0.142857</tt>, but coercing extended precision with <tt>x: 1%7</tt> produces the exact ratio <tt>1r7</tt> (which is J's notation for rational numbers). J will carry exact values as far as it can through its computations; there are some built-in functions which have not been designed to produce exact results, and will revert to floating point values. Users have no control over these functions, and if they want a work-alike that produces exact results, they must write it themselves.
:--[[User:DanBron|DanBron]] 20:04, 20 December 2012 (UTC)
I think there is a problem with the J solution even though exact arithmetic is used. The problem is that
arctan(a/b) could be irrational. Thus the intermediate results are represented as floating points in the
current solutions.
The Perl 6 says it is a port of the Maxima solution, but Maxima uses symbolic computations and Perl 6 does not.
--[[User:Soegaard|Soegaard]] ([[User talk:Soegaard|talk]]) 12:34, 1 June 2013 (UTC)
:: Normally [http://en.wikipedia.org/wiki/Extended_precision extended precision] means floating-point with greater precision, however I will accept your explanation. The J code is very terse, it would be useful to readers if you or someone else can add a brief description to the solution of how it implements the algorithm.
::: Thanks, I hadn't realized J's terminology was non-standard. I'll change the note on the solution to say "exact arithmetic" rather than "extended precision numbers".
| |||