in reply to Re^4: The most efficient way for searching for an element in an array?
in thread The most efficient way for searching for an element in an array?

This node falls below the community's threshold of quality. You may see it by logging in.
  • Comment on Re^5: The most efficient way for searching for an element in an array?

Replies are listed 'Best First'.
Re^6: The most efficient way for searching for an element in an array?
by afoken (Chancellor) on Jan 10, 2016 at 10:39 UTC
    You can put any delimiter like '§', '€' or '€£'..., not used.

    That's exactly the problem: You have to find an "unused" delimiter. In real-word applications, you can have situations where there is no "unused" delimiter. Any array element may contain any sequence of bytes or characters. Whatever sequence of bytes / characters you could invent, it may also occur as part of an array element.

    In the explanation, there are overall 150 elements, so it will be difficult to get 2Gb of array.

    Why? 150 elements each allocating 14 MBytes easily break the 2 GByte limit. And yes, 14 MBytes in a single array element are perfectly legal in Perl.

    But to have 150 elements in an array is bad ;)

    Why? What do you think is the legal upper limit for the number of elements in an array? Heck, even the BASIC of my very first computer back in the 1980s allowed arrays of up to 65535 elements!

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re^6: The most efficient way for searching for an element in an array?
by Anonymous Monk on Jan 09, 2016 at 15:12 UTC

    From the OP:

    keywords in array 1 ... two more arrays that contain elements ...
    You have chosen to ignore the original problem, and solve something similar, but different instead. Why?

    It has been pointed out to you, that the unanchored regular expressions do not produce concrete matches. You have chosen to ignore this concern. Why?

    Once more. The question was a fairly generic one. The only assumptions you are afforded is that inputs are in arrays and that some equality operator is available. Instead of giving a equally generic and sensible answer, you have resorted to a kludgy hack, in defiance of any criticism.

    In this monastery, the tacit assumption—nay, an expectation—is that the participants are able to learn, or to advance the learning in others. Please consider this, and think of the value of your engagement so far.