Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request predicate divmod/4 #71

Open
Jean-Luc-Picard-2021 opened this issue Sep 21, 2022 · 3 comments
Open

Feature request predicate divmod/4 #71

Jean-Luc-Picard-2021 opened this issue Sep 21, 2022 · 3 comments

Comments

@Jean-Luc-Picard-2021
Copy link

Its quite customary that Prolog systems nowadays
have divmod/4, because many bigint algorithms can
produce both div and mod at the same time.

Trying to port a SWI-Porlog program I get:

?- use_module('/draft.pl').
{Compiling /draft.pl
ERROR: (lns 27-30) Predicate divmod/4 undefined in source
ERROR: Aborted module compilation
}

Could this be added to Ciao Prolog, especially the playground?

@jfmc
Copy link
Member

jfmc commented Sep 21, 2022

Thanks for the suggestion!

You may try this:

divmod(Dividend, Divisor, Quot, Rem) :-
    Rem is Dividend mod Divisor,
    Quot is (Dividend - Rem) // Divisor.

which actually gives an implementation for div/3 (before we introduce it as an arithmetic expression):

div(Dividend, Divisor, Quot) :-
    Rem is Dividend mod Divisor,
    Quot is (Dividend - Rem) // Divisor.

@Jean-Luc-Picard-2021 Jean-Luc-Picard-2021 changed the title Feature request divmod/4 Feature request optional evaluable function divmod/4 Sep 21, 2022
@jfmc
Copy link
Member

jfmc commented Sep 21, 2022

No, Ciao uses its own implementation of bignums. Of course we could add it, but is there any example where performance of this operation is critical?

@Jean-Luc-Picard-2021 Jean-Luc-Picard-2021 changed the title Feature request optional evaluable function divmod/4 Feature request predicate divmod/4 Oct 28, 2022
@jfmc jfmc reopened this Jul 29, 2023
@jfmc jfmc reopened this May 3, 2024
@mherme
Copy link

mherme commented May 4, 2024

It is better not to close it because it is not solved. Open issues are reminders of things that need to done or would be good to do, for which we thank you. Unfortunately time is limited, snd thus when to get something done is indeed a matter of priorities, as @jfmc implied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants