From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.devel Subject: Re: Adding a generic mathematical library Date: Sat, 27 Jul 2024 21:40:02 +0200 Message-ID: References: <87o76ik616.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26537"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emanuel Berg , emacs-devel@gnu.org, Sergey Kostyaev , Philip Kaludercic To: Shouran Ma Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 27 21:41:01 2024 Return-path: Envelope-to: ged-emacs-devel@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 1sXnHo-0006kG-Rl for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jul 2024 21:41:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sXnH3-00057d-B3; Sat, 27 Jul 2024 15:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sXnGz-000571-TE for emacs-devel@gnu.org; Sat, 27 Jul 2024 15:40:10 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sXnGw-00025q-Mn for emacs-devel@gnu.org; Sat, 27 Jul 2024 15:40:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.com; s=s31663417; t=1722109202; x=1722714002; i=dimech@gmx.com; bh=qK0mZlW4II44tRUq7wYHvmvvUuurczlzmUgRplq5/B8=; h=X-UI-Sender-Class:MIME-Version:Message-ID:From:To:Cc:Subject: Content-Type:Date:In-Reply-To:References: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=HstQi8MeMfl//I2tBgBbSq+WCYRsTkEkaHockocGPHHdZ7HLMm1IwR5cFmt42Ryc hEw3/5PRKNLuaKCxTQnovMpebb+dvHjG0v1fzEb1iQY/gf+ggqfNxIWaFBSZmcG3L 8QQ1TRh2gqX1bDWZdNItiTQVYKzyhZvJZY+ZrB9ZHhdZL3bm5qPrel14upFoRBHBS HM7kD0hopdwNuU/KYDN2LwW3b+mGW9l+owEk0n0FzggR7t4TEaldxu8GQgyCue70C 92qtmSxH/o3H782lRoFhKf95T55M/UiHxP8LTVQxpp/mzR8oFkAFbGMPwySgixUzu HCqezEAaQ/VXNaFgPw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [92.251.79.197] ([92.251.79.197]) by web-mail.gmx.net (3c-app-mailcom-bs02.server.lan [172.19.170.129]) (via HTTP); Sat, 27 Jul 2024 21:40:02 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <87o76ik616.fsf@gmail.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:KFZ+CpkqklU7bZWm6a1+aS66QaCobHCjC+QWkjrBr/yzGX5/pcjGpoOt1d/wUkrMO18AB 1KH7lNyxcPzuNW/CUqa5jCZQRapcZ6tJ4grQYAVRv3lUyE9KQ6FS5YXoa/apbPT3+eufGLlM/pjk PtDVs0jRm2fKizMJJm2TiiXR/JcWp59f1HZvLGzQPzpaDwYHvPUv2JN/iDD8DvTggU13jwmB6vu4 C0nAoUN2ayeOV7P59xH+uJbHBAbdZmKRC19mkgt8CQAj/XQHtCR6QXQBr8Y1HqpYQhMEse9YtRkj rw= UI-OutboundReport: notjunk:1;M01:P0:zhcCE095AYs=;x2/52n6Ooxo+F84EJcID3zlJDg3 0XUSiVPnof4N/Y7lj/QZiIyCaflwHVGb50+PlNqM9QW7+a3yAmnNXvafF4VCxW61T9tO6arbb 44UynAqSv/gzdS/SR3lqXCK46y5nrw+2hDEWeKWP4NXbOoX3paPHzbmYv7i8v9qwUD+m43bkE MJ8Xb5iRL7PSd8IYUKDyr5o1H0DG6eiPV+IMKLcRn4jPRmjNRqeEs/Pefo3lcLnpz6675HO2t T/KbFbb8sJU/8Wt3Wf/MmUZCW96Gea+EgsY15snLkogPdzVhQlvb/sVGBL6WnJhEAwc6Q6/Y0 1ma325VcMKRiZcfnlK9H0xdDWpGFNHrcACkTRyffaO39CB0n51rPhuleRRswI+ehtZR4tUite tFOsISuwJJNbgX6ozYKE/4+2GgUa3qNHmWE7y8rWMI9OLq8cHN5d/9G7yiyqAT+kRcXDAusH9 QXv0/GAaiRiBshd31I42CRqbr5BH+lUFvw6ayGspnm1XGL3BKdae/i1mv+KaBlVMLE3X4UX8w WHW6ilPlw57Bf4QC2sFswFC/OQDUhqv/qO7wFFvt3CpNVcpEmjSJpMaaTTfK44dW3/IgE73tR 8sK6xw8BXCl8rZFNdKtgrFBjmpPczjx0sA65P6N70K8j0EEarozjSO408t9Z8H8ufYNgkINby kLcE6bCAXuYl8zOdtF0DLvUNGg7uHFy2BRoHd+akdw== Received-SPF: pass client-ip=212.227.15.19; envelope-from=dimech@gmx.com; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322143 Archived-At: > Sent: Sunday, July 28, 2024 at 7:07 AM > From: "Shouran Ma" > To: "Emanuel Berg" > Cc: emacs-devel@gnu.org, "Sergey Kostyaev" , "Phil= ip Kaludercic" > Subject: Re: Adding a generic mathematical library > > > > Sent: Saturday, July 27, 2024 at 16:57 +0200 > > From: "Shouran Ma" > > > > However, WE DON'T EVEN HAVE A UNIFIED WAY TO REPRESENTING A VECTOR. > > I need to elaborate this statement, otherwise it cause confusion to > others. > > Elisp provides "List" and "Vector" as an array of numbers: > https://www.gnu.org/software/emacs/manual/html_node/elisp/Sequences-Arra= ys-Vectors.html > > To express an array of numbers, a developer would either use two of them > - (setq x '(1 2 3 4)) ; (type-of x) =3D> cons > - (setq x [1 2 3 4]) ; (type-of x) =3D> vector > > "cons" (or "list") is the first thing that everybody would choose, for > example, in Sergey's elisa: > https://github.com/s-kostyaev/elisa/blob/main/elisa.el > In the function "elisa--distances", Sergey puts "head" and "(car tail)" > as arguments to "elisa-cosine-distance", this means Sergey uses > cons/list to organize array of numbers. > > However, Elisp also has "array" types: > https://www.gnu.org/software/emacs/manual/html_node/elisp/Arrays.html > > An array object has slots that hold a number of other Lisp objects, > > called the elements of the array. Any element of an array MAY BE > > ACCESSED IN CONSTANT TIME. In contrast, the time to access an element > > of a list is proportional to the position of that element in the list. > > cons/list is something like "linked list" which is not accessed in const > time, but vector support this, e.g. it takes more time to access the > last element if we use cons/list, but less time if use vector. > > However, Elisp provides too few functions on operating the vector type, > for example, to slice a vector like the way in python: array[2:4]. > > So my saying "don't even have a unified way to representing a vector", I > mean, to organize/represent a MATHEMATICAL vector > - I would prefer to choose the object that support const time access, > i.e. the BUILTIN vector type, over the cons/list. > - However, the BUILTIN vector type supports quite a few functions, which > forces me to change my mind to organize/represent the MATHEMATICAL > vectors by cons/list. > > This is the dilemma during developing my own math libraries. > > Besides, in the Calc subroutine, the MATHEMATICAL vectors are > represented by cons/list in this way > (vec 3 5 2 1 0) ; not (3 5 2 1 0) or [3 5 2 1 0] > i.e. a symbol "vec" is placed at the beginning of the list, in order to > simplify the predication. But this leads to the indexing problem, that > elements are indexed since 1, not 0. Such an indexing scheme would cause > a nightmare to the developer who want to use our math subroutine to do > further development. An indexing task should never be a problem to the seasoned developer. If they find it a nightmare, there is something missing with the developer= . Indexing in an everyday task in scientific programming. One just has to f= ocus and think about what one is doing a little bit. > In summary, if the builtin vector type is preferred way to represent the > MATHEMATICAL vector, we should first of all complete the fundamental > vector operations, like vector slicing etc. And of course, we should > take a look at how sbcl > https://git.code.sf.net/p/sbcl/sbcl > organize their vector and their vector functions. > > From my side, I don't want to touch the vector things so far, but instea= d > the rational number (the bullet 2 & 3 in my previous mail). > > Finally, > > Sent: Saturday, July 27, 2024 at 17:49 +0200 > > From: "Emanuel Berg" > > > > However it used to be even worse, when we didn't even have clocks! > > If the "clock" you said is the clock to measure how long a function > runs, we have, it is "benchmark-run". > > > -- > Best Regards, > Shouran Ma > >