小殘的程式光廊

Stable Diffusion 是由 StabilityAI 公司所開發的模型。由於 Stable Diffusion 是開源的，所以可以找到許多線上 AI 藝術生成服務使用這個模型。而官方推出的線上服務是 DreamStudio 這個產品，本篇文章將介紹這個網站基本資訊、操作教學，以及一些實測和使用心得。 基本資訊網址： StabilityAI 官網 或直接連 DreamStudio試用：註冊後可獲得100點數。付費方案： 10 美金可購買 1000 點，生成圖片可選擇不同屬性，依據不同設定扣點不同，預設設定一張圖 0.2 。解析度：最大 1024x1024 ，長寬可自訂介於 512-1024 。運算速度： 5-10 秒浮水印：無商業使用：可以，參考 FAQ 功能介紹註冊完成進入網頁之後可以看到下面的畫面，右側可以選擇尺寸 (Width 和 Height)、生成張數 (Number of Images) 和其他複雜的設定，上方可以看到設定所需花費的短數。我們先用預設值來試試看： 預設產生四張圖，其中一張不知為何產生出模糊不清的圖片，右側可以下載全部圖片，或者點擊圖片可以下載或進一步 ...

DALL·E 2 是由 OpenAI 公司所開發的 AI 文生圖程式， OpenAI 同時也開發了另一個熱門的產品 ChatGPT ，應該不少人聽過。本篇文章介紹 DALL·E 2 這個網站的基本資訊、操作教學，以及一些實測和使用心得。 基本資訊網址： DALL·E 2 官網試用：註冊後可獲得 50 點數，每個月會有 15 點數可以試用，免費點數一個月後會過期，不能累積。付費方案：購買點數， 15 USD 可以買 115 點，生成一次一點。解析度： 1024x1024運算速度：大多 10 秒多，有時會到四五十秒浮水印：右下角有浮水印，需自行移除商業使用：可以摘錄官方部落格: Using DALL·E for commercial projectsStarting today, users get full usage rights to commercialize the images they create with DALL·E, including the right to reprint, sell, and merchandise. This includes images ...

拍攝時間：2023 年 1 月 22 日 行程韓國首爾自由行第四天行程： 梨大 南山首爾塔 晚餐 - 明洞夜市 梨大今天原本排定的行程是梨大一帶和首爾塔，一早就跑來梨大這裡，結果門口寫著疫情不開放…只能在門口拍一張照。 那只好去逛逛附近的女人街，結果… 也許是疫情的關係，這裡的店家倒了一大半，剩下的也沒開。只好拍這裡的地標高跟鞋。 這裡商圈沒落，只好改去再去一次東大門，想說百貨公司應該會開吧，反正前兩天也沒逛到。但到了東大門發現，這邊百貨公司也沒開，後來想是韓國也有過農曆年，所以都關門了。 中午在東大門附近隨便吃了，然後就去逛逛附近清溪川。 接著地鐵站走去，會經過看到興仁之門，感覺真的和台北 87% 像。 接著搭地鐵到明洞後，走一大段路到這家咖啡聽 (카페 구할구 남산점)，不知道中文叫什麼。 位置在首爾塔附近，在頂樓的座位可以看到首爾塔。 原本預計在首爾塔上看日落和夜景，所以安排四點左右上去，就先在咖啡廳休息一下。 南山首爾塔接著走去纜車站搭纜車，結果排隊已經排了很長，從樓上排到樓下，從裡面排到外面，排到天荒地老足足排了一個小時才搭上纜車。 纜車幾分鐘就到山上了，往上走一段路就可 ...

