ピタゴラス数

関数型言語だとピタゴラス数を宣言的に解ける。

Haskell, Elixir のコードを書いて動かした。

study_haskell/pythagoras.hs at master · kzono/study_haskell · GitHub

study_elixir/pythagorean.ex at master · kzono/study_elixir · GitHub

scala のコードを書いている途中で、時間切れ。

あと、rust で説いて見る予定。

 

pythonhaskell を真似てリスト内包表記が使えるので、同じく宣言的に解けるはず。

C++Java, C言語の解と比較してみたい。

Nucleo の開発環境

SystemWorkbench AC6 が一番細かいところに手が届く感じがしたので、それで作業しているが、L6470 のサンプルコードを検索すると Arduino のものが一番多くヒットする。mbed にも L6470 用のライブラリがあるらしい。どちらもお手軽な感じなので試してみたい。

Arduinoで割り込みは使えるのか?Mbedで割り込みは使えるのか?

STM32F401RE + L6470 + bipolar stepping motor

STMicro が提供するサンプルコードを探していたが、漸く発見!たぶん1週間以上探していた。

X-CUBE-SPN2

https://my.st.com/content/my_st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-spn2.html

これが  NUCLEO-F401RE + stepper motor drivers (L6470)  の組合せ。

 

  • X-CUBE-SPN1:NUCLEO-F401RE + L6474 
  • X-CUBE-SPN3:NUCLEO-F401RE  + powerSTEP01 device
  • X-CUBE-SPN4:NUCLEO-F401RE  +  L6206 for DC モータ
  • X-CUBE-SPN5:NUCLEO-F401RE  +   L6208

複合4節リンク

今日の学び。

嵌めあい

raise3D pro2 でプリントしてみたところ、穴 6.15mm , 軸 6.00mm だと隙間嵌めにならず、締り嵌めになってしまうことが分かった。

穴を大きくするか、軸を補足するか、あるいはその両方か、考えどころ。

軸は、今回軸の真ん中に3mmのネジ穴を開けるため、補足すると強度が心配。

ヒンジピン

  • 5mmはぶ厚すぎた。強度的にはおそらく3mm の厚さで十分。
  • ヒンジピンの直径は 6㎜ ではなく 5mm でも強度は十分っぽい。
  • M3のネジ穴を設計したつもりだったが、実際には M2.6 がぴったりで、M3ネジは全く入らなかった。
  • リンク部は穴6.00mm外周円 12.00mm だったが、一回り小さくでもよさそう。外周円 10.00mm, 穴 5.2mm ぐらいでどうだろうか。
  • ヒンジピンの長さが重要。リンクバーを重ねる順番によって、長さが変わる。ヒンジピンの鍔の部分の厚さをちゃんと考慮する必要がある。
  • ヒンジピンの6角穴だが、2.5 が全く入らなかった。2.0 だとスカスカだった。
  • ヒンジピン鍔部分の厚さをどうするか?厚さ2mmに抑えたいが、六角穴の深さは1.5mm で引っかかるのか?

見つけた。

六角穴付皿ボルト(皿キャップ)/よくわかる規格ねじ

ボルトの頭は平ネジにして、裏側をテーパーをつける。ヒンジピンの穴側にテーパーをつければ、ボルトの頭は出っ張ることはない!

 

リンク機構のバーの長さとリンク穴の位置

第1関節(指先部分)が曲がらない。手前の4節リンクはうまく機能しているが、指先側はうまく曲がらない。4説あるうちの2節のリンクバーの長さが少し長いことが原因のように思える。

 

マルチスレッド対応の圧縮コマンド

SDカードのイメージファイルを作成し、圧縮ファイルを作った。このとき、結構時間がかかった。システムモニタを見ていたところ、マルチコアにもかかわらず、1つかせいぜい2つのスレッドしか使われていなかった。そこで、マルチスレッド版の圧縮コマンドがないかぐぐったところ、やっぱりあった。(^^)

qiita.com

シングルスレッドなgzip だとこんな感じ。

$ time sudo dd if=/dev/sda bs=8M | gzip -c > sdcardimg_org.img.gz
1910+0 レコード入力
1910+0 レコード出力
16022241280 bytes (16 GB, 15 GiB) copied, 710.228 s, 22.6 MB/s

real 11m50.237s
user 4m30.003s
sys 0m13.834s

 これに対して、マルチスレッドの xz だと

$ time sudo dd if=/dev/sda bs=8M | pxz -c > sdcardimg_org.img.xz
1910+0 レコード入力
1910+0 レコード出力
16022241280 bytes (16 GB, 15 GiB) copied, 278.309 s, 57.6 MB/s

real 4m39.045s
user 78m52.949s
sys 0m40.581s

 と、約3倍の速度がでた!このときのシステムモニタの様子がこれ。

f:id:kzono:20190125202436p:plain

pxz マルチスレッドでの圧縮

 

Rust の REPL を Google さんが作っていた

jupyter-notebook の Rust 用カーネルを探していたら、なんと Google さんが開発して、公開していた。

github.com

qnighy.hatenablog.com

qiita.com

evcxr_jupyter というのが Rust 用 jupyter-notebook のカーネル

https://github.com/google/evcxr/blob/master/evcxr_jupyter/README.md

これで、Rustの勉強記録を jupyter-notebook で記録できる。楽しい!