[squeakdev] Protocol extension proposal: Boolean>>asBit ?
Igor Stasenko
siguctua at gmail.com
Sun Dec 6 00:10:55 UTC 2009
2009/12/6 Bert Freudenberg <bert at freudenbergs.de>:
> On 06.12.2009, at 00:36, Igor Stasenko wrote:
>>
>> 2009/12/5 David T. Lewis <lewis at mail.msen.com>:
>>> On Sat, Dec 05, 2009 at 02:48:21PM +0100, Bert Freudenberg wrote:
>>>> On 05.12.2009, at 14:29, Randal L. Schwartz wrote:
>>>>>
>>>>>>>>>> "Bert" == Bert Freudenberg <bert at freudenbergs.de> writes:
>>>>>
>>>>> Bert> I don't think it would break any sane application. #asInteger is
>>>>> Bert> descriptive, and "feels right" to me. Reading "asBit" I'd expect it to
>>>>> Bert> return an instance of Bit.
>>>>>
>>>>> Bert> I have not really felt the need for such a method, but I can see how
>>>>> Bert> it's tempting to have, in particular when porting code.
>>>>>
>>>>> It's also "according to who". 0 as false, 1 as true is only one encoding,
>>>>> and clearly not universal. I've worked with systems where 0 is false,
>>>>> and 1 is true.
>>>>
>>>> I knew someone would bring this up ;) I also like to KISS.
>>>>
>>>> This is not about internal representation, but about doing arithmetic with
>>>> booleans. I don't think any other mapping than "true asInteger = 1" and
>>>> "false asInteger = 0" makes sense in that context.
>>>
>>> I don't think that arithmetic with booleans makes sense in any context.
>>>
>>> Is this convenience method really worth muddying up the distinction between
>>> numbers and booleans? Think of all the C programmers with bad habits
>>> (like me for example) who have had to stop and think twice about assuming
>>> that a number means the same thing as true or false.
>>>
>>
>> C is much closer to hardware than smalltalk. And we all know, that
>> whatever you type of whatever program you will create in whatever
>> language, the computers could represent it internally only as a
>> sequence of bits.
>>
>> There are also couple things which can be seen as muddy. Consider #sign method:
>>
>> sign
>> "Answer 1 if the receiver is greater than 0, 1 if less than 0, else 0."
>>
>> self > 0 ifTrue: [^1].
>> self < 0 ifTrue: [^1].
>> ^0
>>
>> which could be also considered as a 'conversion' of boolean
>> expressions to integer values, because i can implement it as:
>>
>> sign
>> ^ (self > 0) asBit  (self < 0) asBit.
>>
>> This is not the only place, where boolean values working together with
>> numerical values.
>> Consider rounding function(s):
>>
>> floor
>> "Answer the integer nearest the receiver toward negative infinity."
>>
>>  truncation 
>> truncation := self truncated.
>> self >= 0 ifTrue: [^truncation].
>> self = truncation
>> ifTrue: [^truncation]
>> ifFalse: [^truncation  1]
>>
>> while we all get used to that rounding works *only* with numbers, it
>> is impossible to implement them without using boolean algebra (but you
>> may try, of course).
>>
>> Moreover, mathematicians using boolean expressions widely for defining
>> a different weirdlooking functions:
>>
>> f(x) = {
>> (x<0) x;
>> (x>=0) x;
>> }
>>
>>
>> So, i wouldn't say that we are first, who guilty by muddying booleans
>> and numbers. It was happen a lot earlier and much more frequent in
>> many areas.
>
> I hope you're not actually proposing to reimplement the above methods using #asBit (or #asInteger, for that matter) ...
>
No, that's not my point. The point is, that booleans & numbers working
together in numerical processing a lot closer than one may expect.
In fact, the whole computer numeric processing based on boolean
algebra (imagine computer which can't compare numbers).
And yes, one could implement #floor much more concise by using #asBit
or #asInteger sent to booleans:
floor
"Answer the integer nearest the receiver toward negative infinity."
 truncation 
truncation := self truncated.
^ truncation  (self < truncation) asBit
>  Bert 
>
>
>

Best regards,
Igor Stasenko AKA sig.
More information about the Squeakdev
mailing list
