[過去ﾛｸﾞ] Perlについての質問箱 64箱目 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
817: 2020/12/06(日)01:06 ID:GZ1arJtc(2/2) AAS
>>814
仕様どおり。ｗ
記述したとおりに正しく動作しているな。
818: 2020/12/06(日)01:19 ID:d/9HsImJ(1) AAS
>>802
今更だけど日付をエポック秒で表して日数×24*60*60を足すんじゃだめ？
車輪の再発明というかただの製作を承知で、自分で日付変換の関数を一通り作ったらそれで十分だった
便利そうなライブラリを探そうとしたこともあるけど、オブジェクト指向的なやつだと結局その
オブジェクトを介した変換が頻出することになってスラスラ書けないなあと思ったのです。
もし今後UTCとかJSTとか出てきたときはそのときまた考える。
819: 2020/12/06(日)02:06 ID:fHRDTQ7E(1) AAS
PerlのYAML関連のモジュールが全部重くて厳しい
高速なYAMLモジュールはないのか？
820: 2020/12/06(日)10:37 ID:kLx/M/5Z(1) AAS
まずは高速なCのライブラリを見つけます
821(1): 2020/12/06(日)11:42 ID:BlX3SIQO(1) AAS
>>803 だが、>>802 の質問は>>803 で終わったと思ったのだが、不親切だった？
例えば2019年12月1日から365日後の日付は、次のようにすれば得られる。
use Time::Local;
$year=2019;$mon=12;$mday=1;$hours=12;$min=0;$sec=0;
$intvl=365;
$basetime = timelocal($sec, $min, $hours, $mday, $mon-1, $year-1900);
$basetime += $intvl*24*60*60;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =localtime($basetime);
$mon+=1;$year+=1900;
print STDERR "$year.$mon.$mday\n";
822: (ﾜｯﾁｮｲ be3b-cfMa) 2020/12/06(日)11:58 ID:5Rf1GOX10(1) AAS
見るからに面倒臭い
823: 2020/12/07(月)09:18 ID:zfvnE2zk(1) AAS
$basetime = timelocal_nocheck($sec, $min, $hours, $mday+$intvl, $mon-1, $year-1900);
824: 2020/12/07(月)09:43 ID:UAiCPmDo(1/3) AAS
Time::Piece はよくできてて、何かのログとかに現在時刻を書き出す、
とかの用途には十分に使える
でも、時刻計算や日数計算はあまり考慮されていない
現在時刻からの計算はできても、任意の時刻からだと弱い
825: 2020/12/07(月)14:03 ID:tC78i6pr(1) AAS
>>807
use Time::Piece;
use Time::Seconds;
my $day = Time::Piece->strptime('2020-12-05', '%Y-%m-%d');
$day += ONE_DAY * 100;
print $day->date, "\n";
print $day->year, "\n";
print $day->mon, "\n";
print $day->mday, "\n";
826(1): 2020/12/07(月)14:21 ID:UAiCPmDo(2/3) AAS
まあ、strptime さえ目を瞑れば
こんなもん、何か見ないと書けない
827: 2020/12/07(月)15:40 ID:15jj6qfl(1) AAS
use POSIX; を宣言してCの標準関数に似た時刻処理機能を使うのが普通じゃないの？
Cの時刻処理サンプルコードを円滑にPerlに移植できるよ。
828: 2020/12/07(月)17:17 ID:VC6/tHTg(1) AAS
>>826
DateTimeモジュール使えば全て解決なんだが
クソデカくて重いという弱点が
829: 532 2020/12/07(月)21:57 ID:WG5ppFXF(1) AAS
Time::Pieceの弱点は
strptime()で作ったインスタンスのtimeゾーンをいじれないとこかな？
後1つなんか弱手あった気がするが忘れた
830: 2020/12/07(月)22:38 ID:UAiCPmDo(3/3) AAS
strptimeはpythonでもrubyでも同じだから、もう慣れなんだろうな
'YYYY-MM-DD' とかではあかんかったのか
831: 2020/12/08(火)04:35 ID:65P2yCaW(1/2) AAS
>>821
timeLocal()の年は1900引かない方がいいよ。これちょっとCのライブラリとは違うんだよ。詳しくはドキュメント読んで。
832: 2020/12/08(火)04:36 ID:65P2yCaW(2/2) AAS
あ。タイプミス。timelocal()ね。
833(5): 2020/12/08(火)23:53 ID:VS4VHEi1(1) AAS
すみません、ソートで教えて欲しいんですが下記のようにみたいな枝番号が付いてる文字列をハッシュのキーとして
ハイフン前の数値でソートした後にハイフン後の数値でソートしたいのですが
普通に$a <=> $bだとハイフンの後の値がバラバラになって上手くいきません
キーを作る際に別々に作ってループ増やすくらいしか自分には解決方法が無いのですが、スマートに出来る方法は無いのでしょうか？
1-1
1-2
2-1
2-2
3-1
834(1): 2020/12/09(水)00:31 ID:LWKBPFtb(1/7) AAS
>>833
シュワルツ変換で検索！
たとえば :
mapでソート用の値として、前の数字×10000+後ろの数字の値をつくって、それともとの値のペアにする。
それを<=>でソートする。
mapで、ソート結果からもとのデータ部分を取り出す。
835: 2020/12/09(水)00:39 ID:LWKBPFtb(2/7) AAS
要は、map{...} sort{...} map{...}となる。
変換のためのループが2回入る(map)が、記述としてはあっさりなので、特殊なソートをしたいときにはよく使われる有名な方法。
伝わるかな？ｗ
836(1): 2020/12/09(水)08:45 ID:UMU4oc+t(1/7) AAS
それで書けるなら、sort { } でも書けるよね
837(2): 2020/12/09(水)09:35 ID:sn/SI4a+(1) AAS
>>833
こんな感じかな。デバッグはしていないが。
@newlist = sort compare @oldlist;
sub compare{
my ($ap, $bp) = @_;
($ap1, $ap2) = $ap=~/([0-9]+)\-([0-9]+)/;
($bp1, $bp2) = $bp=~/([0-9]+)\-([0-9]+)/;
return 1 if $ap1 > $bp1
return -1 if $ap1 < $bp1
# $ap1 == $bp1;
return 1 if $ap2 > $bp2;
return -1;
}
838: 2020/12/09(水)10:27 ID:LWKBPFtb(3/7) AAS
>>836>>837
それだと、要素の比較のたびに、値の変換処理が行われる。
比較は何度も行われるため、変換処理が軽くない場合、ソート全体としてかなり重くなりうる。
すくなくとも「スマート」とは言えない。
そこで、変換結果をキャッシュするような形になるのがシュワルツ変換。
知らんならググれ。
839: 2020/12/09(水)10:46 ID:zREBomTd(1) AAS
sort { s1($a) <=> s1($b) } keys %x;
sub s1 {
shift =~ /(¥d+)-(¥d+)/ && 100*$1+$2
}
sortならこんなかんじ
840: 2020/12/09(水)10:47 ID:UMU4oc+t(2/7) AAS
順番が変わるだけで処理量は変わらんでしょう
どっちにしろ重い
次にソートする時はソート対象が変わっているんだから、キャッシュできない
有効な局面もあるんだろうけど、今回に関してはトリッキーなだけでメリットがない
841(1): 2020/12/09(水)10:51 ID:UMU4oc+t(3/7) AAS
次のソートじゃなくて、1回のソート内部の複数の比較に対してか
あー、確かに速くなりそうな気がする
処理系が気を利かせて変わらない気もする
842: 2020/12/09(水)11:29 ID:LWKBPFtb(4/7) AAS
>>841
ソートの内部処理が想像できんのか？
もとの並び方にはよるが、ふつうは大きく異なる。
「処理系」とやらが気を利かせられる範疇ではない。
比較処理にsayでもいれて試してみろっつーんだよ。
843(1): 2020/12/09(水)12:58 ID:UMU4oc+t(4/7) AAS
内部の話だからsayでは判らんだろ
関数で評価しないといけないと判っていて、動的に処理する必要も無いんだから、
評価済みのテーブルを内部に持たせようというのは自然な発想
844: 2020/12/09(水)13:12 ID:/81rDyGm(1) AAS
>>843
試してから言え。
きっと、想像以上の出力が出てきて驚くから。
845(2): 2020/12/09(水)13:44 ID:UMU4oc+t(5/7) AAS
判ってないのかな
処理速度に配慮した処理系があっても不思議ではないという話
手元で試して遅かったとしても、全ての処理系に対する証明にはならない
846: 2020/12/09(水)14:16 ID:AA5LXV3h(1) AAS
>>845
痛々しいからもうやめとけ
上下前次1-新書関写板覧索設栞歴
あと 156 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.017s