Scratch への提案

falcon_toto

yui0321 wrote:
#3458, #3460,#3461,#3462
なるほど。分かりづらくなってしまうという懸念点がありますし、普通に区別すればいいということですね…
代わりと言っては何ですが、ブロック定義の色を変えられるようにできればいいのではないかと思いました。

「動き」の青や「見た目」の紫など、すでにあるscratchのブロックにある色だけに変更出来たら見分けがつきやすくなると思います。
中を見た人も、「これが動きの部分の定義ブロックだな」と直感的にもわかりやすいですし。

tabakenn

#3457
スクラッチ（JavaScript）は、整数、小数、文字列を一緒くたにするのが特徴です。そこで、配列と連想配列を一緒にすることができなくもないです。

[なにか] を [あ] 番目？に挿入する（ [list v] ）::list
([あ] 番目？（ [list v] ） :: list)

1 なにか
2 なにか
あなにか
いなにか

みたいな感じで、数字と文字列が混在する状態です。つまり、連想配列のキーが数字だけのものが今のリストで、その制限を外す感じです。これなら難しくはないですが、アイデアを出しただけで僕は反対です。←取り消し、実用案を思い付いたので追記

◯全てのスプライト用　◯このスプライト用
⬜︎数字以外もキーに使えるようにする

みたいな感じにして、連想配列を使えるようにできるのでは？（X番目などの表現を変える必要はあるけれど）

Last edited by tabakenn (Dec. 16, 2022 12:11:13)

inoking

tabakenn wrote:
みたいな感じで、数字と文字列が混在する状態です。つまり、連想配列のキーが数字だけのものが今のリストで、その制限を外す感じです。これなら難しくはないですが、アイデアを出しただけで僕は反対です。

通常の配列と連想配列は全く別物です。
ブロックの形的に同様に扱えたとしても
（むしろ連想配列が通常配列と同様のインターフェースで扱えるように考えられていると思われる）
考え方が違います。

「変数って何ですか？」「箱のようなものです」といったやりとりをしている世界にとっては
高度すぎるでしょう。

Last edited by inoking (Dec. 15, 2022 14:59:03)

akinarin

>> #3468
反対です。
#3469で言われているように、高度すぎるというのもありますが
互換性の面からも反対です。

実は、既存のScratchでは、
無理やりリストの「〇番目」の引数に小数を入れるのが可能です。

[] を ([] と [1.3]) 番目に挿入する（ [list v] ）

この場合、引数は切り捨てられて「1番目に挿入する」として実行されます。

もし、Scratchのリストが連想配列になれば、
これの挙動が「1番目に挿入する」→「1.3番目に挿入する」と変わってしまいます。
今まではインデックスが整数だけだったのに、連想配列なら整数以外もインデックスに設定できるからです。

もし、「(小数)番目」の仕様を使ったプログラムが存在していたら、
仕様変更のせいで動かなくなってしまいます

Last edited by akinarin (Dec. 15, 2022 21:02:15)

nyankodaisensou-suki

#3468
反対です。
リストの左のチェックマークを入れた際にどのような順番でリストに表示されるか分からないからです。

inoking

nyankodaisensou-suki wrote:
リストの左のチェックマークを入れた際にどのような順番でリストに表示されるか分からないからです。

それは問題にはなりません。
一般に、連想配列の各要素を列挙したときの並び順は決まっておらず、実装依存です。

つまり、「どのように並んでいてもいい（並び順を気にするほうがおかしい）」です。

Last edited by inoking (Dec. 16, 2022 03:14:21)

tabakenn

#3470
既存のブロックやUIを使うので高度すぎるとは思いません。

tabakenn wrote:
◯全てのスプライト用　◯このスプライト用
⬜︎数字以外もキーに使えるようにする

また選択式なので、そのような互換性の心配はない気がします。（クラウド変数と変数の関係のように、連想配列と配列は別物として扱う）

inoking

tabakenn wrote:
既存のブロックやUIを使うので高度すぎるとは思いません。

いえ、UIが同じだから簡単という話にはなりません。
繰り返しになりますが
通常の配列と連想配列は全く別物です。
配列は array（連続したデータの並び）ですが、
連想配列 (associative array) は dictionary, hash, map などと呼ばれるように（離散的なデータ集合）です。

というか、

tabakenn wrote:
アイデアを出しただけで僕は反対です。

なのですから、こだわらなくてよいのでは？

tabakenn

