Page2RRS

• 07 Nov 2009 00:29

  2009年11月06日

  ・ジパング 今週発売のモーニングで最終回を迎えたわけですが、 あっけに取られたというかなんというか。 【ネタバレ】ジパングの最終回を予想するスレ:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ

  ついったやらやりながらだとペース上がらなくてだめね。 まあほかでも訳そうって人は少なからずいるだろう。たぶん。 はてなブックマーク - If Programming Languages Were Real Persons | Jeez Tech

  
  If Programming Languages Were Real Persons | Jeez Tech
  What if programming languages were real persons like you and me? What if they were 
  parts of families and had relations and affairs? Have you ever thought of going to a 
  supermarket and Visual Basic was the young woman waiting in the line in front of you?
  
  Well we did. We let our imagination free and we came up with pictures and facts :). We 
  hope you enjoy this article since it only exist as a geeks humor. Names are fictional 
  and images has been collected from Google's search.
  
  Charlie C
  
  C is a 70 years old man that knows a lot. Perhaps too proud to reveal what he knows 
  and sometimes too cryptic. He is a very strict person that follows his way of doing 
  things and nothing seems possible to change his mind. In the past he was known as one 
  of the strictest teachers in the Devel City university.
  
  C は多くのことを知っている70歳の男性です。ときおり自分の知っていることを明かす (reveal) 
  ことを誇りすぎることがあり、そしてときに暗号的過ぎることがあります。彼は自分のやり方を
  頑ななまでに守り。彼の考え方を変えることのできる人などいないように思われるとても厳格な
  人物です。過去において彼はDevel City university における最も厳格な教師たちの一人に数え
  られていました。
  
  C can make you happy or disappoint you so much that, you want go for one of his sons 
  or daughters. It depends on how much you try to learn his ways. The more you try the 
  more he gives you.
  
  C はあなたを幸福にするかもしれませんが、さもなければあなたを失望の淵に追いやってしまい、
  あなたは彼の息子たちや娘たちの一人のところへ行きたくなるでしょう、どうなるかはあなたが
  彼のやり方を学ぶのにどのくらい熱意があるかによります。あなたがトライすればするほど彼は
  あなたに与えてくれるものが増えるでしょう。
  
  C has been the main builder behind large projects like the Linuxious stadium and other 
  large scaled buildings that we all use. He still works as a freelancer engineer and 
  has involved in many other projects. Even at his age and with a lot of competition 
  mainly from his son C++, C is still the choice of many companies to do things in Devel 
  City.
  
  C は Linuxious stadium のような大規模プロジェクトの影で main builder でありその他のわ
  たしたちすべてが使っている大規模なビルディングに使われています。彼は今でも freelancer 
  engineer として働いていて、多くのプロジェクトに参加しています。彼のその年齢にもかかわ
  らず、彼の息子のC++をはじめとして多くの競争相手がいるのにC は今でも Devel City で何か
  を行うために多くの企業で選択されています。
  
  C has 3 daughters :
  
  C には三人の娘
  
      * Perl,
      * Java and
      * C#
  
  and one son, C++.
  と、C++という一人の息子がいます
  
  Vin C++
  
  KD-Scientist-GS72C++ is 45 years old teacher at the Devel City university, following 
  his father's steps to become as respected as he is. He loves his father so much that 
  tried to continue his work and knowledge. Being a younger man than C though, made him 
  a much more friendly guy, in the means of approach, than his father. He works as a 
  teacher in the Devel City university and his students have a love and hate affair with 
  him.
  
  KD-Scientist-GS72C++ は Devel City university において彼が尊敬する父親のように歩んでき
  た 45歳の教師です。彼は自分の父親をとても愛していて、父親の仕事と知識を受け継ごうと努
  力しています。それでも C より若い男であることが彼を父親よりもより近づきやすい男にして
  います。彼は Devel City university で教師として働いていますが、彼の学生は彼に対して愛
  情と憎しみとを抱いています。
  
  C++ often lets his students choose their way in the learning process since he follows 
  a different way of teaching approach than his father used to. His students love him 
  because he lets them work in their own way but sometimes they fear his inheritance of 
  C.
  
  C++ は父親が使っていたものとは別の教え方をしているので彼のやり方を学生に選ばせることが
  よくあります。彼の learning process において彼の学生は彼を愛していますそれはC++ が彼特
  有のやり方で学生たちを働かせていますが、ときおり C から受け継いだものを使いたいことも
  あるからです。
  
  Most of his followers admire his wide range of knowledge that mixes C's knowledge with 
  knowledge gained through his life.
  
  彼の followers のほとんどが彼の、Cの知識と彼がその人生を通じて得たものをあわせた広範囲
  にわたる知識に感心しています。
  
  There are also a lot of people that criticise him of being so wide. Most of the time 
  they talk about him as a direct descendant of C that has adopted all of his fathers 
  disadvantages and added some more to it.
  
  C++ のあら捜しを行う人もたくさんいます。ほとんどの場合彼らは C++ を父の disadvantages 
  すべてを取り込み、さらに何かを付け加えているC の直接の後継者として話をしています。
  
  
  C++ has spent many years to get rid some of his fathers bad habits and never does 
  things not needed. He prefers to put as much effort as needed to do the job right and 
  never bloats things. This is why his projects are much more targeted than his fathers.
  
  C++ は何年もかけて彼の父親の悪習 (bad habits) のいくつかと決して必要にはならない事柄を
  取り除こうとしてきました。彼は仕事を正しく行うのに必要な努力をすると同時に決して何かを
  壊したりしないことを好みます。これが、彼のプロジェクトが父親よりもより多く target と
  なっているかの理由です。
  
  Montana Perl
  
  Perl is a 37 years old young woman and works as a data analyst at the department of 
  linguistics in Devel City. As a sexy young woman, her colleagues just love to work 
  with her.
  
  Perl  は37歳の young woman で、Devel City の department of linguistics で
  データアナリストとして働いています。セクシーで若い女性なので、彼女の同僚は
  一緒に働くことに喜びを感じています。
  
  She is extremely clever, very strict when it comes to how people treat to her but has 
  added great value to her carrier with her regular way of expressing things and her 
  unique way of finding needles in haystacks. Many of her colleagues depend on Perl to 
  fix things and they call her a “Swiss knife”.
  
  Her father was a source of inspiration for Perl. Many of her father's principles was 
  inherited and many more added to her philosophy of how things should be done and why. 
  She is a rather laconic character that speaks less but means a lot.
  
  Perl finds it easy to work on different environments and performs well with a little 
  help from her beloved husband Cygwin who always supports her ambitions.
  
  Perl loves to travel. Each summer she goes around the world, most of the time she will 
  be riding a camel in Africa and many times you might find her playing Golf in the 
  State of the union stadium.
  
  Perl は旅をするのが大好きです。毎年夏になると彼女は世界中を飛び回り、ほとんどの場合は
  アフリカのらくだにまたがって旅していて、State of the union stadium でゴルフをプレイす
  るところをあなたも何度も見かけているかもしれません。
  
  She also loves poetry and runs her own amusement company named Acme which aids in 
  teaching young kids the way to do things the funny way.
  
  彼女はまた詩を愛し、Acme という名前の子供たちに funny way で物事を行うやり方を教えるの
  を手助けする会社を経営しています。
  
  Bianca Java
  
  Java is a 35 years old sexy young woman and a mother also. Being so young and mature, 
  Java is one of the most popular women in Devel City. She is very adoptable and can 
  work everywhere. Her name comes as a feature in many projects and a lot of companies 
  want their projects to carry her “Java powered” signature of quality.
  
  Java は35歳の sexy young woman であり同時に母親でもあります。
  若いけれども成熟していて、
  Java は Devel City におけるもっとも名の知れた女性の一人です。
  彼女はとても adoptable かつどこででも働くことができます。
  彼女の名前は多くのプロジェクトで comes as a feature で、
  多くの企業が自分たちのプロジェクトに
  “Java powered” という彼女のsignature of quality を望んでいます。
  
  Being C++'s sister, does not stop Java to be one of the biggest competitors of her 
  brother. As a woman, Java is clean and manages to keep garbage out of her place, clean 
  and clear. She works at JVM, a company specialized in ports creation.
  
  Being C++'s sister,
  does not stop Java to be one of the biggest competitors of her brother.
  As a woman, Java is clean and manages to keep garbage out of her place,
  clean and clear.
  彼女は specialized in ports creation された会社である JVMで働いています。
  
  Java loves sun. Each summer is Java's favorite season and she loves playing with Duke 
  in the beach.
  
  Java は太陽が大好きです。夏は彼女の好きな季節であり、海辺で Duke と遊ぶことが大好きで
  す。
  
  Java has created her own legacy, just like her father did and has 2 daughters that 
  promise to be as competitive as she is. Her daughters also work at JVM and stand out 
  from the crowd of talented persons in Devel City. Their names are:
  
  Java は自分自身の kegacy を作り出しています。それはちょうど彼女の父親が行ったのと同じ
  くpromise to be as competitive as she is.な二人の娘がいます。彼女の娘たちもまた JVM で
  働いていてDevel City の才能ある人々の crowd から stand out しています彼女たちの名前は:
  
      * Groovy and
      * Scala
  
  Jessica Groovy
  
  Groovy is 21. Young but her impact in Devel City is bigger than just big. She was 
  greatly inspired by her aunt Perl and her best friend Ruby.
  
  Groovy is laconic and very expressive like her aunt, got any possible knowledge of her 
  mother and added some cool ways to do her job in JVM. Most of the time she guides her 
  colleagues in a rather strange way… by adding question marks (?) wherever she thinks 
  something should be checked again.
  
  Jane Scala
  
  Scala is 22 years old. She is sweet and quite friendly but many of her friends in Devel 
  City feel a little thread when it comes to job opportunities. The case of Twittorix, 
  where the managers of the project asked Scala to do the job, made Ruby upset.
  
  Scala like her little sister Groovy, got all of her mother's knowledge and took it to 
  a newer level. Not only Scala can work the same way as her mother does, she can also 
  make new ways of working and doing things for a specific job which makes her a 
  valuable part of JVM. Scala gets a lot of suggestions to work for NET (another ports 
  creation company) but she is too busy with JVM at the moment that makes this a little 
  hard to accomplish.
  
  Pierson PHP
  
  PHP is 29 years old and Java's bitter friend. PHP runs her own company in Devel City 
  called Zendix and has become one of the worlds well known ladies because of her easy 
  way of doing things, her adoption of new technologies and a large fun club that make 
  her desirable and efficient.
  
  PHP was a student of C, Java's father and used to work with Perl where she got her 
  expressive character and power. Being a very beautiful woman, PHP has a lot of 
  admirers that range from newcomers to Devel city, to old residents. She might seem 
  easy but she needs a lot of attention to master her ways.
  
  Sometimes her affairs are too strong and sometimes people seem to glance at Java and 
  Ruby which makes her trying to add some of Java's charm into her character. This, 
  makes a lot of people say that PHP tries to become Java in some way.
  
  Recently, PHP was voted as the 3rd most popular person in Devel's city Object's 
  awards.
  
  Mary JavaScript
  
  JavaScript is often confused with Java in Devel City especially from newcomers… but 
  you know what they say that: “where no smoke without fire”. Many rumors say that 
  JavaScript is Java's half sister but she denies it, so does Java.
  
  JavaScript is 32 and her close friends call her “JS”. She is very strict but relaxed 
  also. This, makes her a wonderful companion for most of Devel's residents and she is 
  very popular since a large part of the city has used her services at least once.
  
  JS is one of the most successful women in Devel City. She runs a network of more than 
  20 companies some of which are unique.  jQuerysius, Mootool and Dojodic, to name a few 
  are popping out each and every day.
  
  She works silently and a lot of people think that she spents most of her time to make 
  her job look glamourus. Most of her competitors say that she is good only for that but, 
  to be honest, all of them know that there are some things that only she can accomplish.
  
  She believes that to become successful, you have to keep your friends close and, your 
  enemies closer. So, she tries to cooperate and coexist with all other businessman and 
  businesswoman in Devel City. Everybody loves her even if she breaks things up 
  sometimes.
  
  Angelina Ruby
  
  Ruby is a good friend of Groovy. She is 20 years old and she is one of the upcoming 
  names in Devel City mainly because of her professional maturity and the way she 
  manages to do a job cleanly and fast. Although Scala, Groovy's sister, got a big job 
  from Ruby's hands (case of Twittorix), Ruby is still considered as one of the best 
  professionals out there.
  
  Ruby, became one of the most successful women in City of Devel, after the creation of 
  her Rails company  and got a lot of fame. She also inspired many other famous women in 
  Devel City to start their own Rails-like companies with PHP being one of them with 
  Symfoniac LTD.
  
  She is a very calm person and not fond of surprises. When she works, she wants to have 
  everything there as helpful as it can be for her and her co-workers. Most of the time 
  she applies the POLS principle to her job.
  
  Some Devel City residents state that, if Perl goes away one day, Ruby will do the job 
  as good as she does and with more freedom than with Perl.
  
  Ruby believes in one principle: “Divide and Conquer”, this is why she has divided 
  all of her company groups into Gems. Ruby just needs to use a gem to do a particular 
  job.
  
  Jack Python
  
  One of the most known and respected persons in Devel City, is Python. A 54 years old 
  construction builder. Some people believe that he can use the power of his brain to do 
  magic. Python works in a rather modern way that his age implies and here is where he 
  amazes Devel's residents.
  
  Python always finds new ways of doing things. If a tool is good to work with, Python 
  will use it with no particular disadvantages. Python is one of the best man in Devel 
  to work with since he allows anyone to work the way he thinks is better.
  
  His favorite words are spam and eggs and his projects are named after his nickname. 
  For example PyGameing station and PyS6000 which was a futuristic TV series.
  
  Python as his name implies, is a snakes lover and has a lot of them as pets. His 
  favorite pet is an Anaconda.
  
  His work has been approved by some of the biggest companies in Devel City like 10^10, 
  Yohaaa and DERN.
  

  • ねこ画像を下さい(画像有り） ぶる速-VIP
  • HAMA.jp Autumn 2009 - Google Docs
  • 同人ソフト館が移転したため、隣り合わせて�... on Twitpic
  • Twitter / d'Arc (だるく): シリアルポートを知らない子供たち……まぁ最近のPCに ...
  • グーグル、JavaScriptプログラミングツールをリリース:ニュース - CNET Japan
  • 便利なタイの結び方一覧:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ
  • sed-4.0.7のアドレス拡張(STEP) - 初学者の箸置
  • Form.Visibleは状態ではなく手続き？ - 初学者の箸置やっていて少しわからなくなったのが、デフォルトでフォームを表示させない方法。
  • Vim Plugins You Should Know About, Part V: a.vim - good coders code, great reuse
  • Steve Jobs は過去１０年で最高の CEO：フォーチュン誌特集 « maclalala2
  • Is C faster than C++? - Stack Overflow
  • Twitter / 未知の生物たかの: 歴研のタクティカルシミュレーションゲームマニアが「世 ...
  • 電子式数値積分計算機＝「ENIAC」 - パソコン創世記 弾道研究所はENIACの完成以前から、より強力な計算機を開発するようムーアスクールに要請していたが、 この次期計画は弾道研究所の顧問でもあったフォン・ノイマンの構想にもとづいて進められることになった。 　EDVACと名付けられた次のマシンに関する、1945年6月にまとめられた最初の提案書で、 フォン・ノイマンは「電子的な記憶装置に収めた計算手順を読み出して実行する」プログラム内蔵方式を提案した。この記述はちょっと違うんでないかい? フォン・ノイマンとエッカートが協力して進めることになったEDVACの開発計画は、両者の発想の食い違いもあって大幅に遅れ、 同方式の1号機はイギリス、ケンブリッジ大学のモーリス・V・ウィルクスによって1949年5月に作り上げられたEDSACとなった。この辺も表現が微妙というか。
  • 温故知新。15年ぶりぐらいに使ったUnixの機能 - motd - — ありえるえりあ
  • 中置記法から逆ポーランド記法への変換 - みずぴー日記
  • 金儲けというタブー - Rails で行こう！ その中でも Delphi という Objective Pascal ベースの開発ツールは実によくできていた。 ライバルの Microsoft の Visual Basic なんかまったく目じゃなかった。 でも、商売上勝ったのはどちらか、というと Microsoft なんだよね。悲しいことに。 Borland はマーケティングと財務で Microsoft に負けた。
  • A Japanese Teenage Boy Improved Ruby 1.9 Performance Up to 63% : ruby
  • オープンソースへの参加は難しくない(4)お金を出す 後編 - 生越昌己のオープンソースGTD：ITpro
  • Ask Programming: Is this a real programming language? If so, what is it? (Screengrab from Jurassic Park) : programming
    http://i.imgur.com/niitu.jpg
    キーワードが大文字になっているからModula-2かと思ってしまった。 が、IFに必須のENDIFがないから違うというのに気がついた。
  • Linkers and Loaders
    These are the manuscript chapters for my Linkers and Loaders, published by Morgan-Kaufman. See the book's web site for ordering information.
  • If Python's supposed to be a better language than Perl, then why does Perl have so many more -- and more up-to-date actively-maintained -- modules? : programming

  Permalink  |  View Entire Page

• 06 Nov 2009 02:07

  2009年11月05日

  ・那須野トレードかあ

  ■_ 心をこめてセル操作

  いやまあなんというか。

  マクロを組んで作業するのは実力ではないですか？ -OKWave
  私の職業は一般事務（派遣）ですが少しVBAがわかるのでルーチン化できるものはマクロを組ん
  でいます。そうすることによってエクセルで1時間かかる作業が1分で終わることがあります。
  
  なので職場では「仕事が早い、仕事ができる」と評価されることがありますが
  先日先輩に怒られました。
  
  内容は
  ・VBAを使うのはずるい・それは実力ではない
  ・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
  ・マクロを組むのはズルとしているのを同じ
  と。
  
  確かに手作業で行なえば周りの人と同じくらいの速さなので
  周りと同じ環境であれば（マクロを組まなければ）仕事が早いとは言えないかもしれません。
  
  しかし業務をどう効率よくして作業をするかを考え実践するのも仕事のうちだと思うのですが
  私の考えは間違ってますか？
  入力ミスもチェックするコードを書いたので、ミスはありません。
  
  「マクロを組んだ方が仕事が早くなるがそれが仕事ができる人には繋がらない」
  のでしょうか？
  
  職場にはマクロを組めるのは私しかいません。
  仕事が早く終わったからって遊んでるわけではないし
  時間が余ればさらに効率化できないかを考えたりしています。
  

  こんばんは。
  
  今回の話は、屁理屈でしかありませんが、老婆心なのかもしれませんが、マクロを使わない論理
  というのもないとは言えません。
  
  上の人に、こう聞かされることが多いのです。
  
  「この職場で、あなた一人しか使えないから困るのです。あなたがいないときに、この職場では、
  それを直すことも、止めることも出来ないのでは、困ってしまうのです。あなたが、完璧なマク
  ロを作るというなら、私は、何も言いません。ただ、そう言えないのなら、マクロはこの職場で
  は禁止します。他の社員が使えれば困らないのですが、特別に他の方にも学んでもらうというこ
  とも出来ません。」ということです。必ず、こういうときに、ゼロサムの論理を持ち出してくる
  ものです。
  
  実際、Office にマクロを使えないオプションを付けた人たちは、かなり手厳しい考え方を持っ
  ています。もともと、Office のセキュリティの設定の発想というのは、素人マクロの根絶から
  始まっていて、ウィルスの防除というのは建て前です。素人マクロによって、仕事をダメにされ
  たくない、ということです。だから、プロと認可された、CAデジタル証明付き以外は動かないと
  いう選択肢もあれば、Accessはできませんが、VBAそのものを使用できなくする選択もあるわけ
  です。
  
  マクロは使える人にとっては、何でもないことでも、使えない人には、迷惑だと感じる人がある
  し、いろんな屁理屈は聞かされます。会社によって、Office の開発の人が泣かされるようなリ
  クエストはいくつもあります。職場でマクロ禁止令が出ていないだけ救われています。
  
  質問者さんは経験がないようですが、会社内で、反感を持った人がいたり、社内で一人しか使え
  ない環境では、いろんな妨害や言いがかりがあります。Officeのトラブルがあると、すぐに、そ
  ちらに結び付けます。コンピュータに詳しいと自負している人から、Ver.4 マクロ関数を使った
  だけで、Office やPC自体を危険にさらすとか、言われたことがあります。
  
  それとは逆に、マクロやコンピュータに本当に詳しいということを会社に知られている場合は、
  相当に実力がないと、自分を滅ぼすことになりかねません。趣味でやっている範囲ならそれでも
  よいです。しかし、会社に開発するために入社したわけではないし、数万円の手当てをもらった
  ぐらいでは合わないことが多いのです。一人で、期限があるマクロの開発がどんなに大変か考え
  たほうがよいです。上司が理解があればよいのですが、無理難題を言ってくることがあります。
  社命として受けた以上は断れないし、かといって、特別手当が出るわけでもありません。
  
  私の同僚や先輩は、コンピュータの仕事で一人で必要以上の仕事を抱えて、それに反して、薄給
  で身体を壊して会社を辞めていきました。ともかく、私は、押せ押せの楽観論だけはお勧めしま
  せん。
  
  まず、周りにマクロというものは、どういうものか、大雑把なところぐらいは理解してもらって、
  便利で誰も使えるのだ、というところを宣伝していくことではないか、と思います。
  

  あなたは間違っていないと思います。仕事をするのに自分の持ってるすべてを利用すrのは当た
  り前の話でそれこそが実力です。単なる負け惜しみでしょう。
  
  ただ一つだけあなたが考えておかなければならないのは仕事はチームワークです。
  別にその先輩とやらに気を使えと言ってるわけではありません。他人より早く仕事ができたのな
  らそのマクロの完成度を高めて他人でも使えるようにして、全体の効率を上げるようにしましょ
  う。これはある意味マクロを最初に作るより時間もスキルも必要なことかもしれません。
  自分だけが使えるマクロというのはまだ「未完成」だというくらいに思ってください。
  今、少しづつ顕在化している問題に「Excelレガシー」という問題があります。
  そういうレベルの低い先輩とやらは無視して業務の効率化を目指しましょう。
  
  

  その先輩はクソ以下ですね。この話みて腹立ちました。
  
  (1)VBAを使うのはずるい
  →いうてるやつがせこい企みを持っているだけ。
  (2)それは実力ではない
  →言うてるやつが実力が無くて悔しいだけ。
  (3)仕事が早いというのは同じ環境でどれだけ間違いがなく
  効率よく作業ができるかだ。
  →間違いなくも効率よくもマクロの長所ですから。意味不明。
  (4)マクロを組むのはズルとしているのを同じ
  →殴っておあげなさい。
  

  これは、あまり笑えませんが、似たような笑い話があります。
  
  エクセルでデータを集計して、経理部門で請求書を発行してもらっているのですが、請求書の明
  細として一覧を印刷して添付しています。経理の女性は毎月、一覧表の金額を電卓で計算して合
  計金額を確認しています。他の部署のことなので口出しはしていません。その先輩もそのうちに
  気がつくと思います。
  
  >職場にはマクロを組めるのは私しかいません。
  
  これを機会にエクセルがわかる人を増やすのも試練かと思います。
  
  もうひとつVBAの知識よりも、仕事の流れを理解しOA化するルーチンを発想できる能力（経験も
  必要）が重要でそれをスムーズに業務に取り入れる能力(人間関係を含めて）の方がより難しい
  事であることも忘れないでください。せっかく作ってあげたシステムがあるのですが、意地で使
  ってくれなかったケースもあります。理由は、今まで長い間、この方法で仕事をしてきて問題起
  こしていない、導入することで仕事の流れが変わる、どこのものともわからない（新しい）もの
  は取り入れる必要がないと思っているようでした。
  
  何にでもつき物ですが、新しいことをなすには産みの苦しみが伴い、
  出る釘は打たれるものです。
  

  ご質問者の考え方は間違っていませんよ。
  安心して下さい。
  
  きっとねぇ、マクロやVBAの出来ない人間が
  出来る人間(つまりご質問者)にやっかんでるだけです。
  
  まるで、斧やノコギリだけで仕事してる木こりが
  チェーンソーや電動ノコを使う林業従事者を
  『機械を使うなんてずるい』
  と言ってるようなもの。
  
  確かに完成したマクロやVBAをつかう時点では時間はへりますが実はマクロやVBAを組むのに時間
  がかかります。(勿論、その道の勉強していればその時間は減らせますが)
  
  それと派遣の場合は、貴方の後の後任が、マクロやVBAが出来ないことで、派遣先からいい評価
  が得られなくなって迷惑するとでも言いたいのでしょうね。
  
  自信を持って、なおかつそれをひけらかさず淡々と自分の業務をこなしてください。
  

  他の方とまったく同意見ですが
  >・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
  
  同じエクセル使ってますが・・・・
  VBA使えるってこと自体が仕事が出来てるわけです
  自分で覚える努力もしないでなにいってんでしょうかねその人は
  （ただのひがみにしか聞こえません）
  
  VBA知っててもコーディングが遅ければ（BUGとか含んで）
  手作業のほうが早いって可能性もないとはいえません
  
  あなたの考えは間違ってないと思いますよ
  

  先輩の発言は全く間違っています。
  
  おそらくマクロで仕事をしていることが問題なのではなく、先輩が質問者さんと肌が合わないた
  めいちゃもんを付けたのでしょう。マクロと仕事に関しての論理的な問題ではなく、お二人の感
  情的な問題と推測します。
  
  先輩への対応としては、マクロを使って有無を言わせぬ結果を出して圧倒するか、先輩の仕事を
  マクロでさっと片付けてあげて懐柔するか、その両方を使い分けるか、などが考えられます。
  
  別のカテゴリーでもっといい回答があるかもしれません。
  

  ＞・仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
  アホか。VBAで自動化するのはそのためだろうが。お前は永遠に手作業してろ。
  というのが正直な感想。
  言わせておけばいいんじゃないですか。
  

  ■_ 例外な話

  
  www.hans-eric.com » The Bad Practices of Exception Handling
  
  The Bad Practices of Exception Handling
  
  October 31st, 2009
  Hans-Eric
  
  Exception handling has truly been a blessing to us software developers. Without it, 
  dealing with special conditions and writing robust programs was a lot more painful. 
  But, like any powerful tool, badly used it could cause more harm than good. This 
  article name the top three on my Exception handling bad practices list, all of which I’
  ve been practicing in the past but now stay away from.
  
  例外処理はわたしたちソフトウェア開発者に対して本当に福音をもたらしました。例外処理がな
  ければ、特殊な条件を処理して robust なプログラムを書くことが格段に painful なものにな
  っていたでしょう。しかし他のどんな強力な道具もそうであるように、例外処理も使い方を間違
  えたときには利点よりも害をなすことのほうが大きくなってしまいます。
  このアーティクルでは、わたしが経験したことがあるけれども今はもう使っていないような例外
  処理のバッドプラクティスリストのトップスリーに名前をつけます。
  
  Swallowing Exceptions (例外を飲み込む)
  
  Have you ever come across code like this?
  あなたは次のようなコードを見たことはありませんか?
  
  try
  {
     DoSomeNonCriticalStuff();
  }
  catch (Exception e)
  {
     // エラーを無視 (Ignore errors)
  }
  
  DoStuffThatMustBeDoneDispiteAnyErrorsAbove();
  
  Of all the bad exception handling practices, this is the worst since 
  it's effect is the complete opposite of the programmer's intention. The 
  reasoning goes something like this: Catching exceptions where they don't 
  hurt makes my program more robust since it’ll continue working even when 
  conditions aren’t perfect.
  
  すべての例外処理のバッドプラクティスの中でも、プログラマーの意図を完全に捻じ曲げる効果
  があるのでこの例は最悪のものです。その理由は次のようなものに帰着します:
  例外が傷つけない場所での例外の捕捉はプログラムをより頑健 (robust) なものにします。
  それはコンディションが万全でないときであっても処理を継続するからです。
  
  The reasoning could have been valid if it wasn't for Fatal exceptions; 
  
  Here described by Eric Lippert.
  
  以下は Eric Lippert による説明です。
  
       Fatal exceptions are not your fault, you cannot prevent them, and you cannot
       sensibly clean up from them. They almost always happen because the process is
       deeply diseased and is about to be put out of its misery. Out of memory,
       thread aborted, and so on. There is absolutely no point in catching these
       because nothing your puny user code can do will fix the problem. Just let your
      “finally” blocks run and hope for the best.
  
  
       Fatal exceptions はあなたの間違いではありませんし、あなたはそれに逆らうことは
       できません。そして sensibly clean up することもできません、それが発生してしま
       ったときにはほぼ常にプロセスは deeply diseased であり、何かしら出力しようにも
       使える資源はほとんどありません。メモリーの枯渇、スレッドの中断、などなどとい
       ったものを捕捉するポイントは絶対にありません。なぜならあなたの puny user コー
       ドでその問題を解決できることなどないからです。
       Just let your “finally” blocks run and hope for the best.
  
  Catching and ignoring these fatal exceptions makes your program less robust since it 
  will try to carry on as if nothing happened in the worst of conditions, most likely 
  making things worse. Not very Fail fastish.
  
  こういった fatal exeptions を捕捉してから無視することで、最悪の事態が起きたのにも関わ
  らず何事もなかったかのように処理を続けてしまおうとするので、あなたのプログラムをやわな
  ものにしてしまいますがそれはさらに自体を悪くすることがほとんどです。
  Not very Fail fastish.
  
  So, am I saying that ignoring exceptions is bad and should always be avoided? No, the 
  bad practice is catching and ignoring general exceptions. Specific exceptions on the 
  other hand is quite OK.
  
  ではわたしは例外を無視することは悪いことで、いつでも avoid すべきといっているのでしょ
  うか? いいえそうではありません。bad practice なのは一般的な例外 (general exceptions) を
  捕捉しておいてそれを無視することです。特定の例外について行うのは問題なく OK です。
  
  try
  {
     DoSomeNonCriticalStuff();
  }
  catch (FileNotFoundException e)
  {
     // So we couldn't find the settings file, big deal!
  }
  
  Bad example, I know, but you get the point.
  悪い例ですが、ポイントをつかめたのではないでしょうか。
  
  Throwing Exception (例外の送出)
  
  Here's another bad practice I come across every now and then.
  
  throw new Exception("No connection!");
  
  The problem is that in order to handle Exception we have to catch Exception, and if we 
  catch Exception we have to be prepared to handle every other type of Exception, 
  including the Fatal exceptions that we discussed in the previous section.
  
  この問題は例外を処理するためには例外を捕捉しなければならないということで、仮にわたした
  ちが例外を捕捉したら先のセクションで述べたような Fatal Exception も含め、例外のすべて
  の型を処理するために例外を prepare しなければなりません。
  
  So, if you feel the need to throw an exception, make sure it's specific.
  
  ですから、あなたが例外を送出する必要性を感じたならそれを確実に specific なものにします。
  
  throw new NoConnectionException();
  
  If the idea of defining lots of specific exceptions puts you off, then the very least 
  thing you should do is to define your own application exception to use instead of the 
  basic Exception. This is nothing I recommend though, since general exceptions, like 
  ApplicationException, violate the Be specific rule of the Three rules for Effective 
  Exception Handling.  It’ll make you depend heavily on the message property to 
  separate different errors, so don’t go there.
  
  特定の例外を大量に定義するのを避けることを考えているのなら、あなたが行うべき the very 
  least thing はbasic Exception の代わりに使う自分独自のアプリケーション例外 
  (application exception)を定義することですが、わたしはこれをオススメしません。なぜなら 
  ApplicationException のような一般的な例外は効率的な例外処理のための三つのルールを破っ
  てしまうことになるからです。異なるエラーを分離するためにはメッセージプロパティにとても
  依存することになるので、
  so don't go there.
  
  Overusing exceptions (例外の使いすぎ)
  
  Exceptions is a language construct to handle exceptional circumstances, situations 
  where a piece of code discovers an error but don’t have the context necessary to 
  handle it. It should not be used to handle valid program states. The reasons are:
  
  例外とは exceptional circumstances やエラーを検出すべきコード片を置く situnations を 
  handle するための language construct ですが、エラーを処理するために必要なコンテキスト
  を持っていません。それは正当なプログラムの状態を取り扱うのに使うべきものではありませ
  ん。その理由には以下のものがあります:
  
      1. Performance. Throwing an exception with all that's involved, like building
         a stack trace, will cost you a second or so. Probably not a big deal, which
         is why I concider the second argument more serious:
  
         性能。例外を、スタックトレースの構築のようなそれを引き起こした原因すべてと
         一緒に送出するのは will cost you a second or so.
         大きな問題ではないかもしれませんが、わたしが第二引数がもっと重要であると
         考えている理由です:
  
  
      2. Annoyance. Debugging code where exceptions are a part of the normal execution
         flow can be frustrating. (Eric Lippert calls these types of exceptions Vexing
         exceptions, see the link at the beginning of this article)
  
         わずらわしさ。通常実行フローの一部として例外に置かれているデバッグ用コードは
         フラストレーションとなる可能性があります。
         (Eric Lippert はこの種の例外を Vexing exceptions と呼んでいます。
         see the link at the beginning of this article)
  
    …
  
  Those were the three misuses of exception handling I concider worst. 
  
  What's on your list?
  
  Cheers
  

  ■_ 本日の巡回から

  • プログラミングHaskell - あどけない話オーム社の方曰く「ソフトカバーなのに、ハードカバーのように平たく開ける特殊な製本」だそうです。
  • Plan 9 Gear : Plan 9 Gear based on artwork by Renee French
  • 社内の人間関係について -OKWave
  • お勧めのFPGAボード 2009年版 - ぱた☆へね
  • 技術者の価値 - CROSSFIRE DBとコンパイラの日記
  • ASCII.jp：レールガンのオープニングはアキバで壊滅！
  • Twitter / ユーリヤ・ティモシェンコ: @satomit このやろう、すごい勢いでフォローさ ...
  • Twitter / takeo: そろそろ単行本出版して RT @shelarcy: ...
  • Twitter / HiraSosuke: 祝一平の「試験に出るX1」が読みたい....誰か持っ ...
  • はてなブックマーク - そろそろPHPerにとどめを刺しておくか - 八発白中
  • そろそろPHPerにとどめを刺しておくか - 八発白中
  • Hexenkessel - pdl2h: starchart: ...
  • 小中学生でプログラミングスキルのある方に質問です。 - Yahoo!知恵袋
  • 南條愛乃が加入しテレビアニメ『とある科学の超電磁砲』のオープニングテーマ『only my railgun』を歌う新生『fripSide』を直撃インタビュー！！
  • To Moose Or Not To Moose の邦訳を本人っぽく書き直してみた - iYappoList::Writing
  • true tears ブルーレイ化 正式決定ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ !!!!!:【2ch】ニュー速VIPブログ(`･ω･´)
  • Mooseの為か、そうでないのか - taro-nishino の日記
  • モジラ，「Firefox」プラグインの検査用Webページをオープン - 世界のセキュリティ・ラボから：ITpro
  • 日常の .NET 開発のための関数型プログラミング
  • 「Twitter」と「2ちゃんねる」、イザというとき役に立つのはどちら？ - japan.internet.com Webテクノロジー
  • 大至急解答お願いします！私は今大学でMATLABのSimulinkを用いた解析の研究に取り... - Yahoo!知恵袋
  • 場外乱闘×2 プログラマで、生きている: ワークVSライフ＝デスマーチ真の顧客満足を目指して: 就職活動中の皆さまへ
  • ウェブっ子「愛憎」 - 将来が不安

  Permalink  |  View Entire Page

• 05 Nov 2009 09:59

  2009年11月04日

  ・配下 なーんか使い方が気になるんだよなw

  ■_ 熱血だねえ

  知恵袋から。

  (cache) C言語について質問です（為替） - Yahoo!知恵袋

  
  C言語について質問です（為替） - Yahoo!知恵袋
  C言語について質問です（為替）
  
  double 型の外部変数 dollar (1ドルが何円かを表す) と euro (1ユーロが何円かを表す) を宣言せよ.
  
  円の金額を受け取り, それをドルに両替したとき何ドルになるかを返す関数 double 
  yen2dollar(double) を作成せよ. ただし, 円をドルに両替するときのレートは, dollar+1.0 と
  する. (例えば, 1ドル110円のとき, 円をドルに両替すると1ドル111円で計算される.)
  
  円の金額を受け取り, それをユーロに両替したとき何ユーロになるかを返す関数 double 
  yen2euro(double) を作成せよ. ただし, 円をユーロに両替するときのレートは, euro+1.0 とす
  る.
  
  ドルの金額を受け取り, それを円に両替したとき何円になるかを返す関数 double 
  dollar2yen(double) を作成せよ. ただし, ドルを円に両替するときのレートは, dollar-1.0 と
  する.
  
  ユーロの金額を受け取り, それを円に両替したとき何円になるかを返す関数 double 
  euro2yen(double) を作成せよ. ただし, ユーロを円に両替するときのレートは, euro-1.0 とす
  る.
  
  今日のドルのレート (dl) とユーロのレート (er) を受け取り, 次のように両替の金額の例を表
  示する関数 void kawase_example(double dl, double er) を作成せよ.
  
  dollar に dl を, euro に er を代入する.
  "今日のレートは 1 ドル xxx.xx 円, 1 ユーロ xxx.xx 円です." と表示する.
  10,000円をドルに両替するといくらになるかを yen2dollar を用いて計算し,
  "10000 円をドルに両替すると xxx.xx ドルになります." 等と表示する.
  同様に 10,000円をユーロに両替した結果を表示する.
  100 ドルを円に両替した結果を表示する.
  100 ユーロを円に両替した結果を表示する.
  100 ユーロを円に両替し, それをドルに両替した結果を表示する.
  同様に, 100 ドルを円を経由してユーロに両替した結果を表示する.
  
  main 関数から
  kawase_example(111.0, 130.0);
  を呼び出すようにせよ.
  
  というプログラムの作り方がわかりません。
  どなたか回答お願いします。
  
  

  
  いくつかある中の4つの問題 「円→ドル」、「円→ユーロ」、「ドル→円」、「ユーロ→円」 
  は、一つが分かれば他のものも全て同じ要領で解けるものですよね。このことから、あなはがこ
  の問題のこと自分でまったく考えようとしていないのは明らかです。
  
  宿題を少しも考えもせずに、丸投げして他人にやらせようというのは、無礼な行為であり、ふさ
  わしくありません。いくつかポイントがありますが、どこまで分かっていて、分からないのはど
  ういう点なのでしょうか。
  
  (1) グローバル変数 dollar、euro の宣言の仕方は分かりますか？ (問題 1)
  (2) 為替の計算式とそれを C言語で表現するコードは分かりますか？ (問題 2～5)
  (3) 関数というものの作り方は分かりますか？ 関数で数値を返す方法は分かりますか？ (問題 2～5)
  (4) dollar に dl を、euro に er を代入する方法は分かりますか？ (問題 6)
  (5) 関数を呼び出して、返された値を受け取る方法は分かりますか？ (問題 6)
  (6) 計算結果の数値を表示する方法は分かりますか？ (問題 6)
  (7) そもそも、各設問で何を求められているか、内容を全て理解していますか？
  
  質問するときは、どんな点が分からないのか要点を絞るべきですね。そうでなくては、あなたの
  投稿は、「質問」ではなく、ソフトウェア作成業務の「発注」、あるいは、宿題代行サービスの 
  「発注」 になります。もっとも、実際のところ、あなたが求めているのは「解説」ではなく、
  プログラムコードの「納品」や「サービスの提供」なのでしょうけど、それは、知恵袋の趣旨で
  はないと思いますよ。
  
  http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1016477880
  
  本当に知りたい/理解したいと思っているのであれば、この投稿自体は取り消して、
  上記のような、要点を絞った形で再投稿することをお奨めします。
  
  【このような回答を書く意図】
  
  このような宿題丸投げなどのマナー違反について、無視したり何も言わないのではなく、不快に
  思っている人がいることを明示するべきだと思っております。それは、そうすることで、
  
  (1) 質問投稿者に、自分がしてることが他人を不快にさせているということを認識してもらうためであり、
  (2) これを読んでいる他の質問投稿者予備軍にもそれを伝えるためであり、
  (3) 「レポート代行愛好家」の方たちにも、考え方の説明や大した解説もない、ほとんどコード
  だけの回答をする 「自販機式」 の回答を自重するよう求めるものになるからです。
  
  こういうものは、そのコミュニティーの「空気感」「雰囲気」のものなので、そのためにも、陽
  に空気を作るべきだと思っています。ご理解・ご賛同いただければ幸いです。
  
  

  最近Ｃ言語で「宿題やってくれ」系の投稿が多くなってきていると思います。中には... - Yahoo!知恵袋
  
  最近Ｃ言語で「宿題やってくれ」系の投稿が多くなってきていると思います。中にはせっかくコ
  ードを教えたのに質問を取り消してくる輩もいます。皆さんはこの現状どう思いますか？
  
  私的には、そういった投稿をするのは容認はしますが、やはりどこまでやったのか、どこがわか
  らないのかを記載してほしいですね。ただきいてくるひとはコピーアンドペーストの無限ループ
  だと思うので、何か対策があっても効果ないと思いますが、どうでしょう？
  
  

  ベストアンサーに選ばれた回答
  
  同感です。
  これまで、なるべくプログラムソースで回答してきました。
  自分にとって最も楽で、誤解の無い回答を出しやすかったからです。
  しかし、
  丸投げそのもの質問について、どうしたものかと迷っていました。
  時間を使って提供しても右から左にコピーして提出し、おしまい・・・
  という状況を思うと、回答するのが余りにも馬鹿げていて白けます。
  しかし、
  習いはじめの時期には、人のコードを見習うことで、思いもかけず
  楽にプログラムを体感することができた、昔の経験を忘れられず、
  何がしかの役に立って、興味を持ち、自立してくれるのではないかと
  幾つかの回答を出してきました。
  
  でも、あまりこの手の質問と回答が横行すると、レベルの大差から
  多くの方の邪魔になり、あげくに本カテゴリの質を落としかねません。
  以後、この手の回答は一切遠慮することに致します。
  
  

  こういった輩が専門学校卒に多い。
  入社して使おうとしたら、全くプログラムの組み方が判っていない。
  
  「わかる言語はなに？」
  
  「HTMLです」
  
  「．．．」
  
  

  宿題やってくれ，を含めた，ふざけた質問．
  それに対して，説教たれたり，からかったりする行為をとめる気はありませんが，
  少なくとも，質問者のことを少しでも考えるなら，
  きっちり黙殺してあげるのが親切というものではないでしょうか．
  
  

  だいたいあーいう人って捨てアカで投稿してるでしょ？
  コインももうほとんど残ってないような。
  
  答えるだけ無駄だね。
  努力の跡が見える人には答えてあげてますが・・・
  
  問題だけのせたものに
  答える人がいるから調子にのるんだろうけど。
  個人的には↑この人が一番悪いと思ったり・・・
  
  
  まぁ不適切な投稿で通報が一番ですかね。
  

  まあ、「教えてやる蔵」くんは結構いるしなあ。 んで、今日の丸投げから。

  構文解析のLL法についての質問（今日中）です。 a+b-c×d と a+b-(c*d)をそれぞれLL... - Yahoo!知恵袋
  
  構文解析のLL法についての質問（今日中）です。
  a+b-c×d
  と
  a+b-(c*d)をそれぞれLL法で構文解析するというものですが、この解析の際の
  構文解析表を作ってください、どうかお願いします。
  
  色々ありまして教授にこの課題を明日（今日）までにやってこいと言われました。
  実のところこういった知識はあまりなく自分でやってみたところ表をもとに
  構文を解析することまではどうにかできたのですがディジタル信号的な
  表現（集合）あたりがどうしてもできません。
  期日は今日の昼過ぎおそらく２時までには出さないといけないので急ではあるの
  ですが、どなたかどうかご教授ください！お願いします。
  
  補足
      あと、よろしければ構文解析表が作る際のコツなどありましたら是非教えてくださると
      大変うれしいです。
  
  

  文法自体の規定(生成規則）がないけど。。。
  
  
  ＞ 構文解析表を作ってください
  
  LL(1) として、非終端記号(行）と終端記号（列）に対する生成規則を示す表のこと？
  
  しかし、「やってこい」というのは、「理解してこい」という意味でしょうから、
  他人に作成してもらっても。。。と思いますけどね。
  わからないならわからないと＜教授＞に正直に言うほうがいいでしょう。
  「どうかご教授ください！お願いします。」は、＜教授＞に言うべきかと。
  
  
  ＞ ディジタル信号的な表現（集合）
  
  よくわかりません。。。。^^;
  

  構文解析表? にしたって、文法も提示せずに構文解析しろって。 まあふつーの算術式くらいを考えりゃあいいのだろうけど。 期日は今日の昼過ぎおそらく２時までには出さないといけないので どうなったのかなあw

  構文解析表が作る際のコツなど …小学校からやり直せ。

  ■_ PLnews

  昨日見落としていた○|￣|＿

  V6 Thompson Shell Port 20091029 Released @ PLNews: Programming Language News
  Nov. 02, 2009
  V6 Thompson Shell Port 20091029 Released
  2009-11-02 19:52:21
  Languages :: Shell
  
  V6 Thompson Shell Port 20091029 has been released. It includes two ports of the 
  original /bin/sh from Sixth Edition UNIX.
  
  This release includes: a fix for a compilation problem on AIX, code cleanups, 
  installation updates, and other changes. 
  
  

  Retro Forth 10.2.1 Released @ PLNews: Programming Language News
  Nov. 02, 2009
  Retro Forth 10.2.1 Released
  2009-11-02 19:43:53
  Languages :: Forth
  
  Retro Forth 10.2.1 has been released. RetroForth is a free, portable Forth implementation.
  
  This release includes a bug fix. 
  

  レトロブームでも来てるのか? Retro, A Minimalistic Forth ふむ。 Retro is a small, minimalistic Forth dialect capable of running on all modern operating systems. It can also be used on cell phones and PDA's supporting MIDP and on most modern web browsers (excluding IE). osaka.forth のネタになるかしらん。

  ■_

  あ、*_s ですか。さすがにこっち方面何もしないというのはないですよね。

  めもがき:2009年11月4日分
  2009/11/4(Wed)
  ○ 今日
  @
  
  kbkさんとこ
  
      そいや、strlcpy/strlcat 的なものの追加はないんだろうか?
  
  TR24731-1のstrcpy_s/strcat_sですね。 
  http://www.open-std.org/JTC1/SC22/WG14/www/projects#24731-1
  

  ■_ Histroy of Programming Languages

  An introduction to functional programming
  
  An introduction to functional programming
  
  Way back in the dark ages when I first started programming in BASIC, the first 
  stumblingblock I encountered on my quest for programmerhood was the statement:
  
  わたしが最初に BASICでプログラミングを始めたころの暗黒時代に戻ります。
  programmerhood のわたしの quest において、
  わたしが遭遇した最初の stumblingblock は次の文 (statement) でした
  
      X = X + 1
  
  My High School algebra training screamed out, “That's an unsolvable equation!”  I 
  soon learned that the above is not an equation at all, but rather a command.  It's not 
  a statement of fact, it's an instruction to alter a fact.  This command begins with an 
  implied “LET” (in some BASIC versions, “LET” is even required) and the correct 
  interpretation of the command relies not only on the previous value of X, but also on 
  the fact that the right side is evaluated before the assignment occurs.
  
  わたしの高校の algebra training は絶叫に覆われました。“That's an unsolvable equation!”
  (これって解けない等式じゃん!)即座にわたしはこの行が等式なのではなくてコマンドであると
  いうことを学びましたこれは実際には文ではなくて、alter a fact のための命令でした。この
  コマンドは implied “LET” から始まっていて(一部のBASIC ではこの“LET”は必須でした)、
  実行前の X の値にだけ依存するのではなく代入が行われる前に右辺が評価されるようコマンド
  は正しく解釈されました。
  
  I may have had good reason to be uneasy about statements like this one, which change 
  the state of a program when executed.  They're the bread and butter of imperative 
  programming, but there is an alternative:  functional programming, or FP for short.  
  Functional programming seeks to eliminate the need for program state by expressing all 
  computations in the form of functions that take arguments and return values, without 
  introducing side effects.  Those functions read much more like functions in 
  mathematics, where “X = X + 1″ could never work.  In fact, functional programming is 
  based on the lambda calculus, which is a mathematical system for investigating 
  functions.
  
  プログラムが実行されたときに状態が変化するという、このような文の uneasy でないことの
  きちんとした理由がわたしにはわかったかもしれません。それは命令型プログラミングの bread
  and butter (パンとバター?) でしたがalternative がありました。関数型プログラミング 
  (functional programming)、略して FP がそれです。関数型プログラミングは、関数 form の中
  でのすべての計算を関数が受け取る引数と関数の戻り値で表現することによって、副作用を持ち
  込むことなしにプログラムの状態の必要性を除去することを狙っています。そのような関数は数
  学で言う関数にもっと近いもので“X = X + 1”のようなものは決して動作しません。実際、関
  数型言語はinvestigating functions のための  mathematical system であるλ算法 (lambda 
  calculus) にその基礎を持っています。
  
  Thinking functionally, “X + 1″ is really syntactic sugar for an “add” function 
  that takes two arguments, X and 1.  The reassignment of the result to X, however, 
  creates a situation where program state is dependent on how many times we've executed 
  this piece of code.  In truly functional programming, that reassignment would not be 
  allowed.  Instead, the result could be assigned to a new variable, and the scope of 
  that assignment would be clearly delineated.  For instance, in Haskell:
  
  関数的に考えると、“X + 1” は二つの引数 X と 1 とを取る関数 “add” に対する構文糖 
  (syntactic sugar) です。しかし X に対する結果の再代入は、プログラムの状態が何回このコ
  ード片を実行したのかということに依存してしまう状況を作り出します。本物の関数プログラミ
  ングではそういった代入は許されず、代わりに結果は新しい変数に代入され、その代入のスコー
  プは明確に delineated (言葉で描写) されます。たとえば Haskell では:
  
  let y = x + 1
  in dosomethingwith y
  
  The value of x + 1 (which is shorthand for “add x 1″) is assigned to a variable y 
  that is defined for the statement “dosomethingwith y” (assuming here that the 
  function “dosomethingwith” is defined elsewhere).  Note that outside the “in” 
  clause, “y” is undefined.  If you need the value of y outside this statement, then 
  it must be returned.
  
  (“add x 1 ”の略記である) x + 1 の値は“dosomethingwith y”という文で定義されている変
  数 y に対して代入されます(ここでは関数 “dosomethingwith”がどこか別の場所で定義されて
  いることを仮定しています)。“in” clause の外側では“y”が未定義であるということに注意
  してください。If you need the value of y outside this statement,この文の外側で y の値
  が必要であるのなら、それを return しておかなければなりません。
  
  What do these restrictions buy you?  A little thing called referential transparency, 
  for one.  For any set of arguments to a given function, that function will always 
  return the same value.  The function isn't modifying some persistent state that will 
  make it behave differently, depending.  The advantage is that you can employ the 
  function in any context and rely on its results.  It not only makes understanding the 
  code easier, but it also facilitates moving things around without breaking them.
  
  これらの制限の中で、あなたが関心を持つのはどれですか?ある人にとっては referential 
  transparency (参照透過性)と呼ばれる little thing です。任意の引数の集合が関数に与えら
  れたとき、(同じ引数に対しては) 関数は常に同じ値を返します。その関数は関数の動作を変え
  てしまうようななんらかの永続的な状態 (persistent state) を変更したりしませんその利点は 
  in any context and rely on its results で関数を手に入れることができるということです。
  それはコードを理解しやすくするだけでなく
  but it also facilitates moving things around without breaking them.
  
  
  As you might expect, avoiding program state changes makes looping difficult.  
  Functional languages tend to use recursion instead.  For instance, to count from 1 to 
  10 in Lisp:
  
  すでに気がついているかもしれませんが、プログラムの状態を変更することを排除することがル
  ープを難しいものにしてしまいます。関数型言語ではループの代わりに再帰を使う傾向があり
  ます。たとえば Lisp で 1 から 10 まで数えるには:
  
  (defun count (start end)
    (cond ((< start end) (cons start (count (+ 1 start) end)))
          (t (list start)))
  )
  
  (count 1 10)
  
  The function “count” defines counting from start to end as a list composed of start 
  followed by counting from start+1 to end － unless start is not less than end, in which 
  case it's just a list composed of start.  This function recurses until start and end 
  are equal, then concatenates the list in reverse order as it unwinds (We could have 
  included a case to handle if start is greater than end, but we're keeping the example 
  simple here.  As it stands, that case would simply return a list containing only start). 
  In case you're not used to Lisp, let's translate that logic into JavaScript:
  
  この “count”関数では start に続き start+1 から end までの数え上げが続いているリストを対
  象とする start から end までの数え上げ (counting) を行う関数を定義しています。start が 
  end よりも小さくないということがない限りこの関数は start と endが等しくなるまで再帰し
  ていって、再帰の巻き戻しとして逆順でリストを連結していきます(start が end よりも大きか
  った場合の対処を含めることも可能でしたがここでは例を単純にするためにそれをしていません。
  仮にそのようなことになった場合には start だけを含むリストがただ単に返されます)。もしあ
  なたが Lisp に慣れ親しんでいないのであればこのロジックを JavaScriptに移植してみてくだ
  さい:
  
  function count(start, end) {
    if (start < end)
      return start + ' ' + count(start+1, end);
  return start.toString();
  }
  
  alert(count(1,10));
  
  Using this approach instead of a “for” loop means never having to worry if someone 
  reuses the variable “i”.  On the other hand, languages that don't optimize recursion 
  well can quickly degrade in performance when this technique is overused.
  
  “for” ループの代わりにこのアプローチを使うことで誰かが“i”という変数を再利用してい
  ないか心配しないで済むようになります。その一方で、それほど再帰を最適化できないような言
  語はこの手法が使われすぎたときにすぐに性能が劣化してしまう可能性があります。
  
  Another feature of functional languages is the ability to pass functions as arguments 
  to functions, and call those function arguments as needed (known as “lazy 
  evaluation”).  In many languages, whenever you encounter a function reference, the 
  function is evaluated and the result is returned in its place before anything else 
  happens.  But in a language that supports higher-order functions and lazy evaluation, 
  the function is not evaluated until the function to which it is being passed decides 
  to do so.  This is most useful for passing callbacks to handle special cases and 
  events.  In many languages, you have the option of doing either one.  For instance, in 
  JavaScript:
  
  関数型言語のもう一つの機能が、関数の引数として関数を渡しておいて、必要なときに引数で渡さ
  れたその関数の呼び出しを行えるというものです (これは遅延評価 “lazy evaluation” として
  知られています)。多くの言語では関数のリファレンスに遭遇したときは常にその関数は評価さ
  れ、返されたその評価結果を呼び出しが行われた場所に(関数呼び出しに代えて)置きます。しか
  し高階関数と遅延評価をサポートしている言語では引数として渡されたその関数が実行されるこ
  とが決定するまで評価は実行されません。これは特別なケースやイベントをハンドルするために
  コールバックを渡すのに最も有用です多くの言語では、これを行うかどうかの選択の余地があり
  ます。たとえば JavaScript では:
  
  function doit() { alert("ya!"); return null;}
  
  function test(arg) {
    alert("in test!");
    if (arg != null)
      arg();
  }
  
  test(doit());    // Eager evaluation
  test(doit);     // Lazy evaluation (遅延評価)
  
  The first call to test executes doit beforehand, while the second call doesn't execute 
  doit until the third line of the test function.  Thus, the order of alerts in the code 
  above is “ya!”, “in test!”, then “in test!”, “ya!”.  The parentheses on the 
  function argument (or not) indicates whether to invoke the function immediately or 
  simply pass a reference to it.
  
  test の最初の呼び出しは test の前に doit を実行します。一方、二番目の呼び出しでは test 
  関数の三行目になるまでは doit を実行しません。したがって、上記のコードで alert される
  順番はまず“ya!”, “in test!”, が出力され、続いて “in test!”, “ya!”が出力されりま
  す。関数の引数である doit についていたりついていなかったりしているカッコはその関数が即
  座に実行されるのか、ただ単に関数への参照を渡しているだけなのかを示しています。
  
  Lisp is the first language to be based on the lambda calculus, and it was first 
  specified in 1958.  It boggles the mind to realize how much more advanced Lisp was 
  (and still is) than its contemporaries, especially back in the days of Fortran and 
  COBOL.  Programming languages ever since have learned from Lisp, especially as 
  functional languages have become more popular.
  
  Lisp はλ算法 (lambda caluclus) にその基礎を置いた最初の言語で、1958年に最初に 
  specifiy されました。Lisp が同時代の言語、特に Fortran と COBOL に対してどれほどより先
  進的であったか (かつ今も先進的であるか)を考えると驚くべきものがあります。特に関数型言
  語がより一般的になってきているので、プログラミング言語は今もなお Lisp から学ぶものがあ
  ります。
  
  But Lisp is not a purely functional language.  It supports multiple programming 
  paradigms, and it allows you to create side-effects, like modifying program variables 
  during the execution of a function.  A couple of pure functional languages are gaining 
  in popularity: Haskell and Erlang.  Most other languages that support functional 
  programming are actually multi-paradigmatic, providing imperative and object-oriented 
  features as well.  These include (but are by no means limited to) Scheme and Clojure 
  (more functional Lisp dialects), OCaml, F# (pretty much OCaml for .NET), Ruby, Python, 
  JavaScript, and Perl.   Even C# and Java have added some functional support, notably 
  lambdas.
  
  しかし Lisp は純粋な関数型言語ではありません。Lisp は複数のプログラミングパラダイムを
  サポートしていて、関数の実行時にプログラムの変数の値を変更してしまうような副作用も許し
  ています。Haskell と Erlang という二つの関数型言語が popularity を獲得しつつあります。
  この他のほとんどの関数型プログラミングをサポートする言語は実際にはマルチパラダイム的な
  もの (multi-paradigmatic) であり命令型プログラミングの機能やオブジェクト指向プログラミ
  ングの機能も同じように提供しています。そういった言語にはScheme や Clojure (より関数型
  的な Lisp の変種), OCaml, F# (.NET 向けの OCaml にとてもよく似たもの), Ruby, Python, 
  JavaScript, Perlといったものがあります(ただしこれしかないわけではありません) C# や 
  Java でさえ lambda のような関数言語的なサポートを幾つか追加されています。
  
  It's also possible to use a functional style in some languages that don't specifically 
  provide support for FP. For instance, even in C you can compose an application 
  entirely from functions, avoid creating side-effects within them, and pass functions 
  as arguments with lazy evaluation (using function pointers).
  
  関数プログラミングを特にサポートしていないような言語を使っても関数型スタイルを行うこと
  も可能です。たとえば C でさえ、副作用を排除した関数とからアプリケーション全体を 
  compose することができますし、引数として関数を渡す(関数ポインターを使って)ことで遅延評
  価を行えます。
  
  There are many other features generally associated with functional programming that we 
  don't have space to cover here － for instance, lexical closures and continuations.  
  While not strictly required to qualify a language as supporting FP, they certainly 
  make the functional programming paradigm more powerful.
  
  そのほかにも一般的に関数プログラミングに結び付けられている多くの機能があります。たとえば
  ここではスペースの関係で触れなかったレキシカルクロージャやコルーチンがそれです。言語が
  関数プログラミングのサポートを strictly に要求されなかった間に、そういったものが関数プ
  ログラミングというパラダイムをより強力なものにしていったのです。
  
  How does functional programming relate to object-oriented programming?  OOP 
  concentrates on modeling the actors in an application, and using methods to describe 
  the functions that each one can perform.  FP starts instead from the overall process, 
  and includes objects only as needed.  Sometimes one paradigm works better, sometimes 
  the other.  For instance, objects are useful when describing complex systems with many 
  parts, like an ERP application.  Mathematical computations and document composition, 
  on the other hand, are processes that often really don't need any discussion of the 
  actors involved.  The reason so many so-called functional languages actually support 
  both paradigms is because both are useful in different situations, and often in 
  combination.
  
  関数プログラミングはオブジェクト指向プログラミングとどのように関係しているのでしょうか? 
  OOP (オブジェクト指向プログラミング) はアプリケーションにおけるアクターのモデリング 
  (modeling the actors) に集中していて、メソッドをそれぞれが perform 可能な機能を記述す
  るために使っていますFP (関数プログラミング) はプロセス丸ごとではなくて必要な分だけオブ
  ジェクトを取り込むことから始めますたとえばERP アプリケーションのような多くのパーツを持
  った複雑なシステムを記述するときにオブジェクトは有用です一方で、アクターを inviolve す
  るようなディスカッションを一切必要としないことがしばしばあるプロセスです。その理由は関
  数型言語と呼ばれるものの多くが、異なる状況において両方ともがそれぞれ有用な局面が存在し
  組み合わされることが頻繁にあるために実際には両方のパラダイムをサポートしているからです
  
  
  This post is part 5 in a series on the history of programming languages.  Here are 
  links to parts 1 through 4:
  
     1. The Early History of Programming Languages
     2. An introduction to object oriented languages
     3. The ascent of scripting languages
     4. Scripting Languages and the Web
  
  

  • Reading Gauche/04.項目列挙/VMインストラクション - Mona OS developers Wiki
  • Reading Gauche VM インストラクション全制覇 - ひげぽん OSとか作っちゃうかMona-
  • 仕事が面白く感じる心理状態～フローな状態について － ＠IT自分戦略研究所
  • はてなのインフラを支える「ビジョン」と「数値化」 － ＠IT自分戦略研究所
  • 日本のセキュリティチーム (Japan Security Team) : セキュリティ インテリジェンス レポート 第7版(2009年上半期)
  • 秋の新プリンターは無線LAN対応が標準に：IT羅針盤
  • 脆弱性検査は“黒”から“白”へ（その1）：三輪信雄「ここが変だよみんなの対策」
  • Windowsの歴史 Windows Server 2003 R2編：安定性と先進性の両立目指す「R2」の先駆けとなったOS - builder by ZDNet Japan 「R2」（リリースアップデート2）だ。そうだったのか＞R2
  • [Lua]関数と変数は装備しないと意味ない以上でわかるとおり、グローバル変数のfoo, hoo に関数の内容を代入するためにスクリプト全体を実行する必要があるのです。
  • (6)夜勤だけでない？当直の仕組み - データセンターの舞台裏：ITproと言いながら，私はENTERキーを軽い気持ちで押そうとしたときに，隣に座っていた先輩から怒鳴られた。 　「なんだ，そのへっぴり腰なキー入力の仕方は！」
  • 『PageRankの数理』 » val it: α → α = fun -もっとも、基本的には数学で語られるので(たまにMATLABのサンプルコードが載っているが、MATLABというあたりに著者のお里が知れるよな)、
    MATLAB 使うとなにかいけないことがあるのでしょうか?
    このあと「脅し」が入ってるけどせっかくの向井さんのオススメだから読んでみるかなあ
  • Paste number 89718: Multiple Common Lisp Implementations on Win32 + ASDF setup HOWTO

  ■_ とらんすふぉーむ!

  FORTRAN Ⅳ [chaika]
  662 デフォルトの名無しさん [sage] 2009/11/04(水) 04:25:42 ID: Be:
      フォートランって
      フォーミュラ・トランスフォーマー
      っていうくらいだから、
      科学計算以外には向いていないのか？ 
  
  663 デフォルトの名無しさん [sage] 2009/11/04(水) 07:40:31 ID: Be:
      大昔は、他に言語がなかったから、なんでもFortranで書いてた。
  
      現在では、向いてる向いてない以前に、言語として古い。 
  
  664 デフォルトの名無しさん [] 2009/11/04(水) 12:39:17 ID: Be:
      そういえばなんでトランスフォーマーなんだろう
  
      数式を変形せずになるべくそのままの書き方でコードにできるのが
      Fortranのメリットだったはずなのに。
      今では使っちゃいけないとされる文関数なんてモロその名残だよね。 
  
  665 デフォルトの名無しさん [sage] 2009/11/04(水) 12:56:16 ID: Be:
      >>663
      古いゆえにコンパイラもライブラリも枯れていて、まずバグはない
      最適化も一番今の所進んでいる
  
      というわけで信頼性と速度が要求される局面で現在も使われているわけだ 
  
  666 デフォルトの名無しさん [sage] 2009/11/04(水) 13:02:36 ID: Be:
      トランスフォーマーじゃなくてトランスレータだぜ。
      FORTRAN以前は演算式もアセンブリで書かなければならなかった、
      数式そのものでプログラムを記述出来る事は画期的だったんだよ。 
  
  667 デフォルトの名無しさん [sage] 2009/11/04(水) 13:47:03 ID: Be:
      = で代入、という規則をプログラミングの世界に普及させてしまった
      張本人でもあるな。 
  
  

  Permalink  |  View Entire Page

• 04 Nov 2009 04:56

  2009年11月03日

  ・日本シリーズ ダルビッシュ登板について東スポで言及している記事が。 メジャースカウトは軒並み「なんてことするんだ」的な反応だったらしい(笑) まあそうだろうねえ。 んで、この先の展開によってはもう一回登板があるかもというのはどうなんだろう。 いくらなんでも無理だろういろいろと。 実際、投手陣は反対しているらしいし。

  ■_ \s?

  知恵袋から。

  
  egrepの使い方を教えてください。 - Yahoo!知恵袋
  
  egrepの使い方を教えてください。
  
  /etc/servicesから「22/tcp」、「53/tcp」の行を抽出する場合、下記のコマンドを
  
  実行すると抽出されます。
  
  「egrep '\s(22|53)/tcp' /etc/services」
  
  しかし、「22/tcp」だけ抽出しようと下記コマンドを実行すると、何も抽出されません。
  「egrep '\s(22)/tcp' /etc/services」
  「egrep '\s22/tcp' /etc/services」
  
  なぜ抽出されないのでしょうか？
  

  egrep '\<22/tcp' /etc/services
  
  これでいけますよ。
  詳しくはmanを読むといいですが、抜粋すると以下の部分です。
  
  The symbols \< and \> respectively match the empty string at the beginning and
  end of a word.
  
  日本語で同じような解説を書いてあるページがあったのでそのサイトより抜粋
  \<
  \m,[[:<:]]
  “単語”の先頭にマッチします。たとえば \<away は awayにマッチしますが、faraway
  にはマッチしません。
  
  ＜補足＞
  \sについて議論されてるようですが
  >GNU grep 2.5以降ではPCREを使った Perl互換の正規表現指定ができます(PCREのリンクを有効にした場合)。
  と書いてあるサイトを発見しました。
  
  とはいえ、ロケールに左右される方法では確実とはいえませんので
  Perlの正規表現は利用しない方が良いです。
  （実際こちらの環境でもLANG=Cで\sを試したところ使えませんでした）
  
  \<を利用してはいかがですか？
  
  

  egrep '\s(22|)/tcp' /etc/services
  なら 22/tcp の行だけ抽出されますね。
  でも、これってスマートじゃないですね。
  
  >なぜ抽出されないのでしょうか？
  う〜〜ん....
  もっとスマートな回答を待ちましょう！
  
  [追記]
  xinusun さん
  egrep '\s(22|53)/tcp' /etc/services
  では 22/tcp と 53/tcp の行だけが抽出されますよ。
  [追記2]
  locale は ja_JP.UTF-8 で確認しています。
  質問者が知りたい事(=私が知りたい事)は
  「22/tcp の行だけを抽出するにはどうすればよいか？」
  だと思います。
  
  [追記3]
  kuma_san_2009 さん
  > egrep '\<22/tcp' /etc/services
  なるほど、空白文字でマッチさせるのではなく、単語の先頭でマッチさせるのですね。
  これだとロケールにも左右されませんね。
  とっても勉強になりました。 m(_._)m
  早速「知恵コレクション」に追加させていただきます。
  [追記4]
  egrep でなく grep でも同じ結果が得られますね。
  http://www.kt.rim.or.jp/~kbk/regex/regex.html
  
  

  xinusunさん
  
  \s について認識違いをされていませんか?
  \s で空白文字とマッチさせたいのだと推測しますが、egrep では \s を空白文字の
  表現としてサポートしていません。
  (perl などではサポートしていますが...)
  egrep では \s は s と等価になってしまいます。
  
  > /etc/servicesから「22/tcp」、「53/tcp」の行を抽出する場合、下記のコマンドを
  > 実行すると抽出されます。
  >「egrep '\s(22|53)/tcp' /etc/services」
  
  ですから、そもそも上記ではマッチしないと思いますが、本当にマッチしましたか?
  
  egrep '[ ■](22|53)/tcp' /etc/services
  
  などとすればよいと思います。
  なお、上記において ■ はタブを表します。
  回答ではタブをそのまま書いてもそのままタブとして反映されないので、■ をタブの代替として使っています。
  実際に実行する際は、■ をタブに変更して下さい。
  
  【dolphin960413 さんへの補足】
  ロケールは何で試されていますか?
  私は C ロケール(LANG=C)で試していたのですが、ja_JP.UTF-8 などだとマッチしてしまうようですね。
  ですがこれは正しい動作なのでしょうか?
  
  私には不具合のような気がします。(ちなみに Solaris 10 + GNU egrep の環境では 
  ja_JP.UTF-8 でもマッチしません。)
  
  egrep のマニュアルページなどを確認すればお分かりになると思いますが、少なくとも egrep 
  では \s は空白文字ではありませんよね。
  
  【kuma_san_2009さん への補足というか蛇足】
  確かに grep -P とすれば Perl の正規表現が使えますが、man には以下の通り "highly 
  experimental" の記述がありますね。
  
  ちなみにロケールにより挙動が変わるのは egrep(grep -E) の時で、grep -P ではロケールによ
  らず正常に動作するようですね。
  
  -P, --perl-regexp
  Interpret PATTERN as a Perl regular expression. This
  is highly experimental and grep -P may warn of
  unimplemented features.
  
  

  PCREをリンクした場合云々て書いてあるサイトって、わしんとこか?w

  んで、GNU 拡張で \s てのはなくはないのだけど、それは Emacs で使われるもので Perlのとは意味も違ったりする。だからそもそも質問にあるようなマッチングするのは 使っているのが GNU grep であるなら考えられない。 って、OSとかもなんにも書いてないじゃないか。 みんなGNU grep だって決め打ちすぎw

  そういや -P 指定時って C locale でないと期待通りの動作しないような気がする。 そもそも PCRE自体が ASCII (ISO-8859-1か?) か UTF-8 しか受け付けないし、 UTF-8のときはなんかごちゃごちゃお約束があったような覚えがあるけど、 GNU grep の側でそれをケアしてなかったような… 面倒くさいので確かめないけどな(笑)

  ■_ C1X Standard

  gets がなくなる?

  
  C/C++ Café | C Standard : Tags : alignment
  
  C Standard
  
  The View (or trip report) from the Oct 2009 C Standard meeting
  
  Posted by Michael_Wong Nov 2, 2009
  
  This is the meeting that closes on all new features for the upcoming C1X Standard 
  (with only a few minor known exceptions)
  
  In this meeting, we processed a number of key issues. We incorporated a few additional 
  details to the memory model and concurrency proposals taken from C++ Standardization. 
  We moved zero-initialization for thread locals from 5.1.2p1 to integrate with 6.7.8p10
  
  One proposal removed gets() from the standard. This has been a problematic function, 
  and was made obsolete in TC3. The function gets() has been problematic because of 
  uncertain newline removal. The answer for a long time is to use fgets() instead.
  
  We reviewed whether C wishes to support a general syntax for attributes similar to C++. 
  This was rejected as most members were uncomfortable with the need and the 
  consequences. Instead, C will adapt keywords prefixed with a single underscore for 
  future attributes. For example, the alignment proposal will use _Align.
  
  Personally, I feel this will cause C more problems in the future as attributes 
  proliferates. But I do not think it precludes future adaption of a generalized system, 
  if the need becomes serious. although right now the consensus is that C does not want 
  general system for attributes.
  
  I also pitched the concept of a common vectorized type for C based on OpenCL. There 
  was general enthusiasm for the feature as many felt the need to drive for future 
  parallelization support based on many existing implementations of vector extensions. 
  However, due to C1X being on a schedule for completion of features, and the relative 
  size of this proposal, the members felt that this proposal need time to develop. 
  Furthermore, there was interest in maintaining close liaison with OpenCL to ensure we 
  do not create dialects of OpenCL if we were to pick subsets.
  
  In the end, the meeting closed with great belief that we are on track to have a 
  feature completed draft by the next meeting in April, 2010. This puts C on a very 
  promising track to finish on time.
  
  

  general syntax for attributes similar to C++ ってなんだろう?

  でもまあ標準規格から gets がなくなったとしても結構使われ続けたりするんだろうなあ。 そいや、strlcpy/strlcat 的なものの追加はないんだろうか?

  「トランポリン」を使うと再帰呼び出しするような関数の実装でいいことあるよ という話らしいのだけど、ここに書かれている例ではあまりありがたみは感じないなあ。

  
  Recursion Using Trampoline Functions
  Recursion Using Trampoline Functions
  
  Trampoline function is a general term used to describe an additional level of 
  indirection between the calling code and the called code. For example, a trampoline 
  can be used to intercept calls to a function and supply additional functionality that 
  was not present on the original function (see this Microsoft research project [2] to 
  understand what is possible).
  
  
  
  *トランポリン使わない版
  
  int fact(int x, int total) {
     if (x <= 1) return total;
     return fact(x-1, total*x);
  }
  int main() {
     printf("result is %d\n", fact(10, 1));
     return 0;
  }
  
  The problem with this version is that you are using the function stack to maintain the 
  intermediate results. While this is not really a problem here (because the size of the 
  integer is more of a limitation than the size of the stack), it can be a real concern 
  in other recursive implementations.
  
  →スタックに積む情報が多いから、それが問題になる場合があるんじゃね?
  
  Let us see what we can do using a trampoline function. That is, instead of calling the 
  function itself, we call a pointer to a function that is supposed to do what it needs 
  to do, and then return a pointer to a place where we need to go next:
  
  →「トランポリン」を使ってこう書いてみると
  
  #include <stdlib.h>
  #include <stdio.h>
  
  typedef void * (*Func)(int *x, int *total);
  
  void *fact0(int *x, int *total) { return NULL; }
  
  void *fact(int *x, int *total) {
     if (*x <= 1) return fact0;
     *total *= *x;
     *x = *x-1;
     printf("total %d, x: %d\n", *total, *x);
     return fact;
  }
  
  int main() {
     int res=1, n = 10;
     Func f = fact;
     while (f != NULL) {
        f = (Func)f(&n, &res);
     }
     printf("result is %d\n", res);
     return 0;
  }
  
  This also works, and now there is no problem with the stack size: at each time, the 
  stack holds only the context for the function that is being called. It is always 
  possible to do something like this in a tail recursive function, because we don't 
  need to store return information for the last call.
  
  →スタックの消費量が抑えられる。
  
  In fact, as mentioned by Knuth [1], the method described above can be used to 
  implement any algorithm. This is exactly the direction taken when implementing some 
  interpreters to scheme. The basic idea is to use continuations to store control 
  structure information, so that one never needs to return from a function. However, as 
  stack size is limited in languages such as C, the tactic explained above is used, so 
  one can work with trampoline functions instead of continuations. Tricky but useful 
  when implementing functional languages.
  
  For a similar example in Python, see [3].
  
  [1] Structured Programming With Goto Statements, D.E. Knuth, A.C.M. Computing Surveys, Vol. 6, pp. 261-301.
  
  [2] http://research.microsoft.com/apps/pubs/default.aspx?id=68568
  
  [3] http://mail.python.org/pipermail/tutor/2004-August/031553.html
  
  
  Copyright © Carlos Oliveira · All rights reserved.
  
  

  This is exactly the direction taken when implementing some interpreters to scheme. へー。

  reddit Recursion Using Trampoline Functions : programming

  久しぶりに PLNewsからネタ拾い

  
  Duby 0.0.1 Released @ PLNews: Programming Language News
  Nov. 02, 2009
  Duby 0.0.1 Released
  
  Duby 0.0.1 has been released. It is a programming language with a Ruby-inspired syntax, 
  with an implementation generating JVM bytecode or Java source files.
  
  This is the initial release. 
  

  Ruby に影響を受けたと? んで、言語の紹介ページを見ると

  
  
  The Duby Programming Language — Project Kenai
  
  Duby is a highly customizable programming language (or a structured assembly language) 
  featuring type inference and a heavily Ruby-inspired syntax, while allowing both the 
  inference engine and the compiler backends to be entirely customizable for any 
  platform or type system. Duby currently includes a typer/compiler backend for the JVM.
  

  customizable?

  
  R 2.10.0 Released @ PLNews: Programming Language News
  Nov. 02, 2009
  
  R 2.10.0 Released
  2009-11-02 20:18:18
  
  R 2.10.0 has been released. R is a language and environment for statistical computing 
  and graphics.
  
  This release includes: a new HTML-based dynamic help system, new functions, 
  installation updates, regex and compression changes, bug fixes, and other changes. 
  

  え? 2.10 ってことはそれなりに大きなバージョンアップ? 2.9.3 とどのくらい違うんだろう? あとでチェックしとこ。 http://cran.r-project.org/src/base/NEWS

  
  
  Fortress Blog Announced @ PLNews: Programming Language News
  Nov. 02, 2009
  Fortress Blog Announced
  2009-11-02 20:15:45
  Languages :: Fortress, Websites
  
  Guy Steele has announced the creation of a blog at the ProjectFortress Community site. 
  

  
  [Language] Announcing a Fortress blog
  
  We're going to try to experiment of cranking up a blog at the ProjectFortress 
  community website. I will try to make sure a new article is posted at least once a 
  week to keep everyone up to date on technical discussions and decisions, the status of 
  the compiler implementation, and various language features of interest. My first post 
  discusses the new wiki markup for tables for use in Fortress comments, and my second 
  post discusses some changes to the typing rules for conditional expressions that will 
  help them to interact better with coercion. I also plan to report soon on the status 
  of our efforts to construct a Fortress compiler. Visit 
  http://projectfortress.sun.com/Projects/Community/blog or click on the "Blog" 
  item at the right-hand end of the menu bar on the main Wiki page. --Guy Steele P.S. I 
  tried to announce this a week ago and found that we had problems with these mailing 
  lists. They should now be up and running again. 
  
  

  へー。

  • Twitter / naoya t: 長門型プログラミングの「師匠」 @natsutan ...
  • Twitter / yukishita: Parser Combinatorが分かりにくいとい ...
  • App Storeエフェクト―iPhoneアプリのどん底に向けての競争 : Gizmodo Japan（ギズモード・ジャパン）, ガジェット情報満載ブログ
  • 渋日記: 1日～1週間のでOSSに貢献する方法
  • 『化物語』のラストエピソードが度重なる延期を経てついにWeb配信開始:【2ch】ニュー速VIPブログ(`･ω･´)
  • 告白を断るときの正しいステータスコードの返しかた - As Sloth As Possible
  • 急進的な改革は危なっかしい
  • 愛が足りないから - 猫的怠惰DaysTOYOTA wayと呼ばれるメソッドは、従業員一人一人に対して負荷を与えるシステムだ。 カイゼンしろというのは簡単だが「で、カイゼンすると何かいいことがあるのですか？ それを行うとどのようなメリットを与えてくれるのですか？」ということに対して明確に回答できない、 あるいは暗黙の回答が提示されていないところでは決して成功しない。
  • いいとこ取りの「リーン・シックスシグマ」は泣ける？ - 編集の現場から：ITpro
  • ジュンク堂書店池袋本店　トークセッション情報中と外から見たRails ■2009年 12月3日(木) 19:00 ～
  • Twitter / しかのつかさ: インフルエンザは、個人レベルではほとんどたいしたこと ...
  • Ｃ言語で使用する変数名の最大文字数とはいくらまででしょうか? - Yahoo!知恵袋
  • HP作成業者に作成代行の見積もりを HPから依頼すると、 - Yahoo!知恵袋
  • 汎用 ＣＯＢＯＬで 帳票作成のサンプルプログラムはありませんか？ - Yahoo!知恵袋
  • var/タワゴト(2009-11-03)フリーセルって写経のように落ち着くね。最近やってないなあ。Windows 95の頃は猿のようにやってたけどw
  • 「使ってもらえる」UIが生産性を向上する――iPhone法人利用のメリットとは（前編）（＋D Mobile） - Yahoo!ニュース
  • クレイ・シャーキー曰く「情報洪水などない。それはフィルタリングの失敗だ」：シロクマ日報：ITmedia オルタナティブ・ブログ
  • Twitter / _ko1: http://www.cs.umd.edu/~jfo ...
  • 技術系の翻訳をするときに気をつけてること - atsuoishimotoの日記
  • ＩＴの企画 -OKWave
    ＩＴ部門に居るのですが、この不景気でお金がありません。低コストで経営に大きく寄与するソリューションを探しています。
  • がんばれ長妻たん！:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ
  • スイスの駅で見た時計カコイイ！:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ
  • Twitter / Mikio Yoshida: コードは通常は人に見られないものだけど、美意識を持っ ...
  • Getting Started with Agda アグダを始めよう - にわとり小屋でのプログラミング日記
  • お部屋1975/図書館の中では見えないこと 5 | ポット出版
  • 知識の伝達は難しい：柴田 芳樹 (Yoshiki Shibata)：So-net blog
    文書にして配布するだけで、知識が共有化されて、組織全体の底上げができるというのは、私自身は昔から幻想だと思っています。
  • クレイ・シャーキー曰く「情報洪水などない。それはフィルタリングの失敗だ」：シロクマ日報：ITmedia オルタナティブ・ブログ
  • サンコー、4.3型液晶で6,980円のメディアプレーヤー -AV Watch
    割と自分が欲しいと思ってたのに近い。
  • http://www.kmonos.net/pub/Presen/PLDIr3.pdf

  Permalink  |  View Entire Page

• 02 Nov 2009 16:10

  2009年11月02日

  ・寒い 懐が(笑) まあそれはおいといて、一気に気温が下がったみたいですね。

  ・格ゲー 鉄拳は最近になって6が出ましたが、どちらかというとわたしはヴァーチャファイターのほうが 好きだったり。

  ・ついった なんかわたしのついったのTLで見かける人で、 8月以降退職にしたとかいう人をよく見かけるような希ガス。

  C++ もうちょっと使ってもいいんじゃね? というお話。

  
  
  Embedded Systems Design - Embedded.com
  Poor reasons for rejecting C++ Choosing a programming language should be a 
  well-informed choice.
  
  By Dan Saks
  Embedded.com
  (08/20/09, 03:00:00 H? EDT)
  
  My colleague, Michael Barr, wrote an interesting piece earlier this month, entitled 
  "Real men program in C."1 I won't try to summarize it--you can read it 
  yourself. The article provoked numerous comments from readers citing reasons to prefer 
  C over C++. I disagree with several of those comments, and I'd like to say a little in 
  reply to each.
  
  My colleague の Michael Barr が今月初め(2009年8月)、"Real men program in 
  C."1 というタイトルの興味深い一篇を書きました。わたしはここでそのまとめを書くつも
  りはありませんが  ここで  読むことができます。
  The article provoked numerous comments from readers citing reasons to prefer C over C++.
  I disagree with several of those comments, and I'd like to say a little in reply to each.
  
  One reader wrote, "Just for the fun of it you might as well want to have a look 
  at what Linus Torvalds thinks about C and C++,"followed by the URL to the remark 
  (which I've omitted intentionally).
  
  ある読者曰く「それが楽しいからですよ。Linus Torvalds が C や C++ について考えたような
  ことをあなたも望んでいるかもしれませんけど」
  followed by the URL to the remark (which I've omitted intentionally).
  
  I suppose reading what Torvalds wrote would be fun if you like reading rants. It 
  wasn't fun for me. It's provocative but not well grounded, as explained by my friend 
  and colleague Steve Dewhurst.2 Torvalds has made positive contributions to the 
  computing industry, but this wasn't one of them.
  
  あなたが rants を読むことが好きならば、Torvalds が書いたことを読むのは楽しいことでしょ
  う。わたしにとってはそうではありませんでしたが。彼の発言は、わたしの友人で colleague 
  の Steve Dewhurst が説明しているように刺激的なものではありますが well grounded ではあ
  りませんでした.2。Torvalds はなるほど computing industry に対して positive 
  contributions したでしょうが、今回のこれはその中には含まれません。
  
  Another reader wrote, "I've studied C++ but never used it professionally and, the 
  more I study it, the less I think it appropriate for embedded use. It's not just that 
  it is expensive in terms of resources; it encourages you to do too many risky things. 
  It's bad enough that you can do things like dynamic allocation and recursion in C but, 
  in C++, the language will do it without your ever realizing it, unless you know what 
  its [sic] doing behind the scenes..."
  
  別の読者曰く 「"わたしはC++を学びましたが professionally にそれを使ったことはあり
  ませんでしたしさらに学んだものの組み込み用途に適しているとは思わなくなったのです。It's 
  not just that it is expensive in terms of resources; リソースという観点では高価ではあ
  りませんでしたが、リスクが高いことを encourage しています。それはC　で動的割付をしたり
  再帰を行うのと同じくらい悪いことなのですがC++ ではそれをあなたが認識しないところで行う
  のですunless you know what its [sic] doing behind the scenes..."」
  
  I have used C++ for prototyping embedded systems and consulted for others who have 
  developed production systems in C++. The more I use it and see it used, the more 
  convinced I am that it's preferable to C, when available.
  
  わたしはC++を、組み込みシステムのプロトタイピングやC++ を使ってproduction system を開
  発している他の人のコンサルトに使っています。
  The more I use it and see it used, the more convinced I am that it's preferable to C,
  when available.
  
  Rather than encourage risky behavior, many of C++'s core features--such as classes, 
  access control, constructors, destructors, references and overloading--work 
  hand-in-hand with stricter type checking to help reign in the riskiest parts of C. 
  While I agree that typical C++ code tends to be a bit larger and slower than 
  comparable C, the added expense is rarely prohibitive (on the order of 10-15%). I've 
  had little problem tuning time-critical code, such as interrupt handlers, to be as or 
  more efficient than it would be in C.
  
  risky behavior を強調するのではなく、C++ のコア機能の多く－ クラス、アクセス制御、コン
  ストラクター、デストラクター、リファレンス、オーバーローディング －work hand-in-hand 
  with stricter type checking to help reign in the riskiest parts of C. 典型的なC++ のコ
  ードはCと比較して、大きく遅くなる傾向があることには私も賛成しますが、増加した分が高価
  につくことはほとんどありません　(on the order of 10-15%)。C ではより効率よく書けるであ
  ろう割り込みハンドラーのような time-critical なコードのチューニングで多少問題があった
  ことがあります。
  
  I know of no place where the C++ language performs dynamic allocation or recursion 
  behind the scenes. Indeed, your code might call a function that uses dynamic 
  allocation or recursion, but this is no more a problem in C++ than in C. In fact, C++ 
  supports simple compile- and link-time techniques you can use to explicitly prevent 
  using dynamic allocation, which I'll cover in an upcoming column.
  
  I know of no place where the C++ language performs dynamic allocation or recursion 
  behind the scenes. 
  Indeed, 
  あなたのコードは動的割付や再帰を使っている関数を呼び出すかもしれませんが、C とは違いそ
  れはもはや C++ では問題になりません。事実、C++ は動的割付をはっきりとした形で防ぐため
  に使うことのできる単純なコンパイル時テクニックやリンク時テクニックをサポートしています
  (いずれこのコラムで紹介します)。
  
  Yet another reader wrote, "The only part of object orientation that is a 
  must-have in embedded systems is private encapsulation. C supports this nicely enough 
  with static variables declared at file scope."
  
  さらに別の読者曰く"組み込みシステムになくてはならないオブジェクト指向の要素と言え
  ばprivate encapsulation だけだ。C ではこれをファイルスコープで static 変数を宣言するこ
  とで十分にサポートする。"
  
  While I agree with the basic sentiment of the first sentence, I wouldn't word it so 
  strongly. I would say that the single most useful feature of C++ that's absent from C 
  is classes with private access control. I would not call it a "must-have" 
  feature simply because programmers do write viable embedded systems in C--without 
  classes. However, you can write better embedded systems with classes. I wouldn't want 
  to code without them.
  
  最初のセンテンスの basic sentiment には賛成しますがそれほど強くは言いません。わたしは
  private なアクセスコントロールを持ったクラスが、Cには欠けているC++ のもっとも有用な単
  一の機能だと主張します。わたしはそれを単純に "must-have" feature (必須の機能) 
  とは呼びません。なぜならプログラマーがクラスを使わない C-- で viable な組み込みシステ
  ムを書いているからです。とはいえ、あなたがクラスを使ったより良い組み込みシステムを書く
  ことは可能です。クラス抜きではわたしはコードを書く気にはならないでしょう。
  
  On the other hand, I disagree that C supports access control"nicely enough with 
  static variables declared at file scope". I believe the reader is referring to 
  the common technique whereby you:
  
  その一方でわたしは C  がサポートしているアクセス制御が"nicely enough with static 
  variables declared at file scope". (ファイルスコープで宣言された static 変数で十
  分役に立つ)という主張に反対します。
  I believe the reader is referring to the common technique whereby you:
  
  ・ place the data declarations for the encapsulated data structure in a
     separate source file,
     カプセル化するデータ構造体のデータ宣言を分割したソースファイルにおく
  
  ・ add the keyword static to each data declaration so that the data has
     internal linkage,3 and
     static というキーワードをそれぞれのデータ宣言のために追加しているので
     対象のデータは内部リンケージを持つことになる
  
  ・ define non-inline functions with external linkage in that same source file to 
     provide the publicly accessible operations on the encapsulated data.
     カプセル化されたデータに対する publicly accessible operations を提供するために
     同一のソースファイル中で外部リンケージを持った非インライン関数を定義する
  
  I refer to this technique as encapsulation by separate compilation. It works 
  "nicely enough" only if you're willing to accept the following:
  
  わたしはこの技法を分割コンパイルによるカプセル化と見なしています。この技法は、以下の項
  目をあなたが accept したときにのみ"nicely enough"　に働きます。
  
  ・ Your code will probably be both bigger and slower than it would be if the data
     were not encapsulated, because code outside the encapsulation unit can access
     the data only through non-inline function calls.
  
     あなたのコードは、カプセル化をしなかった場合に比べてサイズが大きく、実行速度も
     遅くなる可能性がありますなぜならカプセル化のユニットの外側にあるコードはインラ
     イン化していない関数呼び出しを通じてのみデータへのアクセスが可能だからです。
  
  ・ Each program can have at most one instance of the encapsulated data structure, 
     unless you're willing to accept even bigger and slower code that comes with using
     an ad hoc memory manager.
  
     各プログラムは、アドホックなメモリーマネージャを使ったことによるさらに大きく遅いコ
     ードを受容しない限り高々一つのカプセル化されたデータ構造のインスタンスしか持つこと
     ができません。
  
  C++ classes don't have these limitations.
  
  C++ のクラスにはこういった制限がありません。
  
  The same reader added that "Initialization through constructors is
  not something you desire; in fact you will want to avoid this for
  security reasons and for reduced bootup time."
  
  この読者はこうも言っています"コンストラクターを通じての初期化はあなたの望んだなに
  かではありません。実際、セキュリティ上の理由や起動時間の短縮のためにこれを取り除きたく
  なるでしょう。"
  
  I strongly disagree with this statement. Initialization by constructors is highly 
  desirable. I'd rank constructors and destructors as the second most useful C++ feature 
  that's absent from C (after classes with access control). Failure to properly 
  initialize objects can lead to security problems, and constructors go a long way 
  toward ensuring proper initialization. (Order-dependencies in member initializers can 
  be hazardous, but you can use static analysis tools that will alert you to such 
  hazards.) I would be interested to see concrete examples of how using constructors can 
  cause security problems. So would Robert Secord, author of Secure Coding in C and C++ 
  (2005, Addison-Wesley) and The CERT C Secure Coding Standard (2008, Addison-Wesley).
  
  わたしはこの statement には強く反対します。コンストラクターを使った初期化は highly 
  desirable です。わたしはコンストラクターとデストラクターを、C にはない、 C++の二番目に
  便利な機能であると rank します(一番目はアクセス制御を持ったクラス)。適切な初期化に失敗
  したオブジェクトはセキュリティ上の問題に繋がる可能性があります。そしてコンストラクター
  は適切な初期化を保証しているのです(メンバーの初期化に関する順序依存は hazardous となる
  可能性がありますがそのような hazardous を警告してくれる静的解析ツールが使えます)。
  I would be interested to see concrete examples of 
  how using constructors can cause security problems. 
  コンストラクターがセキュリティ上の問題を引き起こす可能性のある使い方の
  具体的な例
  So would Robert Secord,
  author of Secure Coding in C and C++ (2005, Addison-Wesley) and 
  The CERT C Secure Coding Standard (2008, Addison-Wesley).
  
  If you're concerned about startup time, C++ offers features such as"placement 
  new" to give you greater control over when constructors execute. Using placement 
  new, you can defer initialization for selected objects until after system startup. I 
  expect to cover this in the not-too-distant future.
  
  もしあなたが起動時間に関心を持っているのなら、C++ には "placement new" のよ
  うな機能があります。これはコンストラクターを実行するときにgreater control をあなたに提
  供するものです。placement new を使うことで選択したオブジェクトの初期化をシステムが起動
  が完了するまで遅らせることが可能です。
  I expect to cover this in the not-too-distant future.
  
  Despite my avowed preference for C++ over C, I still recognize that many
  of my readers have legitimate reasons to use C, such as the lack of an
  adequate C++ compiler for the intended target platform.4 I will continue
  to write about topics of interest to both C and C++ programmers, in part
  because I think your programming language choice should be well-informed.
  
  
  
  Between the time I wrote this column and the time it was posted, further comments on 
  Michael Barr's column pursued the question of whether constructors can lead to 
  security problems. The reader who originally raised this issue explained that the 
  problem "isn't because of the language, but because of the unreliable nature of 
  RAM. there could be days, weeks or years from the point of initialization to the point 
  where the variable is used. If you rely on the initialization values, you leave the 
  safety in the hands of the RAM manufacturer." It sounds to me like the problem 
  he's describing is, by his own admission, independent of the use of constructors. I 
  still see no basis for the claim that one should avoid using constructors for security 
  reasons.
  
  
  
  Dan Saks is president of Saks & Associates, a C/C++ training and
  consulting company. For more information about Dan Saks, visit his
  website at www.dansaks.com. Dan also welcomes your feedback: e-mail him
  at dan@dansaks.com. For more information about Dan click here .
  
  Endnotes:
  
  1. Barr, Michael, "Real men program in C", Embedded.com,
     August 1, 2009. Available online at
     www.embedded.com/columns/barrcode/218600142.
  
  2. Kalev, Danny, C++ Reference Guide: A Response to Linus Torvalds' C++ Diatribe.
     Posted online November 14, 2008 at
     www.informit.com/guides/content.aspx?g=cplusplus&seqNum=411.
  
  3. Saks, Dan, "Linkage in C and C++", Embedded Systems Design,
      March, 2008, page 9. Available online at
      www.embedded.com/columns/technicalinsights/206901036.
  
  4. Saks, Dan, "Moving to Higher Ground", Embedded Systems Programming,
     October, 2003, page 45. Available online at
     www.embedded.com/columns/programmingpointers/15200968
  
  

  • 2ちゃんねるの規制について -OKWaveなんでOKWaveに2ちゃんの規制の解除をお願いするんだろう?
  • 抜き出しマクロ(3) -OKWave
    なにキレてるんですか？ 長いなら見なければいいでしょう？ 僕はマクロ初心者なので。
  • データ抜き出しマクロについて -OKWave
  • 抜き出しマクロについて(2) -OKWave
  • データ抜き出しマクロの改良 -OKWave
    回答の削除の仕方を教えてください。 なかったことに。 回答しなきゃよかった。
  • http://www.naucon.org/~fukuhara/youi/d/text0911.html#091101_2
    ここにもホイホイさん
  • 2009年度日本OSS貢献者賞、授賞式を開催 － ＠IT
    　小崎氏は「Linuxカーネルの開発は難しくなりすぎて、若い人がなかなか入ってこないことが世界的に課題。そこで、開発者を増やしていこうという活動を展開中だ」と述べた。
    「コスト削減というのは、オープンソースを使う目的ではなく結果。コスト削減のためだけにオープンソースを使っても、その恩恵を受けられなくなる」
  • ASCII.jp：8月が終わらない「涼宮ハルヒの憂鬱」第3巻が登場
    ショップスタッフによると、この日入荷したタイトルとしては確実にブッチギリの売れ行きを見せているとのことだが、 ハルヒシリーズの第1シーズンや第2シーズン第1巻の売れ行きに比べると流石に落ち着いているようだ。
  • くねくね科学探検日記 iPhone とクラウド
  • char形のポインタの内容は（基本情報１６年午後第６問に関して） -OKWave
  • C++初心者でとても困っています -OKWave
    調べながらやればできると思い引き受けてしまったのですが、グーグルのソースコードが検索できるサイトをみても専門のサイトをみても全然わかりません。
  • コンパイルエラーの英語の読み方 -OKWave
  • http://www.openbsd.org/images/rack2009.jpg
  • [Lua]関数と変数は装備しないと意味ない
  • 「DSi LL」名前の由来はやっぱり「LLサイズ」だから？　任天堂に聞いてみた（ITmedia Gamez） - Yahoo!ニュース
    「『ニンテンドーDSi LL』の名前についてですが、ご想像のとおり、洋服などの“LLサイズ”から、“より大きい”というイメージを表すために命名したものです」（任天堂）
  • Zコンビネータ - T/O
  • 猫と仲良くなる方法も！かわいいだけじゃない、街で暮らす「野良猫」たちの魅力 - はてなブックマークニュース
  • 就活中です！ - hogeなlog
  • 商品詳細: 三平 三平（みひら さんぺい）
  • 商品詳細: 1/16 ブレイダー/スキャニー/ビゴラス
  • Chapter7　ラムダ式（後編） － ＠IT
  • Bpstudy26
  • App Storeエフェクト―iPhoneアプリのどん底に向けての競争 : Gizmodo Japan（ギズモード・ジャパン）, ガジェット情報満載ブログ
  • egrepの使い方を教えてください。 - Yahoo!知恵袋

  Permalink  |  View Entire Page

• 02 Nov 2009 00:04

  2009年11月01日

  ・日本シリーズ なんですかそれ?(笑)

  ・Interface 隔月で連載しているらしい「 新・組み込みソフトへの数理的アプローチ」 ってのがなかなか面白くて連載の前のほうのも読んでみたいのだけど、 どっかにバックナンバーないかしらん。 昔だったら会社で買ってたんだけどねえ。 まあ、買えばいいのなら置いてる店はあるんだけど。 2009年12月号　目次｜Interface

  ■_ わけわからん

  いろんな人がいますねえ。

  限界です -OKWave
  ～.jp/a.php? →　～.jp/a/ に　httacsessの書き方
  

  ３つ補足してください。
  ・カテゴリ「その他(プログラミング)」と「～.jp/a.php? →　～.jp/a/ に　httacsessの書き方」の関係は？
  ・質問の内容は？
  ・何が「限界」なの？
  

  ＞＞・カテゴリ「その他(プログラミング)」と「～.jp/a.php? →　～.jp/a/ に　httacsessの書き方」の関係は？
  
  物理的なもですか又は論理的或いは定義の様なものですか。
  
  一言「関係性」と言われましても何がどのように或いはどのような関係性を知りたいか又はどん
  な根拠で何を聞くことが目的なのか又は逆に関係性がないと意図することが目的の場合は何が違
  うのかを明確且明朗に記載後でないとこちらとしてもお答えできません。
  
  まずはここの点追記お願いいたします。
  
  さて次ですけど＞＞・質問の内容は？
  については質問の内容が理解できていないと言う意味合いで解釈させていただきますけどでは逆
  に質問内容が理解できていない状況で「教えてＧＯＯ」と言う理解者が理解者の判断でお答えす
  る場所で強制的ではない質問に対しましてなぜに分からない質問に答えたのかまずはここの点に
  関しましてお答えいただきたいです。
  
  えっと次ですけど＞＞・何が「限界」なの？
  これですけど「限界」と言うものの意味或いは個々の理解力や育った環境により人により様々な
  捕らえ方をされるとは思いますけど私が言う「限界」とはいわゆる一般的な「限界」と思ってい
  ただければと思います。まことに申し訳ありませんけど「限界」と言うものの詳しい説明はお控
  えさせていただきたいと思います。なぜならサイト上質問が解決すると言う場所での或いは趣旨
  に対しましての「限界」の意味合いと言うものをお答えすることにより質問が解決するかと言い
  ますとこれは非常に低いからです。
  
  あくまでも個人的見解になります。
  
  またサイトの性質上論争などをする場所ではありませんからぜひここは一歩大人になり争いを望
  むようなそのような無礼なご回答は避けていただきたいと感じます。
  

  ＃１です。
  
  補足を読ませていただきました。
  
  その上で、
  ・なぜ、「httacsessの書き方」を「その他(プログラミング)」というカテゴリに投稿するのか？
  （プログラマなら当然「httacsessの書き方」に詳しいと思っているのか？）
  
  ・「～.jp/a.php? →　～.jp/a/ に　httacsessの書き方」を読んで、どれだけの人が内容を理
  解できると思いますか？どこまで出来て、どこまで出来ないかも記載されていない。１から書き
  方の説明をしてという要望でしょうか？
  
  回答者達は超能力者でも神様でもありませんので、この文章から質問をくみ取らなければいけな
  いのでしょうか？
  
  

  定義付けも根拠も記載のない或いは出来ない状況で他人批判はあまりに幼稚です。
  
  補足について一言も明確なお答えできていませんよね。
  
  まあの流れを見たらどちらが負けか明らかでしょう。
  
  不明朗なご回答有り難う御座いました。
  

  そして予想外の結末を迎えたこれ。

  
  fgetsのエラー -OKWave
  
  C言語でテキストファイルをfgetsで読み込み、for文でfgetsを繰り返しているのですが、テキス
  トファイルの15003行目でfgetsのエラーが出てしまい、止まってしまいます。
  
  20000行まで読み込みたいのですが出来ません。
  
  繰り返しが悪いのかと思い、for文を(i=0;i<10000;i++)と(i=10000;i<20000;i++)で分け
  ても読み込んでも同じ結果でした。
  
  テキストファイルが13880行までの場合はうまくいきました。
  
  ↓Cプログラム↓
  FILE *fpo;
  char line[4096];
  
  for (i=0; i<20000; i++) {
      if (fgets(line, sizeof(line), fpo) == NULL) return(0);
      sscanf(line, "%d %lf %lf %lf %lf %lf %lf",
          &typep[i], &x[0][i], &x[1][i], &v[0][i], &v[1][i],&p[i], &n[i]);　　　　//lineのデータを1つ1つ読み込む
  }
  
  ↓エラー文↓
  Debug Assertion Failed!
  File: f:\dd\vctools\crt_bld\self_x86\crt\src\fgets.c
  Line:57
  Expression:(str!=NULL)
  
  なにが原因なのか分かりません。
  よろしくお願いします。
  

  ソースコードを見直していたら、for文の繰り返し数よりも、配列の個数が少なく止まっていました。
  （forは20000回、x[15000]で足りませんでした）
  
  fgetsの関数の原因ではなく、すごく初歩な原因でした。
  改めて、勝手な思い込みは良くないと思いました。
  
  

  ずこーっ(AA略

  ■_ 理屈がおかしいとは思わないんだろうか

  知恵袋編。

  
  2分探索木の問題を高校2年の実習でやらされてるんですが、よく分かりません。 課題... - Yahoo!知恵袋
  
  2分探索木の問題を高校2年の実習でやらされてるんですが、よく分かりません。 課題...
  
  yosiko_0121さん
  
  2分探索木の問題を高校2年の実習でやらされてるんですが、よく分かりません。
  
  課題内容は2分探索木へのﾃﾞｰﾀの追加です。
  
  15のﾉｰﾄﾞを持つ階層3まである2分探索木がある。この2分探索木を大きな15の配列「nodes」で表
  現する。そして、新たにﾃﾞｰﾀを追加したときに、適切な要素に適切な情報(追加ﾃﾞｰﾀやそれに繋
  がる左部分木や右部分木)が格納されるようなﾌﾟﾛｸﾞﾗﾑを作成せよ。
  
  条件(1)2分探索木のﾉｰﾄﾞを以下のような構造体で定義せよ。それを、大きさ15の配列「nodes」
  で宣言して使用せよ。
  
  struct node{
      int data;
      struct node *left;
      struct node *right:
  };
  
  (2)2分探索木の初期設定はnodes[0]が20、[1]が10、[2]が40、[3]が5、[4]が15、[5]が30、
  [6]が50、残りはNULLです。
  
  (3)変数名は以下の通りにする。
  
  ●15個のﾉｰﾄﾞを表す配列：nodes
  ●配列nodesの制御変数：i
  ●追加ﾃﾞｰﾀ格納領域：indata
  ●ﾎﾟｲﾝﾀ処理用のﾜｰｸ領域：p(struct node型) その他、必要に応じて各自で宣言せよ。
  
  (4)ﾃﾞｰﾀを1個追加するごとに、現在の配列nodesの状態を表示せよ。
  
  (5)ﾃﾞｰﾀを1個追加するごとに、ﾃﾞｰﾀ追加処理を継続するのかどうかの確認をせよ。
  
  
  この条件で、課題のﾌﾟﾛｸﾞﾗﾑを作成してください
  お願いしますっ(汗)
  
  補足
      学校のことは関係ありません
      やり方を教えてもらいたいんです

  「やり方」を教えてもらいたい、ではなく現物が欲しいと書いてますが…
  
  丸投げをやってくれる人もいますが不快に思っている人もいます。
  課題の丸投げは某巨大掲示板に請け負っているところがあるので、そこに投げてください。
  http://pc12.2ch.net/tech/
  
  

  
  ＞ 2分探索木の問題を高校2年の実習でやらされてるんですが、よく分かりません。
  ＞ この条件で、課題のﾌﾟﾛｸﾞﾗﾑを作成してください
  
  「やらされている」と感じるのではつらいでしょう。
  プログラミングの勉強をする気もないようですし、親御さんに相談して、プログラミングがない
  学校への転入などを考えるのがいいのでは？
  
  
  ＞ やり方を教えてもらいたいんです
  
  作成依頼をするつもりはなかったし、勉強する気もあるのだが、文章を書き間違えたということ？
  
  きちんと学費を払っているなら、「やり方」を教えるのは、学校の先生のメインの「お仕事（義
  務）」でしょうから、学校の先生に聞くのが一番かと。。。実装には様々あるでしょうし、下手
  な回答を鵜呑みにして悪いプログラミングスタイルが身についてしまう危険を冒すより、きちん
  としたプログラミングスタイルを先生から学ぶほうがいい。
  
  各人の実力を知りたいための課題なら締め切り後には教えてくれるでしょうし、そうではなく実
  力アップのための課題なら少なくともヒントくらいはもらえるでしょう（そうでないなら、怠慢
  教師だと、学校にクレームを言うべきだ）。
  
  先生に作成依頼したら、断られるでしょうけどね。
  
  

  丸投げじゃないけど、参考にしたいのでソースくださいってのは割りとよく見るパターンですね。

  ■_ 今日の2ch

  例の大規模ホスト規制のせいか、どのスレもあまり伸びていないような。

  この会社辞めようと思ったソースコード＃1B [chaika]
  
  906 仕様書無しさん [sage] 2009/10/31(土) 20:42:45 ID: Be:
      隣の先輩のコードが
  
      if (memcmp(・・・) == TRUE)
  
      と、なってて、そりゃねーだろと思ったけど、定義をみてみたら、
  
      #define TRUE 0
      #define FALSE -1
  
      で、まあ、気持ち悪いけど、これなら動くなと思ってたら
  
      if (memcmp(・・・) == FALSE)
  
      って、書いてるところもあって、やっぱこりゃだめだと思った。
  
      何日かしたら、やっぱり「なんでこれ、こんな動きなんだ！」みたいに騒ぎだして、
      わかってる人から、「そこは != 0 だよ」みたいに教えてもらってた。
  
      「あれ、おれ、なんでこんな書き方してるんだ、ほかのソースはちゃんと書けているのに」
      って言い訳をはじめたけど、たしかに、その先輩は基本的に人のソースをマネして
      書く人なんで、どうしてそんなところだけ独自に書いてバグってんだって感じ。
  
      それから memcmpを検索して、順番に
      == TRUE　だったら == 0　に
      == FALSE だったら != 0　に
      書き直していってたけど、そんな修正してたらミスらねーか? って思ってたらやっぱり何箇所か
      == FALSE　を == 0 って修正ミスしてた。
  
      俺には関係ないから黙ってたけど。
  
  907 仕様書無しさん [sage] 2009/11/01(日) 04:29:27 ID: Be:
      行き当たりばったりか。
      そのまま行き倒れりゃいいんだけどな。 
  
  
  

  TRUEが0ってはなんか怖いなw

  Emacs Lisp にも「モダンな書き方」とかあるんですかね。

  Emacs Part 32 
  164 名無しさん＠お腹いっぱい。 [sage] 2009/10/31(土) 16:44:29 ID: Be:
      外国では(add-to-list 'load-path "path")の書き方が普通なのに
      日本では(setq load-path (cons "path" 'load-pat))と書く人が多いね。
      明らかに前者の方が簡潔だと思うけど後者の書き方には何かメリットがあるのかな？ 
  
  165 名無しさん＠お腹いっぱい。 [sage] 2009/10/31(土) 16:59:09 ID: Be:
      代々伝わる秘伝のタレの味。 
  
  166 名無しさん＠お腹いっぱい。 [sage] 2009/10/31(土) 17:07:05 ID: Be:
      >>164
      > (cons "path" 'load-pat))と書く人が多いね。
  
      まあ、そんな短いS式の中で2つも間違いを犯すような君はコピペで我慢してなさいってこった。
  
  167 名無しさん＠お腹いっぱい。 [sage] 2009/10/31(土) 17:08:21 ID: Be:
      昔add-to-listはなかった。ただそれだけのこと。 
  
  168 名無しさん＠お腹いっぱい。 [sage] 2009/10/31(土) 19:10:19 ID: Be:
      じゃあ後方互換性のためにconsを使うべきだな 
  
  169 名無しさん＠お腹いっぱい。 [sage] 2009/10/31(土) 19:41:36 ID: Be:
      push派は少ないのだろうか。 
  
  170 名無しさん＠お腹いっぱい。 [sage] 2009/10/31(土) 19:58:01 ID: Be:
      nconc派 
  
  176 名無しさん＠お腹いっぱい。 [] 2009/11/01(日) 08:18:07  ID: Be:
      >>167
      > 昔add-to-listはなかった。ただそれだけのこと。
  
      あと、無意味に重いので忌避されていた。 
  
  177 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 10:58:50 ID: Be:
      へ？ 
  
  178 Zeno ◆5nZQbNmQPs [] 2009/11/01(日) 11:03:44 ID: Be:
  
  
      >>168->>171
      add-to-list は重複チェックをしてくれる。
      そのことを知らない初心者に cons や push を使った
      やり方を勧めるのは推奨されない。
  
      つまり貴様等頭は普通に add-to-list を使っていれば良いということだ。
  
  179 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 11:21:47 ID: Be:
      そういえば昔は、「空白連ねるな、タブに変換しとけ」だったんだよな。
      ファイルサイズを縮小するために。
  
  180 Zeno ◆5nZQbNmQPs [] 2009/11/01(日) 11:40:37 ID: Be:
  
      >>179
      ソース内でタブを使うことは推奨されない。
  
  181 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 11:52:19 ID: Be:
      >>178
      なるほど、勉強になる。
      .emacs なんて、web上のものを切り貼りすることしかできないので、
      その辺が全然統一されてないわ。
  
      とりあえず、add-to-list を使っておくのが安全なんですね。 
  
  182 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 14:42:57 ID: Be:
      勉強になるとか言って勉強する気ない奴の典型 
  
  183 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 15:04:47 ID: Be:
      何かいやなことでもあったのか？ 
  
  184 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 16:22:14 ID: Be:
      ちょっとな 
  
  185 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 18:47:24 ID: Be:
      >>180
      なぜだ? 
  
  186 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 19:08:34 ID: Be:
      add-to-listの重複チェックとか常識すぐる 
  
  187 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 19:19:43 ID: Be:
      「知ってる奴にとっては」な 
  
  188 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 22:22:54 ID: Be:
      listにaddする、と聞いた時点で「重複チェックは?」と思い至るようでないと
      emacsは難しい。 
  
  189 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 22:53:59 ID: Be:
      重複チェックするだけなのに無意味に重いってこたないだろ。
      add-to-listはループ内で使うのが普通とかならともかく。 
  
  190 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 23:11:01 ID: Be:
      センス無い人ってほんと徹底してセンス無いよな 
  
  191 名無しさん＠お腹いっぱい。 [sage] 2009/11/01(日) 23:47:33 ID: Be:
      emacsで重いって起動時だけでしょ？
      前の方のレスにも起動が遅くなったとかレスがあるけど
      どうせＰＣ立ち上げてすぐemacs起動したらずっとそのままだし全然気にならん。 
  
  

  • Twitter / なぎせゆうき: @wtnabe はプレゼンうまいな。聞いていて面白い ...
  • 涼宮ハルヒ　エンドレスエイト１と２　仕入数はどのくらい違うの？ - アキバBlogアキバのいくつかのお店に、エンドレスエイト１と２の仕入れ数がどのくらい違うか聞いてみたら、今回のエンドレスエイト２（涼宮ハルヒの憂鬱 5.285714）は、 エンドレスエイト１コ目の６割前後の仕入れ数というお店が複数で、お店によってはもっと減らしたというところもあった。
  • HIMA ＆ 忘年会 - あどけない話
  • Twitter / Hiroki Fukagawa: @hiratara モナドで悟りを得たかったら、層圏 ...
  • Hexenkessel - 都心の大型書店やアマゾン・コムを使い慣れている人は、たとえ少部数しか出版されていなくても、自分の求める...
  • Hexenkessel - GoogleにしろAmazonにしろ、マネタイズに成功するということは他者に儲けられる方法を提供するこ...
  • パソコンはどうやって作られる？ - Yahoo!知恵袋
  • 【250枚】rhinosugarさん この関数をお願いしたいです(他の方でもいいですよ！) - Yahoo!知恵袋折角ご指名にあずかりながら恐縮ですが、このケースで意味もなく試作品をお見せする事は単なる「無駄」ですので、ご遠慮申上げます。あしからず御了承ください。
  • Twitter / 梶本裕介: PHPって初心者にも使いやすいふりして世の中にゴミコ ...
  • LET OVER LAMBDA - hidemonの日記Lispのマクロにちょっとでも似たものが他の言語にあるとすれば，C++のテンプレートだと思うのだが．LisperにとってはC++は論外なのだろうか？
    たぶん。
  • 「制作会社に採用されなくてよかった」原作者・竜騎士07の挫折と下克上（後編） - 日刊サイゾー
  • AIXの勉強方法について -OKWave
  • 配列とポインタの奇妙な関係
  • Twitter / やのつとむ: またモナドの話だけど、群論が分からんでも足し算が使い ...
  • Twitter / やのつとむ: IOモナドって一種の詐欺みたいなもんだから，真剣に考 ...

  ■_ mawk

  mawk の正規表現エンジンについてちょっとだけ書いておくと

  /* returns start of first longest match and the length by
     reference.  If no match returns NULL and length zero */
  
     char *REmatch(str, machine, lenp)
     char *str ;
     PTR machine ;
     unsigned *lenp ;
  {
     register STATE *m = (STATE *) machine ;
     register unsigned char *s = (unsigned char*)str ;
     unsigned char *ss ;
     register RT_STATE *stackp ;
     int u_flag, t ;
     unsigned char *str_end, *ts ;
  
     /* state of current best match stored here */
     unsigned char *cb_ss ;		 /* the start */
     unsigned char *cb_e ;			 /* the end , pts at first char not matched */
  
  	/*printf("REMatch");*/
     *lenp = 0 ;
  
  	/* fprintf(stdout, "in REmatch()\n");*/
     /* check for the easy case */
     if ((m + 1)->type == M_ACCEPT && m->type == M_STR)
     {
        if (ts = str_str(s, (unsigned char*)m->data.str, m->len))
        	 *lenp = m->len ;
  	  /* fprintf(stdout, "out REmatch()\n"); */
        return ts ;
     }
  
     u_flag = U_ON ; cb_ss = ss = str_end = (char *) 0 ;
     stackp = RE_run_stack_empty ;
     goto reswitch ;
  
  refill :
     if (stackp == RE_run_stack_empty)
     {
        if (cb_ss)  *lenp = cb_e - cb_ss ;
  	  /* fprintf(stdout, "out REmatch()\n");   */
  	  /* fprintf(stdout, "len = %d\n", *lenp); */
        return cb_ss ;
     }
     ss = stackp->ss ;
     s = stackp--->s ;
     if (cb_ss)			/* does new state start too late ? */
     {
        if (ss)
        {
  	 if (cb_ss < ss)  goto refill ;
        }
        else if (cb_ss < s)  goto refill ;
     }
  
     m = (stackp + 1)->m ;
     u_flag = (stackp + 1)->u ;
  
  
  reswitch  :
  
     switch (m->type + u_flag)
     {
        case M_STR + U_OFF + END_OFF:
  	 if (strncmp(s, m->data.str, m->len))  goto refill ;
  	 if (!ss)
  	 {
  	    if (cb_ss && s > cb_ss)  goto refill ;
  	    else  ss = s ;
  	 }
  	 s += m->len ;	m++ ;
  	 goto reswitch ;
  
        case M_STR + U_OFF + END_ON:
  
  

  内部表現にコンパイルしたあとのマッチングで、こんな感じの switch 文 + goto でぐるぐる回ってくのですね。 んで、一文字 == 1byte って決め打ちしているようなところがあるので、 途中でマッチングに失敗してバックトラックするときの動作をマルチバイト文字に 対応させるのがちょっと大変と。

  Permalink  |  View Entire Page

• 31 Oct 2009 19:48

  2009年10月31日

  読んだ こういうのを読むと、経済学のえらいセンセのいうことに疑いの目を向けたくなったりするんだよな (まあ色々宗派? があるみたいですけど)。

  ・皇帝戦士ビッグバン・ベイダー 東スポのプロレスのコラム欄で取り上げているのが前回からベイダーなんですが、結構面白い。 日本初登場のときがアレだったのでイメージが悪くなってる気がしますが、 結構な実力者なんですよね。しかし、最初は全日本のリングに上がるという話だったとは。

  ・買ったもの 昨日、買ったとだけ書いたのは実はこれでした→ Twitter / TWOTOP秋葉原本店: 音々ちゃんPC残り6台となりました！発売終了日が11 ... 10/22(たぶん)の深夜の発売開始に行けなかったのでこりゃあダメだとあきらめてたのですが、 台数があったせいか(各店あわせて400台とか)木曜日の夜の段階でもまだ秋葉原で売っているところがある。 でもこの週末で売れ残っている分があっても大阪に引き上げてしまうという話を聞きまして 金曜日の終業後にダッシュでアキバの某店へ行きましたとさ。

  Twitter / Hirofumi Saito: CSVをテキストの表に変換する テキストテーブル - ... tbl。は troff コマンド(に見えるもの)を食わせるんだっけ。 Vector：tbl (MS-DOS / ユーティリティ) - ソフトの詳細

  ・mawk FreeBSD だかできちんとメンテナーがついてがしがしパッチやら取り込んでるらしいですね。 というわけでということではないのですが、以前とは別のやり方で日本語対応(とマルチバイト文字対応)を しようかと考えてたりするんですが、実装がちと面倒。 鬼車とかのライブラリに乗せかえようという話が以前あったような気がしますが、 それはちょっと負けになるのでやだなあと(笑)。 わりと珍しいつくりの正規表現エンジンだと思うので、残せるなら残したいのですよね。

  ■_

  ■_

  最初だけ勢いがあって現在休眠状態のスレだけど、こんなのがあったとは。 Part 2 へ行けるのか(dat落ちでなしに)?

  ----Ovenの概要 ようするに、| 演算子でパイプ(Unix的なあれ)を作ったC++テンプレートライブラリ。 ほう。そういうものだったのか。

  
  Oven/Egg総合スレ part1
  
  1 デフォルトの名無しさん [] 2009/01/04(日) 23:54:01 ID: Be:
  
      ■関連サイト■
      http://p-stade.sourceforge.net/ 
  
  3 デフォルトの名無しさん [] 2009/01/06(火) 01:08:05 ID: Be:
      こんな変態でマイナーナの、努力しないとあっという間にDAT落ちするぞ。
  
      ----Ovenの概要
      ようするに、| 演算子でパイプ(Unix的なあれ)を作ったC++テンプレートライブラリ。
      #include <iostream>
      #include <boost/foreach.hpp>
      #include <pstade/oven/sorted.hpp>
      int main() {
        using namespace pstade::oven;
        int a[] = {1, 9, -5, 10, -2, 6, 4};
        BOOST_FOREACH(int x, a | sorted) {
          std::cout << x << ' ';
        }
        std::cout << std::endl;
      }
      出力: -5 -2 1 4 6 9 10
      a | sortedってのがOvenを使った部分。sortedは名前通り入力をソートした結果を返すというものだ。
  
      このように入力も出力もRange。
      Rangeを知らなければここ読め。ようするに配列やSTLコンテナなど。BOOST_FOREACHできるやつと思っても可。
      http://www.kmonos.net/alang/boost/classes/range.html 
  
  4 デフォルトの名無しさん [] 2009/01/06(火) 01:24:05 ID: Be:
      #include <iostream>
      #include <iterator>
      #include <string>
      #include <vector>
      #include <cctype>
      #include <pstade/oven/transformed.hpp>
      #include <pstade/oven/copied.hpp>
      #include <pstade/oven/copied_to.hpp>
      int main() {
        using namespace pstade::oven;
        std::string s = "HogeFooBar";
        std::vector<char> v = s | transformed(std::toupper) | copied; //当然パイプにパイプを重ねることが可能
        v | copied_to(std::ostreambuf_iterator<char>(std::cout));
        std::cout << std::endl;
      }
      出力: HOGEFOOBAR
      transformedやcopied_toのように、関数呼出の形で引数を与えるものもある。
  
      transformedは各要素に与えられた関数を適用したレンジを返す。Lispでいうmapだな。
      もちろん関数オブジェクトも可。Boost.Lambdaもいけるはず。
  
      copiedはここで打ち止めの意、vectorなどのコンテナへ初期化・代入できるようになる。ただし、std::stringへは上手くいかないようだ。
      Ovenで | を通した結果の型はテンプレートの塊なので、どんな型か考えない方がいい。この点、C++0xのautoがやや待ち遠しい。
  
      copied_toは指定された出力イテレータにコピーを送る。それは副作用としてなので、さらにパイプを続けられたはず。 
  
  5 デフォルトの名無しさん [] 2009/01/06(火) 01:45:57 ID: Be:
      >>1のリンク先から辿れるけど、ダウンロードページへのリンクがあるこっちも挙げておいたほうが親切だと思う。
      http://sourceforge.net/projects/p-stade/
      解凍したら、コンパイラのインクルードパスに通すだけで使える。事前ビルド不要。
  
      これくらい書けば1晩は越せるかな。 
  
  6 デフォルトの名無しさん [] 2009/01/06(火) 21:53:27 ID: Be:
      どう書く？orgからネタをもらう。
      http://ja.doukaku.org/comment/7652/
      #include <cmath>
      #include <iostream>
      #include <iterator>
      #include <pstade/oven/counting.hpp>
      #include <pstade/oven/filtered.hpp>
      #include <pstade/oven/copied_to.hpp>
      #include <pstade/oven/taken.hpp>
      bool t(unsigned n) {
        return (static_cast<unsigned long long>(std::pow(30., static_cast<double>(n))) % n) == 0;
      }
      int main() {
        using namespace pstade::oven;
        unsigned n;
        std::cin >> n;
        counting(1u, max_count)
          | filtered(t)
          | taken(n)
          | copied_to(std::ostream_iterator<unsigned>(std::cout, "\n"));
      }
      こういうのでは、出力に無理してcopied_to使わずにBOOST_FOREACHやBoost.RangeExのfor_eachを素直に使う方がいいと思う。 
  
  7 デフォルトの名無しさん [] 2009/01/06(火) 23:53:54 ID: Be:
      そういえば、countingはまだ紹介していない種類だった。
      counting(m, n)はmからnまで1ずつ増加するレンジを作るというもの。max_countは最大値までの意。
      そういうわけで、これまでのと違って|の左側に置いている。
  
      そうそう、遅延評価風味。foreach類やcopied(_to)などを使わないと動かない。
      次のコードでは何も出力されない。
      #include <iostream>
      #include <pstade/oven/transformed.hpp>
      int f(int x) {
        std::cout << x << std::endl;
        return x;
      }
      int main() {
        using namespace pstade::oven;
        const int a[] = {1, 2, 3};
        a | transformed(f);
      } 
  
  8 デフォルトの名無しさん [] 2009/01/07(水) 00:01:30 ID: Be:
      逆に、次のコードでは2回ずつfが呼ばれる。
      要素を参照するときに評価が起こると思えばいい。
      #include <iostream>
      #include <algorithm>
      #include <boost/range.hpp>
      #include <pstade/oven/transformed.hpp>
      void dummy(int) {}
      int f(int x) {
        std::cout << x << std::endl;
        return x;
      }
      template<typename Range>
      void g(Range const& r) {
        std::for_each(boost::begin(r), boost::end(r), dummy);
        std::for_each(boost::begin(r), boost::end(r), dummy);
      }
      int main() {
        using namespace pstade::oven;
        const int a[] = {1, 2, 3};
        g(a | transformed(f));
      } 
  
  15 デフォルトの名無しさん [] 2009/01/09(金) 20:09:33 ID: Be:
      なぜかすっかり忘れていたけど、Ovenの元ネタはこれ。
      Range Library Proposal
      http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html
      Ovenのマニュアルにも冒頭に「Oven is an advanced implementation of Range Library Proposal」と書いている。
      http://p-stade.sourceforge.net/oven/doc/html/ 
  
  16 デフォルトの名無しさん [] 2009/01/09(金) 23:38:57 ID: Be:
      作者不在で、ovenやeggの更新が止まってるのが残念 
  
  17 デフォルトの名無しさん [sage] 2009/01/10(土) 03:09:10 ID: Be:
      ちょｗなんというマイナーライブラリスレ 
  
  18 1 [] 2009/01/10(土) 10:28:38 ID: Be:
      誰か語って 
  
  19 デフォルトの名無しさん [sage] 2009/01/10(土) 12:33:52 ID: Be:
      Ovenは慣れれば便利だよな
      変態だけど
  
      Egg？ｼﾗﾈ 
  
  20 デフォルトの名無しさん [] 2009/01/10(土) 15:16:38 ID: Be:
      >>17
      >>3-9の間、誰にも邪魔されなかったほどに過疎っている。
  
      >>18
      自分からもネタふりしてくれ。 
  
  21 デフォルトの名無しさん [] 2009/01/11(日) 21:04:17 ID: Be:
      <pstade/oven/algorithm.hpp>と<pstade/oven/numeric.hpp>には、
      それぞれ<algorithm>と<numeric>のRange版が収録されている。
      （もちろん名前空間pstade::oven）
  
      例えば、>>4のv | copied_to(std::ostreambuf_iterator<char>(std::cout));は、
      copy(v, td::ostreambuf_iterator<char>(std::cout));と書き換えることが可能。
  
      もちろん、Boost.RangeExでもいいわけだけど。むしろRangeExのほうがコンパイル速いし。 
  
  22 デフォルトの名無しさん [] 2009/01/11(日) 22:03:35 ID: Be:
      日本語版のドキュメントが欲しくね？
      あと、もう少し詳しく書いて欲しくね？（俺だけか・・・）
      慣れればどれも同じ様な使い方だからなんとか使えるけど。
  
      あと、pstade::oven::regular ってどういう動作するの？
  
  23 デフォルトの名無しさん [sage] 2009/01/12(月) 01:08:55 ID: Be:
      >>22
      確かにHamigakiは日本語文書があるのがやや有難いとは思う。
      ドキュメントを読んでわからないときは、libs\oven\example\を参考にすることが多い。
  
      どういう動作かって？実装のことならソース嫁で頼む。 
  
  31 デフォルトの名無しさん [sage] 2009/01/26(月) 02:49:20 ID: Be:
      そろそろ即死から逃れられる頃合いか？ 
  
  32 デフォルトの名無しさん [] 2009/01/29(木) 17:06:39 ID: Be:
      保守age 
  
  33 デフォルトの名無しさん [sage] 2009/02/02(月) 19:30:41 ID: Be:
      保守 
  
  34 デフォルトの名無しさん [] 2009/02/05(木) 17:21:50 ID: Be:
      保守ついでにany_rangeから目次順に取り上げることを目標にする。
  
      というわけでまずはany_indexed。
      any_rangeのランダムアクセス特化版、らしい。 
  
  35 デフォルトの名無しさん [] 2009/02/10(火) 16:19:16 ID: Be:
      void print( pstade::oven::any_indexed<int> r)
      {
      std::copy(r.begin(), r.end(), std::ostream_iterator<int>(std::cout, "\n"));
      }
  
      std::vector<int> v(boost::counting_iterator<int>(0),boost::counting_iterator<int>(10));
      pstade::oven::any_indexed<int > ai(v);
      print(ai); 
  
  36 デフォルトの名無しさん [] 2009/02/11(水) 14:31:46 ID: Be:
      pstade::oven::identitiesってなにするもん？ 
  
  37 デフォルトの名無しさん [sage] 2009/02/11(水) 20:33:18 ID: Be:
      single pass range conceptを満たすものからiterator_rangeを作って返すものっぽいな
      io.hppのinspect機構はiterator_rangeに対して働くものだから
      single(ryを満たすコンテナのままでは動作しないわけだ
      さらに引数を指定することによって元のコンテナがsingle pass rangeでもrandom access rangeのように見せかけたりできると
      マニュアルやソース、テストを見る限りそう読みとれた 
  
  38 デフォルトの名無しさん [sage] 2009/02/11(水) 22:09:21 ID: Be:
      STLスレからやってきたのか。
      あのコードだと、(v|ov::identities)をov::make_range(v)にしても動くな。
      どっちを使うかは好みの問題かな。 
  
  46 デフォルトの名無しさん [] 2009/03/02(月) 20:43:29 ID: Be:
      http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/67a593c8e747b97c#
      RangeExがレビュー入りだってさ。
      レンジアダプタ（ | 演算子のやつ）も入っているよ！ 
  
  48 デフォルトの名無しさん [sage] 2009/07/29(水) 13:03:13 ID: Be:
      保守 
  
  

  これでも落ちないってのはム板ならではだなー。もっと上があるけど。

  
  Lisp Scheme Part28 
  429 デフォルトの名無しさん [sage] 2009/10/28(水) 07:54:06 ID: Be:
      そんなことよりもSICPの日本語の新訳が早く出ないと色々滅びると思う。
      独習Lispとか独習Schemeとか出てほしいよ。良い文献は洋書しかない。
      とにかく若い人に使ってもらいたい。 
  
  430 デフォルトの名無しさん [sage] 2009/10/28(水) 08:02:54 ID: Be:
      でもSICPはScheme勉強のための本じゃないでしょ？ 
  
  431 デフォルトの名無しさん [sage] 2009/10/28(水) 08:52:25 ID: Be:
      滅びる?
      20年くらい前に比べたらずいぶんと流行ってるけど。
      むしろ流行りすぎ。 
  
  432 デフォルトの名無しさん [sage] 2009/10/28(水) 10:02:00 ID: Be:
      俺も最近はSchemeブームなんだと思ってたｗ 
  
  433 デフォルトの名無しさん [sage] 2009/10/28(水) 11:13:47 ID: Be:
      > 日本語の新訳
  
      和田先生の訳が気に入らない一部の人でしょ。どう見ても。 
  
  434 デフォルトの名無しさん [sage] 2009/10/28(水) 11:55:29 ID: Be:
      現存のSICPスレに別訳を幾つか書いた者だけれど、
      確かに序文の翻訳には酷いものが含まれてると思う。
      訳本の序文は読まないか、理解できなくても気にしない方がいい。
  
  435 デフォルトの名無しさん [sage] 2009/10/28(水) 14:15:07 ID: Be:
      嫌なら旧訳を探して買えば良いのに 
  
  436 デフォルトの名無しさん [sage] 2009/10/28(水) 22:59:40 ID: Be:
      正直、和田訳はだめ。
  
  437 デフォルトの名無しさん [sage] 2009/10/31(土) 01:11:30 ID: Be:
      和田先生の訳を受け付けないのは数学書なんかの固い専門書を読み慣れていない人？ 
  
  438 434 [sage] 2009/10/31(土) 08:20:41 ID: Be:
      序文の翻訳は下手だよ。
      文章が固いとかそういうレベルじゃない。 
  
  439 デフォルトの名無しさん [sage] 2009/10/31(土) 09:58:42 ID: Be:
      本文で身につけたい物が身につけばいいじゃん、だいたい翻訳が気に入らないなら原書読めばいいだけの話
  
  440 デフォルトの名無しさん [sage] 2009/10/31(土) 10:15:40 ID: Be:
      ご飯がまずくて食べられなければパンを食べればいいのに。 
  
  441 デフォルトの名無しさん [sage] 2009/10/31(土) 11:17:18 ID: Be:
      原文の意味を変えないようにすれば正確な文章になるとは限らないし、
      正確な文章であれば読み易いとも限らない。
      間違ってるなら論外だけど、
      結局は何に重点を置くかってことなんじゃないかなぁ。 
  
  442 デフォルトの名無しさん [sage] 2009/10/31(土) 11:19:23 ID: Be:
      バブル世代より上は翻訳脳が欠落してんだよ
      今は翻訳自体のプロでなくても翻訳センスある人多い 
  
  443 デフォルトの名無しさん [sage] 2009/10/31(土) 11:29:57 ID: Be:
      http://iiyu.asablo.jp/blog/2005/10/11/105359#c359800 
  
  444 デフォルトの名無しさん [sage] 2009/10/31(土) 11:50:18 ID: Be:
      ttp://www.alu.org/pipermail/alu-discuss/2009-October/000004.html
      くるかしらね？ 
  
  

  最後のこれは…?

  ■_

  まあ実際、gcなしの環境で malloc失敗したら基本的には実行を終了するよりないような。 下手にリカバリーしようとするとドツボにはまりそうな気がする。 もちろん、そういう『悪足掻き』をしなきゃならないものや局面はあるのだろうけど。

  
  
  Eli Bendersky’s website
  
  Handling out-of-memory conditions in C
  
  October 30th, 2009 at 7:57 am
  
  We've all been taught that when malloc returns 0, it means the machine ran out of 
  memory. This case should be detected and "handled" by our application in 
  some graceful manner. But what does "handled" mean here? How does an 
  application recover from an out of memory (OOM) condition? And what about the 
  increased code complexity of checking all those malloc return values and passing them 
  around?
  
  In this article I want to discuss the common policies of handling OOM conditions in C 
  code. There is no single right approach. Therefore, I will review the code of several 
  popular applications and libraries, to find out how they do it in order to gain useful 
  insights for my own programming.
  
  Note that I focus on desktop & server applications here, not embedded applications, 
  which deserve an article of their own.
  
  The policies
  
  Casting minor variations aside, it's safe to say there are three major policies for handling OOM:
  
  → メモリ確保に失敗した場合の対処ポリシーは大別して三種類。
  
  recovery
  
  The recovery policy is the least commonly used because it's the most difficult to 
  implement, and is highly domain-specific. This policy dictates that an application has 
  to gracefully recover from an OOM condition. By "gracefully recover", we 
  usually mean one or more of:
  
      * Release some resources and try again
      * Save the user's work and exit
      * Clean up temporary resources and exit
  
  Recovery is hard. To be certain that your application recovers correctly, you must be 
  sure that the steps it takes don't require any more dynamic memory allocation. This 
  sometimes isn't feasible and always difficult to implement correctly. Since C has no 
  exceptions, memory allocation errors should be carefully propagated to the point where 
  they can be recovered from, and this sometimes means multiple levels of function calls.
  
  → 「リカバリー」は難しいやり方。
  
  abort
  
  The abort policy is simple and familiar: when no memory is available, print a polite 
  error message and exit (abort) the application. This is the most commonly used policy 
  - most command-line tools and desktop applications use it.
  
  → メモリ確保に失敗したら、メッセージを出して実行を中断。
  
  As a matter of fact, this policy is so common that most Unix programs use a gnulib 
  library function xmalloc instead of malloc:
  
  void *
  xmalloc (size_t n)
  {
    void *p = malloc (n);
    if (!p && n != 0)
      xalloc_die ();
    return p;
  }
  
  When this function is called, its return value isn't checked, reducing the code's 
  complexity. Here's a representative usage from the find utility:
  
  cur_path = xmalloc (cur_path_size);
  strcpy (cur_path, pathname);
  cur_path[pathname_len - 2] = '/';
  
  segfault
  
  The segfault policy is the most simplistic of all: don't check the return value of 
  malloc at all. In case of OOM, a NULL pointer will get dereferenced, so the program 
  will die in a segmentation fault.
  
  → もっとも単純な対処法(?)。ぬるぽを返してそれをデリファレンスしたところでこけるに任せる。
  
  If there are proponents to this policy, they'd probably say - "Why abort with an 
  error message, when a segmentation fault would do? With a segfault, we can at least 
  inspect the code dump and find out where the fault was".
  
  Examples - libraries
  
  In this section, I present the OOM policies of a couple of well-known libraries.
  
  (以下略)
  

  • 忙しい人のための“What Killed Smalltalk Could Kill Ruby, Too” - Smalltalkのtは小文字です
  • Twitter / Shigeya: 突然おもいだしたけれど、Larry Wall の凄か ...
  • Twitter / きしだ: 日本語の書籍は数は多くて広い範囲をカバーしてるのだけ ...
  • DS海腹川背・旬SE完全版　「ファンの望む移植、ココに極まれり!!(*ﾟ∀ﾟ)=3」 - アキバBlog
  • 【コラム】コンピュータアーキテクチャの話 (163) リオーダバッファによるリネーム方式 | エンタープライズ | マイコミジャーナル
  • whale はクジラなのか？(3) - whaleは狩るものか、見るものか  - A Study around Super Heroes
  • モナドで悟りをひらきたいのなら - 図でわかる(?)モナド - a geek born in Tomakomai
  • Windows7でVisutal Studio 6 - arton (Tajima, Akio) - FriendFeed
  • Amazon.co.jp： 犬の帝国―幕末ニッポンから現代まで: アーロン・スキャブランド, 本橋 哲也: 本
  • おまえらもし目の前に小判があったらどうする？:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ
  • 「制作会社に採用されなくてよかった」原作者・竜騎士07の挫折と下克上（前編） - 日刊サイゾー
  • 迷信： Mooseは無用な従属物である - taro-nishino の日記
  • お部屋1971/【必読】多摩図書館廃棄本についての正確な情報 | ポット出版
  • お部屋1972/図書館の中では見えないこと 3 | ポット出版
  • 多摩図書館の件 - 図書館学徒未満
  • None is None is None: 多重デコレート
  • 「encounter」で始まる英和辞典一覧 - goo辞書
  • 「キンドル」が日本で絶対売れない理由: 愛と苦悩の日記
  これってどれが一番強いの？:アルファルファモザイク - ２ちゃんねるスレッドまとめブログ社団法人情報サービス産業協会が、残業代ゼロのホワイトカラーエグゼンプションを推し進めていた件 - 404 ないわー (・∀・)キムティ♪ Not Foundの日記

  Permalink  |  View Entire Page

• 31 Oct 2009 02:47

  2009年10月30日

  ・買ってしまった

  ■_

  Perl 6のデザインミーティングで。

  Journal of chromatic (983)
  
  Perl 6 Design Minutes for 21 October 2009
  
  [ #39819 ]
  
  The Perl 6 design team met by phone on 21 October 2009. Larry, Allison, Patrick, Will, 
  Nicholas, and chromatic attended.
  
  Nicholas:
  
      * I don't like UTF-16
      * Perl 5 should be able to read it big-endian and little-endian
      * Larry wrote the original code
      * I've fought several bugs in it
      * you get the benefit of larger sizes and variable length
      * but you have to deal with partial reads
      * I don't know if Rakudo will have to deal with it, but blah!
  
  

  まあ、UTF-16大好きってひとはいてもごく少数だろうなあ。

  ■_ short coding?

  stackoverflow.com で、自分の作った awk スクリプトを改良したいのだけど… というお話。

  How can I remove selected lines with an awk script? - Stack Overflow
  
  I'm piping a program's output through some awk commands, and I'm almost where I need 
  to be. The command thus far is:
  
  myprogram | awk '/chk/ { if ( $12 > $13) printf("%s %d\n", $1, $12 - $13); else  printf("%s %d\n", $1, $13 - $12)  }  ' | awk '!x[$0]++'
  
  
  The last bit is a poor man's uniq, which isn't available on my target. Given the 
  chance the command above produces an output such as this:
  
  GR_CB20-chk_2, 0
  GR_CB20-chk_2, 3
  GR_CB200-chk_2, 0
  GR_CB200-chk_2, 1
  GR_HB20-chk_2, 0
  GR_HB20-chk_2, 6
  GR_HB20-chk_2, 0
  GR_HB200-chk_2, 0
  GR_MID20-chk_2, 0
  GR_MID20-chk_2, 3
  GR_MID200-chk_2, 0
  GR_MID200-chk_2, 2
  
  What I'd like to have is this:
  
  GR_CB20-chk_2, 3
  GR_CB200-chk_2, 1
  GR_HB20-chk_2, 6
  GR_HB200-chk_2, 0
  GR_MID20-chk_2, 3
  GR_MID200-chk_2, 2
  
  That is, I'd like to print only line that has a maximum value for a given tag (the 
  first 'field'). The above example is representative of the at data in that the output 
  will be sorted (as though it had been piped through a sort command).
  

  
  If you find yourself squeezed for space and speed and this is not premature 
  optimization, you can replace your if ... printf ... else ...printf ... with the 
  shorter and, at least on my system, faster "poor man's abs()": 
  printf("%s %d\n", $1, (($12 > $13) * 2 - 1) * ($12 - $13))`
  
  

  
  Also, note that your awk command that filters lines on /chk/ can be combined into my 
  script below (with mods to save the appropriate "prev" fields instead of the 
  whole line, etc.) so you're only calling awk once. At the top of my script, s would be 
  set to (($12 > $13) * 2 - 1) * ($12 - $13) (untested)
  
  

  Based on my answer to a similar need, this script keeps things in order and doesn't 
  accumulate a big array. It prints the line with the highest value from each group.
  
  #!/usr/bin/awk -f
  {
      s = substr($0, 0, match($0, /,[^,]*$/))
      if (s != prevs) {
          if ( FNR > 1 ) print prevline
          prevval = $2
          prevline = $0
      }
      else if ( $2 > prevval ) {
          prevval = $2
          prevline = $0
      }
      prevs = s
  }
  END {
      print prevline
  }
  
  

  
  Much faster, and because memory is a concern (it's an embedded environment) I'm 
  switching to this as the correct answer. – Jamie 2 hours ago
  
  

  If you don't need the items to be in the same order they were output from myprogram, the following works:
  
  ... | awk '{ if ($2 > x[$1]) x[$1] = $2 } END { for (k in x) printf "%s %s", k, x[k] }'
  
  

  Nicely done. Thanks a bunch.
  

  Just missing the "\n" in the printf(). Otherwise perfect.
  

  Ah, right. I had that in my test version but forget it when typing it here. :)
  

  for xx in yy で列挙したときの順序について言及してますね。

  ■_ 七つの

  あとでや(ry

  
  
  The 7 characteristics of simple code (KISS) | Making Good Software
  
  I used to believe that the most important quality of code is its extensibility. The 
  code had to be prepared for future changes so I would code lots of things not 
  necessary now. But after realizing that I never was right upfront guessing what the 
  future changes will be, and after having quite a few maintenance and handover 
  nightmares, a few a years ago I decided that I will take the opposite approach to what 
  good code is. Ever since I did that, I am every day more convinced that the key 
  characteristic of good code is simplicity. Simple code is easy to read and easy to 
  change. And because it is simple, it is less prone to have bugs (the more complex the 
  algorithm you are creating the more changes to make a mistake).
  
  Whenever you are coding, I recommend you to check every time if your code is still 
  simple, and remember: “there are no hard problems, only hard solutions”
  
  The seven main characteristics of simple code are:
  
  1.- Easy to read. (読みやすく)
  
  Simple code doesn’t need additional documentation, or it only needs minimal 
  documentation to be understood
  
  2.- Easy to use. (使いやすく)
  
  Whoever is using your code will find it intuitive to use your objects.
  
  3. Easy to change. (変更しやすく)
  
  Simplicity means that there is no duplicated logic. A change should match a single 
  place in your code.
  
  4. Doesn’t use any non-necessary third party, tool or technology.
    (必要のないサードパーティ製のツールや技術を使わない)
  
  Through my experience I have observed how some developers just love to use 
  technologies, tools and frameworks just for the sake of making the project more “cool”. 
  Every time you use them, you are adding extra complexity, and extra complexity means 
  that is more difficult to understand, to maintain and is more prone to failures.
  
  5. It looks simple. (シンプルに見えるように)
  
  If it doesn’t look simple, it is not simple! You know your code is simple if when you 
  finish you are astonished at how simple the final solution is and you ask yourself how 
  it was possible that it took you so long.
  
  6. Lean. (最低限のものを)
  
  It only does what is necessary, and nothing else. I think most seasoned developers 
  would agree that trying to anticipate the problems your code will have to face in the 
  future is impossible.
  
  7. Is straight forward.(単刀直入に)
  
  It doesn’t have unnecessary indirections; the most important operations only require 
  a straight method call.
  
  How can we develop simple code?
  
  The key of producing simple code is continuous refactoring, and the only way to do 
  this is continuous testing.
  
  You are going to need refactoring because every time you add a new line to your 
  algorithm, you are probably making it more complex. So every now and then you should 
  refactor to get it back to a simple stage.
  
  You need many tests because you are doing so much refactoring, and if you don’t have 
  a safety net you are going to introduce bugs into your system.
  
  

  ■_

  • ASCII.jp：～師範！　今日公開のUbuntu9.10を解説してください！～｜行っとけ！　Ubuntu道場！
  • 方法改善は 「4つのポイント」を見逃さないことがコツ!!（2/4） － ＠IT MONOist「作業改善の尻切れトンボ」のもう一つの原因は、新しい方法をいくらも試さないであきらめてしまうことです。
  • .NET TIPS － ＠IT
  • InfoQ: IronSchemeが近く最終リリースされるIronSchemeはコマンドプロンプトから実行できるREPL環境として利用できる。また、.NETアプリケーションにライブラリとして埋め込んで使うことも可能だ。 .NETの32または64ビット環境か、Monoの32ビット環境で動作する。
  • InfoQ: アジャイル開発を成功に導く26のヒント1つの作業を完全に終えてから次の作業を開始しなさい。 決定することを恐れるな。そして、以前の決定を変更することを恐れるな。 測定、測定、そして測定。 システム中心ではなく人間中心の設計をするべし。 早すぎる最適化は諸悪の根源。 機能を一般化しすぎるな。 コードの行数を計測するな。 ソフトウエアはプラスチックだ。 新しい言語を発明するな。
  • InfoQ: MacRuby 0.5ベータが登場。JIT、AOT、GCDサポート、GILの削除を実現ripper、digest、socket、zlibといったC拡張は少し修正することで動くようになっています。将来のリリースでは、MRI C拡張APIをフル実装する計画です。
  • The Busy Beaver Problem - good coders code, great reuseThe busy beaver problem is a fun theoretical computer science problem to know. Intuitively, the problem is to find the smallest program that outputs as many data as possible and eventually halts.

  1. 2009年11月(上旬)

  Permalink  |  View Entire Page

• 30 Oct 2009 07:48

  2009年10月29日

  ・川背さん 待ちに待って、今日ようやくDS版を手に入れました。 長かった(笑)

  ・ドラフト 菊池雄星は6球団競合の末、ライオンズが交渉権獲得と。 ベイスターズは退団した人数を考えると、指名した人数がすくなかないか?

  ■_ 浮動小数点数

  ついったでちらほらと話題が出てたのを見かけたので。

  あまり知られていないようですが、10を基数とする浮動小数点数がちゃんと規格になってます。 以前は IEEE754R とも呼ばれていたもので、正式に決まったあとは IEEE 754-2008という 名称になっています→ IEEE 754-2008 - Wikipedia, the free encyclopedia

  IEEE 754-2008 - Wikipedia, the free encyclopedia
  
  The standard defines
  
      * arithmetic formats: sets of binary and decimal floating-point data, which consist of
        finite numbers, (including signed zeros and subnormal numbers), infinities, and
        special 'not a number' values (NaNs)
  
      * interchange formats: encodings (bit strings) that may be used to exchange
        floating-point data in an efficient and compact form
  
      * rounding algorithms: methods to be used for rounding numbers during arithmetic and
        conversions
  
      * operations: arithmetic and other operations on arithmetic formats
  
      * exception handling: indications of exceptional conditions (such as division by
        zero, overflow, etc.)
  

  sets of binary and decimal floating-point data, のように、「decimal」があります。 んで、BCDのように考えると、基数が2のときと比べて仮数部に収められる情報量が減ってしまいますが、 頭の良い人はどこにでもいるもので、表現方法を工夫してできるだけ多くの情報量を保てるように なっています。つかまだ良くわかってません(苦笑) → Decimal32 floating-point format - Wikipedia, the free encyclopediaDecimal64 floating-point format - Wikipedia, the free encyclopediaDecimal128 floating-point format - Wikipedia, the free encyclopedia

  確か POWERの最新のものがこれのハードウェアサポートをしていたような。

  • ASCII.jp：MAC層から改良したIEEE802.11nの仕組み｜無線LANのすべて
  • あなたは大丈夫？今さら聞けない「名刺交換」のマナー - はてなブックマークニュース
  • Clojure プログラミング言語
  • Python で MetaWeblog API を使ってわんくまブログに記事を投稿する - present
  • Python on Ice
  • [PSTweet]TwitterクライアントPowerShellモジュールを作ろう！(1)
  • To Scheme, or Not to Scheme:
    Scheming Schemers and Non-Scheming Schemers, or Keeping the Fun in Scheme « Monadically Speaking: Benjamin’s Adventures in PLT Wonderland
  • What is the symbol "=>" doing after my method in this C# code? - Stack Overflow
  • Python, lambda, find minimum - Stack Overflow
  • プログラミング言語が与える影響 (GrayRecord)
  • Achiral に Scan とか Pairwise とか条件変化可能な TakeWhile を入れてみた - NyaRuRuの日記
  • 無題 - ntnekの日記
  • 梶本裕介の日記
  • Hexenkessel - 海外の高級ファッションブランドが相次いで日本からの撤退・縮小を決めている。世界のブランドが日本を「プレ...
  • Shibuya.lisp » Blog Archive » Shibuya.lisp TT#4 ライトニングトークの発表内容決定!
  • What?
  • 第14回 関数脳のつくり方　Second Season　～モナドで悟りをひらく～ - 刺激を求める技術者に捧げるScala講座：ITpro　へのツッコミ - Onion開発再開しつつある日記
  • 10のPerl迷信 - taro-nishino の日記
  • 的を得とは - はてなキーワード
  • IT Books 刊行スケジュール: 2009年10月29日(木) の新着
    プログラミングHaskell 2009-11-11、オーム社、￥2,940、ISBN：9784274067815
    3000円切ったのか。でもまあ Real World Haskell (実践Haskell)も4000円は切ったしなあ
  • 「禁書」と同じく「とある科学の超電磁砲」のBD＆DVDは全8巻 :おた☆スケ -おたくのスケジュール帳-
  • chris moos’s blog » Blog Archive » libactor – a C library based on the Actor model
  • new と　malloc によるメモリの動的確保について -OKWave

  ＠ITってのは怖いところだなあ

  これはもうダメかもわからんね インフラ系SEの波瀾万丈伝: こ　れ　は　ひ　ど　い
  
  あんたもひつこかね。今、大阪脱出作戦に向けて、首都圏の親類縁者すべてにホームステイ願い
  をお願いしているところなので、お前と遊んでいる暇はなかばい。
  
  どこへでも去ね。あと、こんにちは、じゃなくて、こんばんはの時間なので、コピペなどという
  ちゃちいことはやめようね。やることが姑息で幼いよ。
  

  これはもうダメかもわからんね インフラ系SEの波瀾万丈伝: エンジニアだから、と気負う必要は全くナシ
  あのですね、僕は15歳からずーっとパソコンばかりやってきたわけですよ。で、限界が見えてき
  たんですね。CAD、DTP、情報インフラ……。続ければ続けるほど神経を害する結果になってきま
  した。（何個か前のコラム「傷ついた翼」ご参照）僕の場合、神経に来ているんで、趣味は趣味
  で置いておいて、何か別の就業を考えています（というか、考える年齢に来ています）。
  
  情報マネジメントとか、管理する側に回れればいいのですが、なかなか易々と採用してもらえま
  せん。
  
  若いうちは必要ですよ。好きなことを仕事にして、得手に帆を上げて頑張るというのは、僕もそ
  うでしたし、次に続く若者にもそうあって欲しいとは思います。
  
  ただ、人間40歳近くになると、どうも根気が続かない。頭痛がしたりする。そういうわけですね。
  ではでは。
  

  ■_ The Lisp Machine: Noble Experiment Or Fabulous Failure?

  ところどころすげー苦労した文が(苦笑)。 ということでチョー訳まじりですが。

  The Lisp Machine
  The Lisp Machine:
  Noble Experiment Or Fabulous Failure?
  Draft 11 July 1991
  P. T. Withington
  Symbolics, Inc.
  
  The "Lisp Machine", a custom computer work-station designed specifically for 
  the execution of Lisp, has been an important part of the Lisp tradition for 20 years. 
  Recently, the Lisp Machine has been deprecated in view of the demise of many Lisp 
  Machine vendors, the swing towards standardization, and the advances that reduced 
  instruction set (RISC) architectures have brought. But rumors of its death are greatly 
  exaggerated.
  
  Lisp の実行に特化して設計されたカスタムワークステーションである “Lispマシン”
  は二十年にわたりLisp の重要な部分でありました。近年、多くの Lisp マシンベンダーの終焉
  を目にしてLisp マシンは deprecated (不賛成、非難)されるようになっていて、標準化の方向
  へと方向転換して縮小命令セット (RISC) アーキテクチャーが伸びてきました。しかし、Lisp 
  マシンの死の風評は非常に誇張されたものなのです。
  
  Unlike most commercial computer languages, Lisp has always been a language of ideals. 
  Its roots are in the theory of lambda-calculus. Whereas other languages burden the 
  programmer with implementational gaps in their abstractions, Lisp has always had the 
  aim of supporting complete abstractions.[1] This idealistic bent of Lisp has led to it 
  often being the language of choice for computer-oriented research in universities and 
  industry. Removing the more mundane difficulties of computer programming allowed 
  researchers to experiment with super-complex (at the time) technologies such as 
  windowing, presentation managers, object-oriented programming, integrated programming 
  environments, computer music, integrated-circuit design, and of course Artificial 
  Intelligence (AI).
  
  大部分の商用コンピューター言語とは違い Lisp は常に language of ideals でした。Lisp と
  いう言語のルーツには λ計算があります。Lisp 以外の言語がその抽象化における実装的ギャッ
  プ (implementational gaps in their abstractions)でプログラマーを苦しめていたのに対して、
  Lisp は常に complete abstractions.[1] をサポートすることを目指していました。この Lisp 
  の idealistic bent は大学や産業界における computer-oriented research 向けの language 
  of choise でした。より多くのコンピュータープログラミングに関する mundane difficulties 
  (ありふれた困難?) を取り除くことによってプレゼンテーションマネージャー、オブジェクト指
  向プログラミング、統合プログラミング環境、コンピューター音楽、集積回路の設計、そしても
  ちろん人工知能 (AI, Artificial Intelligence) といった(当時は)非常に難しいことの実験を
  研究者が行うことを可能にしたのです。
  
  But, Lisp's purity did not come without a price. The choice by many languages to 
  expose implementational limitations is often a choice of efficiency. The speed of the 
  normal case is optimized at the risk of the abnormal case going undetected. Lisp, on 
  the other hand, guarantees the unusual as well as the usual will be dealt with 
  uniformly. It must always be on its guard: every operation must be checked for 
  exceptions. As a consequence, Lisp on conventional machines has historically been 
  ponderous to work with.
  
  しかし Lisp の purity (純粋さ) は価格から来たものではありませんでした。多くの言語で為
  された expose implementational limitations (実装上の制限の表面化?) のための選択はしば
  しば choice of efficiency (効率のための選択?) でした。通常のケースでの速度は正常でない
  ケースを検出しない場合もあるというリスクの上で最適化が行われていました。一方 Lispでは 
  unsusalなものは は usual なものと同じように統一的に扱われていて、すべての操作で例外の
  検査を行われることが要求されていました。その結果として conventional machines 上の Lisp
  はそういった検査を行っているために伝統的に動作が重いものになっていました。
  
  In the early 1970's several groups of researchers utilized two novel hardware 
  technologies to improve the efficiency of Lisp: tagged architectures and 
  micro-programming. Tagged architectures store type information with each data word, 
  tracking dynamically changing types (a prominent feature of the Lisp language) with 
  essentially no overhead. Micro-programming allows a simpler compiler by implementing 
  complex instructions that more closely match the high-level semantics of the Lisp 
  language. Experimenting with these techniques eventually led to commercial 
  introductions of "Lisp Machines".
  
  1970年代初め、いくつかの研究者たちのグループは二つの新しいハードウェア技術(novel 
  hardware technologies) をLisp の効率性の向上のために適用していました。タグつきアーキテ
  クチャ (tagged architechtures) とマイクロプログラミング(micro-programming) がそれです。
  タグつきアーキテクチャは個々のデータワードそれぞれに型情報を一緒に格納するというもので、
  型の変更を動的に追跡することがオーバーヘッドがかからずに行えました。マイクロプログラミ
  ングはLispという言語の高度なセマンティクスにより密接にマッチする複雑な命令を実装するこ
  とによってより単純なコンパイラが使えるようにします。これらのアーキテクチャによってなさ
  れた実験は“Lispマシン”の商業的な導入 (comppercial introductions) へと繋がっていった
  のです。
  
  Other novel features of these machines include:
  
  これらのマシンのその他の novel features には以下のようなものが含まれていました:
  
      * The "stack cache"-- Execution of Lisp is stack-oriented. By caching the
        top elements of the stack, efficiency approaching that of register-based execution
        is achieved without complex register allocation algorithms in the compiler. The
        stack cache also supports fast function call and return, as if the function arguments
        and values are passed in registers.
  
        “スタックキャッシュ” － Lisp の実行はスタック指向です。スタックのトップ要素をキャッシ
        ングすることによって、レジスターベースの実行のような効率的なアプローチはコンパイラーが
        複雑なレジスター割り当てアルゴリズムを使わなくても目標とする性能を発揮できました。スタ
        ックキャッシュはまた、関数の引数や戻り値がレジスタを通して渡されるかのような高速な関数
        呼び出しと復帰もサポートします。
  
      * Garbage-collection support-- Lisp's storage management system is often implemented
        as a "garbage collector", which automatically reclaims unused objects.
        The Lisp Machine virtual memory hardware, in concert with the type tags, tracks
        object-reference loads and stores so the software can determine quickly which
        objects are in use and efficiently reclaim those that are not.
  
        ガーベジコレクションのサポート － Lisp のストレージ管理システムは、使われていない
        オブジェクトを自動的に回収する“ガーベジコレクター”(garbage collector) として実装
        されているのがほとんどです。Lisp マシンの仮想メモリーハードウェアは object-reference
        のロードとストアを記録しているのでソフトウェアはどのオブジェクトが使用状態にあるのか
        をすばやく判定することが可能で、これにより使われていないオブジェクトを効率的に回収で
        きるようになっています。
  
      * Instruction emulation-- When the Lisp Machine hardware encounters an exceptional
        situation (for example, an integer arithmetic operation that exceeds the hardware
        imposed implementation limit or an operation on a software-defined type) the hardware
        traps out to a software "emulator" subroutine. This subroutine implements
        the full semantics of the operation, as specified by Lisp, as though it is being
        handled by the machine instruction.
  
        命令のエミュレーション － Lispマシンのハードウェアが例外的状況 (exceptional situation)
        に遭遇したとき(たとえば整数演算がハードウェアの想定している限界を越えてしまったとか
        ソフトウェアで定義している型に対する操作)、ハードウェアはソフトウェアの“エミュレーター”
        サブルーチンへ trap out します。このサブルーチンはオペレーションの full semantics を
        実装していて、Lisp によって specified されるのと同様、machine instruction によるものの
        ように処理されます。
  
  Early Lisp Machines implemented their micro-programmed architectures with a writable 
  control store, which meant the instruction set, and to a certain extent other 
  architectural features of the machine, could be changed by simply writing, compiling, 
  and loading new micro-code. This flexibility led to further experimentation and 
  evolution of the hardware support for Lisp.
  
  初期の Lispマシンは書き込み可能な制御記憶を備えたマイクロプログラム型アーキテクチャ 
  (micro-programmed architectures)によって実装されていました。その制御記憶とは 
  instruction set を意味しており、マシンの other architectural features のいくつかは新し
  いマイクロコードを書き込んでコンパイルし、ロードすることによって変更することが可能でし
  た。この柔軟性というものは further experimentation と Lisp 向けのハードウェアサポートの
  進化に繋がるものでした。
  
  In the late 70's and early 80's both AI and the Lisp Machine enjoyed a brief but heady 
  vogue. Two small companies, Symbolics and Lisp Machines, Inc. (LMI), were founded to 
  build Lisp Machines; Symbolics was eventually taken public. Xerox and Texas 
  Instruments (TI) also entered the market. As late as 1986, Integrated Inference 
  Machines (IIM) entered the Lisp Machine market. Computer science researchers, eager to 
  speed their experiments, snapped up the machines. Companies bought them for their 
  R&D labs in hopes of solving a wide array of problems from analyzing stock trades,
  to interpreting seismological data, to scheduling airlines, to evaluating loan 
  applications. At the time, Lisp Machines were the only computer work-station of 
  significant power and the only economic solution to efficiently developing and running 
  Lisp programs.
  
  1970年代の終わりから80年代の初めにかけて、AI と Lisp Machine は共につかの間の流行を謳
  歌していました (enjoyed a brief but heady vogue)。Symbolics と Lisp Machines, Inc.
  (LMI) という二つの小規模な企業がLispマシンを製造するために設立されました。Symbolics は
  eventually taken public でした。 XeroxとTexas Insturments (TI)もまた市場に参入してきました。
  1986年の終わり頃には、Integrated Inference Machines (IIM) が市場に参入しました。自分た
  ちの実験のスピードに貪欲なコンピューターサイエンスの研究者たちは snapped up the 
  machines。 企業はそういったものを自分たちの R&D labs 用に株取引の解析 (analyzing 
  stock trades) からseismological data の解釈だとか航空便のスケジューリング(scheduling 
  airlines)、loan applications の評価といった幅広い問題を解決できることを期待して購入し
  たのです。その時点で、Lisp Machines は唯一の significant power を持っていたコンピュー
  ターワークステーションでありLispプログラムの開発と実行を効率的に行うための唯一の経済的
  ソリューションだったのです。
  
  The Lisp Machines produced by these companies went through several evolutionary 
  generations: starting at the high price of $150,000 and implemented in TTL in a box 
  rivalling the VAX/780 in size and power consumption[2] and eventually being delivered 
  as 1- or 2-chip VLSI implementations on $10,000 add-in boards for the Apple MacIntosh. 
  With this latest generation of Lisp Machines, Symbolics was satisfied that its 
  instruction set had evolved sufficiently to commit it to mask-programmed ROM. However, 
  the small size of the market for these machines has meant they are unable to take 
  advantage of the cutting-edge hardware technology of commodity machines. They always 
  lag by a few generations, where design and production costs are more reasonable.
  
  これらの企業によって生産された Lisp マシンは、いくつかの evolutionary 世代を辿り
  ました: はじめは価格も15万ドルし、TTLを使って実装されていて大きさや電力消費量 [2] が 
  VAX/780ほどもあるようなものだったものが、eventually being delivered の結果、一つか二つ
  の VLSI で実装された Apple Macintosh 向けの1万ドルのアドインボードまでになりました。こ
  の最後の世代の Lisp Machine と共に、Symbolics はマスクROMに commit するのに evolved 
  sufficiently した命令セットを満足させました。しかしこのマシンに対する市場規模の小ささ
  が理由で、彼らはコモディティ (commodity) なマシンにあった最先端のハードウェア技術のア
  ドバンテージを得ることができませんでした。彼らには設計と製造コストがより reasonable 
  なものになるのにいつも数世代の遅れがありました。
  
  Initially, the small companies received great exposure in the popular press. Because 
  they represented a "pure play"[3] in AI, they were the darlings of Wall 
  Street. But today, only Symbolics remains in the market trying to sell Lisp Machine 
  work-stations, at about 1/6 the size of its heyday. The popular opinion is that AI 
  technology was oversold and lost its credibility; while at the same time, Unix was 
  rising to meet the need for standards and RISC computers, with their simple 
  instructions that can be executed at fantastic rates, obviated the need for a custom 
  machine to implement Lisp. The press was as quick to damn the Lisp Machine companies 
  as it had been to praise them, when they did not meet over-inflated expectations.
  
  初めは小さな企業が一般紙 (popular press) で多大な露出をされていました。彼らは AIで 
  "pure play"[3] を代表 (represent) していましたから、彼らは ウォールストリー
  トの darlings だったのです。しかし今日、Symbolicsだけが市場にとどまりLisp Machine ワー
  クステーションを売ろうとしていますが、それは全盛期に比べれば 1/6 ほどの規模でしかあり
  ません。巷間よく言われていることは、AI テクノロジーは売りすぎてしまったために信用を失
  ったというものです。時を同じくして、標準化とRISCコンピューターに対する必要性に直面した 
  Unix が勢力を伸ばしました。RISC コンピューターはとんでもないレートで実行が可能な単純な
  命令セットを持っていて、Lisp を実装するためのカスタムマシンの必要性をなくしてしまった
  のです。The press は they did not meet over-inflated expectations のときに、Lisp マシ
  ン関連の企業をかつては誉めそやしたのと同じ理由で非難しました。
  
  A more charitable interpretation of the same facts might be that the Lisp Machine 
  market (by its esoteric nature) is small, and given normal start-up statistics, is 
  doing surprisingly well. The Lisp Machine was a pioneer in the early days of 
  work-station technology. It had the now standard high-resolution bit-mapped display, 
  mouse pointing device, large virtual memory and local disk; it even had 16-bit digital 
  stereo sound! Some of these innovations contributed to the evolution of Lisp and its 
  associated technologies. Unfortunately, the similarity of these features to those 
  eventually found on general-purpose work-stations led to confusion over what the 
  market for the Lisp Machine was. The exotic features of the Lisp Machine that made it 
  ideal for running Lisp and the dream-machine of many computer researchers had little 
  or no value in the general-purpose market. The success it enjoyed as a Lisp 
  engineering work-station faltered at attempts to market it as a computer-aided 
  software engineering (CASE) work-station.
  
  同じ効果の、より寛大 (charitable) な interpretaion は(その esoteric な性質により) 小さ
  な Lisp マシンの市場と通常与えられる start-up statistics によりとても surprisingly に
  行われました。Lispマシンというのは初期のワークステーションテクノロジーにおけるパイオニ
  アでした。現在では、高精細なビットマップディスプレイやマウス、大きな仮想メモリとローカ
  ルディスク、さらには16ビットディジタルステレオサウンドでさえも標準的なものとなりました。
  これらの発明の幾つかはLisp や関係した技術の進化に貢献しました。残念なことに、こういっ
  た汎用目的のワークステーションはLisp マシンが指向していたマーケットを混乱に導いたので
  す。Lisp マシンを Lisp を実行するのに理想的なものとするための exotic な機能だとか多く
  のコンピューター研究者にとっての dream-machine といったものは、汎用目的市場においてほ
  とんど無価値といっていいものでしかなかったのです。CASE (computer-aided software 
  engineering) ワークステーション市場を狙ったLisp エンジニアリングワークステーションの成
  功は挫折してしまいました。
  
  At the very least, one can say that the Lisp Machine was there for Lisp when it 
  threatened to drown in its own idealism, due to the primitive power of the hardware 
  architectures of its time. The attention the Lisp Machine companies drew may have 
  added life to the Lisp market; it certainly added to the investment in Lisp research. 
  In their heyday, the companies making Lisp Machines attracted top-notch talent and 
  funded innovative research in many areas of computer science, both hardware and 
  software.
  
  最低限、その時代におけるハードウェアアーキテクチャの primitive なパワーが原因でLisp が
  その理想主義 (idealism) の中で溺死して絶滅しそうだったときにLisp マシンは Lisp のため
  に存在していたということは言えるでしょう。The attention the Lisp Machine companies 
  drew は Lisp マーケットを延命したかもしれません。その全盛期に Lisp マシンを作った企業
  は top-notch talent を惹きつけ、そしてコンピューター科学のハードウェアとソフトウェア両
  方での多くの領域で革新的な研究をたちあげたのです。
  
  However, the Lisp language did suffer in the commercial market from its association 
  with what many customers have come to regard as the "snake oil" of AI. 
  Because its only perceived redeeming value was to run Lisp, the Lisp Machine suffered 
  doubly so. Despite the grim appearance of the future of the Lisp Machine, there remain 
  small groups of zealots who will not part with their Lisp machines without a fight. 
  They battle "MIS" departments and often end up closeting their Lisp Machines, 
  so they won't be pestered about their non-approved equipment.
  
  しかし Lisp という言語はコマーシャルマーケットにおいて苦戦を強いられていました。それは
  多くの顧客が Lisp を AI の  "snake oil" であるとみなしてしまっていたからなの
  です。(Lisp マシンの) perceived redeeming value は Lisp を実行することであったので、
  Lisp マシンは不満を二重に受けていました。Lisp マシンの grim appearance of the future  
  にも関わらず、戦いの外にいてLisp マシンの一部とはならなかったzealots の 小さなグループ
  群が残りました。彼らは "MIS" 部門と戦いを繰り広げましたが、ほとんどの場合は 
  Lisp マシンの closeting をあきらめる結果となってしまいました。このため、彼らは自分たち
  が approved していない equipment に関して pestered (しつこくせがむ) しなくなったのです。
  
  #snake oil → (思いっきり省略) 怪しげなモノ
  
  It has been argued that while Lisp may represent the ideal solution to a problem, the 
  ideal solution is not always the economic solution, even more so when it requires a 
  custom machine to run it. Today, there is a wide choice of general-purpose computer 
  work-stations of similar power to the Lisp Machine, most with competitive Lisp 
  implementations. Many of the software technologies that were considered research areas 
  when the Lisp Machine was introduced have been codified to the point that they are 
  amenable to implementations using commodity software and hardware. Others will follow. 
  This trend has led many to believe there is no longer a need for the power of Lisp and 
  even less a need for the Lisp Machine. What is often not considered, however, is 
  whether these technologies would be where they are today (or would have been explored 
  at all) in the absence of the Lisp Machine. Despite the trend toward commodity 
  software and hardware, there continue to be super-complex and evolutionary problems 
  where the Lisp Machine is the ideal solution and may well also be the most economic. 
  The future is likely to bring more.
  
  理想的ソリューションが常に経済的ソリューションでもあるわけではありません。
  特にそれが実行のためにカスタムマシンを必要とするような場合にはそれが顕著です。
  今日、Lisp マシンと同等のパワーを持った汎用のコンピューターワークステーション
  (general-purpose computer work-stations) が Lisp を実装するのに最も competitive なもの
  として広く選択されています。Lisp マシンが導入された時点では研究領域にあると見なされて
  いたソフトウェア技術の多くが、コモディティなソフトウェアとハードウェアを使って実装する
  ポイントであると codified されましたその他のものもfollow するでしょう。このトレンドは、
  もはや Lisp のパワーを必要としないし、Lisp マシンの必要性はもっとないという believe に
  繋がりました。しかし、これらの技術がLisp マシンが存在していない今日において(あるいは 
  would have been explored at all で)存在し得るかどうかということが省みられることはほと
  んどありませんでした。時代の流れはコモディティなソフトウェアとハードウェアに向いていっ
  てしまいましたが、Lisp マシンが理想的なソリューションであり同時に最も経済的であるかも
  しれないような super-complex かつ evolutionary な問題は存在しつづけています。
  The future is likely to bring more.
  
  Compiler technology has evolved significantly since the birth of the Lisp Machine. 
  Many of the problems that the micro-code of the Lisp Machine solved for the compiler 
  writer can now be dealt with. The RISC revolution, which depends on a super-simple 
  instruction set for its phenomenal execution rate, has forced the compiler writer to 
  deal with similar problems, even in conventional languages. But the companies that 
  market Lisp on RISC machines (perhaps begrudgingly) admit that despite their hardware 
  technology lag, Lisp Machines are still competitive or surpass the latest RISC 
  implementations in both Lisp benchmarks and, more often, high-end Lisp applications.
  
  Lispマシンの誕生以降、コンパイラー技術は長足の進歩を遂げました。Lispマシンのマイクロコ
  ードについての多くの問題はコンパイラー作家 (compiler writer)がそれに対処できるようにな
  りました。phenomenal execution rate (驚異的な実行レート?) を非常に単純な命令セット 
  (super-simple instruction set) に依存していた RISC革命 (RISC revolution) は、たとえ言語
  が conventional languages であっても同様の問題に対処することをコンパイラー作家に強制す
  るようにしました。RISC マシン上での Lisp を販売している企業は、 Lisp マシンがハードウェア
  テクノロジーにおいて差があるにも関わらず Lisp のベンチマークとハイエンドの Lisp アプリ
  ケーションの両方において今でも最新の RISC 実装と比較して同等の性能かあるいは凌駕する性
  能を持っていることを認めています。
  
  Today, most RISC hardware architectures support either large register sets or register 
  windows, which bear great similarity to a stack cache. Close examination of some of 
  the newest RISC architectures will reveal support for tagged data, to efficiently 
  implement generic arithmetic operations. Architecture research papers continue to 
  evaluate the merits of read and write "barriers", pioneered by Lisp Machine 
  garbage collectors to track object references and speed automatic storage reclamation, 
  and "fast traps" to allow expeditious handling of exceptional conditions in 
  a manner similar to the Lisp Machine instruction emulation.
  
  今日における RISC のハードウェアアーキテクチャーは、いずれも bear great similarity to 
  a stack cache であるような(スタックキャッシュに非常に良く似た?)大きなレジスターセット
  かレジスターウィンドウのいずれかをサポートしています。いくつかの最新の RISC アーキテク
  チャの Close examination では一般的な算術演算 (generic arithmetic operations) の効率的
  な実装のためにタグつきデータの reveal support をします。Architecture 研究論文では、
  read and write "barriers" のメリットの評価が続いていて、Lispマシンから始まる
  ガーベジコレクターがオブジェクトの参照を追跡するためや自動記憶領域 reclamation の速度
  のため、さらには Lispマシンの命令エミュレーションに対して in a manner similar な例外条
  件の expeditious handling を可能とするための "fast traps" のメリットの評価を
  続けています。
  
  The current commercial versions of the Lisp machine have reached about the level of 
  integration that floating-point and vector co-processors had in the early 80's. It 
  remains to be seen if they will end up as simply a footnote in the history of Lisp, or 
  if they will continue to evolve and their best ideas live on as an integral part of 
  future commercial computer hardware.
  
  現在の商用バージョン (commercial versions) の Lispマシンは、80年代初期には実現されてい
  た浮動小数点演算コプロセッサーとベクターコプロセッサーが統合されたレベルにまで到達して
  います。もしそれらが Lisp の歴史の footnote に過ぎないもので終わっていたでしょうし、
  逆にそれらが進化しつづけていていたら、their best ideas は 将来の商用コンピューターハー
  ドウェアの integral part として生きているでしょう。
  
  [1]
  For example, in `C' the answer to (1-2/3)*3 is either 3 (!) or perhaps 0.99999994, 
  in Lisp it is 1; in `C' the answer to 2147483647+2147483647 is -2 (!), in Lisp it is 
  4294967294. Because `C' is transparent to implementation detail, it may be that some 
  `C' implementations will give the right answer (or a different wrong answer) for these 
  particular examples; nonetheless, the programmer's task is often more difficult 
  because of this transparency. Lisp also has finite limits in its implementation, but 
  they are usually large enough to not be of practical importance.
  
  一例を挙げると、C では (1-2/3)*3 の答えは 3(!) か、あるいは 0.99999994 のようなものの
  いずれかになります。Lispではこの結果は 1 になります。2147483647+2147483647 の答えは C 
  ではなんと -2になりますが、Lispでは 4294967294 です。これらの特定の例に対して一部の C 
  の実装では正しい答え(あるいは別の間違った答え)を返すかもしれません。いずれにしても、こ
  の透明性が原因でプログラマーの仕事 (task) がしばしば難しさを増すことになっています。
  Lisp もまたその実装によるところの限界というものがありますが、通常それは問題になること
  がないくらい十分大きなものです。
  
  [2]
  It is amusing to realize that a machine of this size and price was ever considered 
  a work-station.
  
  かつてこの大きさや価格のマシンがワークステーションと見なされていた
  ということを realize することを仮定しています。
  
  [3]
  An investment term meaning the company is in a single market and
  can be expected to track that
  market's fortunes more closely than a diversified company might.
  
  
  Last Updated: 02-03-25
  
  Problems, questions to Webmaster
  
  Copyright ﾂｩ 1998-2002 Callitropetm
  
  

  Permalink  |  View Entire Page

• 29 Oct 2009 05:12

  2009年10月28日

  ・速記記念日 10月28日は速記記念日だそうです。

  ・Twitter のデフォルトアイコンとイトーヨーカ堂のマークはなんとなく似ている(気がする)

  ■_ Smalltalk のどこがイヤ

  だいぶ削りましたので、全部見たい方はリンク先へどぞ。

  
  Ask Proggit: what do you dislike in Smalltalk? : programming
  
  A feature of Smalltalk you dislike, a reason for you to dislike smalltalk, a Smalltalk 
  dislike, Smalltalk aDislike.
  
  Only one per post (if you have multiple, just go with the most egregious issue, or 
  with the most obscure).
  
  If you can, expand on why you dislike that, and (if it's fixable) how you'd fix it in 
  "your" Smalltalk
  
  

  
  Back in the day when I learnt it, it was just too slow. I still play with squeak every 
  now and then. In fact, smalltalk is probably the reason I like Ruby so much.
  
  → 遅い
  

  
  The lack of a robust, full-featured, well-integrated, well-documented, well-maintained 
  and widely-used high-level interface to a polished GUI toolkit such as wxwidgets, Qt, 
  GTK (or even Tk at a push), that works out of the box with Squeak/Pharo among others, 
  providing a de-facto cross-dialect standard for building native GUIs in the same way 
  that Seaside has provided for web applications.
  
  

  
  I think for me the greatest reason would be ``because I like Unix too much''. And 
  Smalltalk is so un-Unix.
  
  → 非UNIX的すぎる(って前にもどこかで見たような)
  
  

  
  Lack of modularity.
  
  → モジュール機能がねえ
  

  
  The fact that "1 + 2 * 3" is equal to 9, and not 7 like ALL the other languages out there.
  
  → 1 + 2 * 3 が 9 になるなんて以下略
  

  
  image based dev - doesn't interact with other tools thanks to non text based code 
  representation. you can hack aorund this somewhat, but it is cumbersome.
  
  → 「プログラムのファイル」というものがなくて、「イメージ丸ごと」
  

  
  The syntax.
  
  → 構文
  

  
  The lack of optional "self", even though I appreciate it, makes it harder to 
  develop good DSLs without crowding Object with extra methods or without sprinkling 
  methods in every other class
  
  → self の省略不可
  

  
  ^Smalltalk's methods should just default to returning the last evaluated expression, 
  that would put them more in line with blocks (which do just that), potentially create 
  more useful/interesting return values and remove a number of ^ from the code.
  
  Ruby of course behaves this way, which reminded me of the Kent Beck quote:
  
  "I always thought SmallTalk would beat Java. I just didn't know if would be 
  called 'Ruby' when it did so."
  
  

  
  Ah you were talking hypothetically, I'd misunderstood that part (and thought you'd 
  discovered literals for high level types in Smalltalk).
  
  #[] isn't available by the way, it's the literal for byte arrays (in GST and Dolphin 
  anyway, I don't know if it comes straight from Smalltalk-80).
  
  

  
  Returning self by default enables and encourages a lot of nice DSL tricks which are a 
  pain to do in languages where some other value is returned by default. I'm happy to 
  pay a few ^'s for that.
  
  

  
  I tried to learn smalltalk, but I have bad case lisp, so everyone just laughed at me.
  
  

  
  Because it is object oriented. I find objects harder to reason about and test, and 
  create state transitions that are obsurdly hard to understand, espaecially in code 
  that has been sitting around for years and having features added by assorted 
  developers. Oop does ideally model some classes of problems, but many more it does not 
  and adds more burden then it helps. I generally avoid languages that treat oop as a 
  first class concept.
  
  →オブジェクト指向だからいや?
  
  

  
  The environment and dynamic typing.
  
  →環境と動的型付け
  

  
  Complaining that operators all have the same precedence is a perfectly valid reason to 
  dislike Smalltalk(*). Indeed, others have done so. That isn't, however, what 
  grauenwolf wrote. What he wrote is something along the lines of "Smalltalk has a 
  strict left-to-right evaluation order". And that simply isn't true.
  
  * I think it holds as much water as complaints about Python's indentation-based blocks 
    though.
  
  

  
  It is always the same thing: the bad syntax. All failed languages like COBOL, Lisp and 
  Smalltalk have bad syntax. All successful languages like C, Java, C#, Python, Ruby, 
  JavaScript have beautiful English-like syntax.
  
  

  
  The fact that it's an academic only language not used anywhere...
  
  

  ■_ 教えてSTLの以下略

  コメントの方はあえて抜いで。

  Hidden Features and Dark Corners of STL? - Stack Overflow
  
  C++ developers, all know the basics of C++: Declarations, conditionals, loops, 
  operators, etc.
  
  Some of us even mastered the stuff like templates, object model, complex I/O, etc.
  
  But what are the most hidden features or tricks or dark corners of C++/STL that even 
  C++ fans, addicts, and experts barely know?
  
  I am talking about a seasoned C++ programmer (be she/he a developer, student, fan, all 
  three, etc), who thinks (s)he knows something 99% of us never heard or dreamed about. 
  Something that not only makes his/her work easier, but also cool and hackish. After 
  all, C++ is one of the most used programming languages in the world, thus it should 
  have intricacies that only a few privileged know about and want to share with us.
  
  Boost is welcome too!
  
  For those who interested in modern C++ in action, albeit limited, discussion, go to 
  this wiki-post.
  
  One per post with an example please
  
  P.S Examples are important for other developers to copy and paste!
  
  

  Boost 可とかあったら、Boostべったりのネタしか出さないだろう人が わたしの(ネット的に)近い人にはいっぱいいらさるような気がする。

  ■_ 今日のAA

  なんかいいなw

  【Lua】組み込み系言語総合 その2【Squirrel】
  346 デフォルトの名無しさん [sage] 2009/10/28(水) 14:09:25 ID: Be:
      　　 /ヽ　/ヽ
      　　':'　ﾞ''"　 `':,
      　 ﾐ　　 ･ω･　;,
      　:; . っ　　　 　,つLua!
      　 `:;　 　 　　,;'
      　　 `( /'"`∪ 
  

  ■_ 固定小数点数

  ありがとうございます。

  
  
  2009-10-28 - うっくつさん本を読む。
  固定小数点数のフォロー
  
  http://www.kt.rim.or.jp/%7ekbk/zakkicho/09/zakkicho0910c.html#D20091027の話。
  Wikipediaだと。
  
      固定小数点数（こていしょうすうてんすう）は、コンピュータにおける実数の近似値の表現方式。
      固定小数点数では整数部分に用いるビット数と小数部分に用いるビット数をあらかじめ固定して
      表現する。
  
  と書いてありますが、上記引用部が成り立つのは基数＝２の場合だけで、基数≠２でない場合に
  は成り立ちません。
  
  少なくとも私の関わった範囲だと、「固定小数点数」と一口に言った場合に「基数＝２の固定小
  数点数」を指す、という経験はありません。逆に会計に近い分野だと、「固定小数点数」は「基
  数＝１０の固定小数点数」を指す、というのはありましたが。
  
  誤差は。
  
  同じ基数を利用する固定小数点数とBigDecimalならば、表現範囲に収まる計算の結果は誤差も含
  めて一致します。というより、下記のJava APIを読む限り、BigDecimalは任意長、基数＝１０の
  固定小数点数です。
  
      変更が不可能な、任意精度の符号付き小数です。BigDecimal は、任意精度の「スケールな
  しの整数値」と、32 ビット整数の「スケール」で構成されます。0 または正の場合、スケール
  は小数点以下の桁数です。負の場合、スケールなしの数値に、スケールの正負を逆にした値を指
  数とする 10 の累乗を乗算します。つまり、BigDecimal で表される数値は (unscaledValue × 
  10-scale) です。
  
  〆。
  
  暗黙に「基数＝２の固定小数点数」という分野もあると思うので、ご存知の方は教えてください。
  

  全文引用となりましたがかんべんしてくださりませ。 まず、基数が2か10か(それ以外はまあ無視していいと思います)で違うだろうというのは その通りです。そして基数に10を採用していれば、二進←→十進変換に由来する誤差 (十進の 0.1 が二進だと循環小数になるとか)がないというのも確かにその通りです。 んで、わたしの印象では、固定小数点数といわれても基数が2だろうというものなんですね。 だから、float や double を使わずに(基数の説明ぬきに)「固定小数点数使えばいいじゃん」 といわれても、頭の上に疑問符が何個も浮かぶ状態になってしまうわけです。 まあ確かにJavaの話をしているところだったので、JavaのBigDecimalの実装とか考えろよ ということであればすみませんということろで。

  でまあ、分野によって違うのかというのはあるのかもしれません。わたしの印象では ゲーム(最近はSSEやら使ったりするし、float or dobule という気もします)かなあ。 それも昔の。それと、TeX では最初に開発した当時はIEEE754のような浮動小数点数の 規格がまだなかったので、機械依存性を排除するために固定小数点数を使ったとか聞いた覚えが。 あれは基数どっちだったんだろう?

  
  Fixed-point arithmetic - Wikipedia, the free encyclopedia
  In computing, a fixed-point number representation is a real data type for a number 
  that has a fixed number of digits after (and sometimes also before) the radix point 
  (e.g., after the decimal point '.' in English decimal notation). Fixed-point number 
  representation can be compared to the more complicated (and more computationally 
  demanding) floating point number representation.
  
  Fixed-point numbers are useful for representing fractional values, usually in base 2 
  or base 10, when the executing processor has no floating point unit (FPU) or if 
  fixed-point provides improved performance or accuracy for the application at hand. 
  Most low-cost embedded microprocessors and microcontrollers do not have an FPU.
  

  usually in base 2 or base 10, とありますし、基数2のものが極端に少数ということも ないんじゃないでしょうか。

  • ベンチャー社長で技術者で: ITエンジニアの仕事についての質問
  • Ruby Freaks Lounge：第23回　Rackとは何か｜gihyo.jp … 技術評論社RackはこのWSGIに影響されて開発された，Rubyにおけるサーバとアプリケーション／フレームワーク間のインターフェースの役割を果たすライブラリです。
  • 限界を迎えつつある「パターンマッチング」という手法 － ＠IT
  • FBASIC V6.3 -OKWave数年前に、PC98のDISK-BASICで作られていたものを「FBASIC」置き換えたいと考えて移植しかけた状態で頓挫したものが残っています優先順位のつけ方が間違っているんじゃなかろうかとか
  • Mozilla Firefox Thunderbird の拡張あれこれ-MEMO（2009年10月-7）Firefox は自滅の道を進んでいるのである．
  • AmazonがMySQLデータベースのホスティング（クラウドサービス）を開始
  • Joel Spolsky, Snake-Oil Salesman « Stochastic Geometry
  • AsiaBSDCon 2010AsiaBSDCon は、BSD ベースのシステムの利用者・開発者のための国際会議です。次回の会議は、2010 年 3 月 11 日から 14 日にかけて、東京で開催されます。
  • バッファロー、重さ340gのUSB接続型ポータブルBDドライブ -AV Watch
  • Hexenkessel - G：...「できるかな」の番組の中で紹介されていた段ボールなどを使ったさまざまな工作は誰が考えていたのでしょうか？
  • checkは危険な言葉：柴田 芳樹 (Yoshiki Shibata)：So-net blogしかし、なぜか途中が全部省かれて「用紙を確認」つまり「checkPapaer」という名前付けをしてしまうのです。
  Twitter / tama: 君子VBに近寄らず

  Permalink  |  View Entire Page

Search the Site

Custom Search