【科技新聞】從 E 2

我只是完成論文的一部分，但到目前為止讓我感到有趣的是：

在我熟悉的其他文本到圖像算法中（您通常會看到作為 colab 筆記本傳遞的那些，人們在 Twitter 上發布輸出），基本思想是對文本進行編碼，然後嘗試製作一個與該文本編碼最大匹配的圖像。但是這種最大化通常會導致偽影——如果你要求一張日落的圖像，你通常會得到多個太陽，因為那更像日落。有很多技巧和技巧可以規範流程，使其不那麼激進，但這始終是一場艱苦的戰鬥。

在這裡，他們取而代之的是文本嵌入，使用經過訓練的模型（他們稱之為“先驗”）來預測相應的圖像嵌入——這消除了危險的最大化。然後，另一個經過訓練的模型（“解碼器”）從預測的嵌入中生成圖像。

這感覺像是一種更明智的方法，但只有通過訪問 OpenAI 擁有的巨大 CLIP 數據集和計算資源才能真正實現。

>我們限制了 DALL·E 2 生成…成人圖像的能力。

我認為將這樣的東西用於色情內容可能會給社會帶來最大的好處。關於這個行業如何利用年輕和脆弱的模型，已經說了很多。廉價的自動生成圖像（以及未來的視頻）幾乎可以消除對人體模型的需求並消除相關的痛苦，不是嗎？

編輯：錯字

在 AI 生成的空間中花費了太多時間的人的一些評論：

* 我建議閱讀它附帶的風險和限制部分，因為它非常完整： https://github.com/openai/dalle-2-preview/blob/main/system-c…

* 與 GPT-3 不同，我對該公告的解讀是，OpenAI 不打算將其商業化，並且訪問候補名單確實更多是為了測試其限制（如前所述，將其商業化將更有可能導致有趣法律先例）。根據文檔，訪問權限非常明確：（ https://github.com/openai/dalle-2-preview/blob/main/system-c … ）

