X
トップページ⇒理系全般
1002コメント364KB
関数電卓総合スレッドその８
■ このスレッドは過去ログ倉庫に格納されています
0001Nanashi_et_al.
垢版 |
2017/11/25(土) 23:55:36.42
国内メーカー、海外メーカー問わず、関数電卓についてまったりと語り合うスレです。
タイトルは関数電卓総合スレッドですが、ポケコンやグラフ電卓も可とします。
また、煽り、粘着はスルー、AAのコピペは厳禁、とします。

前スレ
関数電卓総合スレッドその７
http://rio2016.2ch.net/test/read.cgi/rikei/1491278023/
0706Nanashi_et_al.
垢版 |
2018/08/15(水) 02:59:31.76
ひどいBASICとかありましたからね
FOR I ... FOR J ... NEXT ... NEXT
みたいな2重ループの内側からGOTOで脱出すると変数の対応がおかしくなって外側のNEXTでJが増える奴とか
0707Nanashi_et_al.
垢版 |
2018/08/15(水) 09:03:55.24
脱出が済んだらループ内にgotoして戻らなければならない。そのチェックはプログラマがしなければならない
0708Nanashi_et_al.
垢版 |
2018/08/15(水) 10:04:49.04
>>705
>その構造化定理ですら、最近は適切なgoto文ならば複雑化するブロック構造より分かりやすいので排除しない方向もあるそうだけど

当時もダイクストラがgoto文の機械的な排除は好ましくないと言っていたのだが。

>COBOLは内部形式まで指定できるので、その意味では構造化プログラミングでは無いのかな？
>Cの構造体も同様に
>それとも、もっと低レベルな話しなんだろうか

COBOLは勉強したことがないので分からない。
Cは構造体を使ってオブジェクト指向風のプログラミングは一応可能だし、構造化プログラミング可能と言われることは十分できるのでは？

>書かれた年代が古過ぎて、今時ALGOLなんて名前は知ってても使ったことあるひとなんて少数派だろ

つーか、ALGOLなんてC言語と大差ないような気がするのだが。

>しかし、この手の論文に引き合いに出されたCASIO BASICは気の毒だ

電卓用の簡易言語ですからねえ。
PCの言語みたいなまともな実装をされていないし。
「CASIO BASICが構造化プログラミング可能」という人がいるのならそれは違うだろと思うけど。
0710Nanashi_et_al.
垢版 |
2018/08/15(水) 13:56:56.77
>>704
だいたい想像はつくのだが、書かないでおこう
0711Nanashi_et_al.
垢版 |
2018/08/15(水) 13:57:54.66
>>705
構造化定理は逐次的プログラム（つまり並行して動作し得る複数のプロセス・スレッド・タスクが存在せず単一のプログラムカウンタで済むプログラム）について
３基本構造（順接、分岐、反復）の表現能力に関する数学的事実を述べた定理に過ぎず、書かれるプログラムの信頼性とか読み易さ・理解し易さとは無関係

それをさも関係があるように錯覚させたのが実務畑のHarlan D. Millsの狡猾なところであり、またある意味では有能なところでもある
つまり、多くのプログラマはバカだから単純なクライテリアでなければ理解できないから、バカ向けの単純なクライテリアを与えてやった、これが確信犯Millsの功績であり罪過でもある
言い換えればDijkstraの高尚な“structured programming”の精神などはバカな大衆プログラマには理解不能で豚の耳に念仏だとMillsは悟っていたか
Dijkstraの提唱した“structured programming”という標語だけ借りて中身はバカ向けに完全に換骨奪胎したのがMills流の“structured programming＝goto-less programming”という一種の運動
そして、この運動を権威づけるために使ったのが単なる表現定理に過ぎない構造化定理だったわけだ
つまり「この運動が正しいことはちゃんと数学で保証されてるんだよ！」って権威づけをしたわけね

アカデミアの世界にずっと身を置いていたDijkstraとは違い、MillsはIBMの研究員として開発現場の指導なども行って現場プログラマのほとんどはバカばかりだと嫌というほど思い知らされていたはず
だからこそ「正しいが難し過ぎてバカには正しく理解するのは不可能」なDijkstra流の高尚な“structured programming”からキャッチフレーズの“structured programming”だけ流用して
「正しくないがバカにも理解し実行できて多少は効果が見込める」Mills流の低俗な“structured programming”を広めたのだよ

