From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vincent =?UTF-8?Q?Bela=C3=AFche?= Newsgroups: gmane.emacs.bugs Subject: bug#43764: Calc shift right broken Date: Fri, 9 Oct 2020 15:34:35 +0000 Message-ID: References: <87h7r9ozuh.fsf@gnus.org> ,<87wo04nnvr.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_PR3PR06MB6843D55F5B94F69C50AA1F6284080PR3PR06MB6843eurp_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17488"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "43764@debbugs.gnu.org" <43764@debbugs.gnu.org> To: Lars Ingebrigtsen , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 09 17:35:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kQuQJ-0004Ga-Nb for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 09 Oct 2020 17:35:11 +0200 Original-Received: from localhost ([::1]:55098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kQuQI-0002bq-Oh for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 09 Oct 2020 11:35:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kQuQA-0002aE-6K for bug-gnu-emacs@gnu.org; Fri, 09 Oct 2020 11:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52760) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kQuQ9-0006Zu-Su for bug-gnu-emacs@gnu.org; Fri, 09 Oct 2020 11:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kQuQ9-0007kL-QX for bug-gnu-emacs@gnu.org; Fri, 09 Oct 2020 11:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vincent =?UTF-8?Q?Bela=C3=AFche?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Oct 2020 15:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43764 X-GNU-PR-Package: emacs Original-Received: via spool by 43764-submit@debbugs.gnu.org id=B43764.160225768929757 (code B ref 43764); Fri, 09 Oct 2020 15:35:01 +0000 Original-Received: (at 43764) by debbugs.gnu.org; 9 Oct 2020 15:34:49 +0000 Original-Received: from localhost ([127.0.0.1]:36073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kQuPt-0007jp-F0 for submit@debbugs.gnu.org; Fri, 09 Oct 2020 11:34:49 -0400 Original-Received: from mail-db8eur06olkn2022.outbound.protection.outlook.com ([40.92.51.22]:1632 helo=EUR06-DB8-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kQuPq-0007ja-VK for 43764@debbugs.gnu.org; Fri, 09 Oct 2020 11:34:44 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lj4tf5+ElN9Uua3Nfpd87WkWLtiJF14v/LtCQ2rVzOd+BNJ3rIilxJ9sF67XKR2TV2n6rhx8+SIfwzo6eHPCrs2JHWPbA5+rq5u6sPe1PvnoM50BhFJ9SoBH6iJQNYXvCH6E0BDl8ihpkw5AylcUYa3qAseR5IQaWjHngFM/m1DhcHFq+pCEK/abDxIoqRWa1pkjGcL7OcjlplVHmhxrYrMATSWQeDeo2pYR2+lsvSovNzBfI9D/xLe7M5FytJK149dG0sM/26xzFIv1vLf0nyJpgMk9sXeXXFZrM0URtlj2PASFhiBWap3dovluXIq93+W4C7tJbbjrJ9AucCsc6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a2td/7PX6lfuDqg8gM6iO5uhe1+FuSe+cQUAJub8Id0=; b=DtZbVZUcSE2bR81tiyJne9GwTFeMLYyYzKCQQ4GuTK62CyqTexJy7zYUPluASgcgaxbiALK3+N5hS0inuk2tBGxkZBWYLcPjRAyF5K/pOIMg3GoAmiW8qpJvoWYPtCWr4oKBDk1u7fP5mRLrTIrd0zT582ONw6g3qgGT+S0mcvoLjO6wwR5B30+bncx5Li6wtQkI5NkypIS33wgrWKoiew71B5VWvyFsvtWX+ifiKv8Tl1RkYw236/zmE+zGO5BN/r6msFzENXFLnVxWijIFaZgMzvmYCNC3FnWBfeXwCT63M++o/+qhQ0dLVEJfsuKbQsfRT4RI7LRFTO29FfPihQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Original-Received: from AM7EUR06FT011.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc36::41) by AM7EUR06HT048.eop-eur06.prod.protection.outlook.com (2a01:111:e400:fc36::228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Fri, 9 Oct 2020 15:34:35 +0000 Original-Received: from PR3PR06MB6843.eurprd06.prod.outlook.com (2a01:111:e400:fc36::4d) by AM7EUR06FT011.mail.protection.outlook.com (2a01:111:e400:fc36::340) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23 via Frontend Transport; Fri, 9 Oct 2020 15:34:35 +0000 Original-Received: from PR3PR06MB6843.eurprd06.prod.outlook.com ([fe80::b18e:f416:90fd:a1b5]) by PR3PR06MB6843.eurprd06.prod.outlook.com ([fe80::b18e:f416:90fd:a1b5%6]) with mapi id 15.20.3455.027; Fri, 9 Oct 2020 15:34:35 +0000 Thread-Topic: bug#43764: Calc shift right broken Thread-Index: AQHWmP19dkguaBobJUWnDWCr2ydVBKmIrLKdgAAnd4CAAPoAAoAFmvvM In-Reply-To: <87wo04nnvr.fsf@gnus.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR x-incomingtopheadermarker: OriginalChecksum:ADD1D4A1BC57ECD84954993225557D3A2DD7955817FA96FBD3563FC40592BCCE; UpperCasedChecksum:9ECE01E8DC35A0589276BFFC9E735B572FE23E7AD1D2B91DF63CB6A16FD16677; SizeAsReceived:7141; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [/ENBkSu33APukJbCOrp5ghdF0fUoZXU1] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 639eeb45-c4c5-4d93-1e65-08d86c68d3ce x-ms-traffictypediagnostic: AM7EUR06HT048: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RiA/WR42ssXqZjqJIC3JTzAyGiNnN8Scp/jnnwuexLCHi9byVuTPJHqTfU/12G6zXINPljLPpPdun8y+CjiF+6oV4daaeBWEOIlyVu65s0a+sEdbXyB7p4hYoS7hkJ26sHQ2kvT8R18rUepNaMeqtDOHdec37arNl8I6dcbkoIJZuMu3ChgzttEorgDNOwFZDDVsOI9fMrszC6I8cFAVPic3h+44cvNvkmoXs0hWPDMBJtAHMq8XDnk73js1dmzC x-ms-exchange-antispam-messagedata: D62cyHDNnXmGE6uTF0rdhmfKrWPIo/9AEEdIYOoVoIfEsZPME6Y0KAVk+rymCzCNEPY54pYDXt2Lc0MpoKDO8NBDU6vRrwzkVFEQUJETNJ9KVj2LKjpyvgpOkFcEuo0utaIwk8YZ1MHR1RXbxCt/fw== x-ms-exchange-transport-forked: True X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: AM7EUR06FT011.eop-eur06.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 639eeb45-c4c5-4d93-1e65-08d86c68d3ce X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 15:34:35.7968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7EUR06HT048 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:190167 Archived-At: --_000_PR3PR06MB6843D55F5B94F69C50AA1F6284080PR3PR06MB6843eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Sorry for the late feedback. I think that it is good to have the possibility to set a bit width, just be= cause otherwise the two complement signing display ('O d 6') would be broke= n, same for the leading zeros ('d z'). I agree that it is unwise to change anything in the way that it works. Chan= ges should be backward compatible only, unless there is a very good reason = for the change. What could be improved would be to add some more functions, like (some idea= s) : * set bit width 0 would remove the automatic clipping meaning infinite = width. * have the H prefix (Hyperbolic) not only for 'b l' but also for the ot= her shifts operation, so that the width can be set on an operation by opera= tion basis with the prefix argument. * Maybe there could be some display mode in which when integers are wid= er that the bit width this is displayed somehow, e.g. the pipe in 16#12|34 = would appear with a bit width of 8, 16#123|4 for a bit width of 7. Just to = warn the user =AB beware the clip =BB. Vincent. ________________________________ De : Lars Ingebrigtsen Envoy=E9 : mardi 6 octobre 2020 03:28 =C0 : Mattias Engdeg=E5rd Cc : Vincent Bela=EFche ; 43764@debbugs.gnu.org <43= 764@debbugs.gnu.org> Objet : Re: bug#43764: Calc shift right broken Mattias Engdeg=E5rd writes: >> But if we're changing the number of default bits, perhaps it would make >> more sense to default to having no bit width restrictions? Or would >> that entail major Calc surgery? > > Any changes to Calc, however minor, are fraught with danger and excitemen= t! :-) > Fun as it may be, better not making changes speculatively though. > (On the other hand it could be that everyone have been bothered about > this for years. I have no way of knowing.) In olden times, I would guess most people thought that it just had to be this way. But now that the rest of Emacs has bignums, it's perhaps more surprising that Calc behaves this way when doing shifts. On the other hand, I don't know what people use Calc for here. If people are going "I wonder what would happen on a 32-bit machine if I were to do this shift operation", then it'd be something else... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no --_000_PR3PR06MB6843D55F5B94F69C50AA1F6284080PR3PR06MB6843eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
Sorry for the late feedback.

