関数電卓総合スレッドその8

1Nanashi_et_al.2017/11/25(土) 23:55:36.42
国内メーカー、海外メーカー問わず、関数電卓についてまったりと語り合うスレです。
タイトルは関数電卓総合スレッドですが、ポケコンやグラフ電卓も可とします。
また、煽り、粘着はスルー、AAのコピペは厳禁、とします。

前スレ
関数電卓総合スレッドその7
http://rio2016.2ch.net/test/read.cgi/rikei/1491278023/

712Nanashi_et_al.2018/08/15(水) 14:17:15.20
>>711
ミルズがチューリング賞受賞者ダイクストラの権威をうまく利用したってことだよね。
ダイクストラが構造化プログラミングを商標登録しなかったことをいいことにミルズに別の意味で使われてしまった。

しかし、>>703のリンク先の論文を読んでも分かるようにダイクストラの構造化プログラミングはちと難しすぎる。訳注だらけになっているのも仕方がない。
科学者ダイクストラの自己満足的なところをもう少し排除するべきだったような。

とは言え、ミルズのせいで科学的にプログラムの設計手法を研究する流れが断たれたのは悲しい限り。

713Nanashi_et_al.2018/08/15(水) 14:41:12.19
>>712
早速のレスありがとう

一言で言えばまあそういうことですね

> しかし、>>703のリンク先の論文を読んでも分かるようにダイクストラの構造化プログラミングはちと難しすぎる。訳注だらけになっているのも仕方がない。
> 科学者ダイクストラの自己満足的なところをもう少し排除するべきだったような。

Dijkstraの書いたものはその論文に限らず哲学的というか彼自身の「哲学」が色濃く滲み出ていて難しくて正しく理解し辛いのが多い
例えば、>>703の翻訳者は品切れで読めなかったそうだが、Hoare, Dahlと共著の“Structured Programming”の翻訳「構造化プログラミング」の
Dijkstraの論説(そのタイトルも「構造化プログラミング」)を読んでも判り辛かった記憶がある
それ以外のDijkstraの著書数冊もかつては翻訳が上と同じくサイエンス社から出ていて読んだが、どれもかなり読み辛く難しくて正しく理解できたと思えるまでには相当な時間がかかった

その点は、同じくTuring賞受賞者で上の本の共著者でもあるC. A. R. Hoareの書いたものとは大違いだね
HoareのCSPの本 “Communicating Sequential Processes” なんて説明の中で実務的な動機付けとかもあって読んでいてワクワクしてグングン引き込まれる感覚を覚えた
もしも並行プロセスとかに興味があってHoareの上の本は未読ならば時間を使っても読む価値は大いにあると思うよ、英語の原書なら恐らく今でも手に入るだろうし彼の英語は読み易い
(かつては確か丸善から翻訳が出ていて翻訳陣も信頼おける人たちだったけれど、まず確実に品切れだろうなあ)

714Nanashi_et_al.2018/08/15(水) 14:50:47.32
>豚の耳に念仏

715Nanashi_et_al.2018/08/15(水) 14:58:25.96
>>714
欧米人は太った人が多い

716Nanashi_et_al.2018/08/15(水) 15:04:32.53
>>715
白人は日本人と違って糖分への耐性が強いからね
日本人だと欧米人のデブ並みに太る前に糖尿病になって痩せてしまうケースが圧倒的に多い

717Nanashi_et_al.2018/08/15(水) 15:13:51.97
>>716
糖分耐性というよりは肥満耐性かと

718Nanashi_et_al.2018/08/15(水) 15:35:46.95
>>711
それでIBMは、PL/Iを開発したの?
(ついつい、素人目にはそれなら構造化プログラミング理論にそったプログラミング言語を作ってよってことに)

一般の商業プログラマは理論なんてどーでもいいんだよってスタンスなんでは?w
例えば昔の汎用機で富士通のマシンには無料でFortranコンパイラが付いてきたので、科学計算はもちろんのこと、リアルタイム処理までそれでやっていた。経理は流石にCOBOLとか使ったんだろうけど
与えられたもので何とかしろってことだから
構造化プログラミング理論なんて研究所で勝手にやってろ、但し、(殆ど宗教教義の様に)GO TO分は極力減らせと言われ続けた・・