そしてMichael Jacksonパパが構造化定理に基づいて事務処理向けのプログラミングを入出力データ構造の対応から３基本構造を用いる形で系統的に導出する手法として
JSP (Jackson Structured Programming) を提案して大人気を博したことでMills流の低俗な“structured programming”運動は一層の盛り上がりを見せたというわけ
0712Nanashi_et_al.
垢版 |
2018/08/15(水) 14:17:15.20
>>711
ミルズがチューリング賞受賞者ダイクストラの権威をうまく利用したってことだよね。
ダイクストラが構造化プログラミングを商標登録しなかったことをいいことにミルズに別の意味で使われてしまった。

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

とは言え、ミルズのせいで科学的にプログラムの設計手法を研究する流れが断たれたのは悲しい限り。
0713Nanashi_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の上の本は未読ならば時間を使っても読む価値は大いにあると思うよ、英語の原書なら恐らく今でも手に入るだろうし彼の英語は読み易い
（かつては確か丸善から翻訳が出ていて翻訳陣も信頼おける人たちだったけれど、まず確実に品切れだろうなあ）
0716Nanashi_et_al.
垢版 |
2018/08/15(水) 15:04:32.53
>>715
白人は日本人と違って糖分への耐性が強いからね
日本人だと欧米人のデブ並みに太る前に糖尿病になって痩せてしまうケースが圧倒的に多い
0718Nanashi_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文があるが、意図しないループ抜けのバグの元になる可能性あり
0719712
垢版 |
2018/08/15(水) 15:38:06.14
>>713
なるほど。
ダイクストラさんの文章は総じて難解なのですね。
ダイクストラさんがオランダ人なので英文が余計に難しくなっているのかも。

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

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

ここは日本語の不利なところ。
訳本が絶版になると読めなくなってしまう。
0720Nanashi_et_al.
垢版 |
2018/08/15(水) 15:57:44.54
>>718
PL/Iは単純に全部入りの言語を作っただけのような気がする。
0721Nanashi_et_al.
垢版 |
2018/08/15(水) 16:59:10.16
>>711
>Dijkstraの提唱した“structured programming”という標語だけ借りて中身はバカ向けに完全に換骨奪胎したのが
>Mills流の“structured programming＝goto-less programming”という一種の運動

換骨奪胎は通常良い意味で使うから誤用では？
皮肉であえて換骨奪胎と書いているのかもしれないが
0722711
垢版 |
2018/08/15(水) 19:41:35.80
おっ、思いの外、色々とレスしてくれてますね、皮肉じゃなくて真面目な話、どうもありがとう

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


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

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

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

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

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

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


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


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

まあバカな凡俗プログラマでも少しは御利益に与れるようにしてくれたという意味（それこそ皮肉かｗ）も込めてそう書きました
要するにMillsがやったのは嘘も方便というやつの一例ですね
0723Nanashi_et_al.
垢版 |
2018/08/15(水) 20:49:37.28
>>718
>Ti-BASICではループ内からGotoするのを繰り返しているとループ管理がオーバーフロー起こして予期せぬ異常終了の元になる
>なので途中で脱出するにはループ終了条件を成立させてループ外で該当処理しなさいとユーザーズグループが勧告している(常識的テクニックらしい)
>
>一方、CASIO BASICにはBreak文があるが、意図しないループ抜けのバグの元になる可能性あり

そういう問題があるとは知らなかった。
電卓の言語って実装がいい加減なのかな？
0724Nanashi_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へのコンバートプログラムもあり
0726Nanashi_et_al.
垢版 |
2018/08/15(水) 23:14:30.47
>>724
>>723は言語の問題について語っているのに話が噛み合っていないぞ？
あんた e-Gadget の管理人か？空気読めないところが似ているような。
違っていたらスマヌ。
0727Nanashi_et_al.
垢版 |
2018/08/16(木) 02:15:10.92
>>724
上の人も言っているようにレスの内容が>>723と全然噛み合っていない
どういうつもりで書いたんだ？
0728Nanashi_et_al.
垢版 |
2018/08/16(木) 11:49:05.62
>>724
自分の知識をひけらかしたいだけで周囲が見えていない感じ。しかも他のスレッドでも見たことのあることを書いている。
0729Nanashi_et_al.
垢版 |
2018/08/16(木) 11:57:27.56
人の話を聞かないで、聞いてもいない自分の話を
ペラペラ喋りだす人

