From owner-sc22wg5@open-std.org Tue Aug 2 15:07:43 2005 Return-Path: X-Original-To: sc22wg5-domo2 Delivered-To: sc22wg5-domo2@open-std.org Received: by open-std.org (Postfix, from userid 521) id 5715A11591; Tue, 2 Aug 2005 15:07:43 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from dkuug.dk (ptah.dkuug.dk [195.215.30.66]) by open-std.org (Postfix) with ESMTP id 507EE112F5 for ; Tue, 2 Aug 2005 15:07:41 +0200 (CET DST) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id j72D7PwE095518 for ; Tue, 2 Aug 2005 15:07:28 +0200 (CEST) (envelope-from dick.hendrickson@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc11) with SMTP id <2005080213021111100o70j8e>; Tue, 2 Aug 2005 13:02:12 +0000 Received: from [69.137.48.249] by 204.127.135.57; Tue, 02 Aug 2005 13:02:11 +0000 From: dick.hendrickson@att.net To: "WG5" Subject: Re: (j3.2005) (SC22WG5.3306) Re: 05-188 - BITS version of old typeless proposal Date: Tue, 02 Aug 2005 13:02:11 +0000 Message-Id: <080220051302.1704.42EF6ED2000BFE96000006A8216037631602019C050C079D0B020A08D2050C070B@att.net> X-Mailer: AT&T Message Center Version 1 (Feb 14 2005) X-Authenticated-Sender: ZGljay5oZW5kcmlja3NvbkBhdHQubmV0 X-Spam-Score: 0.339 () NO_REAL_NAME Sender: owner-sc22wg5@open-std.org Precedence: bulk -------------- Original message ---------------------- From: "Whitlock, Stan" > I know it's August and a lot of people are on vacation but I'd like some > input from the people who attended the Delft WG5/J3 meeting about what > they expected the TYPELESS requirement J3-047 to turn into. The WG5 > minutes N1631, the J3 minutes 05-190, and the WG5 resolutions N1630 are > not very detailed in this regard. It would seem that straw votes on the > TYPELESS proposal J3-047 favored instead "variable sized bit strings" > and the proposal was to be renamed BITS. Future paper 05-188 which has > just appeared was to replace the proposal in J3-047. That's all the > information available to those of us who did not attend the meeting. > > I'm off visiting the granddaughter, so I don't have my notes. But my recollection is that there was agreement that limiting bit vairables to only 32, 64, (96?), 128 wasn't acceptable and that the bit size should be fairly unrestricted. It should at least allow 1, 2, 3,...n for some reasonable n. But, I don't recall any discussion of the differences/merits/demerits/implications of kind versus length specificiers. KIND seemed natural when there were only 3 or 4 "clearly different" kinds of bits, It's less obvious that an 11 bit thing is intrinsicly different from a 12 bit variable. Personal comments, not related to Delft below. I think the kind mechanism effectively prevents using bits in generic routines. How do you write a generic bit sort? It's easy for characters, declare things with len=* and one routine sorts any length string. Won't I have to write a separate routine to sort each bit kind? Doesn't that effectively prevent doing any generic routines? I think designing the base mechanism around efficiency is the wrong way to start thinking. Efficiency is important, but so is capability. Look at the array stuff - optional arguments to reshape, pack, etc; vector valued subscripts; dim= variable arguments to reduction functions;.... These aren't efficient in terms of machine cycles. They are efficient in terms of human thought cycles because they let programmers express ideas in a "natural" way. It's a trade off, but I think Van is basically right. If a compiler will "obviously" generate good code when the bit size is known at compile time, then the compiler will generate good code when the bit size is known at compile time. It shouldn't matter how we spell "attribute = constant". People who need efficiency will tailor their code style to the machine, just like they do now. People who need capabilities will get what they need (albeit slowly). Dick Hendrickson