>>706
Ti-BASICではループ内からGotoするのを繰り返しているとループ管理がオーバーフロー起こして予期せぬ異常終了の元になる
なので途中で脱出するにはループ終了条件を成立させてループ外で該当処理しなさいとユーザーズグループが勧告している(常識的テクニックらしい)

一方、CASIO BASICにはBreak文があるが、意図しないループ抜けのバグの元になる可能性あり

7197122018/08/15(水) 15:38:06.14
>>713
なるほど。
ダイクストラさんの文章は総じて難解なのですね。
ダイクストラさんがオランダ人なので英文が余計に難しくなっているのかも。

ホーアさんのことは知らなかったなあ。

>(かつては確か丸善から翻訳が出ていて翻訳陣も信頼おける人たちだったけれど、まず確実に品切れだろうなあ)

ここは日本語の不利なところ。
訳本が絶版になると読めなくなってしまう。

720Nanashi_et_al.2018/08/15(水) 15:57:44.54
>>718
PL/Iは単純に全部入りの言語を作っただけのような気がする。

721Nanashi_et_al.2018/08/15(水) 16:59:10.16
>>711
>Dijkstraの提唱した“structured programming”という標語だけ借りて中身はバカ向けに完全に換骨奪胎したのが
>Mills流の“structured programming=goto-less programming”という一種の運動

換骨奪胎は通常良い意味で使うから誤用では?
皮肉であえて換骨奪胎と書いているのかもしれないが

7227112018/08/15(水) 19:41:35.80
おっ、思いの外、色々とレスしてくれてますね、皮肉じゃなくて真面目な話、どうもありがとう

>>717
確かにその言い方のほうが正しいですね、間違いを指摘してくれてありがとうございます


>>718
> それでIBMは、PL/Iを開発したの?

いえPL/Iの登場は1964年なのでDijkstraの提唱(1968年のNATO主催の会議)よりも前ですね

基本的には>>720さんが指摘しているように当時の3大言語、FORTRAN, COBOL, ALGOL(この時代の言語名はやはり大文字だけで書かないと
雰囲気が出ない ;-p)を全部カバーしちゃえという発想で作られたのがPL/Iですが、Dijkstraとの関係は無いにしてもそういう面もあるでしょうね

そもそもPL/IはIBMの開発部門や研究所でなくSHAREというIBMのユーザーグループが主導権を握って開発された言語ですし

実際、あまり現実の商用プログラム開発には使われなかったALGOLは別にして、当時のFORTRANやCOBOLの文法は貧弱で
制御構造はジャンプ(つまりGOTO文)を多用しないと作れなかったですから、商用プログラム開発にGOTOを必要としない
ALGOLのような豊かな制御構造を持つプログラミング言語を使いたいという目論みがユーザーサイドにあったでしょう

例えば昔のFORTRANの論理IF文は条件の成立時に実行すべき文を1つだけ書けるのみでELSE相当の構文はFORTRAN 77まで存在せず
従って、通常の if 〜 then 〜 else 〜 endif の制御構造を当時のFORTRANで作ろうとするとGOTO文を2つ使う必要があるという悲惨さでしたからね
こんな現状を何とかしたいというのは大先生が難しいことを言わなくても普段からプログラムを書いている人間の少なからずは思ってたことでしょう


>>719
Hoareの英語は下手な日本語の本よりずっと読みやすいから原書で読むと良いですよ


>>721
> 換骨奪胎は通常良い意味で使うから誤用では?
> 皮肉であえて換骨奪胎と書いているのかもしれないが

まあバカな凡俗プログラマでも少しは御利益に与れるようにしてくれたという意味(それこそ皮肉かw)も込めてそう書きました
要するにMillsがやったのは嘘も方便というやつの一例ですね