それを指摘しても、
人の話を聞かないから指摘自体がムダなんだよ
0730Nanashi_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/&;#8254;kurihara/classes/SE/02-strprogam.pdf
0731Nanashi_et_al.
垢版 |
2018/08/16(木) 14:16:40.52
そもそも構造化定理って可能かどうかということであって、見やすさとか読みやすさとは全く関係ないものでは
0732Nanashi_et_al.
垢版 |
2018/08/16(木) 14:25:08.53
>>731
確かに構造化定理はパターンに当てはめるってだけ
しかし、gotoを少なくしたらバカなプログラマーでも多少はましなコードが書けるのも事実
0733Nanashi_et_al.
垢版 |
2018/08/16(木) 16:23:37.57
>>726
ここ関数電卓のスレじゃん
関数電卓で構造化プログラミング理論話そうってのは無理ありすぎでしょう
構造化定理すら満たしてない言語仕様なんだよ？
分かってて理論論じるのもいいけど、関数電卓スレではねえ・・
専用スレ立てた方がいいよ

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

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


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

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

HP primeのPPLなら理論を考慮出来るかもだけど、RPN(HP社)はスレチだからなあ
0735Nanashi_et_al.
垢版 |
2018/08/16(木) 16:35:54.58
理系全般だからこそ高尚な理論論じたいんだろうけど
それなら、情報学が適切だろう
0736Nanashi_et_al.
垢版 |
2018/08/16(木) 16:39:36.20
>>734
もしアスペルガーだったとして、どうだというんだ？
悪いことなのか？
社会から排除されるべき存在なのか？
僕にはヘイトスピーチにしか聞こえないが
0737Nanashi_et_al.
垢版 |
2018/08/16(木) 16:41:43.03
つーか CASIO BASIC が構造化プログラミングできないのは明確だろうに。
>>703のリンク先に分かりやすく書かれている。

e-Gadget の人は構造化定理（goto less）のことを構造化プログラミングと誤解しているようなことを明確に書いている。
確かに CASIO BASIC はIF文やFOR文を使えば構造化定理は満たせる。
0738Nanashi_et_al.
垢版 |
2018/08/16(木) 17:10:11.78
しかしそもそも >>703 のリンク先これ正しいのか？
およそ「定理」と呼べそうもないものを「定理」だと言っているが。
Mills は単に Böhm-Jacopini theorem を引用して使っただけで、
構造化定理を考案したわけではないと思うが。
0739Nanashi_et_al.
垢版 |
2018/08/16(木) 17:17:36.72
>>738
Mills は On folk theorem という論文で構造化定理を作ったと自称している。
0740Nanashi_et_al.
垢版 |
2018/08/16(木) 17:19:48.29
>>739
訂正。On Folk Theorems だった。

詳しくは英語版Wikipediaの Structured program theorem を読むこと！！！
0741Nanashi_et_al.
垢版 |
2018/08/16(木) 17:24:49.10
>>738
>Mills は単に Böhm-Jacopini theorem を引用して使っただけで、
>構造化定理を考案したわけではないと思うが。

ベーム・ヤコピーニの定理はフローチャートの書き方
ミルズはそれをプログラムの書き方に変えた
0742Nanashi_et_al.
垢版 |
2018/08/16(木) 17:28:49.99
>>738
>およそ「定理」と呼べそうもないものを「定理」だと言っているが。

