Raul wrote: > So I am curious about the examples driving your concern here.
I'm in the throes of converting TABULA ( https://code.jsoftware.com/wiki/TABULA ) to work with rationals instead of floats. Or more accurately, the engines CAL and UU which TABULA uses. No, I don't need to offer the speed of light to more than 10 significant digits. My motivation has little to do with performing a particular scientific calculation, and everything to do with offering a general-purpose tool and rubbing down the rough edges as they emerge. It's a game of whack-the-rat. The imprecision of working with floating-point numbers shows up so often with TABULA that I haven't bothered to collect examples. In just about every session I hit an instance or ten. But it's worse when using the tool to demonstrate technical principles to novices, rather than do mundane calculations, because in the latter case it would be used by an engineer well-versed in computers and the funny little ways of floating point, tolerant comparisons and binary-to-decimal conversion. But a novice is apt to suffer a crisis of confidence when she sees (sin A)=1.23E-5 in the same display as (cos A)=1. Even hardened physicists wince. Two areas stand out: • Infinitestimals, i.e. intermediate values which look like zero – and ought to be zero – but aren't. They act like grit in the works. • Backfitting, where the user overtypes a calculated value and CAL backfits suitable input values, for which it mainly uses N-R algorithms – which don't like noisy values. It's too early to say yet – I have to finish the conversion and think up examples to stress-test it before I can be sure the effort is worthwhile. So far I've only upgraded UU (the units-conversion engine), but already some backfitting examples which were rather iffy are hitting the target spot-on: particularly where the slope of the "hill" being climbed is nearly zero. Even I succumb to feelings of pleasure to see (sin A)=0 in the same display as (cos A)=1. But knowing the innards of CAL, I can't understand how it can possibly be showing benefits at this early stage. Perhaps UU's rational values are leaking further down the cascade of calculations than I expected? I'd love to get to the bottom of it, but my systematic "rationalization" of the CAL code will destroy the evidence, just as exploring Mars will destroy the evidence for indigenous life. Too bad: I'm not aiming at CAL working occasionally, but every time. Thanks for reminding me about digits separation. Yes, my numeral converter (I find I'm mainly working with numerals than numeric atoms) can already handle standard scientific notation, like '6.62607015E-34' -- plus a few J-ish forms like '1p1'. I only had to type-in π to 50 places of decimals to feel the need for some form of digit separation (…a good tool should support ALL forms!) e.g. '6.626,070,15E-34' but was unconsciously assuming (y -. ',') would handle it. …It won't. SI specifies spaces as digit separators, and Germany uses commas where the UK and USA use dots, e.g. '6,626 070 15E-34'. Okay, fine… but in places I detect the first space in a (string) quantity to show where the numeral stops and the units begin. Ah well… another rat to whack. Ian On Wed, 27 Mar 2019 at 15:16, Raul Miller <rauldmil...@gmail.com> wrote: > On Tue, Mar 26, 2019 at 7:38 PM Ian Clark <earthspo...@gmail.com> wrote: > > I will still employ my "mickey-mouse" method, because it's easily checked > > once it's coded. I need built-into TABULA a number of physical constants > > which the SI defines exactly, e.g. > > • The thermodynamic temperature of the triple point of water, Ttpw , is > > 273.16 K *exactly*. > > • The speed of light in vacuo is 299792458 m/s *exactly*. > > > > The first I can generate and handle as: 27316r100 -whereas (x: 273.16) > > is 6829r25 . If you multiply top and bottom by 4 you get my numeral. But > > (x:) will round decimal numerals with more than 15 sig figs and so lose > the > > exactness. > > I was looking at > https://en.m.wikipedia.org/wiki/2019_redefinition_of_SI_base_units but > I did not notice anything with more than 10 significant digits. So I > am curious about the examples driving your concern here. > > (That said, if you're going to go there, and you have not already done > so, I'd use your approach on strings, and I'd make it so that it would > work properly on values like '6.62607015e-34'. I might also be > tempted to make it accept group-of-three-digit representations to make > obvious typos stand out visually. Perhaps: '6.626 070 15e-34') > > 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
