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 <juergen.sauerm...@t-online.de > 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> > > > > > > > > >
