Shane Stanley wrote:
> Doing floating point comparisons is a problem, period. 0.7*0.7=0.49 should return true as far as users are concerned, but it doesn't, because AS's comparison operators don't allow for the inherent imprecision of FP representation. Frankly I'd far rather the language dealt with this sort of thing itself so users never need to think about it, but it doesn't, so whatcha going to do? So, other than the embarrassing syntax, that one I'm not too bothered about. If nothing else it serves to make users aware that such an issue even exists.
But is a StandardLib the place to make the point? If you want a lib that people are going to use, I think you need to concentrate on what you think they *will* use, not what you think they should, and try to keep it compact enough that people don't just give up wading through comments. And I think that needs a touch of the Jobsian approach, throwing out (well, moving elsewhere) what doesn't answer a common problem. Education is mission creep too, in this instance.
Hey I'm convinced.:) I've removed the `compare numbers` command: too
big, too complicated, too loud. I did sneak a simpler, less
prominent `cmp` command in, similar to the one found in Python's
stdlib, that takes two numbers and returns -1/0/+1 to indicate
less/equal/more. It's just a variant of the IsEqualEnough() handler
found in ESG MathLib (which is what MathLib is based on), so there
is precedence. (Not a fan of returning numerical flags instead of
'constant' names, but AS's comparison operators have already snagged
all the obvious names. And ListLib's sort comparators already use
the same approach, so it can be used there too.)
Math functions are always a tricky one: young folks nowadays don't
even know what a hyperbolic sine is, never mind use it, but when
they do require one it really should be in the standard math library
as it's just basic trigonometry. I actually left out quite a few
functions that are provided by ESG MathLib, Satimage.osax, math.py,
math.h, etc. so I'd appreciate if anyone who does do math-y work has
a skim of the MathLib dictionary and point out any egregious
omissions.
If you've any thoughts on how best to resolve the awkward overlap
between TextLib, MathLib, DateLib, and FormatLib in particular, I'd
appreciate those too. I'm leaning towards having `parse date/number`
and `format date/number` commands use canonical formats by default,
eliminating the need for separate `convert text to date/number` and
`convert date/number to text`, and shifting everything except the
JSON commands into TextLib as "Parsing and Formatting Text" and
"Locale Support" suites, but am still dithering.
Also, anyone any thoughts on what should go into a WebLib: URL
manipulation, JSON conversion, HTTP transfer; anything else? Once
WebLib is added I'm going to call that a full set, after which it's
just a case of ironing out each library's commands and making sure
it's all tested and documented. (Main PITA is I don't have an
automated test framework done yet, as I'm still trying to decide how
to design that: AS does not make it easy.)
Thanks again,
has
|