[squeak-dev] 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 weird-looking 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 re-implement 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 Squeak-dev mailing list