Re: [Bug-apl] Performance problem with simple program

[Juergen Sauermann]

Hi Elias, I have added an optimization for ⍎ with a single APL value. SVN 682. /// Jürgen On 10/09/2015 04:36 PM, Elias Mårtenson 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 <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>