Inefficiency when both div_ and rem_ are needed

[spj101]

There is an inefficiency when the user wants the result of both div_ and rem_. These are computed simultaneously by the divmod algorithms inside FORM but then only one is returned. This effectively doubles the time the user must wait.

Is it possible to add something like the following?

L q,r = divrem_(f,g);

or

divrem(f,g,q,r);

Thanks!

[tueda]

I really like the first syntax in which divrem_ returns a tuple, but probably FORM never gets such a cozy syntax. I'm not sure about the exact meaning of the second one, but I guess divrem_(f,g,q,r) that returns a product of the quotient and reminder that are hold in functions q and r, so q(...)*r(...). This would be fine but at some point one will encounter the MaxTermSize problem.

[vermaseren]

I guess the proper syntax would be something like divrem_(f,g,$remainder) where the function returns the quotient and the remainder gets stored in the dollar variable. One can then also think of remdiv_ that returns the remainder and puts the quotient in the $. The only little complication is thatthis function needs a special status internally to prevent the $ from being expanded. Things like this have been done already with some other functions and names of expressions and dollars. Actually div_ and rem_ also do not expand expressions until they get busy. Hence I think it should not be much work. Jos

…

On 24 May 2018, at 03:21, Takahiro Ueda ***@***.***> wrote: I really like the first syntax in which divrem_ returns a tuple, but probably FORM never gets such a cozy syntax. I'm not sure about the exact meaning of the second one, but I guess divrem_(f,g,q,r) that returns a product of the quotient and reminder that are hold in functions q and r, so q(...)*r(...). This would be fine but at some point one will encounter the MaxTermSize problem. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#282 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLxEkO3IuNT4B_j0kusiBY-6-ZRSe9Nks5t1gr9gaJpZM4UKj8u>.

[vermaseren]

On second thought: We do not need a divrem_ function. Just adding a dollar to the arguments of div_ and rem_ should do the job. Hence L F = div_(f,g,$rem); should leave the remainder in $rem. Probably very small things to change only. Jos

…

On 24 May 2018, at 08:15, Jos Vermaseren ***@***.***> wrote: I guess the proper syntax would be something like divrem_(f,g,$remainder) where the function returns the quotient and the remainder gets stored in the dollar variable. One can then also think of remdiv_ that returns the remainder and puts the quotient in the $. The only little complication is thatthis function needs a special status internally to prevent the $ from being expanded. Things like this have been done already with some other functions and names of expressions and dollars. Actually div_ and rem_ also do not expand expressions until they get busy. Hence I think it should not be much work. Jos > On 24 May 2018, at 03:21, Takahiro Ueda ***@***.*** ***@***.***>> wrote: > > I really like the first syntax in which divrem_ returns a tuple, but probably FORM never gets such a cozy syntax. I'm not sure about the exact meaning of the second one, but I guess divrem_(f,g,q,r) that returns a product of the quotient and reminder that are hold in functions q and r, so q(...)*r(...). This would be fine but at some point one will encounter the MaxTermSize problem. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub <#282 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLxEkO3IuNT4B_j0kusiBY-6-ZRSe9Nks5t1gr9gaJpZM4UKj8u>. >

[spj101]

Thanks a lot for thinking about this.

@tueda with my divrem_(f,g,q,r) suggestion all arguments would be expressions, the quotient and remainder would be written to the expressions q and r respectively.

@vermaseren I think the syntax

L F = div_(f,g,$rem);

is acceptable but I would be concerned about the the $rem dollar variable getting corrupted as discussed in issue #215 and #211 (comment). Could this corruption potentially happen if the remainder is large (especially if work is done to extend the size of polynomials that can be handled by the C++ part of FORM)?

[vermaseren]

Well, if you are thinking that big…. In that case you can already use L F = div_(f,g); .sort L G = f-g*F; * remainder. I just checked. It is not quite easy to extract both from the current routines. The routine is poly_divmod, but there parts where it assumes that it is calculating only one of the two. The remaining part (for either syntax) is the easy part. Jos

…

On 24 May 2018, at 12:25, Stephen Jones ***@***.***> wrote: Thanks a lot for thinking about this. @tueda <https://github.com/tueda> with my divrem_(f,g,q,r) suggestion all arguments would be expressions, the quotient and remainder would be written to the expressions q and r respectively. @vermaseren <https://github.com/vermaseren> I think the syntax L F = div_(f,g,$rem); is acceptable but I would be concerned about the the $rem dollar variable getting corrupted as discussed in issue #215 <#215> and #211 (comment) <#211 (comment)>. Could this corruption potentially happen if the remainder is large (especially if work is done to extend the size of polynomials that can be handled by the C++ part of FORM)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#282 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLxEqQeTeOLSy2DzHau9Ev3trrM-uIQks5t1oqmgaJpZM4UKj8u>.

[spj101]

I agree, we can of course compute using a multiplication rather than calling rem_. This is slightly less efficient than if the function just returned the sorted(?) remainder which is already known to it.

Yes I see that poly_divmod only converts either the quotient or the remainder from the C++ poly class to the syntax needed by the C part of FORM. The thing I would be least sure how to implement is how to return an additional result in a dollar variable (or other expression).