uu_uu_ now works with boxed argument. But needs a lot more testing for "pathological" boxed arguments.
Upgrade the addon to version 2.1.14. Calling uu with purely string arguments is really only appropriate for toy applications, since the value of a scientific quantity inevitably gets rounded, sometimes quite crudely. To 2 significant figures, for some of the rarer temperature scales. uuengine needs similar treatment. convert_uu_ is dyadic/monadic, but presently ignores its x-arg. Since convert is highly convenient as the API in limited applications, the x-arg needs reinstating to avoid having to call it twice. My original intention was to polish math/uu for standalone use, but I need to prioritize supporting its use by math/cal (math/tabula). More extensive testing will smooth off the rough edges. Ian Clark On Sun, 28 Apr 2019 at 18:39, Ian Clark <[email protected]> wrote: > You're right, Tom, it did, and it should. It's a bug. > > Like Scarlett O'Hara, I'm going to think about it tomorrow. > > I've been recoding math/uu to work with rational numbers throughout. This > is one of the traps I've put in, to catch any floats slipping though. Alas, > boxed arguments to uu have not been in my test suite, because they're going > to be an undocumented feature of uu, which I was planning to support for > string arguments only. > > Are you aiming to make serious use of math/uu, or are you simply exploring > what it can do? > > Either way it stands to reason you'd want to work with quantities to > higher precision than you get by having to turn all your values to strings. > Presently the ways to do this are: > > 1. use convert_uu_ > This accepts units, not whole quantities, and returns the conversion > factor to SI base-units. > To convert one arbitrary units to another, you call convert twice, once > for each units, and take the quotient of the conversion factors. > > convert_uu_ 'ft' > ┌─┬─┬────────┐ > │m│0│381r1250│ > └─┴─┴────────┘ > convert_uu_ 'g/mol' > ┌──────┬─┬──────┐ > │kg/mol│0│1r1000│ > └──────┴─┴──────┘ > convert_uu_ 'cal/g' > ┌───────┬─┬────┐ > │m^2/s^2│0│4184│ > └───────┴─┴────┘ > > 2. use the all-purpose keyhole interface: uuengine_uu_ > At present undocumented – the only way to find out what it does is > RTC. > (…but it's very easy code to read.) > > 3. treat uu as a class, and access attributes and methods via a numbered > locale. Study the code of math/cal/cal.ijs to see how to use it this way. > (Thus, find all instances of '__uun') > > These days I'd strongly recommend against using math/uu via 3. A public > interface via itty-bitty calls and state-variables turns out to be a > monster to support. > > Instead uuengine will be offered as the API for math/uu, because it > collects all the sensible ways to use math/uu into one keyhole interface > that comes with a single readable test script. Hey – and even a lab, when I > get time to write it. > > If you want a survival-guide to calling uuengine, I can post one, or > better still, write a jwiki page. > > Ian Clark > > On Sun, 28 Apr 2019 at 05:33, Tom Arneson <[email protected]> wrote: > >> I seem to remember that uu would accept boxed right argument (y) and >> return value;unit, but now this: >> >> >> uu '100 ft' >> 30.480 m >> uu 100;'ft' >> |assertion failure: uu_uu_ >> | notFloat ratarg=.ralu scale_displace~rcoeft,rcoefu,rdispt,rdispu >> >> >> uu '100';'ft' >> |assertion failure: uu_uu_ >> | notFloat ratarg=.ralu scale_displace~rcoeft,rcoefu,rdispt,rdispu >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