723Nanashi_et_al.2018/08/15(水) 20:49:37.28
>>718
>Ti-BASICではループ内からGotoするのを繰り返しているとループ管理がオーバーフロー起こして予期せぬ異常終了の元になる
>なので途中で脱出するにはループ終了条件を成立させてループ外で該当処理しなさいとユーザーズグループが勧告している(常識的テクニックらしい)
>
>一方、CASIO BASICにはBreak文があるが、意図しないループ抜けのバグの元になる可能性あり

そういう問題があるとは知らなかった。
電卓の言語って実装がいい加減なのかな?

724Nanashi_et_al.2018/08/15(水) 22:53:41.20
>>723
Ti-BASICはというよりCASIO BASIC※は代入記号の直前の閉じ括弧や文字列を表すダブルクォーテーションが行末の場合省略できる
マニュアルにも閉じ括弧は省略可能と明記されてる
メモリ節約の為なんだろうね
また、閉じ括弧ない方がいくぶん実行速度速い

また、2 * X は、2Xと乗算に限り省略可能
(変数X)

ブログに掲載されたプログラムリストに閉じ括弧あると、わざわざ「閉じ括弧不要」とコメント付くほどw

※CASIO BASICとTi-BASICは構文が似ており、多分どちらかがパクったのだと思う
だから相互で移植が簡単
Ti-BASICは有志が作ったコンパイラやPythonのソースリストをTi-BASICへコンバートするプログラムも存在する
他にはZ80や68000のアセンブラが使用可能
確かTi関数電卓用Cコンパイラもあったはず

一方、CASIOはPythonをフランス版で先行搭載、有志が作ったPython風構文備えたCASをアドインとして使える
また日立SHのアセンブラが利用可能

PythonからHP50sのRPLへのコンバートプログラムもあり

725Nanashi_et_al.2018/08/15(水) 23:09:52.36
>>724
>HP50s

なにその機種w

726Nanashi_et_al.2018/08/15(水) 23:14:30.47
>>724
>>723は言語の問題について語っているのに話が噛み合っていないぞ?
あんた e-Gadget の管理人か?空気読めないところが似ているような。
違っていたらスマヌ。

727Nanashi_et_al.2018/08/16(木) 02:15:10.92
>>724
上の人も言っているようにレスの内容が>>723と全然噛み合っていない
どういうつもりで書いたんだ?

728Nanashi_et_al.2018/08/16(木) 11:49:05.62
>>724
自分の知識をひけらかしたいだけで周囲が見えていない感じ。しかも他のスレッドでも見たことのあることを書いている。

729Nanashi_et_al.2018/08/16(木) 11:57:27.56
人の話を聞かないで、聞いてもいない自分の話を
ペラペラ喋りだす人

それを指摘しても、
人の話を聞かないから指摘自体がムダなんだよ

730Nanashi_et_al.2018/08/16(木) 13:13:31.39
>>704
「e-Gadget - プログラム関数電卓」のことじゃね?
e-Gadget のURLはNGワードなので貼れないが、こんなことを書いている

>プログラミング経験者だからこそ、Casio Basic はよくできていると思います。
>構造化プログラミングが可能な高級言語です。

完全に構造化定理と構造化プログラミングを勘違いしている典型例
e-Gadget の管理人は「Casio Basic は構造化プログラミング可能」とブログ全体で連呼している

もっとも構造化定理と構造化プログラミングの混同はこの人に限らない

ASCII.jpデジタル用語辞典やデジタル大辞泉ですら勘違いしている
https://kotobank.jp/word/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-3287

呆れたことに北海道大学ですら誤解している(構造化プログラミングと構造化定理を同一視している)
http://kussharo.complex.eng.hokudai.ac.jp/‾kurihara/classes/SE/02-strprogam.pdf

731Nanashi_et_al.2018/08/16(木) 14:16:40.52
そもそも構造化定理って可能かどうかということであって、見やすさとか読みやすさとは全く関係ないものでは

732Nanashi_et_al.2018/08/16(木) 14:25:08.53
>>731
確かに構造化定理はパターンに当てはめるってだけ
しかし、gotoを少なくしたらバカなプログラマーでも多少はましなコードが書けるのも事実