I think that it is good to have the possibility= to set a bit width, just because otherwise the two complement signing disp= lay ('O d 6') would be broken, same for the leading zeros ('d z').


I agree that it is unwise to change anything in the way that it works. Chan= ges should be backward compatible only, unless there is a very good reason = for the change.

What could be improved would be to add some more functions, like (some idea= s) :
  • set bit width 0 would remove the automatic clipping meaning infinite wi= dth.
  • have the H prefix (Hyperbolic) not only for 'b l' but also for= the other shifts operation, so that the width can be set on an operation b= y operation basis with the prefix argument.
  • Maybe there could be so= me display mode in which when integers are wider that the bit width this is= displayed somehow, e.g. the pipe in 16#12|34 would appear with a bit width= of 8, 16#123|4 for a bit width of 7. Just to warn the user =AB beware the = clip =BB.

   Vincent.
De : Lars Ingebrigtsen <= larsi@gnus.org>
Envoy=E9 : mardi 6 octobre 2020 03:28
=C0 : Mattias Engdeg=E5rd <mattiase@acm.org>
Cc : Vincent Bela=EFche <vincent.b.1@hotmail.fr>; 43764@d= ebbugs.gnu.org <43764@debbugs.gnu.org>
Objet : Re: bug#43764: Calc shift right broken
 
Mattias Engdeg=E5rd <mattiase@acm.org> write= s:

>> But if we're changing the number of default bits, perhaps it would= make
>> more sense to default to having no bit width restrictions?  O= r would
>> that entail major Calc surgery? 
>
> Any changes to Calc, however minor, are fraught with danger and excite= ment!

:-)

> Fun as it may be, better not making changes speculatively though.
> (On the other hand it could be that everyone have been bothered about<= br> > this for years. I have no way of knowing.)

In olden times, I would guess most people thought that it just had to be this way.  But now that the rest of Emacs has bignums, it's perhaps mo= re
surprising that Calc behaves this way when doing shifts.

On the other hand, I don't know what people use Calc for here.  If
people are going "I wonder what would happen on a 32-bit machine if I<= br> were to do this shift operation", then it'd be something else...

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://la= rs.ingebrigtsen.no
--_000_PR3PR06MB6843D55F5B94F69C50AA1F6284080PR3PR06MB6843eurp_--