Yes, I agree, values like 10 would be meaningless.  I was thinking in values 
smaller than 1.
My suggestion would be for the tolerance to be defined solely regarding the 
distance from the rational approximation.

Consider the following toy implementation of a Stern-Brocot binary search:

rat =: 4 : 0"0
b=.l=.0j1
r=.1j0
s=.*y
be=.y=.|y
while. be>x do.
  vm=. %/@+. m=.l+r
  if. y < vm do. r=.m else. l=.m end.
  e=.|y-vm
  if. e<be do.
    b=.m
    be=.e
  end.
end.
s * %/&x:+.b
)

Here the x argument is the tolerance. It tries to find a rational approximation 
within x from y.
Thus one could do:

   (10^-i.8) rat o.1
3 16r5 22r7 201r64 333r106 355r113 355r113 75948r24175

   x:inv (10^-i.8) rat o.1
3 3.2 3.14286 3.14063 3.14151 3.14159 3.14159 3.14159

And in my earlier example:

a=:​0.1667 0.8333 0.4286 0.1111

0.01 rat a

1r6 5r6 3r7 1r9

As another example, suppose one wants to find a rational approximation for e 
within 0.01, he would do:

   x:(!.0.01) ^1
19r7

________________________________
From: Programming <programming-boun...@forums.jsoftware.com> on behalf of Raul 
Miller <rauldmil...@gmail.com>
Sent: Friday, August 2, 2019 12:10 PM
To: Programming forum <programm...@jsoftware.com>
Subject: Re: [Jprogramming] Extended precision tolerance

On Thu, Aug 1, 2019 at 5:01 PM Nimp O <tr...@outlook.com> wrote:
> Perhaps this upper bound could be removed, at least for x:, since I believe 
> the main use cases for tolerance on this verb would be bigger values, as 
> illustrated in my earlier example.
> At least in this context, I can't see anything catastrophic happening by 
> increasing this tolerance, on the contrary.
> But maybe this change cannot be made in such an isolated way.

You definitely need an upper bound (and a lower bound). Values like 10
would be meaningless (and negative values are also meaningless).

Here's an implementation of tolerant equality:

   teq=: |@- <: ".@'ct' * >.&|

If ct were 1, then all numbers would be equal. Even values close to 1
can be confusing:

   ct=:0.5
   1 teq 2
1

If ct is 2^-n and n is an integer, n-1 approximately represents the
number of significant bits in the numbers being compared.

This concept is important for floating point representation (and
"disastrous" for exact representations).

That said, it might be useful to allow larger values than the current
implementation. (But how by much?)

Thanks,

--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to