Calling convention for list of lists of polynomials

[Brent W. Baccala]

Hi -

I'm working on a new subroutine, fmpz_mpoly_addmul, that will take a list of lists of polynomials, multiply each sub-list together, then add up all of these products into the final result.

The idea is to do this without storing all of the intermediate results, saving space.

Any suggestions what the calling convention should be?  FLINT usually takes a list of polynomials as an array pointer with a length, but what about a list of lists?  So common in most C code would be NULL-terminated lists.

Just wondering if this has been done elsewhere in FLINT and if a standard calling convention has been developed.

    agape

    brent

[Bill Hart]

Hi Brent,

I don't know of a specific instance of this in Flint. One of the
challenges with lists is using them from Julia, so I think we nowadays
prefer an array of fmpz_mpoly_t's instead of fmpz_mpoly_structs, for
example, when working just with a single array. I guess a list of
lists would just be an array of arrays, i.e. an fmpz_mpoly_t **.

Can I petition for a change of name though. addmul is used in flint
for c = a*b and this is a function we may want at some point. Perhaps
addmul_multi or something like that would be better.

Bill.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "flint-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/a30bd930-d330-4cb7-b7d5-b4c5e5b2cb58n%40googlegroups.com.

[fieker]

its an inner product, are there conventions for inner products?

> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/CAB0xFntbcfmeSNr68AP4S%3DuCJwD9PDNnX-dK-FDZLhcZhkhXJA%40mail.gmail.com.

[Brent W. Baccala]

On Monday, July 12, 2021 at 4:39:42 AM UTC-4 Bill Hart wrote:

Hi Brent,

I don't know of a specific instance of this in Flint. One of the
challenges with lists is using them from Julia, so I think we nowadays
prefer an array of fmpz_mpoly_t's instead of fmpz_mpoly_structs, for
example, when working just with a single array. I guess a list of
lists would just be an array of arrays, i.e. an fmpz_mpoly_t **.

Are you thinking of a pointer (fmpz_mpoly_t **) to an array of pointers (fmpz_mpoly_t *) to arrays (fmpz_mpoly_t)?

Would the first array end with a NULL?  Or pass in a length for it?  And how would we communicate the length of the secondary arrays?  An extra array of integers?

A problem I see with that is that, unlike the binary operators like fmpz_mpoly_mul, we'd have to create a new array of fmpz_mpoly_t's just to structure things properly to pass into the addmul function.  Perhaps pointers to polynomials would be better; arrays of pointers to polynomials, and an array of pointers to arrays of pointers to polynomials.  Still wondering the best way to encode the length of the arrays.

I don't know Julia; I've been looking at how to do this from Sage/Python.  It looks like I'll create a dynamically allocated array in the Cython code to pass into the FLINT function, so a single array of pointers to polynomials would be the most convenient.  I'm currently ending each sub-list with a NULL pointer, and ending the entire list with two NULL pointers.  Obviously a bit of a weird convention; it can be tweaked.

 

Can I petition for a change of name though. addmul is used in flint
for c = a*b and this is a function we may want at some point. Perhaps
addmul_multi or something like that would be better.

Sure, that sounds fine.  fmpz_mpoly_addmul_multi, then?

    agape

    brent

[Brent W. Baccala]

On Monday, July 12, 2021 at 5:11:32 AM UTC-4 fie...@mathematik.uni-kl.de wrote:

its an inner product, are there conventions for inner products?

Not that I know of, other than that a matrix inner product would be done by forming the entire thing into a matrix and passing it as a matrix argument.

Maybe others who know FLINT better than I can comment better.

    agape

    brent

 

[Bill Hart]

On Mon, 12 Jul 2021 at 23:36, Brent W. Baccala <cos...@freesoft.org> wrote:
>
> On Monday, July 12, 2021 at 4:39:42 AM UTC-4 Bill Hart wrote:
>>
>> Hi Brent,
>>
>> I don't know of a specific instance of this in Flint. One of the
>> challenges with lists is using them from Julia, so I think we nowadays
>> prefer an array of fmpz_mpoly_t's instead of fmpz_mpoly_structs, for
>> example, when working just with a single array. I guess a list of
>> lists would just be an array of arrays, i.e. an fmpz_mpoly_t **.
>
>
> Are you thinking of a pointer (fmpz_mpoly_t **) to an array of pointers (fmpz_mpoly_t *) to arrays (fmpz_mpoly_t)?

I'm thinking of an array (fmpz_mpoly_t **) or arrays (fmpz_mpoly_t *)
of polynomials (fmpz_mpoly_t)

