Pythonのお勉強 Part57
■ このスレッドは過去ログ倉庫に格納されています
>>775
visual studioとvisual studio codeを間違えてただけだった… >>776
その問題は、socpですらないんじゃないの? PythonやるのにCとかJAVA知っとく必要ありますか? >>780
必要ない
俺はCやJavaを何年も勉強して身につかなかったCOBOL使いだが、Pythonはスッと頭に入った
おそらくこれほど理解しやすい言語はこの世に存在しない オブジェクト指向が全然わからん、classとか全く使ってない
みんなオブジェクト指向してるんですか? >>784
そんなものは必要ない
コードの上からずらずらとやりたいことを書くだけで良いのがPythonの強み
Javaプログラマがクラス設計に頭を悩ませている間に
Pythonプログラマはそこそこ動くコードを書き終えているだろうね jupyterlabのvim拡張ってキーマップ設定とかできる?
notebookの方だとディレクトリの深い所にあるvim.jsを書き換えれば好きにキーマップ変えられたけど >>787
Javaでもmainメソッドの中にずらずら書いてそうだなあんた Javaにリファクタリングって本があるから立ち読みでもして見てみ
OOPがどう便利なのかシンプルに分かるから Pythonプログラマーになるのに基本情報技術者資格勉強する必要ある?
アルゴリズムとかJAVAとかややこしそうなんだけど 少なくとも現状の国内では、Pythonの本職エンジニアにはほぼ例外なく基本情報(またはその上位互換)を持っているor取ろうと思えば楽勝で取れる人しかいない
米国だとPythonはお子さま言語でもあるからもっとレベルの幅は広いんだろうけど >>792
何で今日はこういう質問多いんだろ
言語はツールであって資格ではない
やる気と毎日コードを書く環境にあるならば誰でも身に着けられる
ただしPythonだけで食っていくことは無理
日本ではマイナーだから仕事がない いや最近はDNNや機械学習の普及により
研究開発分野でPythonやnumpy, tf, Flaskが要件の案件があって、
俺はそれでおまんま食べてる >>797
DNNや機械学習のバックグラウンドがあってはじめてPythonで稼げるって言ってるのと同じだろソレ
資格よりもPythonで稼げる市場を見つけるほうが大事 >>784
C言語に当てはめていうなら構造体とそれを扱う関数みたいなものなんだけどな。 >>805
プログラムの出力結果をWEBに出したいという要求もたまにあってね。
Bootstrapなどと組み合わせて使うことになりそう
Webはあまり得意じゃないからまちょっと勉強しなきゃなんだけれど だったらまずHTTPの勉強するほうが先
小手先のインチキフレームワークなんか使うから
どういった仕組みなのか全然分からないワケ
わかった?
簡単なHTTPサーバー作るとこから始めなさい
簡単なのならすぐに作れる
そうすればどういった仕組みになってるかすぐに分かる >>807
PHP7とか昔はCGIを結構やってきたから基礎は多少分かっているつもりだけど
FlaskとBootstrapまたはJQueryがほぼ要件として決定らしくて
FlaskはともかくBootstrapやJQueryははっきりいって勉強してこなかったから
社内で出来そうな人材を探し中さ pydoc -pでブラウザでpydocを見れたりするじゃない。
ああいったpythonの持っているHTTPサーバ機能で要件が満たせてしまえれば
いいんだけれどもね… ローカル計算機でhttpサーバー動かして
ローカル計算機のUAでそれに接続してインタラクティブに表示するワケか
表示するデータがローカルの計算機ですべて完結するなら
やり方としてそれはそれで問題ないともいえる
いちいちサーバーをたてないで
htmlにjavascriptつっこんでできないぐらいの
複雑さが要件にあるかどうかはオレには分からんからなんともいえない Djangoでクエリ使うのって、SQL直打ちに比べてものすごくもどかしいし制限多い気がするんだけど、気のせい? 気のせいじゃない
ORMはどのフレームワークや言語においても糞 質問なんだけどPythonだけで食っていくのは可能? pythonは食べられるよ、美味いらしい。でも食べられた人もいるからきをつけろよ! 大物だとかば焼きにすれば数百人分くらいは食えるんじゃないかな >>818
そうなんだ
でもなんかアレだし趣味に留めておくわ ツールとしての最適化を図ってる感じだからな
何かの専門知識+Pythonで成立する 社内環境からpip install しようとすると、リトライを繰り返して失敗する。謎だ。 >>824
set proxy でググれば出てくると思われ >>825
ユーザー名とパスワードは端折っていいのかな。とりま出社したらやってみよ、ありがとう。 >>826
社内のプロキシで止まってるからユーザー名とパスもいる
書き方のフォーマットはぐぐれば何種類かある たしかこんな感じだった
set proxy https://ユーザー名:パスワード proxyserver ってcmdで入力してからpipすれば入るはず >>827
詳しくありがとう。
社内環境だとプロキシはpacファイルの自動構成でやってて、ユーザー名とパスワードがあるかどうかわかんないんだよね。ドメインと同じでいいのかな。 >>789
コンストラクタが数千行って話を思い出した。 >>779
以下のような形式を解こうとしています
(Hは共役複素転地)
min c^H*x
s.t. ||A*x||<=b^H*x
||D*x||<=e
F*x=g
の形式なのですがcvxoptのsocpでは解くことは出来ないのでしょうか?
数学もプログラムも苦手で… >>831
min の部分がおかしいんですね
自己解決しました
現在の問題としてmin の部分がない時、s.t.の条件を満たすxが存在するかどうかのfeasibilityチェックはcvxoptでは出来ないのでしょうか? >>832
minがおかしい以前に、複素数には順序がないので大小比較できません
なので、複素関数の最小化というのは意味がありませんし、制約条件内で
不等式に複素数がそのまま出てきた場合は、
意味のない問題であるか、implicitに両辺の「計算結果は実数になる」
という制約条件を追加しています(質問で見るのはいつも前者ですが)
たぶん後者を扱えるものはないので、実数部分と虚数部分にわけて
両辺の虚数部分の係数が0になるという制約を追加したより大きな実数問題
として扱うことになるのかな
実数問題に直したあとのfeasibilityは、目的関数を0にでもして解けばいいです 今頃pathlib(3.4からなのか)を知ったんだけど
この辺りやたらと機能ダブってるけど
後々何処かに一本化されるのかな? ユーザ向けの統一試みたのがpathlibで、別にこれまでのものをなくすわけでもなく ファイルパスを抽象化しようとするのは昔から数々の言語が試みて
結局「パスは既に優れた抽象化であり、オブジェクトにすると余計に不便になるだけである」という結論に至っているのにな
Python開発陣の中にも「俺は他のアホとは違う」という中二病患者がいたんだろうけど、誰か止めなかったんだろうかとは確かに思う
結局パス文字列を引数に渡す代わりにオブジェクト作らないといけないだけ、くらいにしか使われてないね Path操作がos.pathとosとglobに散らばってるのをまとめただけだろ
PEPの趣旨を読んで言ってるとは思えないな >>837
統一するのは結構なことだけど、やり方の筋が悪いわ
既存のライブラリをPathに対応させようとして元々パス文字列を受け取るようになってた他のモジュールの引数をPathを受け取れるようにした
静的型言語ならPathに対応してるかどうかは明らかだけど、動的型だとドキュメントを注意深く確認しないと分からないから、
みんな心理的に確実な方(文字列)を選んでしまうもんなんだよ
そうなってしまうといちいちインスタンス作るのが面倒臭いだけで、単なるパス文字列操作のユーティリティ関数群で十分だったってことになる そしてライブラリの開発者には文字列とPathの両方に対応する無駄な手間が生じる
統一するはずが、更に重大な不統一を生じさせ、結果的には明らかに不利益の方が大きい Path便利じゃないか?
Windowsでもマックでも同じコートでパス指定できるし。 ID:fTMxnY19みたいなバカには使えないってだけの話だろ w
ちゃんと使えば普通に便利 Pathをちゃんと使うということは、Pathを単なるユーティリティとしてではなく、
ファイルパスを受け取る引数などインターフェイスレベルで統一的にPathを使うってことで、その世界こそがPathの目指したものなわけだけど
その意味で本当にちゃんと使ってるの? pathlibは便利だけど、Pathオブジェクト作る前にos.path.exists()やos.path.isdir()で
チェックするから結局os.pathは使うよね? >>842
> ファイルパスを受け取る引数などインターフェイスレベルで統一的にPathを使うってことで、その世界こそがPathの目指したものなわけだけど
なんでそんなアホな考えになるんだよ w
単に便利な機能だけ使えばいいだろ 単なるパス文字列操作ユーティリティとしてだけ使って文字列に戻してしまうんだったら、オブジェクトである必要は全くないわな
アホなもクソも、実際Pythonの標準ライブラリはだいたいの場所でPathをそのまま受け付けるようになってるよ >>845
> 単なるパス文字列操作ユーティリティとしてだけ使って文字列に戻してしまうんだったら、オブジェクトである必要は全くないわな
だからそんな時は使わなきゃいいだけだろ
いちいち使えない場合を書いてマウント取った気になるのやめたら?
アホにしか見えないよ w リファレンスも目を通さずにケチつけようとするくらいどうしようもなく頭悪いんだから
最新の言語機能にいちいちついてこなくていいんだよ
ロートルは死ぬまでレガシーコードを書いていればいいの やっぱりパイソンつかってるのはガイジ脳しかいない
むしろガイジ脳がどんな場面でも使えるように
>>845 みたいなインターフェースになってる でも気になって覗きに来ちゃう半角ガイジなのであった pathlibでパスの起点を任意に指定した相対パスが扱えるらしいけど、これバグってんの?
>>> import os; import pathlib
>>> os.getcwd()
'C:\\tmp\\hoge\\fuga'
>>>
>>> s = pathlib.Path(r'C:/tmp/hoge/fuga')
>>> s
WindowsPath('C:/tmp/hoge/fuga')
>>> s.absolute()
WindowsPath('C:/tmp/hoge/fuga')
>>>
>>>
>>> s2 = s.relative_to(s.parent) #C:/tmp/hogeを起点にした相対パス作成
>>> s2
WindowsPath('fuga')
>>> s2.absolute()
WindowsPath('C:/tmp/hoge/fuga/fuga') #変なパスになっちゃったw
>>>
>>>
>>> os.chdir(s.parent) #cwdを変更しないとダメ
>>> s3 = pathlib.Path(s.name)
>>> s3
WindowsPath('fuga')
>>> s3.absolute()
WindowsPath('C:/tmp/hoge/fuga') #OK
>>>
relative_toでcwdの変更までやれよ、もしくはPathオブジェクト毎にカレントディレクトリ保持しとけよ
pathlibにcwdを変更するメソッドが無いのもダメ、こんなんでpathlibで統一とかありえないがな >>851
ガイジは使わなくていいんだって
ガイジだから理解できないかな? >>851
Pathは単なるパス文字列のラッパーであり、ファイルシステム上の特定の要素を指しているわけではない
まあ実際851のような勘違いをする初心者は多いだろうね
単に文字列を引数に渡す関数群であれば起こり得ない間違いであり、pathlibの設計の筋の悪さを示す好例だな 最初はPath文字列操作のユーティリティ群で十分といっていた人が、
Path文字列操作のユーティリティ群であるpathlibを使ったら、
文字列操作を大きく超えた要求へ >>839
レジ袋有料化でゴミ袋買わされてその中にレジ袋入れて捨てる環境省アホだよな >>840
エンコとシステムロケールのgdgdはどうなん >>853-854
Pathは文字列操作のラッパーだけじゃないよ、初心者は知らないかもしれないけど
ファイルのチェックやファイルの作成などのメソッドも提供している
パスはただの文字列だけどファイルシステムと密接に関係しているのだからファイルシステム関連の
ユーティリティは当然必要で当然の要求
relative_toはparent情報から相対パスを作るのに、元の絶対パスに戻すときにcwdを使うのはおかしい
ここらへんは文字列操作とファイルシステムがごっちゃになってて筋が悪い
文字列操作に限定するならparent情報を保持しておいて、絶対パスを作る時にparentを使うべきだし
ファイルシステムと連動するならcwdの変更を行うべき >>856
俺はシステム作るときのフォルダとかファイルは英文字しか使わないようにしてるよ If 条件文 and 1: という書き方のif文を見たのですが、実用的にはif 条件文:と同じですよね?
こういう風に書くメリットって何かあります? >>853
ガイジは使わなくていいんだぞ
Twitterで自分から肥溜めに近づいてクサイクサイ大騒ぎしてるガイジフェミと同じだな >>859
一時的にそのif文を無効にしたくなったときにand 0に書き換えるだけで済む >>861
素早いご返信ありがとうございます!
目から鱗です
プログラミング界はクレバーな方が多いですね! 3のstrとbytesってホントに改良なんかね微妙に使いにくい
2の時代の方に慣れ過ぎたから可笑しく感じるのかな >>862
いや多分それ書いたのプアでフールな人だから真似するなよ >>865
それは真逆
Rubyの文字列は内部表現がエンコーディング依存で、どちらかというとPython2に近い考え方だ
Python3の内部エンコーディングを一律unicodeに揃えてしまうやり方はJavaや.NETなんかの割とビジネス的な系統
シェルスクリプト的な使い方だと勝手な変換が入らない方が使いやすいこともあるんだけど、
Pythonはスクリプトの中では単独できっちり書くという指向が強いから後者のほうが適してるだろうね >>860
肥溜めがクサイのは当たり前のこと
同様にpathlibに欠点があるのも当たり前のこと
そして欠点は使っているからこそ気づくもので、その欠点を指摘すると怒り狂う方がカイジじゃなかろうか 自身の能力の低さ故に望まない結果が得られただけのことを欠点と言われても困る
「初心者でも使えるように」と言うが、初心者のレベルの設定にも下限がありどこまでも下げていくとむしろ複雑怪奇な構造が生まれてしまう 「初心者でも使えるように」などと誰も言っていない、それは低能なキサマの心の叫びだ
オレは何にでも欠点はあるという当たり前のことを言っているだけだろ?レスを見ろ!
キサマはキサマが作った妄想と戦っているのだ、その妄想はキサマ自身だ、そんなに自分を責めるな! 最近Pythonの勉強を始めました。
for文を使った行列のかけ算ですが、
x=np.array([[1,2,3,4]]
y=no.array([[5],[6],[7],[8]])
s=np.array([[0]])
for a in range(0,4):
for b in range(0,4):
s[,]=s[,]+x[,]*y[,]
後半の数値の入れ方が分かりません
ご教授ください scipy.matrixて使ったことないけど、どういう点が優れてるの? >>859-864
If 条件 and 0:
If 条件 and 1:
このどちらでも、先に条件文が評価されてしまうから、
この条件文に、何かの状態を変える副作用があると面倒だから、逆に書くべき
If 0 and 条件:
If 1 and 条件:
0 の場合は短絡評価だから、条件が評価されないから安全 ■ このスレッドは過去ログ倉庫に格納されています