Reasonable suggestion. The current algorithm for floating-point GCD is
30 years old and predates rational arithmetic.
On the other hand, if all you wanted was +.&.x:, you could have written
that.
I will leave the code as is. Many floating-point values are exact
integers and I wouldn't want to lumber them with a forced conversion to
extended integer.
Henry Rich
On 5/15/2020 11:17 PM, bill lam wrote:
Yes I agree GCD meant for whole numbers, so that +. on floating points can
first convert to rational first and convert back to float afterwards
+./&.x: 4.57 4.34 4.44
0.01
x: is clever enough to find the shortest form of rational equal to the
original floating number range
(3!:3) 4.5700000000000003
e300000000000000
0800000000000000
0100000000000000
0000000000000000
48e17a14ae471240
(3!:3) 4.57
e300000000000000
0800000000000000
0100000000000000
0000000000000000
48e17a14ae471240
x: 4.5700000000000003
457r100
x: 4.57
457r100
That said, I don't see any real benefit for change, if a user want rational
number behavior, he/she can use the form
+./&.x:
On Sat, May 16, 2020 at 7:18 AM Devon McCormick <devon...@gmail.com> wrote:
Since, AFAIK, GCD was originally defined in the context of whole numbers,
you probably get what you deserve using it with non-integers.
On Fri, May 15, 2020 at 7:04 PM Raul Miller <rauldmil...@gmail.com> wrote:
It is odd, though, that even with comparison tolerance set to zero, +.
is not associative on fractional floating point values:
9!:19]0
0j16":,.+./4.57 4.34 4.44
0.0000000000000036
0j16":,.+./|.4.57 4.34 4.44
0.0000000000290870
It is commutative though:
(-:|:)+./@>{;~4.57 4.34 4.44
1
0j16":+./@>{;~4.57 4.34 4.44
4.5700000000000003 0.0100000000000655 0.0099999999999758
0.0100000000000655 4.3399999999999999 0.0200000000000466
0.0099999999999758 0.0200000000000466 4.4400000000000004
I'm not quite sure what's going on here... maybe a built in epsilon
which is independent of comparison tolerance?
Thanks,
--
Raul
On Fri, May 15, 2020 at 6:53 PM Hauke Rehr <hauke.r...@uni-jena.de>
wrote:
In case you are willing to accept labelling it a problem.
As I mentioned by altering the thread’s subject, yes,
this ain’t a bug. But there may be an opportunity for
improvement without sacrifice. Or so do I think.
Am 16.05.20 um 00:49 schrieb 'Michael Day' via Programming:
Not a new "bug" - I've still got J503 for some reason - so:
+./4.57 4.34 4.44
5.39568e_12
ABOUTJ_jijs_ NB. nearest thing to JVERSION???
Copyright 1994-2004 Jsoftware Inc.
For information about this and related products:
Jsoftware Inc.
P.O. Box 330
Excelsior, MN 55331
tel: 952 470-7345 fax: 952 470-9202
www.jsoftware.com
i...@jsoftware.com
As Devon and Henry suggest, it's the usual problem with "exact"
representation of reals.
Mike
On 15/05/2020 15:17, 'Bo Jacoby' via Programming wrote:
+./4.57 4.34 4.44
5.39568e_12
NB. this was not the correct answer. A bug?
+./x:4.57 4.34 4.44
1r100
NB. this was a work-around
Thanks!
Bo.
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
Devon McCormick, CFA
Quantitative Consultant
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