あのー。構造化定理という言葉が明確に存在するわけでしてそれを否定してどうするの？バカなの？
0743Nanashi_et_al.
垢版 |
2018/08/16(木) 20:35:59.55
>>738
何を定理とするのかはお前が決めることなのか？
構造化定理は構造化定理であって、それは定理だと昔から決まっている。
0744Nanashi_et_al.
垢版 |
2018/08/16(木) 21:14:03.32
「定理」は言ったもん勝ちだからね。
誰かがそれは定理では無いと証明するまでは定理。
0745Nanashi_et_al.
垢版 |
2018/08/16(木) 21:28:01.37
愚者論に負けず、か
0746Nanashi_et_al.
垢版 |
2018/08/16(木) 22:46:59.67
プログラム電卓に高級言語は似合わない。
低級でマシンディペンデントなコードが相応しい。
0748Nanashi_et_al.
垢版 |
2018/08/17(金) 00:23:34.12
確かにe-Gadgetは構造化定理と構造化プログラミングを盛大に誤解しているようだけど、
関数電卓用のソフトウェアを幾つも公開したり、関数電卓の技術情報を発信したりしているわけだから、
こんな掲示板で揚げ足取りしかしてない俺らみたいな連中よりは、はるかに国内外の関数電卓のコミュニティに貢献しているよね
何だか虚しくなる
0749Nanashi_et_al.
垢版 |
2018/08/17(金) 00:27:30.18
>>748
e-Gadget は、国外はともかく国内での貢献は間違いなくある。
我々もないわけではないぞ
0750Nanashi_et_al.
垢版 |
2018/08/17(金) 01:15:23.66
>>749
電卓のサイトは総じてマイナーなのでここの住民が広める役目は大きい
0751Nanashi_et_al.
垢版 |
2018/08/17(金) 04:38:45.63
ディスる方がコミュ障だと厄介だわ
0753Nanashi_et_al.
垢版 |
2018/08/17(金) 12:02:30.52
>>750
確かに電卓を扱っているブログやサイトは総じてマイナー
それらを繋げる5chの役目は大きい
0755Nanashi_et_al.
垢版 |
2018/08/17(金) 18:45:38.58
チャックが空いていたら
こっそり教えてあげるのが紳士だよ
0756Nanashi_et_al.
垢版 |
2018/08/17(金) 20:28:30.00
口に出しちゃいけない
ゼスチャーで

「おじいさん、ポロリしてるよ」
0757Nanashi_et_al.
垢版 |
2018/08/17(金) 23:45:22.69
>>747
グラフ関数電卓でキーストロークは流石にキツイ

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


プログラム組んで楽しんでる人達は、やはり手書きノートやPC上のtext形式でプログラムリストの保存とかやってるんでしょ？
PC用のプログラムソース転送アプリ対応ならいいけど、プリントアウトも出来ないなら手書き(手打ち)で残すしかないから
それだとキーストローク方式は余計に辛いな
0758Nanashi_et_al.
垢版 |
2018/08/18(土) 17:04:48.15
>>757
確かに最初のグラフ電卓 fx-7000G もキーストローク言語ではなかった。
キーストローク言語風のテキスト言語という感じだろうか。
0759Nanashi_et_al.
垢版 |
2018/08/18(土) 21:06:13.35
>>758
8bit時代に流行った構造化アセンブラっぽい感じ
或いは、MZ-80K用BASIC風アセンブラw
アセンブラなのにFORやIF、PRINT文が使えた
0761Nanashi_et_al.
垢版 |
2018/08/18(土) 23:58:01.25
>>759
fx-7000G のプログラミング言語はFORとかIFがなかった。
>>758の言うように条件ジャンプ命令などがキーストローク言語を彷彿とさせるものが多かった。
0762Nanashi_et_al.
垢版 |
2018/08/19(日) 01:24:16.84
構造化というのはキーストロークとは関係ないところにあるのだが
0763Nanashi_et_al.
垢版 |
2018/08/19(日) 06:06:53.28
>>761
>>762
FORやIFはマクロと捉えれば、キーストローク式ともいえる
一連のコマンドの並びをグループ化して抽象化したのがFORやIF
マシン語になればブランチ命令ばかりになるのだから
構造化プログラミングというのはこの様な低レベルな抽象化とデータ構造の抽象化という高レベルな抽象化を組み合わせたものだと思うんだけど根本的に間違ってる？