拍攝時間：2023 年 1 月 21 日 行程韓國首爾自由行第三天行程： 洪川大明滑雪村 晚餐 - 新村食堂 弘大商圈 洪川大明滑雪村這天的行程是在 Klook 上購買的，內容包含遊覽車、滑雪場門票、部分器具和基礎教學。早上有幾個不同的集合點，遊覽車會會沿途載人，我們是早上7點從明洞出發的集合點。 上車之後就開始漫長車程，就先睡了一下。不知道睡了多久，往窗外看有一條河流 結冰了 首先到達滑雪學校，在這裡進行簡單的介紹，然後會在這裡先穿上部分裝備。介紹的時候會建議你們要另外購買滑雪手套、滑雪巾和滑雪襪，同時還會建議你租借頭盔。如果和他們一次購買滑雪手套、滑雪巾和滑雪襪三個裝備的話，就會免費租借頭盔。我們最後就買了兩組，一組五萬韓幣。換算台幣的話一個人要1250，相當的昂貴。 建議在台灣先買好滑雪手套、滑雪巾和滑雪襪帶過去，再租借頭盔1萬韓幣。 提供的裝備有滑雪外套、滑雪褲和護目鏡，衣物的保暖效果蠻好的，我把外套外衣外褲脫掉換上，在滑雪的過程中是不會覺得冷，但停下不動的時候會覺得冷。穿好裝備後會到滑雪場領取最後的領取滑雪鞋、滑雪板和滑雪雪仗。 滑雪場有幾種不同坡度的滑雪道，我們當然是到 ...

拍攝時間：2023 年 1 月 20 日 行程韓國首爾自由行第二天行程： 早餐 - 烤麵包餐車 韓服體驗 - 西花韓服 景福宮 午餐 - 土俗村蔘雞湯 三清洞 北村韓屋村 東大門 SPAREX 汗蒸幕 東大門設計廣場 晚餐 - 咸草醬花螃蟹 早餐一早先穿在台灣的穿法出來買早餐試試溫度，結果冷到受不了，回去旅館加厚裝備。早餐就買旅館附近的餐車： 有不少當地人在現場吃，拿杯子喝湯或是泡不知道是什麼的即溶包喝。 忘記多少錢了，好像是 3500 ，味道還不錯。 韓服體驗 - 西花韓服接著到 kkday 預定的西花韓服換裝，有的店員會講中文。網路上說需要押金和護照，但這次實際去都沒有要求。 換好裝東西可以寄放在這，但天氣太冷，我們外面還是有穿外套圍巾等衣物，拍照的時候再脫下。 先放一張女友穿韓服的背影 韓服店家大多最早都是九點才營業，所以穿韓服走景福宮排在早上的話，可能會卡到中午吃飯時間。 景福宮進入要門票，但有穿韓服就可以免費入場，我進去的時候有被要求拉下外套看裡面是不是穿韓服。 這次去的時候前面在施工，站位不好沒辦法完整拍到光化門。 定時有交易交接儀式，會有穿韓服古裝的人員。 慶 ...