733Nanashi_et_al.2018/08/16(木) 16:23:37.57
>>726
ここ関数電卓のスレじゃん
関数電卓で構造化プログラミング理論話そうってのは無理ありすぎでしょう
構造化定理すら満たしてない言語仕様なんだよ?
分かってて理論論じるのもいいけど、関数電卓スレではねえ・・
専用スレ立てた方がいいよ

関数電卓に高級言語搭載するのも可能だろうけど、関数電卓の意義考えたら簡易言語になるのは仕方ないこと
知識ひけらかすと言ったひといるが、分かってるよね?
複雑な式をどうプログラミングするかって時に構造化プログラミング理論を考慮するのもいいが結局は実行速度との兼ね合いだ
基本インタプリタなのだから

>>728
それは、ボクが書いたものだw
同じような内容のスレが二つあるからこんなことが起きるのだ
板を跨ぐ引用もねぇ


そもそもはCASIO BASICは構造化プログラミング出来ます発言に対する認識の誤りを正した論文を紹介してくれて、補足説明してくれただけ

でも、簡易言語に理論もなにもないと思う
初期のプログラマブル関数電卓の痕跡を残してるのが現在のプログラミング可能な関数電卓
未だにXレジスタを意識した言語仕様なのだから
また、知識ひけらかすと言われるが、前回の計算結果であるAnsを積極利用しましょうってスタンスで理論もクソもない
(Ansこそ究極の抽象化か? 実数、複素数、リストなんでもありなんだから)

HP primeのPPLなら理論を考慮出来るかもだけど、RPN(HP社)はスレチだからなあ

734Nanashi_et_al.2018/08/16(木) 16:26:34.17
>>733
滅茶苦茶な文章だなあ
アスペルガー?

735Nanashi_et_al.2018/08/16(木) 16:35:54.58
理系全般だからこそ高尚な理論論じたいんだろうけど
それなら、情報学が適切だろう

736Nanashi_et_al.2018/08/16(木) 16:39:36.20
>>734
もしアスペルガーだったとして、どうだというんだ?
悪いことなのか?
社会から排除されるべき存在なのか?
僕にはヘイトスピーチにしか聞こえないが

737Nanashi_et_al.2018/08/16(木) 16:41:43.03
つーか CASIO BASIC が構造化プログラミングできないのは明確だろうに。
>>703のリンク先に分かりやすく書かれている。

e-Gadget の人は構造化定理(goto less)のことを構造化プログラミングと誤解しているようなことを明確に書いている。
確かに CASIO BASIC はIF文やFOR文を使えば構造化定理は満たせる。

738Nanashi_et_al.2018/08/16(木) 17:10:11.78
しかしそもそも >>703 のリンク先これ正しいのか?
およそ「定理」と呼べそうもないものを「定理」だと言っているが。
Mills は単に Böhm-Jacopini theorem を引用して使っただけで、
構造化定理を考案したわけではないと思うが。

739Nanashi_et_al.2018/08/16(木) 17:17:36.72
>>738
Mills は On folk theorem という論文で構造化定理を作ったと自称している。

740Nanashi_et_al.2018/08/16(木) 17:19:48.29
>>739
訂正。On Folk Theorems だった。

詳しくは英語版Wikipediaの Structured program theorem を読むこと!!!

741Nanashi_et_al.2018/08/16(木) 17:24:49.10
>>738
>Mills は単に Böhm-Jacopini theorem を引用して使っただけで、
>構造化定理を考案したわけではないと思うが。

ベーム・ヤコピーニの定理はフローチャートの書き方
ミルズはそれをプログラムの書き方に変えた

742Nanashi_et_al.2018/08/16(木) 17:28:49.99
>>738
>およそ「定理」と呼べそうもないものを「定理」だと言っているが。

あのー。構造化定理という言葉が明確に存在するわけでしてそれを否定してどうするの?バカなの?