* 幾個月前，OpenAI 發布了 GLIDE ( https://github.com/openai/glide-text2im )，它使用了類似的 AI 圖像生成方法，但可疑的是從未收到過這樣有趣的博客文章。回想起來，原因可能是“因為我們讓它過時了”。

* 公告中的圖像仍然是精選圖像，因此這是他們在非精選圖像上測試 DALL-E 1 與 DALL-E 2 的一個很好的理由。

* 挑選櫻桃是相關的，因為 AI 圖像生成仍然很慢，除非你進行可能會損害圖像質量的真正惡作劇，儘管 OpenAI 可能有更好的基礎設施來處理大型模型，正如 GPT-3 所展示的那樣。

* 似乎 DALL-E 2 有一個有趣的端點，可以鏈接回該站點以獲取帶有歸屬的示例： https ://labs.openai.com/s/Zq9SB6vyUid9FGcoJ8slucTu

這篇文章製作精良，揭示了非常有趣的事情。我喜歡它在技術上的組合方式，在移動設備上瀏覽它是一種很棒的體驗，起首部分，我喜歡數字時代的出版商在提供自動播放廣告之外有多麼棒的新格式。

引起我注意的是所謂的 USCentric 方法，因為它以英里為單位計算距離。我還想知道它是否被翻譯成俄語，以便可以與被 TikTok 欺騙的俄羅斯公民分享

這是一個很好的視覺和具體例子，說明敘事是多麼容易控制。

這只是 21 世紀媒體更大的系統性問題的一個例子，也是人們如何消費媒體的問題。

幾乎每個平台都是這樣的，不僅僅是 TikTok。這不像 TikTok 試圖將自己展示為一個中立、公正的來源。他們的整個前提是盡快向您提供“高度策劃”的內容。問題是人們已經接受了這一點，這是正常的，它對世界造成了可怕的影響。每個人都覺得我們是有史以來最分裂的人是有原因的……從這樣的事情開始。

就烏克蘭的戰爭而言，這就像經典的二戰宣傳一樣，但由於這些天傳播 [錯誤] 信息的速度和容易程度，它變成了 11 個。

我喜歡這個的執行！

沒有比較，但我 8 年前在以色列/巴勒斯坦衝突的高峰期做了一個類似的項目，比較來自巴勒斯坦的推文和來自以色列的推文。

當您並排看到它們時，會有令人難以置信的差異。

如果有人能在更多衝突領域執行這樣的想法以提高意識，那就太好了。

Jd周圍的環境從小就變了一點！ Jsoftware[0] 於 2012 年宣布它，並且這個特定頁面自 2017 年創建以來實際上是相同的（我懷疑這是一個頁面移動，並且內容有些舊）。在這些早期，面向列的數據庫迅速普及，但仍然晦澀難懂，這就是為什麼有這個“列”部分在解釋這個概念時遇到了這麼多麻煩。現在這個想法在數據庫用戶中是眾所周知的，還有很多其他的選擇[1]。

歷史可以追溯到更遠的地方，因為面向列是用數組語言構建數據庫的自然方式（製造高性能的面向行的 DBMS 基本上是不可能的）。這是因為可以將列視為每個元素都具有相同類型的向量。行對不同類型的值進行分組，而數組語言沒有像 C 結構這樣的東西來處理這個問題。在 J 中，Jd 來自 Chris Burke 的 JDB 概念驗證（announced[2] 2008，看起來像），鏈接頁面提到了 kdb+ (K) 和 Vstar (APL)。 KDB 於 1993 年首次發布，它有點出名，並在 Wikipedia 的面向列的數據庫的歷史中被提及 [3]。

[0] 公司歷史： https ://aplwiki.com/wiki/Jsoftware

[1] https://en.wikipedia.org/wiki/List_of_column-orientation_DBMSes

[2] https://code.jsoftware.com/wiki/JDB/Announcement

[3] https://en.wikipedia.org/wiki/Column-oriented_DBMS#History

我做了一些工作將 Jd 與 data.tables 進行比較，發現它在某些情況下性能更高，例如在派生列上，並且在聚合和查詢上的性能大致相同。 Jd 目前是單線程的，而多線程在某些類型的查詢中很重要。我試圖同時（可能是一年前）進一步與 Julia DB 進行比較，發現作者錯誤地進行了基準測試，並且比兩者都慢得多；現在可能不一樣了。 jd更相當於磁盤上的data.tables； Clickhouse 在大型數據庫方面要好得多。

關於內存使用的經驗法則：Python/Pandas（非內存映射）：“在 Pandas 中，經驗法則是數據大小需要 5 到 10 倍的內存。” R（非內存映射）：“粗略的經驗法則是你的 RAM 應該是數據集大小的三倍。” Jd：“一般來說，如果可用 ram 是查詢中通常使用的 cols 所需空間的 2 倍以上，則性能會很好。”

關於 CSV 閱讀，Jd 有一個快速的 CSV 閱讀器，而 J 本身沒有。我編寫了一個 Arrow 集成，使 J 能夠訪問那個快速的 CSV 閱讀器並閱讀 Parquet。

作為一名數據科學家，我已經在 J 中進行了專業的編程（誠然沒有那麼久），巧合的是，我剛剛完成了一個使用 J 的小型分析，作為我正在計劃的數據分析內部研討會的一部分。我通常使用 R 和 Python 工作，我不得不說，在這個階段，我幾乎沒有理由選擇 J 來做任何工作。除非代碼高爾夫級別的簡潔是您唯一的目標，否則這些其他平台提供卓越的性能、清晰度、易用性、對庫的訪問，並且作為編程語言，設計得更好。

作為函數級編程的狂熱愛好者和 J 愛好者，我這麼說。我想說我非常熟悉 J 的編程範式和概念小部件和小工具（我知道動詞、名詞、副詞和連詞，並且可以適當地使用它們）。我什至記得 Nuvoc 的相當一部分。但是，與使用 R 和 tidyverse 相比（特別是，我錯過了 dplyr 和 ggplot），即使在 J 中進行最簡單的分析也是_excrutiatingly_緩慢且不方便的。例如，tidyverse CSV 閱讀器比您從 J 宇宙中獲得的任何東西都更快、更智能、更方便且信息量更大。

我喜歡矢量語言，但在這一點上，J 無法與主要的數據分析平台競爭。它不太方便，通常_慢_，低級得多，奇怪，它的圖書館狀況充其量是貧乏的。我建議學習 J，因為它會擴展你的思維，但我無法想像將它用於實際工作。