What's happening is that unexact trumps exact -- floats imply rounding and other non-arithmetic behavior, so when they appear in data they always carry a huge warning sign.
-Wm On Mon, Apr 8, 2019 at 8:48 AM 'Mike Day' via Programming <programm...@jsoftware.com> wrote: > > ... also it might be worth noting this, which I had wondered about but not > confirmed before: > VERSION_j_ > 701.1 2 > datatype 1r3 2r7 > rational > datatype 1r3 2r7 1p1 > floating > datatype x:1r3 2r7 1p1 > rational > > And I’ve just checked; it’s the same behaviour in J901 beta. > > So irrationals trump rationals, as they should, I suppose, just as any floats > raise type integer to type floating. > > x: ensures rational here. > > > Mike > > Sent from my iPad > > > On 8 Apr 2019, at 14:30, Ian Clark <earthspo...@gmail.com> wrote: > > > > Linda wrote > >> The rational numbers are exact. > > > > Yes, programs using them have a nice crisp feel. > > I used to think the only people who should be using them are number > > theorists, but now I'm a convert to their general use. > > But it's worth remembering that in some circumstances you're working with > > rational approximations, not exact values, > > Common examples: anything involving π and √2. > > > > I'm using Roger Hui's rational replacements for trig based on (o.) -- > > https://code.jsoftware.com/wiki/Essays/Extended_Precision_Functions#Collected_Definitions > > …which give 40 decimal places. They're fun to play with. > > No snags hit yet. But in the course of my investigations, some massively > > long rationals emerge. > > Can't see any performance deterioration yet, however, but I've developed > > code to cut-back a monster rational to (say) 40 decimal places. > > > > Ian Clark > > > >> On Mon, 8 Apr 2019 at 12:57, Linda Alvord <lindaalvor...@outlook.com> > >> wrote: > >> > >> The rational numbers are exact. > >> > >> ([:+/\|.)^:(i.5)1 1 > >> 1 1 > >> 1 2 > >> 2 3 > >> 3 5 > >> 5 8 > >> fr=: 13 :'%/"1([:+/\|.)^:(i.y)1 1' > >> (,.0j25":"0 fr 20);' ';x:,.fr 20 > >> ┌───────────────────────────┬─┬──────────┐ > >> │1.0000000000000000000000000│ │ 1│ > >> │0.5000000000000000000000000│ │ 1r2│ > >> │0.6666666666666666300000000│ │ 2r3│ > >> │0.5999999999999999800000000│ │ 3r5│ > >> │0.6250000000000000000000000│ │ 5r8│ > >> │0.6153846153846154200000000│ │ 8r13│ > >> │0.6190476190476190700000000│ │ 13r21│ > >> │0.6176470588235294400000000│ │ 21r34│ > >> │0.6181818181818181700000000│ │ 34r55│ > >> │0.6179775280898876000000000│ │ 55r89│ > >> │0.6180555555555555800000000│ │ 89r144│ > >> │0.6180257510729614300000000│ │ 144r233│ > >> │0.6180371352785145600000000│ │ 233r377│ > >> │0.6180327868852458800000000│ │ 377r610│ > >> │0.6180344478216818200000000│ │ 610r987│ > >> │0.6180338134001252000000000│ │ 987r1597│ > >> │0.6180340557275542100000000│ │ 1597r2584│ > >> │0.6180339631667065600000000│ │ 2584r4181│ > >> │0.6180339985218034100000000│ │ 4181r6765│ > >> │0.6180339850173579600000000│ │6765r10946│ > >> └───────────────────────────┴─┴──────────┘ > >> > >> Linda > >> > >> > >> > >> -----Original Message----- > >> From: Programming <programming-boun...@forums.jsoftware.com> On Behalf Of > >> William Tanksley, Jr > >> Sent: Friday, March 29, 2019 12:23 PM > >> To: Programming forum <programm...@jsoftware.com> > >> Subject: Re: [Jprogramming] converting from 'floating' to 'rational' > >> > >> Ian Clark <earthspo...@gmail.com> wrote: > >>> But why should I feel obliged to carry on using lossy methods when > >>> I've just discovered I don't need to? Methods such as floating point > >>> arithmetic, plus truncation of infinite series at some arbitrary > >>> point. The fact that few practical measurements are made to an > >>> accuracy greater than 0.01% doesn't actually justify lossy methods in > >>> the calculating machine. It merely condones them, which is something > >> else entirely. > >> > >> There will be a cost, of course. Supporting arbitrarily small and large > >> numbers changes the time characteristics of the computations in ways that > >> will depend on the log-size of the numbers -- and of course will blow the > >> CPU's caching. Also, because the intermediate values are being stored with > >> unlimited precision, you may find some surprises, such as values close to 1 > >> which have enormous numerators and denominators. > >> > >> IMO it's a worthy experiment, especially if you wind up gathering data > >> about the cost and benefit. > >> > >> There's some interesting reflections going on about this on the "unums" > >> mailing list. The trouble with indefinite precision rationals is that they > >> are overkill for all of the problems where they're actually needed, since > >> the inputs and the solution will normally need to be expressed to only > >> finite digits. Now, I don't think this makes doing experiments with them > >> worthless; far from it. By tracking things like the smallest expected input > >> (for example the smallest triangle side, or the largest ratio between > >> sides) and the largest integer generated as intermediate value (perhaps > >> also tracking the ratio in which this integer appeared), we can wind up > >> answering how bad things can get (of course, this is the task of numerical > >> analysis). > >> > >> Ulrich Kulisch developed technology called the "super-accumulator", which > >> was supposed to function alongside the usual group of floating-point > >> registers. It stored an overkill number of bits to permit it to accumulate > >> multiple additions of products of arbitrary floats, the sort of operations > >> you need to evaluate polynomials and linear algebra. Using this, he was > >> able to show that a large number of operations which were considered > >> unstable were possible to stabilize by providing this unrounded > >> accumulator. In the end this wasn't made part of the IEEE standard, but > >> it's being included in some of the numerical systems being developed in > >> response to the need for more flexible floating point formats from the > >> machine-learning world, where smaller-bitwidth floating point numbers both > >> make stability a serious concern and also make the required size of the > >> superaccumulator much smaller. > >> > >>> Ian Clark > >> > >> -Wm > >> ---------------------------------------------------------------------- > >> For information about J forums see > >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jsoftware.com%2Fforums.htm&data=02%7C01%7C%7Cdd9b991445bd4aee1e7a08d6b462d9c2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636894733979469996&sdata=0uEWVVEQ3RUboB2xRtJgdxL%2FUSZGkeff1L9HAEGmhYM%3D&reserved=0 > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
