Re: Tablicious in Octave Forge

[Rik]

On 03/12/2021 07:09 AM, octave-maintainers-request@gnu.org wrote:

Subject:

Re: Tablicious in Octave Forge [was: Re: [GSoC 2021] How should I do now with project Table datatype]

From:

Guillaume <guillaume.offline@gmail.com>

Date:

03/12/2021 06:25 AM

To:

Octave Maintainers List <octave-maintainers@gnu.org>

List-Post:

<mailto:octave-maintainers@gnu.org>

Precedence:

list

MIME-Version:

1.0

References:

<tencent_300023794073ED7E3E3582B2@qq.com> 51dbe730-1288-4fcd-2e5d-b9806925f377@gmail.com"><51dbe730-1288-4fcd-2e5d-b9806925f377@gmail.com> 85122ca5-3827-f0b7-015b-1bc583623207@apjanke.net"><85122ca5-3827-f0b7-015b-1bc583623207@apjanke.net> ddac8f79-6b02-81d4-e86f-f42664edefeb@octave.org"><ddac8f79-6b02-81d4-e86f-f42664edefeb@octave.org> aaf1e170-890b-3473-fe1a-128bb4fa205f@apjanke.net"><aaf1e170-890b-3473-fe1a-128bb4fa205f@apjanke.net>

In-Reply-To:

aaf1e170-890b-3473-fe1a-128bb4fa205f@apjanke.net"><aaf1e170-890b-3473-fe1a-128bb4fa205f@apjanke.net>

Message-ID:

<CAEAX1kFSk-iJzsY+U+aVq8OmwZwt0QkSEO0_PzHpXJ=Zc8t41g@mail.gmail.com>

Content-Type:

multipart/alternative; boundary="00000000000019254605bd57ab0b"

Message:

4

I think having a GSoC student working on the implementation of table would be great and I would skip the Forge packaging to focus on adding the functionality in core Octave (of course, reusing as much as possible of Tablicious).

Once the low level data structure is in place (a write-up on "proxy key" would be great), the burden of the implementation of all table related functions could be shared among all interested parties:

https://www.mathworks.com/help/matlab/tables.html

Would it also be possible to decouple projects? Why not implementing (part of) table without requiring strings or datetime or categorical or missing? I feel that if the foundations are there and robust, we can build the rest one bit at a time.

Guillaume.

My vote as well is to just implement this in core Octave.  Developer time is limited and spending 1/4-1/3 of the effort setting something up in Octave Forge only to discard it later when the code moves to core seems a grievous waste.

We are also early in the 7.0 cycle so now is the time to make big changes and potentially de-stabilize the code base for a while.

See also this Discourse thread where I introduced some ideas about possible large themes for the next release: https://octave.discourse.group/t/goals-for-the-next-release/358/6.

In particular, two themes I mentioned bear on this discussion:

Matlab compatibility
** strings class (bite the bullet and implement this and, probably, get rid of Octave’s very UNIX-y way of understanding single and double quotes)
** “argument” input validation blocks
** others? Seems like there are tall arrays, dataframes, etc.

Octave-only functionality
** built-in hash operator. I would like to see an O(1) search function incorporated in to the Octave language, similar to hashes in Perl or dictionaries in Python. This would be an extension over what Matlab provides, and could be used to implement containers.Map more easily as well as data frames.

--Rik