>
> Would the first array end with a NULL? Or pass in a length for it? And how would we communicate the length of the secondary arrays? An extra array of integers?

I would pass in an array of lengths, one for each of the (fmpz_mpoly_t
*)'s and a length for the number of elements in the first array
(fmpz_mpoly_t **)

>
> A problem I see with that is that, unlike the binary operators like fmpz_mpoly_mul, we'd have to create a new array of fmpz_mpoly_t's just to structure things properly to pass into the addmul function. Perhaps pointers to polynomials would be better; arrays of pointers to polynomials, and an array of pointers to arrays of pointers to polynomials. Still wondering the best way to encode the length of the arrays.

Why? If I have an array of polynomials, fmpz_mpoly_t * polyarr; then
to get the i-th polynomial is just polyarr[i]. That can be passed in
to addmul.

>
> I don't know Julia; I've been looking at how to do this from Sage/Python. It looks like I'll create a dynamically allocated array in the Cython code to pass into the FLINT function, so a single array of pointers to polynomials would be the most convenient. I'm currently ending each sub-list with a NULL pointer, and ending the entire list with two NULL pointers. Obviously a bit of a weird convention; it can be tweaked.
>
>>
>> Can I petition for a change of name though. addmul is used in flint
>> for c = a*b and this is a function we may want at some point. Perhaps
>> addmul_multi or something like that would be better.
>
>
> Sure, that sounds fine. fmpz_mpoly_addmul_multi, then?

Sure.

>
> agape
> brent
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "flint-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/8b56fb8e-77da-46cc-b291-3be34d6af526n%40googlegroups.com.

[Brent W. Baccala]

On Monday, July 12, 2021 at 6:04:49 PM UTC-4 Bill Hart wrote:

On Mon, 12 Jul 2021 at 23:36, Brent W. Baccala <cos...@freesoft.org> wrote:
>
> On Monday, July 12, 2021 at 4:39:42 AM UTC-4 Bill Hart wrote:
>>
>> Hi Brent,
>>
>> I don't know of a specific instance of this in Flint. One of the
>> challenges with lists is using them from Julia, so I think we nowadays
>> prefer an array of fmpz_mpoly_t's instead of fmpz_mpoly_structs, for
>> example, when working just with a single array. I guess a list of
>> lists would just be an array of arrays, i.e. an fmpz_mpoly_t **.
>

> ...

>
> A problem I see with that is that, unlike the binary operators like fmpz_mpoly_mul, we'd have to create a new array of fmpz_mpoly_t's just to structure things properly to pass into the addmul function. Perhaps pointers to polynomials would be better; arrays of pointers to polynomials, and an array of pointers to arrays of pointers to polynomials. Still wondering the best way to encode the length of the arrays.

Why? If I have an array of polynomials, fmpz_mpoly_t * polyarr; then
to get the i-th polynomial is just polyarr[i]. That can be passed in
to addmul.

The problem is that I typically don't have an array of polynomials.  I have a bunch of polynomials that have been individually allocated.  It'd be most convenient to pass in pointers to their structures instead of creating an array of structures. 

    agape

    brent

[Bill Hart]

I see. Yes, that sounds like the best solution then.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "flint-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/9ea1c0a1-7ede-408a-b7f6-bec12fc35a46n%40googlegroups.com.

[Brent W. Baccala]

On Monday, July 12, 2021 at 6:19:14 PM UTC-4 Bill Hart wrote:

I see. Yes, that sounds like the best solution then.

Which solution do you think sounds best?

    agape

    brent

 

[Bill Hart]

Just what you said. It'll have to be an array of pointers to
polynomial structs. These can be passed directly to addmul and I think
Julia will be ok with them so it seems like the best solution I think.

Bill.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "flint-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to flint-devel...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/00443b79-f9e6-4583-b186-591757a9ae72n%40googlegroups.com.

[Brent W. Baccala]

And do you think it would be best to pass a separate array of integer lengths instead of using NULL termination?

[Brent W. Baccala]

How about a single array of pointers to polynomials, an array of integer lengths, and a length of the integer array?  The total length of the array of pointers would be the sum of the integers in the integer array.

Any reason not to do it that way?

[Claus Fieker]

Looking at the fq_mat templates the name could should include vec_dot probably

To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/d3a7e322-b872-4806-8a5a-d639ecdb9936n%40googlegroups.com.

[Bill Hart]

That sounds ok too.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/flint-devel/d3a7e322-b872-4806-8a5a-d639ecdb9936n%40googlegroups.com.