[#26488] Add Standard Deviation Function to Math Module — Daniel Cohen <danielc2017@...>

This patch adds a Standard Deviation function to the Math Module. It takes

25 messages 2009/11/02
[#26489] Re: Add Standard Deviation Function to Math Module — Yukihiro Matsumoto <matz@...> 2009/11/03

Hi,

[#26490] Re: Add Standard Deviation Function to Math Module — Daniel Cohen <danielc2017@...> 2009/11/03

OK,

[#26493] Re: Add Standard Deviation Function to Math Module — Yukihiro Matsumoto <matz@...> 2009/11/03

Hi,

[#26511] Re: Add Standard Deviation Function to Math Module — Yusuke ENDOH <mame@...> 2009/11/03

Hi,

[#26492] HashWithIndifferentAccess to core — Urabe Shyouhei <shyouhei@...>

Hello,

35 messages 2009/11/03
[#26496] Re: HashWithIndifferentAccess to core — Yukihiro Matsumoto <matz@...> 2009/11/03

Hi,

[#26507] Re: HashWithIndifferentAccess to core — Jeremy Kemper <jeremy@...> 2009/11/03

On Tue, Nov 3, 2009 at 6:48 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wro=

[#26514] Re: HashWithIndifferentAccess to core — "Martin J. Dst" <duerst@...> 2009/11/04

Just a thought: What about implementing this with an option on Hash:new,

[#26522] Re: HashWithIndifferentAccess to core — Yusuke ENDOH <mame@...> 2009/11/04

Hi,

[#26555] Re: HashWithIndifferentAccess to core — Yukihiro Matsumoto <matz@...> 2009/11/05

Hi,

[#26584] Re: HashWithIndifferentAccess to core — Yugui <yugui@...> 2009/11/07

2009/11/6 Yukihiro Matsumoto <matz@ruby-lang.org>:

[#26589] Re: HashWithIndifferentAccess to core — Yukihiro Matsumoto <matz@...> 2009/11/07

Hi,

[#26593] Re: HashWithIndifferentAccess to core — Lourens Naud<lourens@...> 2009/11/07

Hi,

[#26523] [Bug #2330] Non systematic segmentation fault with autoload rubyspec — Marc-Andre Lafortune <redmine@...>

Bug #2330: Non systematic segmentation fault with autoload rubyspec

12 messages 2009/11/04

[#26560] [Feature #2340] Removing YAML/Syck — Yui NARUSE <redmine@...>

Feature #2340: Removing YAML/Syck

38 messages 2009/11/06
[#26562] [Feature #2340] Removing YAML/Syck — Yui NARUSE <redmine@...> 2009/11/06

Issue #2340 has been updated by Yui NARUSE.

[#26567] Re: [Feature #2340] Removing YAML/Syck — James Edward Gray II <james@...> 2009/11/06

On Nov 6, 2009, at 4:02 AM, Yui NARUSE wrote:

[#26568] Re: [Feature #2340] Removing YAML/Syck — Jon <jon.forums@...> 2009/11/06

> > Issue #2340 has been updated by Yui NARUSE.

[#26571] Re: [Feature #2340] Removing YAML/Syck — "NARUSE, Yui" <naruse@...> 2009/11/06

Jon wrote:

[#26574] Re: [Feature #2340] Removing YAML/Syck — Aaron Patterson <aaron@...> 2009/11/06

On Sat, Nov 07, 2009 at 12:59:25AM +0900, NARUSE, Yui wrote:

[#26635] [Feature #2348] RBTree Should be Added to the Standard Library — James Gray <redmine@...>

Feature #2348: RBTree Should be Added to the Standard Library

20 messages 2009/11/08
[#28842] [Feature #2348] RBTree Should be Added to the Standard Library — James Gray <redmine@...> 2010/03/21

Issue #2348 has been updated by James Gray.

[#26650] [Feature #2350] Unicode specific functionality on String in 1.9 — Manfred Stienstra <redmine@...>

Feature #2350: Unicode specific functionality on String in 1.9

12 messages 2009/11/09
[#28985] [Feature #2350](Rejected) Unicode specific functionality on String in 1.9 — Yusuke Endoh <redmine@...> 2010/03/25

Issue #2350 has been updated by Yusuke Endoh.

[#28993] Re: [Feature #2350](Rejected) Unicode specific functionality on String in 1.9 — Nikolai Weibull <now@...> 2010/03/25

On Thu, Mar 25, 2010 at 14:45, Yusuke Endoh <redmine@ruby-lang.org> wrote:

[#26704] Maintainer confirmation process done. — "Yugui (Yuki Sonoda)" <yugui@...>

I'm sorry for my closing the maintainer confirmation process so late.

13 messages 2009/11/12

[#26736] [Bug #2365] Matrix: poor handling of coercion errors [patch] — Marc-Andre Lafortune <redmine@...>

Bug #2365: Matrix: poor handling of coercion errors [patch]

12 messages 2009/11/14

[#26772] [Bug #2378] Regression in ParseDate.parsedate('nn-nn') — Vladimir Sizikov <redmine@...>

Bug #2378: Regression in ParseDate.parsedate('nn-nn')

10 messages 2009/11/16

[#26774] Ruby constant lookup — Yehuda Katz <wycats@...>

Over the past six months or so, I have been working with the new Ruby 1.9

22 messages 2009/11/16
[#26775] Re: Ruby constant lookup — Shugo Maeda <shugo@...> 2009/11/17

Hi,

[#26777] Re: Ruby constant lookup — Yehuda Katz <wycats@...> 2009/11/17

Shugo,

[#26778] Re: Ruby constant lookup — Shugo Maeda <shugo@...> 2009/11/17

Hi,

[#26869] Caching #to_s for immutables (and a possible future for constant-folding) — Kurt Stephens <ks@...>

I have a proof-of-concept patch to MRI that caches #to_s values for

16 messages 2009/11/23
[#26936] Re: Caching #to_s for immutables (and a possible future for constant-folding) — Roger Pack <rogerdpack@...> 2009/11/29

> =A0It reduces the number of #to_s Strings created during the MRI test sui=

[#26958] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch] — Kurt Stephens <ks@...> 2009/11/30

The attached patch add caching of #to_s results to the main immutable

[#26960] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch] — Roger Pack <rogerdpack@...> 2009/11/30

> Yes. =A0The MRI test suite runs at 45 sec with these changes and at 53 se=

[#26963] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch] — Kurt Stephens <ks@...> 2009/11/30

I just ran rubyspec against it; ~ 5% time improvement.

[ruby-core:26963] Re: Caching #to_s for immutables (and a possible future for constant-folding) [with patch]

From: Kurt Stephens <ks@...>
Date: 2009-11-30 21:57:15 UTC
List: ruby-core #26963
I just ran rubyspec against it; ~ 5% time improvement.

WITH PATCH:

  > time mspec -t /home/kurt/local/ruby/kstephens/bin/ruby

2849 files, 13035 examples, 186461 expectations, 231 failures, 441 errors

real	4m18.626s
user	0m23.349s
sys	0m8.685s

WITHOUT PATCH:

  > time mspec -t /home/kurt/local/ruby/trunk/bin/ruby
2849 files, 13035 examples, 187339 expectations, 246 failures, 318 errors

real	4m30.655s
user	0m28.386s
sys	0m9.857s

Note the difference in failures/errors.  I don't know yet if these are 
errors due to the intended semantic difference or actual bugs.  What 
might be the best way to see the differences in object allocations and GCs?


Roger Pack wrote:
>> Yes.  The MRI test suite runs at 45 sec with these changes and at 53 sec
>> without.  The MRI tests pass with no issues.  There is a naive test in the
>> attached patch that demonstrates the improvements.
> 
> Wow that's a pretty good improvement.  I like it.
> 
> What's the speed difference for make test-all?
> 
Didn't know about test-all.  Right now test-all has some failures 
related to frozen String.  So there is still more work to be done. :(

6836 tests, 1826745 assertions, 56 failures, 248 errors, 0 skips
make: *** [yes-test-all] Error 1

real	4m23.824s
user	1m45.195s
sys	0m27.594s

>>> Does it break rails?
>> I don't know yet.  I need to setup a proper Rails test environment.
> 
> Yeah that would be nice, as well as comparing speeds for the test runs
> to see if it's useful.
> 
>> There maybe some native thread issues with the cache hash tables, but I did
>> start adding a mutex to each one.  I have not tested on 64-bit or anything
>> other that Ubunutu 9.10.
> 
> Would there be thread issues if each thread runs under the GLI?
> 
> Thanks.
> -r
> 


In This Thread