私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.133 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
javascriptで今流行りの機械学習勉強したいのですがだめですか?
本が全然みつからない。
もう年だしプログラマーでもないので他の言語やりたくない。
本が全然みつからない。
もう年だしプログラマーでもないので他の言語やりたくない。
ガッツリやりたいならCPUでは限界があるから
どちらにせよWebGLを使うことになるからそれは他言語で書いてるようなもの
まあTensorFlow.jsくらいからやるといいんじゃない
どちらにせよWebGLを使うことになるからそれは他言語で書いてるようなもの
まあTensorFlow.jsくらいからやるといいんじゃない
一定の規則に沿った数列をいくつか作りたいなら
ベースとなる配列作っといてそれをmap()で回すとか?
ベースとなる配列作っといてそれをmap()で回すとか?
初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発
http://www.amazon.co.jp/dp/toc/4873117836/ref=dp_toc?_encoding=UTF8&n=465392
徹底マスター JavaScriptの教科書 プログラミングの教養から、言語仕様、開発技法までが正しく身につく (Informatics&IDEA)
http://www.amazon.co.jp/dp/toc/4797388641/ref=dp_toc?_encoding=UTF8&n=465392
上の2つならどっちがおすすめ?
一通りの知識はあるけどもうちょっと知識深めたいってレベルです。
http://www.amazon.co.jp/dp/toc/4873117836/ref=dp_toc?_encoding=UTF8&n=465392
徹底マスター JavaScriptの教科書 プログラミングの教養から、言語仕様、開発技法までが正しく身につく (Informatics&IDEA)
http://www.amazon.co.jp/dp/toc/4797388641/ref=dp_toc?_encoding=UTF8&n=465392
上の2つならどっちがおすすめ?
一通りの知識はあるけどもうちょっと知識深めたいってレベルです。
>>306
ありがとうございます
たしかに配列を作成するのはそれが一番シンプルですね
実際の問題はすでにある配列に同一の要素を任意数追加するというもので
fillやpushを使う以外にもっとシンプルな方法があるんじゃないかと思ったのですが、なさそうですね
ありがとうごさいました
ありがとうございます
たしかに配列を作成するのはそれが一番シンプルですね
実際の問題はすでにある配列に同一の要素を任意数追加するというもので
fillやpushを使う以外にもっとシンプルな方法があるんじゃないかと思ったのですが、なさそうですね
ありがとうごさいました
配列のlengthを拡張してあってパターンを含ませてるならcopyWithinで１発
>>307
それくらいならMDN眺めたり実装追ってるブログ見りゃいいと思うよ
それくらいならMDN眺めたり実装追ってるブログ見りゃいいと思うよ
>>たしかに配列を作成するのはそれが一番シンプルですね
>>実際の問題はすでにある配列に同一の要素を任意数追加するというもので
>>実際の問題はすでにある配列に同一の要素を任意数追加するというもので
それならpushでいいじゃん。ループは要らないぞ。
何で嫌がるのかサッパリだらっしゃい…
すでにある配列をaに、3を45個追加するには、
a.push(...Array(45).fill(3))
だがこういうことではなくて？
何で嫌がるのかサッパリだらっしゃい…
すでにある配列をaに、3を45個追加するには、
a.push(...Array(45).fill(3))
だがこういうことではなくて？
>>fillやpushを使う以外にもっとシンプルな方法があるんじゃないかと思ったのですが、なさそうですね
use strict宣言してた場合、;セミコロンも書かないのが普通？
つまり、好みの問題じゃなく全部改行使って書いたほうがいい？（結局圧縮するだろうし）
つまり、好みの問題じゃなく全部改行使って書いたほうがいい？（結局圧縮するだろうし）
use strictはセミコロンの挙動を変えはしないぞ
つまるところ好みの問題だぞ
～の方が良い？的な質問はしないほうが良いぞ
つまるところ好みの問題だぞ
～の方が良い？的な質問はしないほうが良いぞ
Int8Array.BYTES_PER_ELEMENT
的なクラスに直接生えてるプロパティのことだろ
ES2019くらいで
class {
static p = hoge
}
と書けるようになるとは思うが、
それまでは代わりに
class {
static get p() { return hoge }
}
とするのが定石だな
prototype下のプロパティでも同じだ
的なクラスに直接生えてるプロパティのことだろ
ES2019くらいで
class {
static p = hoge
}
と書けるようになるとは思うが、
それまでは代わりに
class {
static get p() { return hoge }
}
とするのが定石だな
prototype下のプロパティでも同じだ
>>317
あ、そういう意味ではなくて今後セミコロンが廃止になりますか？
みたいなニュアンスだったのです
調べてみるとuse strictに限らずセミコロンありなし混合はjavascriptのそういうスタイルだったみたいですね
ありがとうございました
あ、そういう意味ではなくて今後セミコロンが廃止になりますか？
みたいなニュアンスだったのです
調べてみるとuse strictに限らずセミコロンありなし混合はjavascriptのそういうスタイルだったみたいですね
ありがとうございました
>>320
参照透過性のある書き換え不能の変数じゃないのか?
参照透過性のある書き換え不能の変数じゃないのか?
>>322
そりゃ100年後は分からんが、現時点で非推奨になる理由がないだろう
ある面ではスペースみたいな存在なのだから
ほとんどの普通の言語およびコミュニティに於いてそれが無駄だとしても
言語仕様として過剰なスペースを禁止しようということにはならないだろう
そりゃ100年後は分からんが、現時点で非推奨になる理由がないだろう
ある面ではスペースみたいな存在なのだから
ほとんどの普通の言語およびコミュニティに於いてそれが無駄だとしても
言語仕様として過剰なスペースを禁止しようということにはならないだろう
例えばデジタル時計を表示するアプリをつくったときに
setIntervalで1秒毎に更新するようにして
スリープ状態になってスリープ解除すると
遅れた時間が表示されます。
①これはどうしてなのでしょうか?
スリープになると、タイマーが止まって処理が実行されずにキューが溜まっていって、
解除されるとタイマーが止まった時点から再開して
溜まったキューが最初の分からひとずつ実行されるのかなとおもってるのですが
この考えは完全に正解でしょうか?1つでもおかしなとこあったら教えて下さい
②どう解消すればいいのでしょうか?
setIntervalで1秒毎に更新するようにして
スリープ状態になってスリープ解除すると
遅れた時間が表示されます。
①これはどうしてなのでしょうか?
スリープになると、タイマーが止まって処理が実行されずにキューが溜まっていって、
解除されるとタイマーが止まった時点から再開して
溜まったキューが最初の分からひとずつ実行されるのかなとおもってるのですが
この考えは完全に正解でしょうか?1つでもおかしなとこあったら教えて下さい
②どう解消すればいいのでしょうか?
①代わりにsetTimeoutで実装することを考えたら分かりやすいだろう
実行されたら次のキューを登録する
したがって実行が遅延するとキューが溜まっていくことはない
②そもそも精度は保証されて無く、色々なことで遅れるので、
JSに限らずだがタイマーで時を進めて行ってはいけない
更新の度に現在時刻を取得すること
もしストップウォッチ的なものなら開始時刻を取っておいて、毎回比較して差分を出す
そしてオマケで更新はrequestAnimationFrameを使うと良い
実行されたら次のキューを登録する
したがって実行が遅延するとキューが溜まっていくことはない
②そもそも精度は保証されて無く、色々なことで遅れるので、
JSに限らずだがタイマーで時を進めて行ってはいけない
更新の度に現在時刻を取得すること
もしストップウォッチ的なものなら開始時刻を取っておいて、毎回比較して差分を出す
そしてオマケで更新はrequestAnimationFrameを使うと良い
そのレベルならやめといた方がいい。
pythonでやりな。
あっちはあっちで大変だと思うが。
pythonでやりな。
あっちはあっちで大変だと思うが。
基本的に既にできてるモデルをWebで動かす用であって
学習もできなくはないけどAPIもぜんぜん違うよ
学習もできなくはないけどAPIもぜんぜん違うよ
普通static変数=静的な変数っていったら、呼び出すごとに初期化されず状態が保持される変数のことでいい
言語によって扱いは全然異なる
javascriptではクロージャに閉じ込めればもちろんできるし
そもそもjavascriptにあんまし馴染まない概念といえなくもない
こんなとこで合ってる？（質問）
言語によって扱いは全然異なる
javascriptではクロージャに閉じ込めればもちろんできるし
そもそもjavascriptにあんまし馴染まない概念といえなくもない
こんなとこで合ってる？（質問）
いや、そういう関数の機能としてのstatic変数が存在する言語は少ないので
普通staticな変数と言ったらクラスの何らかを想定するだろう、JSでも
普通staticな変数と言ったらクラスの何らかを想定するだろう、JSでも
classでも基本同じでは
インスタンスごとに独立固有でなくインスタンス間で共有され、
インスタンス生成ごとに初期化されるのではなく、一度だけ初期化される、要するに状態が保持される
静的変数が関係する場合、常に同じ入力に対し同じ結果が返されるとは限らない
なので静的変数の性質として「参照透過性があること」を持ってくるのは間違い
書き換え不能かどうかも静的変数の概念には直接関係しない
インスタンスごとに独立固有でなくインスタンス間で共有され、
インスタンス生成ごとに初期化されるのではなく、一度だけ初期化される、要するに状態が保持される
静的変数が関係する場合、常に同じ入力に対し同じ結果が返されるとは限らない
なので静的変数の性質として「参照透過性があること」を持ってくるのは間違い
書き換え不能かどうかも静的変数の概念には直接関係しない
それを言うとJSの場合はstaticな変数なんて存在しないけどな
staticとして宣言されたものはクラスオブジェクトのプロパティになるだけだから
staticとして宣言されたものはクラスオブジェクトのプロパティになるだけだから
クラスベースオブジェクト思考に毒されたやつは話を聞かない
唯一絶対の真理と思ってやがる
jsにclass構文なんか導入したせいで拍車がかかった
ちなみに拍車とはカウボーイのブーツのかかとについてるトゲトゲの車輪な
唯一絶対の真理と思ってやがる
jsにclass構文なんか導入したせいで拍車がかかった
ちなみに拍車とはカウボーイのブーツのかかとについてるトゲトゲの車輪な
「ある要素を、それ以外の要素がクリックされたら閉じる」
のような処理はどう実装するのがベストなのでしょうか？
モーダルウインドウでは半透明の黒幕を表示してそこでイベントを受けるというやり方を見ますが
他のコントロールへのイベントは生かしたままにしたいです
要素にtabindexを付けてフォーカスを持たせて、focusoutを検出したらいいのでは？
と思ってやってみたのですが、ブラウザ以外のアプリにタスク切り替えしても反応してしまいました
あとはdocumentに一時的なclickイベントリスナを付けるくらいしかなさそうですが
これだと他のイベントリスナでstopPropagationされたら反応しなくなると思います
つまり、考えついたどの方法にも何かしら問題があるのです・・
問題のない方法はないでしょうか？
のような処理はどう実装するのがベストなのでしょうか？
モーダルウインドウでは半透明の黒幕を表示してそこでイベントを受けるというやり方を見ますが
他のコントロールへのイベントは生かしたままにしたいです
要素にtabindexを付けてフォーカスを持たせて、focusoutを検出したらいいのでは？
と思ってやってみたのですが、ブラウザ以外のアプリにタスク切り替えしても反応してしまいました
あとはdocumentに一時的なclickイベントリスナを付けるくらいしかなさそうですが
これだと他のイベントリスナでstopPropagationされたら反応しなくなると思います
つまり、考えついたどの方法にも何かしら問題があるのです・・
問題のない方法はないでしょうか？
>>339の件ですが
stopPropagationされる可能性が少ないイベントリスナを使えばいいんじゃないかとひらめきました
クリックイベントはmousedownやclickで受けるのが普通なので、
これらはstopPropagationされる可能性がありますが
あまり使われることのないmouseupなら殺されることもないのではないかと。
試しにmousedownやclickをstopPropagationするコードを書いてみましたが
mouseupはちゃんとdocumentまで伝わってきました
これはいいのではないでしょうか？
もっと良い方法ありますか？
stopPropagationされる可能性が少ないイベントリスナを使えばいいんじゃないかとひらめきました
クリックイベントはmousedownやclickで受けるのが普通なので、
これらはstopPropagationされる可能性がありますが
あまり使われることのないmouseupなら殺されることもないのではないかと。
試しにmousedownやclickをstopPropagationするコードを書いてみましたが
mouseupはちゃんとdocumentまで伝わってきました
これはいいのではないでしょうか？
もっと良い方法ありますか？
>>340
組み込んだらうまく動きました
今まで、リスナでイベントを捕捉して処理をした時には
大抵の場合、とりあえずstopPropagationとpreventDefaultを両方実行していました
処理はもうしたんだから、他の要素はもうそれを知る必要がないだろう、
その方が負荷が下がっていいだろう、と。
が、イベントは一連の処理を開始するきっかけにもなれば、
一連の処理を終わらせるきっかけにもなるので、
「処理はもうしたから、他の要素はもう知る必要がないやろ」という態度は問題ですね
そうしなければならない理由がない限り、
処理を済ませたからといってイベントの伝播を止めるのは良くないのでしょう
組み込んだらうまく動きました
今まで、リスナでイベントを捕捉して処理をした時には
大抵の場合、とりあえずstopPropagationとpreventDefaultを両方実行していました
処理はもうしたんだから、他の要素はもうそれを知る必要がないだろう、
その方が負荷が下がっていいだろう、と。
が、イベントは一連の処理を開始するきっかけにもなれば、
一連の処理を終わらせるきっかけにもなるので、
「処理はもうしたから、他の要素はもう知る必要がないやろ」という態度は問題ですね
そうしなければならない理由がない限り、
処理を済ませたからといってイベントの伝播を止めるのは良くないのでしょう
>>335
バカ？
バカ？
JSでstaticといったら
class C{
static m(){}
}
みたいなのを指すけど
そこに高度な思想や概念なんて特に無いよ
class C{
static m(){}
}
みたいなのを指すけど
そこに高度な思想や概念なんて特に無いよ
>>343
名前がにてるんだから仲良くしろやカス
名前がにてるんだから仲良くしろやカス
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
トップメニューへ / →のくす牧場書庫について