2017-02-08 138 views
3

我的透鏡is that的基本理解,「一個鏡頭是代表一個複雜的類型及其成分之一之間的映射值這個地圖是雙向的,我們可以得到或‘訪問’的成分,設置或「變異」,它」斯卡拉:倫辛VS可變的設計

我碰到這個來的時候,我設計一個機器學習庫(神經網絡),這需要保持的參數的大數據結構,組中的,需要在算法的不同階段進行更新。我想創建整個參數數據結構不可變,但更改一組參數需要複製所有參數,並重新創建新的數據結構,這聽起來效率很低。並不奇怪other peoplehave thought它也是。有些人建議使用透鏡,從某種意義上說,讓你修改不可變的數據結構。而其他一些人則建議使用這些可變因素。不幸的是我找不到任何東西比較這兩個範例,速度明智,空間明智,代碼複雜性明智等。

現在問題是,什麼是使用透鏡vs可變設計的優點/缺點?

回答

4

兩者之間的權衡是你猜測漂亮多了。鏡頭不如手動跟蹤對大型不可變數據結構的更改那麼複雜,但仍需要比可變數據結構更復雜的代碼,並且存在一定量的運行時間開銷。要知道有多少,你將不得不衡量,但它可能小於你認爲,因爲很多更新的結構是不可複製的,但共享

可變數據結構更簡單,修改速度稍快,但難以推理,因爲現在您必須考慮命令的功能,考慮併發性等問題。

你的第三個選擇是讓一幫小一成不變的數據結構,而不是一個大單。由於需要單一的事實來源,並且確保所有對數據的引用同時發生更改,可變性通常會強制使用單個大型數據結構。具有不變性,這很容易控制。

例如,您可以有兩個單獨的Maps具有相同類型的密鑰和不同類型的簡單值,而不是具有更復雜值的Map。這不僅具有性能優勢,而且使模塊化代碼更容易。

+0

謝謝你的好的答案。但有一個問題:爲什麼鏡頭不會產生任何併發問題? (如果它與可變類型相似,則它在併發性方面具有相同的問題會有意義) – Daniel

+1

Lensing仍然是不可變的,它只是創建一個類似於深度變化的API。當你進行「設置」時,任何參照舊結構的任何部分的其他人將仍然具有舊的未修改值。您必須將結果分配給新範圍中的新變量。 –