I think this is a great optimization!!
On Fri, Oct 9, 2015 at 9:36 AM, Elias Mårtenson <[email protected]> wrote: > Hello Jürgen, > > I am assuming that I am not alone in commonly using ⍎ for the purpose of > parsing a number embedded in a string as APL (i.e. something analogous to > PARSE-INTEGER in Lisp, or strtol() in C). > > With that in mind, I made a small change to > Bif_F1_EXECUTE::execute_statement() which checked if the string is a > "pure" number. In my test case, I simply checked if all characters where > digits, but it should be slightly more clever in a production grade version. > > If the string statement is a pure number, then I simply circumvented the > entire parsing machinery and directly returned the number itself. In doing > so, I got a 4× performance improvement, even though I incorrectly allocated > an array to put the result in, which is not correct. Returning a pure > number would make it even faster, but for some reason it crashed when I > tried returning Token(TOK_APL_VALUE1, *the_number*). > > I think it makes sense to add this performance fix. The method already > begins with a call to statement.remove_leading_and_trailing_whitespaces(), > so if the check were to be done at the same time the performance impact > would be minimal, while making ⍎ useful as a number parsing function. > > Regards, > Elias > > On 7 October 2015 at 22:30, Juergen Sauermann < > [email protected]> wrote: > >> Hi Peter, >> >> I guess when L⍟(|R)+R=0 is integer then ⌈ and ⌊ would be the same >> and then the 1+⌊ is different from ⌈. >> >> /// Jürgen >> >> >> >> On 10/07/2015 04:19 PM, Peter Teeson wrote: >> >> Re: encode >> >> ((1+⌊10⍟N)⍴10)⊤... >> >> I was wondering why the APL Lang Ref Manual p.161 shows: >> ⌊1+L⍟(|R)+R=0 >> >> Why would this not be just as correct? >> ⌈L⍟(|R)+R=0 >> >> and so >> >> ((⌈10⍟N)⍴10)⊤... >> >> two symbols less……..<grin> >> >> >> >> >> >> >> >> >> >
