Re: Tablicious in Octave Forge

On 03/12/2021 07:09 AM, [email protected] wrote:
> Subject:
> Re: Tablicious in Octave Forge [was: Re: [GSoC 2021] How should I do now
> with project Table datatype]
> From:
> Guillaume <[email protected]>
> Date:
> 03/12/2021 06:25 AM
>
> To:
> Octave Maintainers List <[email protected]>
>
> List-Post:
> <mailto:[email protected]>
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]>
> <[email protected]>
> In-Reply-To:
> <[email protected]>
> 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