fx-7000Gはプログラムエリアが少なく、グラフ式の手続きをプログラム化する程度しか想定してなかったからアセンブラレベルの言語仕様で事足りたんだと思う
0764Nanashi_et_al.
垢版 |
2018/08/20(月) 00:51:38.26
聴いてると昔のマシン語・機械語エンビロンメントってなんかすごいw
今の小学校ではタブレットで簡易プログラミングを学び
工業高校・高専・工業系専修学校・工科大学では教室のオンライン端末や貸し出しノーパソ、個人のPCで
MS OFFICEのマクロ中心にいろんなプログラミングが百花繚乱だね
関数電卓にももちろん実習や現場での大事な役割はあって不滅だけどね
0765Nanashi_et_al.
垢版 |
2018/08/20(月) 00:59:57.10
>>763
>構造化プログラミングというのはこの様な低レベルな抽象化と
>データ構造の抽象化という高レベルな抽象化を組み合わせたものだと思うんだけど根本的に間違ってる？

構造化プログラミングの段階的抽象化の考えからすると、低レベルから高レベルまでの全てが抽象化の対象になる。
0766Nanashi_et_al.
垢版 |
2018/08/22(水) 01:21:08.64
自称専門家が構造化を偉そうに述べててウゼーなあ
0767Nanashi_et_al.
垢版 |
2018/08/26(日) 12:30:52.61
関数電卓って映画やドラマ、アニメではなかなか見かけなくて
某サイトで紹介されていたロケットガールのHP35だけなのかな？
ノーパソとスマホとタブレットの時代だから出演者が関数電卓を手に持つシーンって皆無だね
0768Nanashi_et_al.
垢版 |
2018/08/26(日) 21:38:24.88
>>767
関数電卓じゃないけど・・・
映画「アポロ１３」で、爆発事故の報告を聞いたエンジニアが、計算尺を使って
軌道計算を始めるシーンが印象に残ってる
0769Nanashi_et_al.
垢版 |
2018/08/26(日) 22:42:55.00
計算尺ってコンピュータの登場前は原発とかの設計にも使われるほど万能だったらしいね
0770Nanashi_et_al.
垢版 |
2018/08/26(日) 22:51:42.93
ドリームっていうNASAで計算係として働く黒人女性の活躍描いた映画では
IBMのメインフレームも出てくるが
それが導入されるまでは卓上の歯車式加算器で計算するシーンが出てくる
歯車式加算器は機械式レジスタとほぼ同じ機構

アポロ13号のアクシデント描いたアポロ13なら
HP41cx 出てきてもおかしくないんだけど
気が付かなかったな

2001年宇宙の旅の続編「2010」では一般の普通電卓がディスカバリー号のHAL9000をシャットダウンする起動スイッチとして出てきたが、関数電卓は出てきてないな
2001年でタブレット端末出てきてるから、もう関数電卓の出る幕ないんだろうw

映画制作スタッフは関数電卓の存在を知らないのかも知れない
0771Nanashi_et_al.
垢版 |
2018/08/26(日) 23:02:56.72
『NUMBERS』という海外ドラマのシーズン1で、主人公の数学者がhp33sを使ってるシーンがあったな
向こうで放送されたのが2005年らしいから、まだ35sは存在してない
0772Nanashi_et_al.
垢版 |
2018/08/26(日) 23:40:51.68
ハリウッドのスタッフも大学でTIやHPの関数電卓を全員使ってたはずだけど印象に残ってないのかもしれないね
0774Nanashi_et_al.
垢版 |
2018/08/27(月) 14:01:50.17
>>773
あ、そうだったのか！
ISSには何を持ち込んでるんだろ
0776Nanashi_et_al.
垢版 |
2018/08/27(月) 14:21:17.74
>>772
日本のドラマなんてPCといいながらワープロ専用機※置いたり、時代遅れな機種置いてたりしてるから
32bit機全盛の頃にPET2001が小道具に使われてたのを観たことある
電卓なんて経理の小道具くらいしか


