[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Elias Mårtenson
Subject: Re: [Bug-apl] Performance problem with simple program
Date: Fri, 9 Oct 2015 22:36:10 +0800

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.


On 7 October 2015 at 22:30, Juergen Sauermann <address@hidden> 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
I was wondering why the APL Lang Ref Manual p.161 shows:

Why would this not be just as correct?

and so 
two symbols less……..<grin>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]