I ran into that problem too when I was coding the quiz.
Does anyone else find it strange that a + b - b != a if a contains
duplicates of any element in b?
To finish the quiz, I added this method:
class Array
def subtract arr
return clear if arr==self
arr.each{|e| if (n=index(e)) then delete_at(n); end }
self
end
end
> This may not be of any use to you, but here's a way to delete all
> elements but the first:
>
> class Array
> def no_dup!( x )
> (i = index(x)) && delete( x ) && insert(i,x)
> self
> end
> end
Array.uniq!
???
James Edward Gray II
irb(main):008:0> a=[1,1,2,2,3,3]
=> [1, 1, 2, 2, 3, 3]
irb(main):009:0> a.no_dup!(2)
=> [1, 1, 2, 3, 3]
irb(main):010:0> a.uniq!(3)
ArgumentError: wrong number of arguments (1 for 0)
from (irb):10:in `uniq!'
from (irb):10
irb(main):011:0> a.uniq!
=> [1, 2, 3]
Well, i don't think it's 'amazingly bad'. Array#- doesn't raise an error in this case, Array#clear doesn't raise an error if the array is already empty, neither does the Array intersection or any of the Set methods.
Perhaps you can explain why Array#delete doesn't return the array but the parameter (preventing method chaining).
My first idea was that it should work like Array#flatten / Array#flatten! both returning the modified array, the bang version returning nil if there was no modification.
Ok, just my 2 cents, fell free to ignore this post - i just stumbled about a similar 'inconsistency' myself and wanted to say that.
(no i don't want to change ruby, and there is no offense intended)
cheers
Simon
···
ara.t.howard@noaa.gov wrote:
[...]
not raising an error when the element is not found is an
amazingly bad idea that would mask many bugs
[...]
- Array#- doesn't raise an error since it can partially succeed/fail, in
otherwords some of the elements might be removed while some are not: is
this success or failure? also Array#- is defined as 'set difference' and,
under that def not raising an error certainly makes good sense - the
result is always what you asked for - even if it's empty.
- Array#clear shouldn't raise an error, since the result after calling it
always want you'd hoped for : an empty arrray.
- Array#delete... well you got me there. nil is at least useful so one can
do
a.delete(elem) or raise "failed"
otherwise you have no idea if the operation succeeded or not.
the thing with writing a Array#delete_first method that returns the array is
that there's absolutely no indication of success or, as in the case of
Array#clear, a guarantee of success.
in general i think methods basically fail into two categories
- those that always succeed, Array#clear for example. these can simply
return self.
- those that might fail and need to either return nil or raise an exception
to indicate this. raising is nice because you can chain.
it's not clear to me why 'delete_first' would be in the first category but i
think this is largely religious.
cheers.
-a
···
On Sun, 5 Feb 2006, [ISO-8859-1] Simon Kröger wrote:
ara.t.howard@noaa.gov wrote:
[...]
not raising an error when the element is not found is an
amazingly bad idea that would mask many bugs
[...]
Well, i don't think it's 'amazingly bad'. Array#- doesn't raise an error in
this case, Array#clear doesn't raise an error if the array is already empty,
neither does the Array intersection or any of the Set methods.
Perhaps you can explain why Array#delete doesn't return the array but the
parameter (preventing method chaining).
My first idea was that it should work like Array#flatten / Array#flatten!
both returning the modified array, the bang version returning nil if there
was no modification.
Ok, just my 2 cents, fell free to ignore this post - i just stumbled about a
similar 'inconsistency' myself and wanted to say that. (no i don't want to
change ruby, and there is no offense intended)
cheers
--
happiness is not something ready-made. it comes from your own actions.
- h.h. the 14th dali lama
I think you're confusing "failure" with something else. If I ask a method to delete a "22" from an array that contains none of them, then, as I see it, deleting nothing from the array is a correct, successful response. If I *care* if there are any such elements in the array in the first place I can easily (and succinctly)
if myArray.index(element)
···
On Feb 5, 2006, at 8:50, ara.t.howard@noaa.gov wrote:
On Sun, 5 Feb 2006, [ISO-8859-1] Simon Kröger wrote:
ara.t.howard@noaa.gov wrote:
[...]
not raising an error when the element is not found is an
amazingly bad idea that would mask many bugs
[...]
in general i think methods basically fail into two categories
- those that always succeed, Array#clear for example. these can simply
return self.
- those that might fail and need to either return nil or raise an exception
to indicate this. raising is nice because you can chain.
it's not clear to me why 'delete_first' would be in the first category but i
think this is largely religious.