※新宿署公安課の警部から事情聴取受けた時、警部はワープロ専用機で調書作成してた
部屋から出ようとした時捜査から帰ってきた刑事達から容疑者見るような目付きで睨まれたのが悔しい
机の上にはショットガン(押収品)が無造作に置かれてたし
捜査協力費として5000円くれたから良かったけど
0778Nanashi_et_al.
垢版 |
2018/08/27(月) 23:59:13.96
ThinkPadって、レボノだものな
それなら、HPにするんじゃない？
0779Nanashi_et_al.
垢版 |
2018/08/28(火) 06:10:42.42
中国は国際宇宙ステーションに参加を申し込んで断られているので、ThinkPadはあり得ない。
0781Nanashi_et_al.
垢版 |
2018/08/28(火) 21:05:47.91
レノボの宣伝のために単独で打ち上げた天宮に持ち込んでそうなイメージ
天宮はハリウッド映画でもVIP級の活躍をさせてもらってたっけ
世界中の関数電卓のほとんどの生産を請け負ってるしすごい国かもね
(花火のように墜落したのはご愛嬌)
0782Nanashi_et_al.
垢版 |
2018/08/28(火) 22:41:23.93
「きぼう」にはV70
まさかFC-9801じゃないよね

君津にあった衛星管制センターのNECの地上設備はFC-9801が使われていた
それ以外は富士通のメインフレーム2セットでシステム全体を二重化してた

二重化の自動切り替え試験は大迫力だったな
主システムが電源断(CEが人為的に)すると
ドーンという音と共に専用の沢山の蓄電池からのバッテリー駆動で副システムがスタンバイ状態から復帰
その間、僅か数秒
0784Nanashi_et_al.
垢版 |
2018/08/30(木) 00:17:25.66
売却される前は日本IBMが開発したThinkPadだね
ただ中国に売却後は流石に変更してるだろう
0786Nanashi_et_al.
垢版 |
2018/08/30(木) 08:11:08.86
>>785
Pentium MMXの頃なら売却される前じゃん
1990年代後半のCPU
0787Nanashi_et_al.
垢版 |
2018/08/30(木) 12:10:04.46
>>784の文章だと、「今はもうThinkPadを一切使ってない」という意味にも取れるんだが
0788Nanashi_et_al.
垢版 |
2018/08/30(木) 16:55:04.72
そもそも>783のは古い記事
IBMだのPentium MMXだの
いつの時代だよ
ってこと
その当時に書かれた記事なんだから未来の事が載ってないのは当たり前だけど
米国政府が中国製品を国の重要設備から排除してるってのにISSから排除しないわけがない
中国人宇宙飛行士は一人もISSに居たことないんだから

と、調べてたら大西さんが使ってるのもThinkPadらしく
売却前のお古を使い続けているみたい
OSもLinuxに変えてあるのでMMXでも耐えられるのかもね
Windows XPサポート終了の時期にLinux(Debian)に切り替えたらしい

記事によってはLenovoのThinkPadと書いてるのもあるが、2013年記事には386SXが載ったPCとあるから矢張りIBM時代のThinkPadなのでは？
そりゃ、ゲームやグラフィックしなけりゃ386SXでも十分なんだろう
船内コンピュータにスーパーコンピュータを搭載させる実験もやってるようなので、ThinkPadは家族との通信用などに利用されてるようだ
0789Nanashi_et_al.
垢版 |
2018/08/30(木) 22:06:00.70
Linuxって西欧の公的機関でもフリーオフィスソフトとともによく採用されてるし
ブラックorホワイトハッカーたちはクラックイベントでLinuxはターゲットにしない/したくないってよく言ってるけど
個人情報保護が喧伝される昨今に実務に使うのは･･･？
0790Nanashi_et_al.
垢版 |
2018/08/31(金) 02:02:47.70
ISSのThinkPadからマルウェアが発見されて以来
セキュリティを強化したんだってさ
まあNASA独自のセキュリティアプリを入れてるんだろうね
0792Nanashi_et_al.
垢版 |
2018/09/05(水) 22:19:26.59
店頭でも通販でも初学者イジメなCASIOfx375ばかり売れて
使いにくい関数電卓で理数離れに拍車をかけるばかりで
オープンでフランクなグラフ電卓環境からクリエイティブでイノベーションあふれる人材が留学生を含めて毎年輩出されるアメリカには離されるばかり
0793Nanashi_et_al.
垢版 |
2018/09/05(水) 22:53:07.45
>>792
1300円で買えるんだから仕方ないよ
ライン表示ならシャープのが千円未満なんだし

