面接時「プログラミング得意です」入社時「何も分かりません」←これ多すぎ
■ このスレッドは過去ログ倉庫に格納されています
面接だから話盛るのは分かるけど
全く出来ないのに嘘八百で入られると流石に扱いきれない >>2
中途でもこんな人たちばかりで頭抱える
前年度に関しては新卒の方が出来てたぞ辞めたけど どこでも通用するプログラミング知識とその現場で必要な知識はまた別だからな プログラミング出来るやつほど得意ですとは言わんから判別できない面接者が悪い
プログラミング完全に理解してますて言う奴居たらあーそのレベルねってなるだろ それでいて、わかりますわかります言うのも困るんだろ?
前にこういうのをやったことあります、なんて言おう物なら完全に突き放される。
なんやかんやローカルルールべったべたの田舎企業のくせに、それを教えようとしない。
何やっても否定。わざと間違えさせて教えを乞わせて服従させる昭和のやり口。 得意ってのはプログラミング自体が好きってことしか分からんだろ
どの程度のスキルが必要とか明確な基準でもなけりゃ相手もプログラミング好きだから教えてもらえばすぐ覚えられる気で話すだろ ポートフォリオ持参させないの?
と思ったけどそういう奴はネットからコピペして持ってきそうだな アメリカでも工学部卒でプログラミングの修士でもFizzBuzz問題できないのがほとんどらしいからな
どの領域に詳しいかって本当に人によるから大事なのは学ぶ姿勢があるかないかよ 四則計算とか変数辺りで1月潰れる
興味ありますで覚えていってくれればいいけど
大体分からないまま半年以上経つか分からないからと言って辞める どういうもん作ったのかとか
会社で必要となる知識つつくとか
見抜く方法はあるだろ 俺プログラミングできるけどプロの現場で通用するかは疑問だわ
まず責任あるプログラミングと遊びでは全く違うし
集団作業かどうかも違う >>18
エロ画像クローラー
趣味でプログラムやる奴は100%作ってるはず 何もわからんけどやる気あります!勉強しながら貢献したいです!
↑
こいつ欲しい? 時間かかるのは仕方ないがそれなら最初から0スタートの人入るって教えて欲しい
これ新人じゃなくて人事の問題か プログラミングエアプだから知らんのだけど面接の段階である程度専門用語とか出して確認できないもんなの? >>28
それ全く同じようなこと言って入ってきた人いたけど
俺が見た中で過去一の地雷だった 経験者(最初から教えてもらいたいし…)
経験者「ほとんど経験ないです!」 >>31
がんばれ
ふざけてるようで実用性の高い技術がてんこ盛りだ >>17
四則計算て+= とか++とか教えるてことか?それ何も知らんと同義だろ小学一年生やん >>14
ポートフォリオをパクると言う発想はなかった
ありがとう 嘘を見抜けないのが悪いよね
面接ってそういうものだから >>28
中途ならいらんけど新卒なら大学次第で考えるかな >>38
今いる子は画像サイズを1/60にするところで半日使ってたよ フロントエンドならまだしも
バックエンドの違う言語の仕事させようとしてんじゃね?
あと使った事ないframework使わせようとしてるとか 俺もさすがに人並には字は書けるけど
入社いきなり企画書書けって言われても困惑するし書き方わからないと言って泣きつく自身あるわ >>42
割りとマジで俺が入りたいわ
コンソールライトラインと四則演算くらいなら書ける どっちが悪いという話ではなく
寄生虫求職者vs無能面接官
という話 文学部卒
農学部卒
商学部卒などはいた
経済学部はけっこう多い
法学部は聞いたこと無い、いるんだろうけど
音楽学部がいたらしい >>45
ある程度言語に精通してればコンバートは余裕 >>38
プログラミングで四則演算を正確に扱うには
float型とかint型とかきっちり理解して
場合によってはコンピュータは正確な結果を出せないことを
学ぶ必要がある
ビット演算も理解してcpuの基本的な仕組みも学ばないといけない
>>17の「1ヶ月」ってのは恐らくそれを意味してる >>50
まあ何もわかりませんってことにはならんけど
多少は習熟時間見てやれよとは思う VBAだけ出来るけどVBAで無双できる会社無いの? >>42
そんなんやったことないプログラマーなんてたくさんおるやん
わいは給与システム作っとるけど画像なんか扱わないからわからへんで
けどプログラムはできる言うで? >>52
int float double教えにゃならんとか小学一年2学期やんけ大差ねーわ >>55
スレ全部読んでなかったわ
流石にこれはないな
マジでなんもできねえじゃん >>58
まずfloat型が正確な計算結果を出せないことを理解してるか? 結構経験積んだプログラマが
.5がピッタリになっているのはおかしい
浮動小数だからキリの悪い数値になるはずだ
と言い出したのにはびびった >>57
やったことなくても、適当なライブラリのリファレンス検索すればできるぞ >>62
2進少数にするから0.3でも誤差が出るのは常識だろ >>67
そう
コンピュータが少数の計算や割り算をすると大抵誤差が出る
そのことを理解して業務で使うにはコンピュータの
基本的な仕組みを理解しないといけない
だから「1ヶ月」かかるんでしょう エントリーシートもポートフォリオもAIに作らせる時代だぞ 四則演算とか知らなくても大抵のものはライブラリで作れるけど PaizaのランクかAtCoderのレートを提出させれば良い コンピュータがではなくて
10進数表現でも普通に割り算すると桁溢れて正確じゃなくなるだろ
分数表現するしかない 会社側もあらゆる場面で嘘ついてくるからお互い様やね 必要な時以外浮動小数使うのやめようぜ
装置側が値の100倍したものを送ってくるのに
何故ソフト側でそっこー浮動小数変数に入れるのか 面接官が無能
どうせ自ら有能切って無能いれて
文句言ってるんだろ ゲームで位置とかバグることがあるのは
浮動小数点の誤差が発生してるから? 人事が業務内容把握してないから面接時の質問で見抜けないだけ
無能なのは人事 正確な計算結果を出せないってそれ欠陥では
どうやって使うんだよそんなの すまんな
ECサイト作った程度でプログラミング出来る言って入社したが1年くらい迷惑かけっぱなしだったわ
正直プログラミング力は客観視出来んと思った プログラムできるって言うとあらゆる言語が調べずに即座に使えて
AIだの画像処理だのの知識もあるしUIデザインもこなせると思ってるアホがいて困る >>82
10進数で言うと
1/3が0.333333333333333333
になるみたいなもん
正確じゃないが許容される場面は多くね? >>82
昔の銀行とかで度々問題になった
小数点の端数を自分の口座に入れて横領とか。
コンピュータで少数や割り算を使う時は注意して
誤差のことを計算に入れてシステムを作らないといけない
そのための「1ヶ月」なのでしょう そんなものか
パソコンやプログラム得意と言って大手ITベンダーに入ったが
入社時俺よりパソコン詳しい人は周囲にいなかったと思う >>82
普通は仕様で有効桁数と切り捨て切り上げ決めて扱う
計測機器作ったりするなら必ずあるはず
ただfloatがどうとかは>>1の話から若干ズレてる気がしないでもない >>89
それを2回足すと有効桁が一つ落ちる
物理の数値計算とかだと気づいたら有効桁一桁になって使えないとかはある ダブル、イント、フロートみたいなデータ型は教えてるというか調べて理解したなぁ
多少の知識だけ覚えたら後はひたすら実践
これやってをネットで調べながらひたすら自分流で作る
完成したら見せて他の解答やこうすればよかったを理解する
インプットよりひたすらアウトプットした方がいいイメージだわ ぼく「エクセルできます(足し算くらいなら)」
敵「ほほぅ」 すまんな
ECサイト作った程度でプログラミング出来る言って入社したが1年くらい迷惑かけっぱなしだったわ
正直プログラミング力は客観視出来んと思った 最初クラスとか意味不明だったけど
実践繰り返すと、はいはいこのパターンはクラス使えば楽ねって勝手になる
努力はネットで検索する努力これだけ
他はいらない >>94
もちろん上で出ている銀行業務とか君の言う物理計算とか
許容されない例はいくらでも有るだろうけど
>>82へのレスだからね
全く使えないわけじゃないことを示したんだよ >>96
>>1の者は「四則演算」と指定してて
四則演算の中に割り算は含まれてる できる!ってなにを持って信用するのかが重要であって
何も考えずに採用するとかこの先大変 同級生で一番最初にHelloWorld出せました! こんな程度でマウント言われても困るわ
小学生でも出来る、何せ俺がやってるくらいだからな >>103
うん
何らかのアウトプットとして割合とかを出すことはあるが
その数値を再利用することは稀だし有効桁もfloatで十分なレベル >>99
ぶっちゃけあんまり気にしなくていいよ
製造やるなら設計書しっかり読める方がよっぽど重要 >>108
それは業務によって様々でしょう
業務の内容によってどこまでが有効桁数か変わる
有効桁数というものを理解するためにはやはり
型であるとかビットであるとかコンピュータの基本的な仕組みも理解してないといけない >>100
ECサイト作れるならポテンシャル自体はありそうだけどなぁ 20年位前までソフトハウスで働いていたけど女性を顔でとる会社で入社して3年経っても試験の検証しかしたことないってのがいっぱいいたな
なんでこの仕事選んだの?ってのだらけだった
そして社内でくっついたり離れたりを繰り返してギスギスしとった >>110
お前が勝手にそういう妄想してるだけっていつになったら気づくんだ 面接で好きなデザインパターンは?って聞けばプログラミングへの理解度は大体想像つく >>115
>>1はどんな業務やってるのか言ってないし
どういう四則演算が必要なのかなんてわからんだろ 面接時「人と接するのが好きです」入社時「人権宣言?なんですかそれ」 何次面接の想定かわからんが、技術者採用するのに面接に社内の技術部門が立ち合わないなんてことあるか? >>120
インキャほど人に聞くって事が出来ないから
自分で色々調べて理解するから
インキャはプログラマー向いてるジレンマ >>118
グローバル変数のノリでシングルトン量産するやつだな!帰れ! プログラミング向いてる人って趣味でUnity使ってゲームを作ってたり既に書き込まれてるけど画像クローラーを自作したりしてる人になるのか? 人事自体が仕事できないやつの集まりだからな
他の業務で結果出せて金を稼げるんなら人事で遊ばせておかないよ
面接は現場のやつも同席させた方がいいわ >>117
その後画像がどうの言ってるからそういう分野じゃないのは確か Javaのソースコード読める程度の知識しか無いのに既存の簡単な改修なら可能って書いてるけどセーフ? 普通プログラミングで何ができる?って言いかたしねえ?
車運転できます!だけで大型貨物運転させようと思わんだろ 何処から出来るって言っていいのかマジで分からない
出来ない人よりは出来るって言いたい プログラミング向いてる人って言うより絶望的に向いてない人がいるイメージ
あとシンプルに実際やってみたら思ってたのと違ったパターン
そういう意味で未経験でも一度はプログラミング触ってやってけそうか確認しておくのがお互いの為だと思う >>133
プログラム完全に理解した
と表現すれば伝わる VBA使えるのはプログラミングできるって言って良いのか? >>134
プログラミングって例えば何かゲームを作るとか? >>132
画像処理で有効数字気にするような演算しないが 出来ると言っていいか悩んでる人は
騙す意図がないならしっかり話せばいいだろ
自分が書いたプログラム作ったプログラムはこういうものだ
ここはライブラリ使ったので1からは作れないだろう
こういうことは概念としては勉強したが
使い所が分からない上手く使えている気がしない
とか
自分が何が出来て何が出来ないか
客観的に語れたら俺的には評価高いわ >>138
有効桁数を気にしなくても画像サイズをピッタリにしたい時とか
少数の計算できないと正確な結果にならないこともあるだろ 俺「チャットボット作りました!(嘘だよ!Googleが後悔してるAPI丸パクリだよ!)」 >>141
ぴったりにする必要あるか?
そもそも画像サイズは整数だろ >>137
ゲームでも良いしツールでもいい
ゲームつってもゲーム開発志望とかでなければシューティングとかアクションみたいなオリジナルゲームじゃなくてオセロとかテトリスみたいなルールがシンプルで見た目とか拘らないミニゲームでいい
基礎と雰囲気掴む為のもんだから難しくなくて良い >>143
整数でピッタリ合わすには正確な少数計算が必要なこともあるだろ >>145
四捨五入するだけだが
そもそも少数が出た時点でぴったりにならないんだから気にする必要がないって言ってる >>144
ありがとう
IT業界が気になってたけど自分に適正があるのかどうか調べるにはどうすれば良いのか分からなかったから助かる >>146
四捨五入しても少数の扱いが雑だと1ズレることもあるだろ >>150
例えば256対256のサイズで納品しないといけないファイルを
256対257で納品しちゃったとか起きたら大変なことだろ Java Silverの資格は馬鹿にならない
デバッグ能力がないと合格できない
PaizaAランクも馬鹿にはできない
ビジネスロジックが組めないと合格できない
この辺持ってるビギナー人材は宝の宝庫だけど人事は重視しないよなあ >>151
なんで納品サイズ決まってんのにずれるんだよ
最後にトリミングするだろうよ ID:nuhtnd0o0は机上の空論だけで話してて仕事したことないって感じするな >>153
まぁ1例だけどトリミングもプログラムだろ
画像処理だからトリミングも込みの仕事かもしれないし >>151
少なくともサイズに関しては拡大率縮小率での指定ならそのくらいの差は許容範囲
目的とするサイズが最初から決まっているならサイズの計算で有効桁数がどうこうなんて話にはそもそもならない >>151
サイズが指定されてる画像を何で縮尺率で割ってサイズ出そうとしてるの?
サイズ決まってるなら計算するまでもなく、そのサイズなのでは? >>157
許容範囲も何も指定したプログラム組めなかったら問題やろ >>158
だからファイルのサイズが正しくない可能性がある >>159
画像処理において画像サイズ変えることはいくらでもあるだろ
バカなのかw 画像ファイルを指定したサイズに変えるっていうのは例えば動画サイトのサムネイルを作るときに必要だよね こいつ実数と浮動小数の区別ついてなさそう
浮動小数は計算結果が正しいかどうか以前にそもそも正確に表現出来ない値があるんだよ? >>161
だから最後トリミングで整形するんだから関係ないじゃん >>162
いや、だから納品する画像サイズが指定されてるなら、そのサイズにしかならないんだから計算する必要ないだろ
画像サイズを元の○%って指定なら、1ピクセル単位のズレなんか許容範囲だって話をみんなしてると思うんだが >>165
「指定したサイズ通りのファイルを出力する
プログラムを作ってください」って業務かもしれないだろ 浮動小数で金融の話持ち出してくるのも謎
そういうのは仮に小数点以下を表現する必要があったとしても固定小数点を使うからそもそも問題にしてる誤差なんて出ない >>167
計算で画像生成するプログラムを作る業務かもしれないだろ >>171
そういうプログラムを作れと言われたら作るしかないだろw
アタマボケてるなほんと >>173
?
指定したサイズを出力しろって言われてるんだから
ズレたらトリミングする必要があるだろ
そもそもどんなデータが投げられるかもわからんし最初からトリミング前提かもしらんし >>174
「指定したサイズのファイルを出力しろ」
と言われたら
「指定したサイズ通りのファイルを出力するプログラム」
を作る以外ないじゃん
馬鹿なのかw >>170
いや、だから仮に指定されてる画像ファイルが256✕256なら計算するまでもなく256✕256にしかならないんだから、257✕257になるかもしれないなんて心配する必要があるの?って訊いてるんだけど
他の人が何度も言ってるように微妙なズレはトリミングでサイズ256✕256にすりゃいいだけの話だし
それともトリミングの意味が分かってないのか?もしや(´・ω・`) まず実務ではプログラムが目的じゃなくて業務の達成が目的なのよね プログラミング関係は話盛るのが定番だから仕方ない
このスレでも既に盛られてるし >>176
例えば「800×426のサイズのファイルを色々処理して
256×256のサイズで出力しろ」と言われたら
少数の計算がしっかりしてないと変な出力に
なるかもしれないだろ >>179
途中でどんな処理挟んでも最終的に指定サイズでトリミングするんだから途中経過でどんだけ誤差出ようが最後に帳尻合うだろ
バカなのか? >>180
プログラミングできるけどとかプロの現場でとかほざくからだよ >>181
処理によってはピクセルごとに正確な情報入れたいかも分からないだろ
その時に少数の計算の正確性が関わる 画像処理関わったことないのだが
てきとーにやったら1pixel増えちゃったから
最後もう一回変換処理かけるべ
で許されんの? はーいいなぁ
うちなんか
「入力が大変です」
ぼく「同じ内容なんだからコピペですぐできるでしょ」
「そうなんだ!しらなかった!」
「そのマニュアル作ってくれ!!」
こーんなレベルだよもうマニュアルなんてアホらしくて作ってられんわ >>183
そもそも画像サイズを変更するような加工してる時点で正確な情報は残せないんだわ
仮にそういう要求されたら相手に無理だと納得させろよ。それが仕事だろ >>186
それ決めるのお前じゃないだろw
そういう依頼を受けたらそのプログラム作んなきゃいけない >>188
要件定義したことないのか?
依頼通りに作るアホはプロの世界にはいないぞ >>189
画像処理の会社なんだったら「こういう画像処理の
プログラムを作ってください」と依頼を受けるわけでしょ
その業務内容はよく知らないけど少数の計算を
いい加減に扱っていい分野とは思わないな >>190
その依頼に対して具体的にどういう仕様にするのか要件を詰めるだろ?
その段階で実現が無理だったりコストに見合わない要求あれば相手を説得して要件変えたりするだろうが
まさかろくに要件定義もせずに二つ返事で作り始めんのかお前 正確性が失われるは良いけど
そのメカニズム説明するのに
1Pixex増えちゃうから最後辻褄合わせの制御してます
ってお客さんに説明すんの?
そりゃ嫌だわ……
画像処理界隈では許されるのかもしれんが
俺の常識では無いわ >>191
仕様を実際にプログラムする時により正確な少数計算関係あるだろ >>193
そもそも画像処理にそこまで正確な計算いらないって話に対してお前は必要って主張してるんだろ?
1ピクセル単位の画像のズレが許されない業界なんて聞いたことないんだが、そんな特殊すぎる環境持ってきて何の主張を通したいんだお前
そんな超絶激レアな依頼されたらその時は対応すれば?
でも一般的には画像処理でそんな計算いらないからな
いい加減分かれ ちょっと実際に考えてみたんだけど
プログラミングで1/3を1×3したら1ちょうどに
ならないじゃないですか
この誤差は四捨五入をしたら緩衝できるというのは
だいたいそうだろうとは思うけど
コードによってはこの誤差が致命傷になることはない?
俺はちょっと具体的には思い浮かばないけどこれはあるんじゃないかなという予想を持ってる
どう思います? >>194
例えばゲームエンジンのUnityでは256と257は大違いなんですよ
257のサイズだと512と見なされる 画像処理とかゲームとかだと小数点の切り捨ては大した問題にならんと思う
問題になるのはお金の計算、特に金利回りじゃね?
でも、そういうのって会社ごとにルールが決まってて末端の作業員はそれに忠実に従ってプログラム書けばいいだけだと思う
金融はまともにやったことないけどJavaのビッグデシマル型でないとダメとかCOBOLでやれとかあるんでしょ? >>197
だからトリミングするだろって何度も言わせんなよw
ここで言ってるズレは画像サイズのズレではなく、指定サイズ通りに縮尺した結果で1ピクセル単位で表示がずれる可能性の話をしてる
というかゲームの開発では各サイズ毎に画像作って組み込む事がほとんどだから、プログラムで画像リサイズなんて普通しない >>199
俺ちょうど今ゲーム作ってるんだけど画像リサイズはする
ネットで手に入れた画像を4の倍数のサイズにしないといけない >>201
プログラムで動的にサイズ変えてるの?
そんな処理入れるよりサイズ毎に予め作っておいた方が軽くなっていいぞ
まあ個人レベルで作ってるゲームなら好きにしたらいいが 大抵公開されてるライブラリとかで住むから一からロジック考えなくていいと思うの >>204
プログラムで画像処理する話してたんじゃないのかよ……
ここまでの話なんだったんだ >>205
だから>>1の会社が画像処理の仕事してるって話だろうがw
俺が使ってる画像処理サービスもそういう会社が作ってるはず >>206
???
画像編集ソフト使ってリサイズしてて、何の計算が必要になるの?
おまいさんは何を主張したかったんだ?
何かもう言ってること滅茶苦茶だぞ >>207
そのソフトもどこかの会社が作ったものなんだからプログラムで作られてるだろ
で、>>1の者の会社もそういう会社
だから>>17のようなやり方も意味あるだろ
という話をしてるんだけど >>208
???
何が言いたいかまだよくわからんが……
画像リサイズ処理なんて画像編集ソフトじゃなくてもよくある実務でやるプログラム処理だから>>1の会社がそういうものを作ってる会社の可能性は限りなく低いが、まあ仮にそうだとしよう
それで?小数点の細かい計算が必要ってのはどうしてそう思った?
そうしたソフトが小数点単位で細かい計算した上でリサイズしてるはずってお前の決めつけじゃないの?
お前がそういうのを作ってるわけじゃないんだろ? >>210
だから誤差出てもサイズ指定されてるなら最終的にそのサイズに調整されるんだから問題ないだろ?
それで何で納得しないの?
これが画像じゃなく、例えばよくある消費税の計算で、税込み表記の価格のお店で商品買って最後に税込みから税抜き価格を算出するロジックとかになってると、税抜きから改めて税込み計算し直したときにズレることはあるから、お前の疑問も一理あるよ
でも画像では基本ズレても大した問題起きないわけで、何でいつまでたってもそれを認めようとしないの? >>211
少数の計算をいい加減にした結果間違った出力出ることもあるだろ多分 >>212
あ、今何となく分かったぞ
お前、1を3で割ってから3で掛けた時に元の数値にならない事の知識をひけらかしたかっただけだろw
でも、その話をする題材が画像サイズの話だったために、色々ツッコまれて引くに引けなくなったんだなw
それなら多分おまいさんの主張の意図が理解できてくるw
気持ちは分かるぞー。俺も昔これ知ったときは誰かに話したくなったからなw >>213
俺はプロでもなんでもないアマチュアゲーム製作者だが
「どう見ても少数の四則演算をいい加減に扱うプロの現場なんて無いに違いない」
という予想を述べただけ >>215
そういう意味で言うとものによる
画像サイズの計算ではこのスレで再三言われてるように必要ない
金額周りの計算だと必須になることも多い
というか本当に「予想」だったならさっさと折れて納得すりゃ良いのにw
いつまでも食い下がってプロでもないのにプロ語って恥ずかしいやつ >>216
ピクセルの情報がひとつズレることってないの? ゲームとかで当たり判定が1pxずれて困ることってそんなにあるか? >>217
ズレたところで99%問題にならない。
問題にならないという言い方をするのは、基本リサイズしてる時点で何らかのズレは発生しているので、そのズレを人間の目で感じるかどうかでしかないから
だから小数点レベルの計算なんて不要だと言ってる
仮に非常に小さいサイズに加工したり、非常に小さいサイズから加工したりした場合は目に見えてズレることはあり得るけど、
そういう場合は普通手作業で何らかの調整加えるのが前提であることがほとんど
動的に小さい画像をリサイズしてる場合は流石に知らん。そんなレアケース聞いたことない >>220
画像処理で1ピクセル分処理を間違えてほんとに全く問題にならない?
おれはそうは思わない >>221
もうお前は勝手にずっとそう思ってろよw
ただこういうスレでしたり顔で語るのは恥ずかしいからもう止めたほうがいいぞw >>222
お前こそ「処理ミスは大した問題じゃない」とか
プロ失格なこと言ってるじゃんw >>223
処理ミスじゃない
勝手にミスにするなw
無駄な計算はしないってだけだよ
お前は複雑な計算の処理を書くのがプロだと思ってるのかもしれないけど逆なんだよ
プロなら如何にシンプルで簡潔な処理にするかだ
1ピクセル単位のズレなんてこだわっても意味がないことで無駄に処理を複雑にしたりはしない >>224
でも1ピクセルズレることはあるんでしょ?
16×16のドット絵に加工する処理なら全データの
約1/8が不正確なデータのファイルになる >>225
16✕16ならどのみち手作業で調整必要だろw
100%正確にリサイズすることは物理的に不可能
特に小さいサイズに変換していれば元よりデータ量減ってるんだから当たり前だよな?それくらいはわかるか?
どこまでズレを許容するかでしかないし、一般的に1ピクセル単位のズレで問題になることはない
小さいサイズならありえるが、それは>>220で言った通りでそこまで小さいサイズなら手作業で調整加えるのが普通。リサイズして出力された画像データまんま使うことなんて普通ない
何で納得できないの(´・ω・`) >>226
そのファイルが100個あっても手作業でやるの? >>227
やるに決まってんだろ
だからこそ今の時代ドット絵ゲーはそれだけで評価されたりするんだぞ。そういう労力掛かるから
言い方を変えようか?
どんだけ正確な計算をしても絶対にズレは回避できないんだから、正確な計算する意味ないよね?
これで理解できるか? >>228
ズレは回避できないってことは仕様によっていかようにも変わる要素
ってことだろ
ならなおさらそこの部分はデリケートに扱うべきなのでは?
だから>>17みたいな話になるわけで >>229
仕様は「○○✕○○のサイズにリサイズする」だろ
仕様として求められるのはあくまで画像サイズでしかない、サイズ通りであれば仕様満たしてるとみなされるし、多少のズレは人間の目では気にならないから許容される、というかそんなピクセル単位のズレなんて端から考慮しないよ
1ピクセル単位のズレなんてデリケートでも何でもないし
何だかなあ。自分の考えをしっかり持つのは立派なことだけど、相手の言うことに耳を傾け理解するのも大事なことだぞ
そろそろ俺の言ってる事を分かってくれても良いんじゃない? >>230
依頼が「16×16の画像を作る」で
実際できたファイルが「17×17」だったり
「16×16でも端のピクセルに不正確なデータが入ってる」
とかだったら「処理ミス」だよね? >>231
だからもう何度も言わせないで( ;∀;)
16✕16でリサイズするなら、計算するまでもなく16✕16でしょ
なんでわざわざ意味のない計算挟んで17✕17にするの?バカなの?
そして小さいサイズの画像の縮尺はそもそもズレるの前提で考えるものだよ。何度も言うけど。
処理ミスじゃなくてそういう画像処理の仕様 まだやっとる…
1ピクセルずれた事によってどんなすごいことが起きる想定なんだw >>233
端のピクセルに不正確なデータが入ることは? Unityに1pxずれると正しく挙動しない仕様があるとさっきから主張している模様
ただし、何のコードがどう正しく動作しないのか言わないので話が一向に前に進まない >>236
そんなこと言ってないよ?
「画像処理プログラムで計算ミスで1ピクセルズレることはあるんじゃないの?」
というのと
「Unityでは256ピクセルと257ピクセルは別物で512ピクセル扱いされることがある」
という別の話をしてる
お前の脳みそが糞だからごっちゃにしてるだけw >>235
余計なピクセルが入ることはないと思うよ
抜けることはあるかもしれんけど
でも抜けたとしても端っこの1ピクセル分の行や列が抜けたところでドット絵以外なら全く問題にならないし、ドット絵ならそもそも手作業で調整するから
何度も言うけど >>238
16×16の画像の端が不正確ならそのプログラムは失敗でしょ >>239
だーかーらー
そもそもリサイズってそういうものなの
サイズを縮小する場合、元の画像から削って小さくするんだから
端も削れてたところでなんの問題があるんだよ
正確も不正確もない
リサイズはそういうものだから
失敗してるのはいつまでも自分の間違いを認められないお前だよ >>241
だから
その劣化とやらは人間の目には分からないレベルなの
何度も言わせるな
ずっと俺はズレは起きるって言ってるだろ
そのズレをそのchatGPTは劣化と表現してるだけ
そのChatGPTの言ってることと俺の言ってる事に矛盾はない
お前が認めたくないだけ >>242
この文面に間違いがあるかどうか聞いてるんだけどw
「ある」か「ない」かで答えて? >>243
ないよ
俺の言ってる事の正しさを証明してる >>244
つまり「画像処理において浮動小数点数の不正確さによって
不正確な処理結果が出ることはある」ってことだな
じゃあやっぱり>>17の勉強大事ってことじゃんw >>245
そもそもの論点忘れたのか?
計算でズレが起きるかどうかじゃないぞ
正確な計算が画像のリサイズ処理に必要がどうかだ
お前は正確な計算が必要って主張してたんじゃないのか?
俺は正確な計算はいらないって言ってるんだぞ
おまいの言うとおり、浮動小数点を考慮すると計算でズレが起きますね
で?それがどうして正確な計算が必要って話になるの?
むしろ正確な計算無理だからしなくていいって話になるの気づいてる? >>248
リサイズは単なる俺が出した一例
昔何かのソフト使った時指定した解像度として
出力されなかった経験があるから少数上の誤差が原因だと思っただけ
で、俺やお前より遥かに知識があるChatGPTくんは「浮動小数点数は問題がある」と示して
お前は「間違いない」と同意した
その時点で>>17のカリキュラムは実に真っ当だと判断できる >>249
それ浮動小数点関係ないんじゃね?
多分一旦倍率に変換してからリサイズしてるってことだろ?
浮動小数点によるズレじゃなくて、小数点以下が途中で切り捨てられたんじゃねーの >>250
多分そうだろうな
よく考えたら。
リサイズの話は俺の勘違いだったようだ ■ このスレッドは過去ログ倉庫に格納されています