From nobody Fri Mar 10 23:57:30 2023 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1423FC1524DC for ; Fri, 10 Mar 2023 23:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.888 X-Spam-Level: X-Spam-Status: No, score=-6.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeCd66mbTQVu for ; Fri, 10 Mar 2023 23:57:23 -0800 (PST) Received: from smtp.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4EDC14F749 for ; Fri, 10 Mar 2023 23:57:19 -0800 (PST) Received: from smtpclient.apple (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4PYZyM60YdzDCbK; Sat, 11 Mar 2023 08:57:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) From: Carsten Bormann In-Reply-To: <38de8a78-0140-45af-b4fb-f601265809e4@gmail.com> Date: Sat, 11 Mar 2023 08:57:05 +0100 Cc: cbor@ietf.org, Wolf McNally Content-Transfer-Encoding: quoted-printable Message-Id: References: <83BF059D-BEF2-4C5F-9DE8-7A99A529833F@island-resort.com> <8999DCEA-6572-4A69-85EC-AA7AD0170837@tzi.org> <38de8a78-0140-45af-b4fb-f601265809e4@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3731.400.51.1.1) Archived-At: Subject: Re: [Cbor] Decoding numbers and compliance verification in dCBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2023 07:57:29 -0000 On 11. Mar 2023, at 08:06, Anders Rundgren = wrote: >=20 > If shortest possible number representation is an absolute goal, you = already have a problem with "pure" integers. An integer value of = 1099511627775 (0xffffffffff) would actually yield two bytes less(!) = using the Bignums type. Yes. This observation was my second example. It has been somewhat surprising to me how many applications actually = need 40-bit numbers a lot... > It would (IMO) be unwise trying to fix this in dCBOR. I was not making a recommendation to do this; I=E2=80=99m just pointing = out that for 2**32 to 2**48-1 (and the negative) a tag 2/3 = representation is more compact than the CBOR major type 0/1 = representation, which is an artifact of the large gap between 4- and = 8-byte integers, and the byte-wise granularity of byte strings. Another = profile (e.g., one that needs those 40-bit numbers) might choose to do = this, maybe not dCBOR. Back to floating point numbers: For many applications, the ability to = represent 1.0 in one byte (instead of three), 4711.0 in three bytes = (instead of five) etc. could be of more interest than the above. Also, = if -0.0 scares you, replacing 0.0 and -0.0 with 0 may comfort you. So I = have some sympathy for the dCBOR choices. But Zipf=E2=80=99s law tells = us these applications are rare in the sensor/actuator space, which is = why we didn=E2=80=99t suggest that any more in RFC 8949. One area where the application (possibly in a data model) needs to = decide is whether float64 is actually needed or the non-existent = precision can be lopped off to float32 (or float16!). This comes up in = sensors that have decimal fractional base, e.g., reading 1.1 V =E2=80=94 = do you really need "fb 3f f1 99 99 99 99 99 9a=E2=80=9D to represent = this, or is "fa 3f 8c cc cd=E2=80=9D fine, or maybe "f9 3c 66=E2=80=9D? = Only the application can know. Often the same application needs float64 = as well (e.g., for some timestamping), and float32 for sensors with a = higher resolution, so it can=E2=80=99t be a global setting. Gr=C3=BC=C3=9Fe, Carsten