アイデアを出しただけで僕は反対です。
と書いた後に、
「数字以外もキーに使えるようにする」というオプション方式にすれば実用的だなと思い、取り消し線を引いて付け加えました。
#3474
たしかに配列とマップをまとめるのはナンセンスな気がしてきたので、提案取り下げます。

Last edited by tabakenn (Dec. 16, 2022 09:20:53)

newmomizi_txt

ハッシュ的なものであれば、リストを二つ使うことで代用できませんかね。

((vals v) の ((keys v) の中の (キー) の場所 :: list) 番目 :: list)

唯一の問題点は、本物のハッシュよりも計算量が多いことです。
このプログラムはO(n)ですが、C++のmapはO(log n)なので、計算量は本物のハッシュより多いことになります。(参考)
そもそもの話、Scratchに実行速度を求めるべきではないと思いますが…

Last edited by newmomizi_txt (Dec. 16, 2022 09:24:42)

tabakenn

#3476
それで超簡単に代用できますね！
でも値を取得するだけでO(n)なのは少し気になりますし、連想配列は汎用性が高いので便利だと思うのですけど……

Last edited by tabakenn (Dec. 17, 2022 06:01:03)

inoking

tabakenn wrote:
連想配列は汎用性が高いので便利だと思うのですけど……

便利ですが初心者向きではないと思います。

tabakenn

このように、カラーピッカーの下にカラーコードがあるといいと思います。
色、鮮やかさ、明るさ　を調整するとカラーコードが更新され、
カラーコード欄に入力すると、3つのパラメータが更新される感じです。

tabakenn

連想配列について
#3478
うーん、やはり初心者向きではないですか……
代用(#3476)も確立していますし、反対意見しかないので、再び取り下げます！

Last edited by tabakenn (Dec. 17, 2022 06:12:34)

akinarin

僕は、配列と連想配列をまとめるのでなければ余り高度になるとは考えていません。
しかし、#3476の簡単な代用方法もあるし、初心者のプログラミング能力向上の為にも
連想配列の採用は反対です。

akinarin

>> #3479
賛成です。
色をいじると変わるこの数値を初心者が「何だろう？」と思って調べたり人に聞いたりすることで
光の色相はRGBで表せることなどを学ぶ手助けになります。

Last edited by akinarin (Dec. 17, 2022 06:17:18)

h_team_x

by turbowarp
これのことですか？

Last edited by h_team_x (Dec. 17, 2022 16:41:57)

tabakenn

！まさにそれですね。考えていた仕様通りです。
ちなみに、調べるブロックの指定にだけ使える想定でしたが、ターボワープのようにコスチューム編集にも使えた方が良いのかな？

（元々は、

変数 [変数 v] を [#f5f] にする ::variables//カラーコードを入れる

これがなくとも、調べるブロックの色をカラーコードで持ってこれれば事足りるのでは、と思って出した案です。

Last edited by tabakenn (Dec. 17, 2022 17:08:00)

inoking

#3476:

newmomizi_txt wrote:
ハッシュ的なものであれば、リストを二つ使うことで代用できませんかね。
((vals v) の ((keys v) の中の (キー) の場所 :: list) 番目 :: list)
唯一の問題点は、本物のハッシュよりも計算量が多いことです。
このプログラムはO(n)ですが、C++のmapはO(log n)なので、計算量は本物のハッシュより多いことになります。(参考)
そもそもの話、Scratchに実行速度を求めるべきではないと思いますが…

((vals v) の () 番目 :: list)

は O(1) であるとして、

((keys v) の中の (キー) の場所 :: list)

が線形探索になっているため O(n) になるわけですが、
実行速度を求めるなら二分探索とかで自作するのでしょうね。

tabakenn

#3485
リプライ元ではありませんけど…

前作った封印されたプロジェクトで、
https://scratch.mit.edu/projects/693120734/
要素7000のリストから文字を検索する必要があったのですが、通常ブロックの検索では無視できないほど遅いことがわかりました。
そこで、（あ＞い）のような文字の比較ができることを利用して、二分探索木を使用したところ、100〜200番目の要素くらいから二分木の方が早いことが分かりました。

普通、スクラッチ標準ブロックが代用ブロックに速度面で負けることはないため、これは良くないのでは、というのもあっての提案です。
それに、二分木はソートされている必要がありO(logn)ですが、通常のハッシュマップはO(1)です。
よって連想配列が使えてもいいのではないかと思っていました。

Last edited by tabakenn (Dec. 17, 2022 18:11:37)

Discuss Scratch