プログラミング可能なのも6千円前後なんて
昔を知る者からは考えられない価格破壊
聞いたこともない社よりも国内メーカー品選ぶのは日本人の特性でもあるしさ
本体価格999円のがAmazonにあるけど、どうせ何処かのクローンだろうし
0794Nanashi_et_al.
垢版 |
2018/09/05(水) 22:56:11.42
FX-603Pは復活させればいいのに
0795Nanashi_et_al.
垢版 |
2018/09/05(水) 22:58:09.12
>>792
グラフ電卓が一概に使いやすいとは思えない
関数電卓だとキーで直接入力できる記号がグラフ電卓だとメニューから探すことになることが多い
0796Nanashi_et_al.
垢版 |
2018/09/05(水) 23:01:29.04
Amazonで2,635円で売られてるfx-JP500のフランス版には小学生向けプログラミング学習用簡易言語搭載のが販売されてる
タートルグラフィックも可能なようだ

日本はScratch言語を採用したけど、関数電卓では実装難しいな
次のステップで日本もPython採用すればいいのに

Scratchは情報処理技術者試験用CASLの二の舞になりそうで心配
0797Nanashi_et_al.
垢版 |
2018/09/05(水) 23:21:59.67
>>795
だぬ、新しいものほどキーが少ない傾向が
0799Nanashi_et_al.
垢版 |
2018/09/09(日) 21:32:47.97
今時の関数電卓(プログラミング機能なし含め)
関数の種類が多くなり、基本的な関数以外はメニュー呼び出しなのは致し方ないんじゃないかな

INTやFRACですら、XEQで呼び出すHP41シリーズもあったけど
TI-Nspireみたいにやたらとボタン多いのもあるけど
0801Nanashi_et_al.
垢版 |
2018/09/10(月) 19:55:04.49
>>800
ライン表示のグラフ描画できない関数電卓だって基本変わらないよ？
最近は2行以上表示できるのが結構あるけど、メニューから関数選ぶ機種多いよ(というよりその傾向が強い)
別にグラフ関数電卓だからキーが少なくなったわけじゃないよ？
fx-JP500やJP900、5600Pもそうだよ
プログラミング機能の有無も関係ないってことだよ

関数じゃなくて記号だろ？って言いたいのかな？
なら逆に聞くが記号ってなんだよw
Σとか分数の括線のこと？
使用頻度が低い関数や記号はメニュー入力になるのは仕方ないこと
0802Nanashi_et_al.
垢版 |
2018/09/10(月) 22:07:12.38
>>801
お前、相当頭が悪いな
>>795 >>797 は「関数電卓の方がグラフ電卓よりもメニュー操作が少なくて済む」ということを言っているのであって、メニュー操作の是非を語っているのではない。
0803Nanashi_et_al.
垢版 |
2018/09/11(火) 00:08:32.23
>>802
そんな事じゃないよww
メニューから探す事の方が多いっていってんだよ？
さては、関数電卓を使ったことないな？

キーにショートカットが割り当てられてれば
シフトキーやalphaキー押して目当ての関数なり記号を入力できるが、どのメニューか覚えきれないから探す手間が面倒って言ってるのだよ
だから、元の発言者はシンプルでいいからメニュー入力は極力無くしてって言いたいのさ

関数電卓使った事あるなら、みんな感じてる事だよ
TI84で60進数の記号°や'を入力するのに何処のメニューだったか分からなくなることがあるんだよ
CASIOなら°'"が一つのキーで押せるから分かりやすい
0804Nanashi_et_al.
垢版 |
2018/09/11(火) 00:10:30.15
>>803
TI-84 Plus はグラフ電卓だ。関数電卓ではない。
関数電卓とグラフ電卓の区別もできないのか。
0805Nanashi_et_al.
垢版 |
2018/09/11(火) 00:12:34.18
>>803
>そんな事じゃないよww

そんなことだよ。元の書き込みを理解できないのか？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況