743Nanashi_et_al.2018/08/16(木) 20:35:59.55
>>738
何を定理とするのかはお前が決めることなのか?
構造化定理は構造化定理であって、それは定理だと昔から決まっている。

744Nanashi_et_al.2018/08/16(木) 21:14:03.32
「定理」は言ったもん勝ちだからね。
誰かがそれは定理では無いと証明するまでは定理。

745Nanashi_et_al.2018/08/16(木) 21:28:01.37
愚者論に負けず、か

746Nanashi_et_al.2018/08/16(木) 22:46:59.67
プログラム電卓に高級言語は似合わない。
低級でマシンディペンデントなコードが相応しい。

747Nanashi_et_al.2018/08/16(木) 23:16:52.64
>>746
つまり、キーストローク言語が良いと?

748Nanashi_et_al.2018/08/17(金) 00:23:34.12
確かにe-Gadgetは構造化定理と構造化プログラミングを盛大に誤解しているようだけど、
関数電卓用のソフトウェアを幾つも公開したり、関数電卓の技術情報を発信したりしているわけだから、
こんな掲示板で揚げ足取りしかしてない俺らみたいな連中よりは、はるかに国内外の関数電卓のコミュニティに貢献しているよね
何だか虚しくなる

749Nanashi_et_al.2018/08/17(金) 00:27:30.18
>>748
e-Gadget は、国外はともかく国内での貢献は間違いなくある。
我々もないわけではないぞ

750Nanashi_et_al.2018/08/17(金) 01:15:23.66
>>749
電卓のサイトは総じてマイナーなのでここの住民が広める役目は大きい

751Nanashi_et_al.2018/08/17(金) 04:38:45.63
ディスる方がコミュ障だと厄介だわ

752Nanashi_et_al.2018/08/17(金) 09:34:00.75
>>751
誰をディスるんだい?

753Nanashi_et_al.2018/08/17(金) 12:02:30.52
>>750
確かに電卓を扱っているブログやサイトは総じてマイナー
それらを繋げる5chの役目は大きい

754Nanashi_et_al.2018/08/17(金) 15:04:46.75
>>751
またコミュ障とか言ったりする

755Nanashi_et_al.2018/08/17(金) 18:45:38.58
チャックが空いていたら
こっそり教えてあげるのが紳士だよ

756Nanashi_et_al.2018/08/17(金) 20:28:30.00
口に出しちゃいけない
ゼスチャーで

「おじいさん、ポロリしてるよ」

757Nanashi_et_al.2018/08/17(金) 23:45:22.69
>>747
グラフ関数電卓でキーストロークは流石にキツイ

DM42はグラフィック描画領域を大幅に拡張してるけど、キーストローク方式なんだよねw
完全に趣味のマシン


プログラム組んで楽しんでる人達は、やはり手書きノートやPC上のtext形式でプログラムリストの保存とかやってるんでしょ?
PC用のプログラムソース転送アプリ対応ならいいけど、プリントアウトも出来ないなら手書き(手打ち)で残すしかないから
それだとキーストローク方式は余計に辛いな

758Nanashi_et_al.2018/08/18(土) 17:04:48.15
>>757
確かに最初のグラフ電卓 fx-7000G もキーストローク言語ではなかった。
キーストローク言語風のテキスト言語という感じだろうか。

759Nanashi_et_al.2018/08/18(土) 21:06:13.35
>>758
8bit時代に流行った構造化アセンブラっぽい感じ
或いは、MZ-80K用BASIC風アセンブラw
アセンブラなのにFORやIF、PRINT文が使えた

760Nanashi_et_al.2018/08/18(土) 23:50:30.73
BASE-80ですな

761Nanashi_et_al.2018/08/18(土) 23:58:01.25
>>759
fx-7000G のプログラミング言語はFORとかIFがなかった。
>>758の言うように条件ジャンプ命令などがキーストローク言語を彷彿とさせるものが多かった。

762Nanashi_et_al.2018/08/19(日) 01:24:16.84
構造化というのはキーストロークとは関係ないところにあるのだが

新着レスの表示
レスを投稿する