臨時突然決定出國去玩，不過不常出國又很久沒出國，有許多東西沒準備好，記錄一下這次經驗。 機票住宿這次透過燦星購買的機加酒五天四夜來回，飛機是長榮航空，飯店是 Savoy。 01-1915:15 - 18:45 桃園往仁川 01-2311:40 - 13:30 仁川往桃園 兩人總共 46008 由於是春節連假加上開始規劃的太晚，所以價格似乎比平常貴一些，能選的時段也很差。後來在規劃的過程中才發現，去頭尾就只剩三天可以玩，想改時間延長天數增加兩天，但手續費和罰金加起來兩個人要貴一萬五，就放棄了。當時重新訂一個七天六夜機加酒也是四萬六，不過飛機是變成立榮，時間是凌晨。 換錢 - 匯率比較如同網路上建議的，在台灣換韓幣匯率較差，建議先只換一點就好，到韓國的換錢所再換匯率較好。本來計畫第一天晚上在明洞旅館附近的換錢所換，但到達時間太晚，後面幾天行程都沒辦法在營業時間去換，所以最後都沒成功在換錢所換。這次總共在三個地方換錢，都是用新台幣千元鈔票去換： 出發前兆豐銀行： 0.0264 (37.88) 仁川機場換錢 (Hana Bank)： 0.0289 (34.6) 地鐵站的換錢機 (Wow ...

說明你也許不知道，Solidity 宣告變數的順序也會影響 gas 的消耗。由於 EVM 的操作都是以 32 bytes 為單位進行，所以編譯器會嘗試在讀寫變數時，將小於 32 bytes 的變數打包成 32 bytes 一組來進行存取，以達到節省存取次數的目的。不過編譯器並沒有足夠聰明，能自動將合約的變數做最佳化的分組。他會將固定大小的變數，依序每 32 bytes 為一組。例如下面的例子： 12345678910111213contract MyContract { uint64 public a; uint64 public b; uint64 public c; uint64 public d; function test() { a = 1; b = 2; c = 3; d = 4; }} 在執行 test() 時，雖然看起來寫入了四個變數，但是由於這四個變數加起來剛好是 32 bytes ，可以做一次性的寫入，所以實際上執行一個 SSTORE ，消耗 20000 gas 。接著看下面的例子： 123 ...

在開發智能合約的過程，由於想要能夠達到多筆撮合的功能，我們實作了一個函式能夠輸入多筆訂單資料。在隨著我們加入了越來越多的功能，同時為了確保合約公正性，而需要越來越的參數，例如：礦工手續費、taker 手續費、maker 手續費和支付手續費方式等，我們遇到了變數過多而無法編譯的情況，而大量的資料所消耗的 gas 也成為一個問題。 我們在撮合的函式中，最後每個訂單會有這些資料： 1234567891011121314uint256 amountSell,uint256 amountBuy,address tokenSell,address tokenBuy,address user,uint256 nonce,uint256 gasFee,uint256 takerFee,uint256 makerFee,uint256 joyPrice,bool isBuy,uint8 v,byte32 r,byte32 s 於是我們試著想辦法減少變數的數量，在某次我看著 Etherscan 某交易顯示如下的參數資料時 12345678910111213Function: trade(address t ...

說明你也許不會想到，函式名稱也會對 gas 消耗造成影響，事實上，在最糟的情況下，甚至會有上千 gas 的差距。我們來看看下面程式： 1234contract Test { function b() public { }} 上面程式執行 b() 會消耗 125 gas，接著改成下面： 1234567contract Test { function a() public { } function b() public { }} 這次執行 b() 變成消耗 147 gas，一樣的空函式怎麼消耗增加了呢？試著執行 a() 會發現只消耗 125 gas。原來在智能合約中，函式存在前後順序，排序越後面的會消耗越多，每差一個順位就會多 22 gas。此時你可能會想把它改成下面： 1234567contract Test { function b() public { } function a() public { }} ...

如果一間區塊鏈公司業務，成本都來自於智能合約的交易，那麼智能合約的 gas 消耗，就直接影響公司營業成本。寫出節能的智能合約，在商用上有其重要性。這篇文章將整理分析智能合約中，影響 gas 消耗的一些因素，有助於我們了解消耗最大的指令是哪些，並謹慎的使用。gas 消耗可參考下面兩個表： 表一 表二 表一中的 Gas Used 為消耗的 gas。如果顯示為 FORMULA，表示不是一個固定值，要參考右邊的說明。由於我們通常使用 Solidity 開發，所以可能無法直接對應到上面表一中的指令；這時可參考表二，他有多加上一些額外的指令。以下列出消耗較多 gas 的行為與指令： 建立合約對應到 CREATE 和 CODECOPY 兩個指令。在合約中建立另一個空的合約消耗 42901 gas ( 總共 64173 gas)，如果是直接部署一個空合約則總共是 68653 gas。加上合約的功能實作，可能會有幾十萬甚至百萬的 gas，應該是所有指令中消耗最多一個。拆分多個類別與實例的實作方式，gas 消耗可能會很可觀。避免用 Contract 當作資料結構： 不好 123456789contra ...