[Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[olexandr543 at yahoo.com]

 Yes, you can use IntMap. It needs another dependency and the complexity choice as O(log (min (n, W))) where W is a number of bits in a representing key, used for mapping. 
For me, it is rather hard to solve whether it can be better, because it raises another problem of efficient binary representation of the keys.
While working on the topic, I found out that may be the most efficient will be hashing (for lookup it can be used e. g. Cuckoo hashing) and there is a library in Haskell for it.Data.HashTable.IO Using it, you can write something like:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.HashTable.IO as I
import Data.Maybe (fromJust,isJust)
import System.Environment (getArgs)
main :: IO ()
main = do          args <- getArgs         let a = [([z,t],x) | x <- ['a'..'d'], z <- ['f'..'t'], t <- ['a'..'p'], [x,z,t] <= "fnf"]          b :: I.CuckooHashTable String Char <- I.fromList a          c <- I.lookup b ("kn")          let d1 u = do                   d <- I.lookup b u                  print c                  if isJust d                     then putStrLn . show . fromJust $ d                     else putStrLn "Nothing"                  return ()          if null args            then d1 "fa"           else d1 (head $ args)


| 
| 
|  | 
Data.HashTable.IO


 |

 |

 |


so it works. And the library documentation says that a complexity of Cuckoo hash lookup is about O(1), but with hashing there are questions of ratio of fulfilling the buckets and collisions.
So, my library having the very generic constraints can be used instead.
Best regards,Oleksandr Zhabenko.

    субота, 21 вересня 2019 р., 21:52:18 GMT+3, olexandr543 at yahoo.com <olexandr543 at yahoo.com> написав:  
 
  Yes, you can. It needs another dependency and the complexity choice as O(log (min (n, W))) where W is a number of bits in a representing key, used for mapping. For me, it is rather hard to solve whether it can be better, because it raises another problem of efficient binary representation of the keys.
While working on the topic, I found out that may be the most efficient will be hashing (for lookup it can be used e. g. Cuckoo hashing) and there is a library in Haskell for it.Data.HashTable.IO Using it, you can write something like:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.HashTable.IO as I
import Data.Maybe (fromJust,isJust)
import System.Environment (getArgs)
main :: IO ()
main = do          args <- getArgs         let a = [([z,t],x) | x <- ['a'..'d'], z <- ['f'..'t'], t <- ['a'..'p'], [x,z,t] <= "fnf"]          b :: I.CuckooHashTable String Char <- I.fromList a          c <- I.lookup b ("kn")          let d1 u = do                   d <- I.lookup b u                  print c                  if isJust d                     then putStrLn . show . fromJust $ d                     else putStrLn "Nothing"                  return ()          if null args            then d1 "fa"           else d1 (head $ args)


| 
| 
|  | 
Data.HashTable.IO


 |

 |

 |


so it works. And the library documentation says that a complexity of Cuckoo hash lookup is about O(1), but with hashing there are questions of ratio of fulfilling the buckets and collisions.
So, my library having the very generic constraints can be used instead.
Best regards,Oleksandr Zhabenko.


    субота, 21 вересня 2019 р., 21:34:38 GMT+3, Henning Thielemann <lemming at henning-thielemann.de> написав:  
 
 
On Sat, 21 Sep 2019, olexandr543--- via Haskell wrote:

> My library that can help to optimize using 'case ... of ...' construction if there are multiple (more than at
> least 5) variants.
> mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

Isn't this a problem you would solve using Data.Map?
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell/attachments/20190921/f24ba5a4/attachment-0001.html>