https://github.com/hunkyjimpjorps/gary

A Gleam interface to Erlang's array module, for sparse, efficiently-implemented functional arrays. 🐝
https://github.com/hunkyjimpjorps/gary

arrays beam erlang-otp gleam

Last synced: 9 days ago
JSON representation

A Gleam interface to Erlang's array module, for sparse, efficiently-implemented functional arrays. 🐝

• Host: GitHub
• URL: https://github.com/hunkyjimpjorps/gary
• Owner: hunkyjimpjorps
• Created: 2024-04-30T16:02:33.000Z (7 months ago)
• Default Branch: main
• Last Pushed: 2024-05-23T15:14:26.000Z (6 months ago)
• Last Synced: 2024-10-01T09:14:52.141Z (about 1 month ago)
• Topics: arrays, beam, erlang-otp, gleam
• Language: Gleam
• Homepage: https://hex.pm/packages/gary
• Size: 14.6 KB
• Stars: 9
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# gary

A Gleam interface to Erlang's `array` module, for sparse, efficiently-implemented functional arrays. 🐝

[![Package Version](https://img.shields.io/hexpm/v/gary)](https://hex.pm/packages/gary)

[![Hex Docs](https://img.shields.io/badge/hex-docs-ffaff3)](https://hexdocs.pm/gary/)

## When should I use `gary`?  When are other data types better?

Erlang arrays are $O(\log n)$ for both lookups and updates.  If you don't remember big-O notation, for the purposes of this explanation that essentially means "faster than $O(n)$ (linear time), but slower than $O(1)$ (constant time)".

Tuples are $O(1)$ for lookups, but $O(n)$ for updates -- you can lookup a tuple by its index without iterating over the tuple, but the entire tuple has to be copied to a new location in memory to update one of its values.  Tuples are faster when you're doing repeated random lookups on an unchanging set of values, but lose out to arrays when random updates are required.  

[`glearray`](https://hex.pm/packages/glearray)'s version of arrays are represented as a single tuple, so if you're solely doing lookups and don't need the sparse representation or dynamically resizeable arrays, `glearray` will likely be faster than `gary` .

Lists are $O(n)$ for both lookups and updates anywhere but the head of the list, since you need to iterate over the pairs of the linked list to find an arbitrary index within it.  Lists will be faster that arrays if you can ensure that you only ever operate at the head of the list, like in most traditional recursive algorithms.

## Example

```sh

gleam add gary

```

```gleam

import gary/array

pub fn main() {

  list.range(1, 10)

      |> array.from_list(default: -99)

      |> array.drop(at: 5)

      |> result.map(array.map(_, fn(_, v) { 2 * v }))

      |> result.map(array.to_list)

  // = Ok([2, 4, 6, 8, 10, -198, 14, 16, 18, 20])

}

```

Further documentation can be found at .

## Development

```sh

gleam run   # Run the project

gleam test  # Run the tests

gleam shell # Run an Erlang shell

```