From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Using the GNU GMP Library for Bignums in Emacs Date: Sun, 22 Apr 2018 13:00:27 +0000 Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <83bmecy6fx.fsf@gnu.org> <0d3175d8-d996-651e-b221-71978bde3a65@cs.ucla.edu> <51e619e0-ee38-eb97-6c1d-0925b675290a@disroot.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000fb3297056a6f81c0" X-Trace: blaine.gmane.org 1524401932 13238 195.159.176.226 (22 Apr 2018 12:58:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Apr 2018 12:58:52 +0000 (UTC) Cc: eliz@gnu.org, eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org To: dancol@dancol.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 22 14:58:48 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fAEZr-0003Lg-UV for ged-emacs-devel@m.gmane.org; Sun, 22 Apr 2018 14:58:48 +0200 Original-Received: from localhost ([::1]:56354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAEby-0000ON-NO for ged-emacs-devel@m.gmane.org; Sun, 22 Apr 2018 09:00:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAEbm-0000Km-TE for emacs-devel@gnu.org; Sun, 22 Apr 2018 09:00:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fAEbl-0006kX-Q0 for emacs-devel@gnu.org; Sun, 22 Apr 2018 09:00:46 -0400 Original-Received: from mail-oi0-x234.google.com ([2607:f8b0:4003:c06::234]:36433) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fAEbf-0006cW-Cy; Sun, 22 Apr 2018 09:00:39 -0400 Original-Received: by mail-oi0-x234.google.com with SMTP id h11-v6so11885336oic.3; Sun, 22 Apr 2018 06:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AwIejnTaYPkQmYlHKortT/egISm8Y+cmYrr+hY6Lkfw=; b=M10en5AiYYqXmVih1ySro4kwN71SDjDtjhj9wbhYp6d14ihWTct0bf0w7Jgnr/X5fi 8Mmx/c1Im8c1E9MmarL+QlrUIj1XFmt6/6UmuWsZVoFvh7HurRCxRfKt8yHkQzk7nPWA Xj/D8shBNSsMOOPvDx78f0L8VeJz9wNgbccBm2et4aoVzcCvxEVi/kMB5nt+JWEZao/b wiFuvtnoXMGmG89xew4VBsD+uRb+9bbtQpSU6UMBBKXf3TniXniuYHiljMF9pg+F+oRT PewocXxIyiEexjJc/SCJ4GV81OjaEUuDzYnRkxombfCEl2Xs2u3YBl+PCoA7FeqkuZBg YuvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AwIejnTaYPkQmYlHKortT/egISm8Y+cmYrr+hY6Lkfw=; b=YWOndB6+SM+AhvW1z60JfZPICIqRjhKlrOGTxUPiYRSOD+YTg0D4hPU5k9fStRrxuY w3CtgKQ4AWMKcpKG3iRp38pn0mwX1sPrf2+Y310SlXjQUpVDkEYAcTwrgwPElf4VnBeR zNkJGx1PpKwH4PTCi1pVM1OkT3fEkOZ+UeAy6PnvRIjl/XV+napbr/vxJnGnJDzjAuLT fMbTKqKRNn11wLr21xd816jTi4CwTzaLAIjIh1Nz1zywh82O+YZYDHvnvsgPIQHmfXcz +MHt+SUaHGunD+Mo4W68s1QDcHMmeNmVNLspH375jxB5nI9gKr9szGqo6vHDV8a/VUo3 bA5g== X-Gm-Message-State: ALQs6tA/NC6S6ginikXR5wfRbt5KI65dnghteg6nny0WVL4I10msYv2t g0kzQDR/QXdvLISvO5bg6NjQUf+sg2iikK5bEhk= X-Google-Smtp-Source: AIpwx4/TwlFPU37ZkhVCsE5cHGZPr/ZNuaD9XoEfuYLJFtsJvSKKmDiqwxcOWRbK3Q5pp9eVnKoOLpqQ0kb8lf0G2rg= X-Received: by 2002:aca:e308:: with SMTP id a8-v6mr11249268oih.237.1524402038186; Sun, 22 Apr 2018 06:00:38 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224787 Archived-At: --000000000000fb3297056a6f81c0 Content-Type: text/plain; charset="UTF-8" schrieb am So., 22. Apr. 2018 um 04:49 Uhr: > > [[[ To any NSA and FBI agents reading my email: please consider ]]] > > [[[ whether defending the US Constitution against all enemies, ]]] > > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > > > Of course we could to do that. Hopefully there isn't existing > > > Emacs Lisp code that relies on unsafe arithmetic /anywhere/. If the > > > functions + - * / operate on bignums (instead of dedicated bignum > > > functions), would that mean we drop 32/64 bit integers entirely? > > > > To eliminate the current types for small integers would > > require rewriting of much of the C code in Emacs. > > It would be better to represent small integers as now, > > and have a different structure for larger integers. > > > > I'd love to see Emacs get transparent bigint support. Python semantics are > fine, as is using a normal int representation at the C level. Adding > transparent bigints as Lisp types doesn't require us to increase various > Emacs core limits right away. > > > We need to be very careful with transparent bigint support though, as a naive design will break many invariants. For example, integers are currently documented to use modular arithmetic ( https://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Type.html , https://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Basics.html), and they are documented to be pure value types, i.e. same-valued integers are the same object ( https://www.gnu.org/software/emacs/manual/html_node/elisp/Equality-Predicates.html). Especially the second property is widely used. --000000000000fb3297056a6f81c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<dancol@dancol.org> schrieb am So.= , 22. Apr. 2018 um 04:49=C2=A0Uhr:
= > [[[ To any NSA and FBI agents reading my email: please consider=C2=A0 = =C2=A0 ]]]
> [[[ whether defending the US Constitution against all enemies,=C2=A0 = =C2=A0 =C2=A0]]]
> [[[ foreign or domestic, requires you to follow Snowden's example.= ]]]
>
>=C2=A0 =C2=A0> Of course we could to do that. Hopefully there isn= 9;t existing
>=C2=A0 =C2=A0> Emacs Lisp code that relies on unsafe arithmetic /any= where/. If the
>=C2=A0 =C2=A0> functions + - * / operate on bignums (instead of dedi= cated bignum
>=C2=A0 =C2=A0> functions), would that mean we drop 32/64 bit integer= s entirely?
>
> To eliminate the current types for small integers would
> require rewriting of much of the C code in Emacs.
> It would be better to represent small integers as now,
> and have a different structure for larger integers.
>

I'd love to see Emacs get transparent bigint support. Python semantics = are
fine, as is using a normal int representation at the C level. Adding
transparent bigints as Lisp types doesn't require us to increase variou= s
Emacs core limits right away.



We need to be very careful with transp= arent bigint support though, as a naive design will break many invariants. = For example, integers are currently documented to use modular arithmetic (<= a href=3D"https://www.gnu.org/software/emacs/manual/html_node/elisp/Integer= -Type.html">https://www.gnu.org/software/emacs/manual/html_node/elisp/Integ= er-Type.html,=C2=A0https://www.gnu.org/software/emacs/ma= nual/html_node/elisp/Integer-Basics.html), and they are documented to b= e pure value types, i.e. same-valued integers are the same object (https://www.gnu.org/software/emacs/manual/html_node/elisp/Equa= lity-Predicates.html). Especially the second property is widely used.
--000000000000fb3297056a6f81c0--