4,493
edits
Key: Difference between revisions
Jump to navigation
Jump to search
m
→Computing the unique
(Problems) |
|||
| Line 67: | Line 67: | ||
</source> | </source> | ||
However, while this code works, it is inefficient in that the unique is computed twice. This can be avoided by letting Key return the unique and using that: | However, while this code works, it is inefficient in that the unique is computed twice. This can be avoided by letting Key return the unique and using that: | ||
<source> | <source lang=apl> | ||
(keys counts)←,⌿{⍺,≢⍵}⌸'TCCGCGGTGGCG' | (keys counts)←,⌿{⍺,≢⍵}⌸'TCCGCGGTGGCG' | ||
keys⌷⍨⊃⍒counts | keys⌷⍨⊃⍒counts | ||
| Line 73: | Line 73: | ||
</source> | </source> | ||
Unfortunately, this can introduce a different inefficiency, in that the result of Key's operand can end up being a [[heterogeneous array]] (containing multiple [[datatype]]s), and these are stored as pointer arrays, consuming memory for one pointer per element, and forcing "pointer chasing" when addressing the data. A possible work-around is to collect the unique keys separately from the result of counts: | Unfortunately, this can introduce a different inefficiency, in that the result of Key's operand can end up being a [[heterogeneous array]] (containing multiple [[datatype]]s), and these are stored as pointer arrays, consuming memory for one pointer per element, and forcing "pointer chasing" when addressing the data. A possible work-around is to collect the unique keys separately from the result of counts: | ||
<source> | <source lang=apl> | ||
data←'TCCGCGGTGGCG' | data←'TCCGCGGTGGCG' | ||
keys←0⌿data | keys←0⌿data | ||