[#11507] parser generator — Minero Aoki <aamine@...>

あおきです。今年もよろしくおねがいいたします。

54 messages 1999/01/07
[#11508] Re: parser generator — ttate@... 1999/01/07

立石です。

[#11511] Re: parser generator — shugo@... (Shugo Maeda) 1999/01/08

[#11514] Re: parser generator — keiju@... (石塚圭樹 ) 1999/01/08

けいじゅ@日本ラショナルソフトウェアです.

[#11517] Re: parser generator — aamine@... 1999/01/08

あおきです。

[#11519] Re: parser generator — keiju@... (石塚圭樹 ) 1999/01/09

けいじゅ@日本ラショナルソフトウェアです.

[#11521] Re: parser generator — aamine@... 1999/01/10

あおきです。

[#11537] Re: parser generator — keiju@... (石塚圭樹 ) 1999/01/12

けいじゅ@日本ラショナルソフトウェアです.

[#11564] Re: parser generator — Minero Aoki <aamine@...> 1999/01/14

あおきです。

[#11566] Re: parser generator — keiju@... (石塚圭樹 ) 1999/01/14

けいじゅ@日本ラショナルソフトウェアです.

[#11585] Re: parser generator — aamine@... 1999/01/16

あおきです。

[#11611] Re: parser generator — keiju@... (石塚圭樹 ) 1999/01/18

けいじゅ@日本ラショナルソフトウェアです.

[#11643] [racc] help me [Re: parser generator] — keiju@... (石塚圭樹 ) 1999/01/20

けいじゅ@日本ラショナルソフトウェアです.

[#11648] Re: [racc] help me [Re: parser generator] — kjana@... (YANAGAWA Kazuhisa) 1999/01/20

In message <199901200705.QAA02084.keiju@bc.mbn.or.jp>

[#11659] Re: [racc] help me [Re: parser generator] — keiju@... (石塚圭樹 ) 1999/01/21

けいじゅ@日本ラショナルソフトウェアです.

[#11661] Re: [racc] help me [Re: parser generator] — kjana@... (YANAGAWA Kazuhisa) 1999/01/21

In message <199901210735.QAA03189.keiju@bc.mbn.or.jp>

[#11664] Re: [racc] help me [Re: parser generator] — keiju@... (石塚圭樹 ) 1999/01/21

けいじゅ@日本ラショナルソフトウェアです.

[#11681] Re: [racc] help me — Minero Aoki <aamine@...> 1999/01/22

あおきです。

[#11685] Re: [racc] help me — keiju@... (石塚圭樹 ) 1999/01/23

けいじゅ@日本ラショナルソフトウェアです.

[#11687] Re: [racc] help me — aamine@... 1999/01/23

あおきです。

[#11740] Re: [racc] help me — keiju@... (石塚圭樹 ) 1999/01/26

けいじゅ@日本ラショナルソフトウェアです.

[#11759] Re: [racc] help me — aamine@... 1999/01/27

あおきです。

[#11783] Re: [racc] help me — keiju@... (石塚圭樹 ) 1999/01/28

けいじゅ@日本ラショナルソフトウェアです.

[#11793] Re: [racc] help me — aamine@... 1999/01/28

あおきです。

[#11812] Re: [racc] help me — keiju@... (石塚圭樹 ) 1999/01/29

けいじゅ@日本ラショナルソフトウェアです.

[#11553] はじめまして&環境変数についての質問 — Atsuko Yoshida <atsuko@...>

こんにちは。はじめまして。

22 messages 1999/01/14

[#11587] Array.new([SIZE]) — Yoshinori Toki <toki@...>

土岐です。

15 messages 1999/01/17

[#11621] Segmentation fault — polygon <polygon@...>

ポリゴンです。

18 messages 1999/01/19

[#11660] ruby 1.2.2 released — matz@... (Yukihiro Matsumoto)

Hi.

19 messages 1999/01/21

[#11720] ruby からの MSAccess への DB アクセス方法 — ymaekawa@...

はじめまして前川@NECと申します。

13 messages 1999/01/25
[#11723] Re: ruby からの MSAccess への DB アクセス方法 — たむら けんいち <t9655832@...> 1999/01/25

たむら です。

[#11746] (joke :-) ruby chip — Noritsugu Nakamura <nnakamur@...>

14 messages 1999/01/26
[#11747] Re: (joke :-) ruby chip — "Kikutani, Makoto" <kikutani@...> 1999/01/26

Wed, Jan 27, 1999 at 07:19:14AM +0900 において

[#11803] Array クラス — hisanori@...

松尾です。

36 messages 1999/01/29
[#11804] Re: Array クラス — matz@... (Yukihiro Matsumoto) 1999/01/29

まつもと ゆきひろです

[#11807] RE: Array クラス — ozawa@... 1999/01/29

最近Beなさくです。

[#11813] RE: Array クラス — ISII takesi <isii@...> 1999/01/29

石井です。

[#11814] Re: Array クラス — keiju@... (Keiju ISHITSUKA) 1999/01/29

けいじゅ@日本ラショナルソフトウェアです.

[#11815] Re: Array クラス — matz@... (Yukihiro Matsumoto) 1999/01/29

まつもと ゆきひろです

[ruby-list:11770] Re: Array.new([SIZE])

From: Yoshinori Toki <toki@...>
Date: 1999-01-27 17:56:20 UTC
List: ruby-list #11770
土岐です。

From: Koji Arai <JCA02266@nifty.ne.jp>
Subject: [ruby-list:11768] Re: Array.new([SIZE])
Date: Thu, 28 Jan 1999 00:04:22 +0900

> > Array.new()の仕様が今のようになった以上、
> > 「メモリのリアロケートが裏で発生するかもしれない」
> > という考えは捨て去るのが健康的かも知れない。
> 
> こういう理想がある以上、やはりこれを追求するべきだ
> と思いました。このような考えに至ったのは、

蛇足ですが、理想に半歩近づくかもしれない方法を考えてみました。既に考慮
されてたらごめんなさい。

現在の配列の実装は、配列の大きさが拡張されるとき内部のメモリは常に「必
要な大きさ + 16」に拡張されるようです。これだと、配列が大きくなるにつ
れてコピーの手間がどんどん増えてしまいます。一方、配列が短くなるときは
内部のメモリが配列の長さの 1/10 になったときに内部のメモリが切り詰めら
れているようです。ソースの array.c をざっと眺めてみたところ、こうなっ
てるように思ったんですけど、あってるでしょうか?

この仕様だと、長さゼロの配列に push して巨大配列を作ろうとすると、追加
する数 n に対して内部メモリーの再確保&複製が O(n) 回生じます。一方、
巨大配列から pop していくときは、切り詰める長さが配列長に応じて変化す
るので、内部メモリーの再確保&複製は O(log n) 回生じることになり、この
コストは push していく時と比較してかなり低いです。

# うーん、ビッグ O 記法の使い方ってこれでいいんだろうか。
# 本当は再確保&複製の手間の考慮しないといけないような気がする。

だったら配列を拡張するときも内部のメモリの増分を現在の長さに応じて変化
させればいいのではと考えて、とりあえずパッチを作ってみました。内部のメ
モリは現在の長さに対して 3/2 倍ずつ増えてゆきます。当然ながら、メモリ
は余分に消費することになります。メモリよりも速度を優先する人にはいいか
も。

*** array.c.orig	Thu Jan 28 02:10:25 1999
--- array.c	Thu Jan 28 02:13:11 1999
***************
*** 231,237 ****
      }
  
      if (idx >= RARRAY(ary)->capa) {
! 	RARRAY(ary)->capa = idx + ARY_DEFAULT_SIZE;
  	REALLOC_N(RARRAY(ary)->ptr, VALUE, RARRAY(ary)->capa);
      }
      if (idx > RARRAY(ary)->len) {
--- 231,241 ----
      }
  
      if (idx >= RARRAY(ary)->capa) {
! 	int capa_inc = RARRAY(ary)->capa / 2;
! 	if (capa_inc < ARY_DEFAULT_SIZE) {
! 	    capa_inc = ARY_DEFAULT_SIZE;
! 	}
! 	RARRAY(ary)->capa = idx + capa_inc;
  	REALLOC_N(RARRAY(ary)->ptr, VALUE, RARRAY(ary)->capa);
      }
      if (idx > RARRAY(ary)->len) {
***************
*** 304,310 ****
  {
      ary_modify(ary);
      if (RARRAY(ary)->len >= RARRAY(ary)->capa) {
! 	RARRAY(ary)->capa+=ARY_DEFAULT_SIZE;
  	REALLOC_N(RARRAY(ary)->ptr, VALUE, RARRAY(ary)->capa);
      }
  
--- 308,318 ----
  {
      ary_modify(ary);
      if (RARRAY(ary)->len >= RARRAY(ary)->capa) {
! 	int capa_inc = RARRAY(ary)->capa / 2;
! 	if (capa_inc < ARY_DEFAULT_SIZE) {
! 	    capa_inc = ARY_DEFAULT_SIZE;
! 	}
! 	RARRAY(ary)->capa+=capa_inc;
  	REALLOC_N(RARRAY(ary)->ptr, VALUE, RARRAY(ary)->capa);
      }
  
----------------------------------------------------------------------------
土岐 仁謙	神戸大学高エネ研 M1
URL: http://www3.phys.sci.kobe-u.ac.jp/~toki/index.html
PGP fingerprint = D0 A8 90 AB 73 F8 34 FE  CE CA DB BF 01 30 C0 35

In This Thread