On Sun, Oct 3, 2010 at 1:45 AM, David Ward Lambert
<[email protected]> wrote:
> NB. tolower of nu...@tolower is incorrectly global
> 1bA
> |ill-formed number
How does my supporting this case conflict with the dictionary?
Other cases to ponder:
36xbthequickbrownfoxjumpsoverthelazydog
I kind of liked doing this one. In particular, I liked that if I wanted to
deal with very large hexadecimal numbers that I was not limited by
my machine's precision.
1.2e3.4
This one bothers me more than the 1bA case, since I can imagine someone
entering 1e2.3 and thinking that it means something like 1.3e2. However,
(a) that sort of thinking is quite a stretch, and
(b) the dictionary does not specify that this be an error case.
1.2 3b4 5x
This is another one where people might be confused. Here,
the result is not extended precision because the floating point
entry drags it down. However, I dislike syntactic prevention
of type matching, and I do not really have the tools in J to do
a concise job of dealing with the type issues in the context of
this project.
1.0
This, in my opinion, is my biggest failure. J's implementation
produces a boolean for this case, where I produce a floating point
result. However, this behavior from J was not specified
on that dictionary page, and supporting it would add a fair
bit of complexity.
That said, I think I know how I could implement it:
1&{.^:('0' -:&~.S:0 {:)
Or, more usefully
length1handler`length3handler^:('0' -:&~.S:0 {:)
Verbs like this would need to replace my existing
length 3 handlers, for most but not all of the
length 3 cases.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
