[#23132] [Bug #1357] Fixing variables into specific CPU registers deemed overrated & may disturb compilers' optimizers — Ollivier Robert <redmine@...>
Bug #1357: Fixing variables into specific CPU registers deemed overrated & may disturb compilers' optimizers
5 messages
2009/04/06
[#23154] [Bug #1363] Wrong value for Hash of NaN — Heesob Park <redmine@...>
Bug #1363: Wrong value for Hash of NaN
10 messages
2009/04/08
[#23423] Re: [Bug #1363] Wrong value for Hash of NaN
— Nobuyoshi Nakada <nobu@...>
2009/05/11
Hi,
[#23425] Re: [Bug #1363] Wrong value for Hash of NaN
— Yukihiro Matsumoto <matz@...>
2009/05/11
Hi,
[#23427] Re: [Bug #1363] Wrong value for Hash of NaN
— Urabe Shyouhei <shyouhei@...>
2009/05/11
Yukihiro Matsumoto wrote:
[#23168] [Bug #1367] flatten(0) is not consistent with flatten(), flatten(1), etc. — Paul Lewis <redmine@...>
Bug #1367: flatten(0) is not consistent with flatten(), flatten(1), etc.
6 messages
2009/04/08
[#23211] [Bug #1367] flatten(0) is not consistent with flatten(), flatten(1), etc.
— Paul Lewis <redmine@...>
2009/04/15
Issue #1367 has been updated by Paul Lewis.
[#23174] [Feature #1371] FTPS Implicit — Daniel Parker <redmine@...>
Feature #1371: FTPS Implicit
6 messages
2009/04/09
[#23193] Regexp Encoding — James Gray <james@...>
I'm trying to document the Encoding Regexp objects receive for the =20
5 messages
2009/04/13
[#23194] [Feature #1377] Please provide constant File::NOATIME — Johan Walles <redmine@...>
Feature #1377: Please provide constant File::NOATIME
5 messages
2009/04/13
[#23231] What do you think about changing the return value of Kernel#require and Kernel#load to the source encoding of the required file? — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>
Dear Ruby developers and users!
8 messages
2009/04/17
[#23233] Re: What do you think about changing the return value of Kernel#require and Kernel#load to the source encoding of the required file?
— Michael Neumann <mneumann@...>
2009/04/17
Wolfgang N叩dasi-Donner wrote:
[#23244] Re: What do you think about changing the return value of Kernel#require and Kernel#load to the source encoding of the required file?
— Michael Neumann <mneumann@...>
2009/04/17
Wolfgang N叩dasi-Donner wrote:
[#23245] Re: What do you think about changing the return value of Kernel#require and Kernel#load to the source encoding of the required file?
— Wolfgang Nádasi-Donner <ed.odanow@...>
2009/04/17
Michael Neumann schrieb:
[#23252] [Bug #1392] Object#extend leaks memory on Ruby 1.9.1 — Muhammad Ali <redmine@...>
Bug #1392: Object#extend leaks memory on Ruby 1.9.1
4 messages
2009/04/18
[#23267] StringIO: RubySpec violation — Hongli Lai <[email protected]>
I ran RubySpec against the 1.8.6-p368 release. It seems that
5 messages
2009/04/20
[#23289] [Bug #1399] Segmentation fault is raised when you use a postgres gem — Marcel Keil <redmine@...>
Bug #1399: Segmentation fault is raised when you use a postgres gem
3 messages
2009/04/23
[#23297] Ruby Oniguruma question — Ralf Junker <ralfjunker@...>
I see that the Ruby source code contains modified and more recent version of the Oniguruma regular expression library.
5 messages
2009/04/23
[#23305] [Bug #1403] Process.daemon should do a double fork to avoid problems with controlling terminals — Gary Wright <redmine@...>
Bug #1403: Process.daemon should do a double fork to avoid problems with controlling terminals
7 messages
2009/04/24
[#23306] Re: [Bug #1403] Process.daemon should do a double fork to avoid problems with controlling terminals
— Nobuyoshi Nakada <nobu@...>
2009/04/24
Hi,
[#23307] Re: [Bug #1403] Process.daemon should do a double fork to avoid problems with controlling terminals
— Gary Wright <gwtmp01@...>
2009/04/25
[#23311] [Bug #1404] Net::HTTP::Post failing when a post field contains ":" — Ignacio Martín <redmine@...>
Bug #1404: Net::HTTP::Post failing when a post field contains ":"
5 messages
2009/04/25
[#23318] [Feature #1408] 0.1.to_r not equal to (1/10) — Heesob Park <redmine@...>
Feature #1408: 0.1.to_r not equal to (1/10)
19 messages
2009/04/26
[#23345] [Feature #1408] 0.1.to_r not equal to (1/10)
— Roger Pack <redmine@...>
2009/05/01
Issue #1408 has been updated by Roger Pack.
[#25662] [Feature #1408] 0.1.to_r not equal to (1/10)
— Marc-Andre Lafortune <redmine@...>
2009/09/20
Issue #1408 has been updated by Marc-Andre Lafortune.
[#29652] [Feature #1408] 0.1.to_r not equal to (1/10)
— tadayoshi funaba <redmine@...>
2010/04/20
Issue #1408 has been updated by tadayoshi funaba.
[#29663] Re: [Feature #1408] 0.1.to_r not equal to (1/10)
— Marc-Andre Lafortune <ruby-core-mailing-list@...>
2010/04/20
Hi,
[#29887] Re: [Feature #1408] 0.1.to_r not equal to (1/10)
— Marc-Andre Lafortune <ruby-core-mailing-list@...>
2010/04/29
Hi.
[#23321] [Bug #1412] 1.8.7-p160 extmk.rb fails when cross compiling — Luis Lavena <redmine@...>
Bug #1412: 1.8.7-p160 extmk.rb fails when cross compiling
5 messages
2009/04/26
[ruby-core:23118] Re: [Bug #1336] Change in string representation of Floats
From:
brian ford <brixen@...>
Date:
2009-04-04 17:50:50 UTC
List:
ruby-core #23118
On Fri, Apr 3, 2009 at 11:49 PM, Roger Pack <[email protected]> wrote: > Issue #1336 has been updated by Roger Pack. > > >>> * numeric.c (flo_to_s): keeps enough precision for round trip. > > One possibility would be to allow Float#to_s to still be (depending on how you look at it) "friendly" or "imprecise." > > And keep the precise version for Float#inspect. > > The benefit of having them both verbose is that (tongue in cheek) it makes floats hideously ugly which might encourage people to avoid them :) > > But having both available separately via #inspect and #to_s would be nice and I'd imagine a patch to that effect would be well received. > > A discussion on it can be read at http://www.ruby-forum.com/topic/179361 It's not an issue of float precision. It is an issue of representation and there are many possibly representations of a float. The previous representation was user-friendly. The change is not. The only justification for the change that I see is this idea that there is value to being able to round trip a float from #to_s through eval. However, I think that is a poor reason to change because: 1. I can count the number Ruby classes that can be round-tripped this way on one hand. 2. There is a perfectly good mechanism for round-tripping any Ruby object. 3. If you don't want to marshal, you can use #sprintf when *you* want to round-trip a float via a string and eval. 4. The vast majority of times a float is represented as a string it is *not* to round-trip. So, this decision takes a marginal case for which a perfectly good mechanism already exists and promotes it to the common case. But that's not all. The consequence for the common case is that 2.4 is unnecessarily and uselessly echoed back to me as 2.3999999999999999. It is very poor interface design to promote a marginal case above a common case. There is nothing that this change in representation makes better in the common case. It makes the common case hideous. Floats are what they are. Use them as you will. Ruby used to have nice, friendly representations of floats for humans. Nothing gained, much lost. The decision should be reversed. Brian > > Cheers. > -=r > ---------------------------------------- > http://redmine.ruby-lang.org/issues/show/1336 > > ---------------------------------------- > http://redmine.ruby-lang.org > >