[#5322] O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...>

I just did some benchmarks on push, pop, shift, and unshift

24 messages 2005/07/01
[#5338] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/02

On Fri, 1 Jul 2005, Eric Mahurin wrote:

[#5348] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/02

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5357] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/03

On Sat, 2 Jul 2005, Eric Mahurin wrote:

[#5359] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/03

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5361] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/03

On Sun, 3 Jul 2005, Eric Mahurin wrote:

[#5362] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/03

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5365] Re: O(1) performance for insertions/deletions at the front of an Array/String — Yukihiro Matsumoto <matz@...> 2005/07/04

Hi,

[#5367] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/04

--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#5368] Re: O(1) performance for insertions/deletions at the front of an Array/String — Yukihiro Matsumoto <matz@...> 2005/07/04

Hi,

[#5372] Re: O(1) performance for insertions/deletions at the front of an Array/String — Florian Gro<florgro@...> 2005/07/04

Yukihiro Matsumoto wrote:

[#5420] Sydney Developer Preview 1 released — Evan Webb <evanwebb@...>

Sydney, an experimental ruby interpreter, has been released!

15 messages 2005/07/11
[#5424] Re: [ANN] Sydney Developer Preview 1 released — Evan Webb <evanwebb@...> 2005/07/12

Thanks everyone for the feedback so far!

Re: Object#=~

From: Hugh Sasse <hgs@...>
Date: 2005-07-06 16:53:19 UTC
List: ruby-core #5404
If I may jump in here:

On Thu, 7 Jul 2005, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Object#=~"
>    on Wed, 6 Jul 2005 20:10:08 +0900, "daz" <dooby@d10.karoo.co.uk> writes:
         [...]
> |true  - positive pattern match result
> |nil   - negative pattern match result
> |false - don't know (no match was done)
>
> Hmm, sorry for behaving unexpectedly.  But I like your idea.
> Ryan, what do you think?
>
> 							matz.
>

I'd expect nil and false to be swapped in the above scheme. In logic
false is the opposite of true. Nil is untrue, but it is not false.

Suppose, [for a moment of madness :-)], that you woke up one day to
find you'd given us Fuzzy truth values as a native Ruby class. :-)
Nil would still be different from a truth value of 0.5, and would
mean that nothing could be said about the truth value.  So I think
things which are proper truth values should be used for positive and
negative results, and nil for the third case.

This also fits any mental TTL[1] metaphor people might have: true ==
high, false == low, and nil == tristate.

But I wonder how much code would break if this path were taken...
         Hugh

[1] Transistor-Transistor Logic



In This Thread