Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.prolog > #13157 > unrolled thread
| Started by | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| First post | 2022-08-17 05:18 -0700 |
| Last post | 2023-11-19 10:54 -0800 |
| Articles | 16 on this page of 116 — 5 participants |
Back to article view | Back to comp.lang.prolog
Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 05:18 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 06:37 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 07:00 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-17 13:28 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 02:59 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 03:04 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 03:10 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 10:18 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-08-31 10:22 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:06 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:12 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:13 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 16:14 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 23:57 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-09 23:59 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 05:11 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 10:46 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 10:48 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-12 13:22 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 05:53 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 07:32 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 11:16 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 11:18 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 11:36 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-13 13:28 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-14 01:41 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-14 01:43 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-14 07:41 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <janburse@fastmail.fm> - 2022-10-15 14:30 +0200
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:42 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:50 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:51 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 07:52 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 18:55 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 18:58 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-19 19:46 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 05:55 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 05:59 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 08:36 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-25 10:53 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-26 07:01 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-10-26 07:02 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-14 14:21 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-14 14:31 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-17 06:08 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2022-11-17 06:21 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-11 12:45 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-11 12:52 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-11 14:24 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 01:56 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 01:58 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 01:59 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 02:01 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-13 04:49 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-16 15:03 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-16 15:07 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-17 00:49 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-01-17 03:22 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 03:08 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 03:08 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 10:31 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 10:33 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-02-27 16:05 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-01 09:01 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-01 09:02 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-02 04:06 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-02 04:08 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-08 01:45 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-08 01:47 -0800
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 05:55 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 05:56 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 06:01 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-03-18 06:06 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-05-13 06:36 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-05-13 06:41 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mostowski Collapse <bursejan@gmail.com> - 2023-05-21 03:54 -0700
Differences among the "bomb" and "xbetween" (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-09-24 17:10 +0200
The issue with free speech Mild Shock <janburse@fastmail.fm> - 2024-10-09 15:29 +0200
failure of formal verification [software.imdea.org] (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:33 +0100
Re: failure of formal verification [software.imdea.org] (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:35 +0100
Re: failure of formal verification [software.imdea.org] (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:37 +0100
variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-12 22:02 +0200
Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-12 23:16 +0200
Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-12 23:34 +0200
Re: variant_term/2 is faster than variant/1 (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-10-13 00:54 +0200
Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <bursejan@gmail.com> - 2023-07-29 04:51 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <bursejan@gmail.com> - 2023-09-07 17:15 -0700
Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <janburse@fastmail.fm> - 2023-11-19 19:56 +0100
Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <janburse@fastmail.fm> - 2023-11-19 19:59 +0100
Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <janburse@fastmail.fm> - 2023-11-19 20:01 +0100
New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-07-28 14:32 +0200
Re: New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-07-28 14:38 +0200
Re: New milestone float formatting [LoL] (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-07-28 16:42 +0200
Re: Differences among the "bomb" and "xbetween" (Was: New milestone float formatting [LoL]) Mild Shock <janburse@fastmail.fm> - 2024-09-24 17:20 +0200
New milestone time formatting (Was: Differences among the "bomb" and "xbetween") Mild Shock <janburse@fastmail.fm> - 2024-09-26 13:22 +0200
More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404] Mild Shock <janburse@fastmail.fm> - 2024-10-09 09:43 +0200
Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404]) Mild Shock <janburse@fastmail.fm> - 2024-10-09 09:45 +0200
Re: Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404]) Mild Shock <janburse@fastmail.fm> - 2024-10-09 10:00 +0200
Re: Even More Prolog Improvement Proposals (PIPs) [PIP301 - PIP303] (Was: More Prolog Improvement Proposals (PIPs) [PIP401 - PIP404]) Mild Shock <janburse@fastmail.fm> - 2024-10-09 11:22 +0200
A FFI for evaluable functions Mild Shock <janburse@fastmail.fm> - 2024-10-10 00:14 +0200
Name resolution is a blackbox (Re: A FFI for evaluable functions) Mild Shock <janburse@fastmail.fm> - 2024-10-10 00:16 +0200
plonk in discourse (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-10-10 00:48 +0200
When do two Prolog terms marry? (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-10-14 19:15 +0200
Re: When do two Prolog terms marry? (Was: The issue with free speech) Mild Shock <janburse@fastmail.fm> - 2024-10-14 19:22 +0200
native implementation of variant/2 can be fast (Was: When do two Prolog terms marry?) Mild Shock <janburse@fastmail.fm> - 2024-10-15 01:35 +0200
KISS principle pays off (Was: A FFI for evaluable functions) Mild Shock <janburse@fastmail.fm> - 2024-11-03 00:52 +0100
Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) Mild Shock <janburse@fastmail.fm> - 2024-11-06 09:51 +0100
Re: Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) Mild Shock <janburse@fastmail.fm> - 2024-11-06 10:09 +0100
Re: Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) Julio Di Egidio <julio@diegidio.name> - 2024-11-06 10:43 +0100
SICStus Prolog is overrated (Was: Waste of EU money / bread and butter of statistics) Mild Shock <janburse@fastmail.fm> - 2024-11-06 12:57 +0100
Crashing under its own bloath, Scryer Prolog (Was: SICStus Prolog is overrated) Mild Shock <janburse@fastmail.fm> - 2024-11-06 13:03 +0100
“Luce,” which is Italian for “light.” (Was: Crashing under its own bloath, Scryer Prolog) Mild Shock <janburse@fastmail.fm> - 2024-11-06 13:12 +0100
More Poisened Meat balls? [NIVIDIA & OpenAI] (Way: “Luce,” which is Italian for “light.”) Mild Shock <janburse@fastmail.fm> - 2024-11-06 13:33 +0100
Re: More Poisened Meat balls? [NIVIDIA & OpenAI] (Way: “Luce,” which is Italian for “light.”) Julio Di Egidio <julio@diegidio.name> - 2024-11-06 14:17 +0100
Not all Red-Black Trees are Okasaki (Was: Request for comments, Novacore the sequel to ISO modules) Mild Shock <janburse@fastmail.fm> - 2024-11-07 00:59 +0100
Re: Request for comments, Novacore the sequel to ISO modules Mild Shock <bursejan@gmail.com> - 2023-11-19 10:54 -0800
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-10-10 00:16 +0200 |
| Subject | Name resolution is a blackbox (Re: A FFI for evaluable functions) |
| Message-ID | <ve6vbr$7df2$2@solani.org> |
| In reply to | #14223 |
In the proposal Name resolution is a blackbox.
It can be anything, atom table, dynamic lookup,
etc.. etc.. There should be a lot of synergy in
every Prolog system using the same approach for
predicates and evaluable functions concerning
their existence. But of course evaluable
functions need special attention to have
efficient evaluation.
Mild Shock schrieb:
> The implementation to allow native libraries to register
> new evaluable functions is the same as how predicates
> are consulted. Take these two files:
>
> $ cat > foo.p
>
> test :- hello.
>
> $ cat > bar.p
>
> hello :- write('hello'), nl.
>
> If I consult foo.p before bar.p there is a forward reference.
> But if I ultimately consult bar.p the forward reference is
> resolved. How does a Prolog system do that?
>
> $ target/release/scryer-prolog
> ?- ['foo.p'].
> true.
>
> ?- test.
> error(existence_error(procedure,hello/0),hello/0).
>
> ?- ['bar.p'].
> true.
>
> ?- test.
> hello
> true.
>
> Now enhance is/2, etc... so that it uses the same resultion
> meachanism, but only for the evaluable function namespace,
> and provide a FFI where one can register evaluable functions,
>
> in the evaluable function namespace, eh voila you are done,
> makeing your Prolog extensible. Allowing to register evaluable
> functions like gdc/2, popcount/1, etc.. outside of the core.
>
> Mild Shock schrieb:
>> The new multilingual strings are also an exercise in
>> Novacore. There were a few issues that needed novel
>> Prolog solutions, to make a Novacore solution.
>>
>> One problem was I didn't want to use library(format)
>> and format/3 to format multilingual strings when
>> generating error messages. This addresses more
>>
>> the later multilingual strings processing than the
>> multilingual strings store itself. So how resolve this
>> paradox? Here is my take, a mini format/3 boostraped
>>
>> from the Dogelog Player specific atom_split/3:
>>
>> % sys_inter_polate(+Stream, +Atom, +List)
>> sys_inter_polate(Stream, Template, Args) :-
>> atom_split(Template, '~', [Head|Tail]),
>> put_atom(Stream, Head),
>> sys_zipper_output(Args, Tail, Stream).
>>
>> % sys_zipper_output(+List, +List, +Stream)
>> sys_zipper_output([Arg|Args], [Head|Tail], Stream) :-
>> writeq(Stream, Arg),
>> put_atom(Stream, Head),
>> sys_zipper_output(Args, Tail, Stream).
>> sys_zipper_output([], [], _).
>>
>> It only understands format specifier '~', but is sufficient:
>>
>> /* German Text */
>> strings('syntax_error.singleton_var', de, 'Alleinstehende Variable(n)
>> ~, anonyme Variable(n) (_) benutzen.').
>>
>> /* English and Fallback Text */
>> strings('syntax_error.singleton_var', '', 'Singleton variable(s) ~,
>> use anonymous variable(s) (_).').
>>
>> LoL
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-10-10 00:48 +0200 |
| Subject | plonk in discourse (Was: The issue with free speech) |
| Message-ID | <ve718e$7ejh$1@solani.org> |
| In reply to | #14224 |
I have a problem with the code of conduct of the group New PIP proposals - Prolog Community which is not free speech friendly. It says: If You See a Problem, Flag It https://discourse.prolog-lang.org/faq Thats not a good approach since it can be easily abused. What I think is a better approach are individual kill files, like in the good old USENET times. Interestingly plonk is also provided by discourse. For example in SWI-Prolog discourse I can go to a user, and choose ignore indefinitely:
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-10-14 19:15 +0200 |
| Subject | When do two Prolog terms marry? (Was: The issue with free speech) |
| Message-ID | <vejjj4$dlal$1@solani.org> |
| In reply to | #14225 |
Now I was struggling giving this predicate
a better name. Namely variant_term bootstrapped
as follows:
variant_term(X, Y) :-
subsumes_term(X, Y),
subsumes_term(Y, X).
Why does it need a better name? Well because it
is not really the variant, as realized by
for example SWI-Prolog's (=@=):
For example I find:
?- variant_term(f(X,Y,Z,T), f(A,B,C,D)).
true.
?- variant_term(f(X,Y,Z,T), f(A,B,Z,D)).
true.
?- variant_term(f(A,Y,Z,T), f(A,B,Z,D)).
true.
?- variant_term(f(A,Y,Z,T), f(A,B,C,Z)).
fail.
?- variant_term(f(X,A,Z,T), f(A,B,Z,D)).
fail.
The first 3 test cases match what variant/2
usually does. But the last 2 test cases don't
match what variant/2 usually does.
So how can characterize the behaviour of
this weak variant. I came up with this observation:
- A weak variant takes has variables that appear
in the left hand side and in the right hand side,
i.e. common variables, only obtaining an identity
relation.
- Othewise variables that are either specific to
the right hand side or that are either specific
to the left hand side, are associated by a
bijection relation.
I came up with names like "twin", "sibling" for
this relation. But I got also inspired by the
fact that builtins:variant/2 from Scryer Prolog
leaves bindings. So looking for a name similar
like "unify", but only its weak variant and it
leaves a binding trace. My idea is to use "marry"!
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-10-14 19:22 +0200 |
| Subject | Re: When do two Prolog terms marry? (Was: The issue with free speech) |
| Message-ID | <vejjvu$dleb$1@solani.org> |
| In reply to | #14231 |
Amazingly simple and falling back again on Richard O'Keefes
subsumes/2. How to implement subsumes/2 directly is
for example found here:
% File : METUTL.PL
% Author : R.A.O'Keefe
% Updated: 15 September 1984
% Purpose: meta-logical operations as described in my note
http://www.picat-lang.org/bprolog/publib/metutl.html
subsumes/2 has the advantages that it doesn't need
cyclic term capable unification to be implemented,
since it has no problems in refuting:
?- subsumes(X, f(X)).
fail.
It can be also used to easily bootstrap subsumes_term/2:
subsumes_term(X,Y) :-
\+ \+ subsumes(X,Y).
Putting the two together we can define:
marry(X, Y) :-
subsumes_term(X, Y),
subsumes(Y, X).
Lets see some test cases:
?- marry(f(X,Y,Z,T), f(A,B,C,D)).
X = A, Y = B, Z = C, T = D.
?- marry(f(X,Y,Z,T), f(A,B,Z,D)).
X = A, Y = B, T = D.
?- marry(f(A,Y,Z,T), f(A,B,Z,D)).
Y = B, T = D.
?- marry(f(A,Y,Z,T), f(A,B,C,Z)).
fail.
?- marry(f(X,A,Z,T), f(A,B,Z,D)).
fail.
What can we do with it? I recently made
distinct/1 working based on marry/2:
d(_,_).
d(a,a).
d(_,_).
?- findall(X-Y,d(X,Y),L).
L = [_70340-_70341, a-a, _70346-_70347].
?- findall(X-Y,distinct(d(X,Y)),L).
L = [_71298-_71299, a-a].
Which is pretty cool!
Mild Shock schrieb:
> Now I was struggling giving this predicate
> a better name. Namely variant_term bootstrapped
> as follows:
>
> variant_term(X, Y) :-
> subsumes_term(X, Y),
> subsumes_term(Y, X).
>
> Why does it need a better name? Well because it
> is not really the variant, as realized by
> for example SWI-Prolog's (=@=):
>
> For example I find:
>
> ?- variant_term(f(X,Y,Z,T), f(A,B,C,D)).
> true.
> ?- variant_term(f(X,Y,Z,T), f(A,B,Z,D)).
> true.
> ?- variant_term(f(A,Y,Z,T), f(A,B,Z,D)).
> true.
> ?- variant_term(f(A,Y,Z,T), f(A,B,C,Z)).
> fail.
> ?- variant_term(f(X,A,Z,T), f(A,B,Z,D)).
> fail.
>
> The first 3 test cases match what variant/2
> usually does. But the last 2 test cases don't
> match what variant/2 usually does.
>
> So how can characterize the behaviour of
> this weak variant. I came up with this observation:
>
> - A weak variant takes has variables that appear
> in the left hand side and in the right hand side,
> i.e. common variables, only obtaining an identity
> relation.
>
> - Othewise variables that are either specific to
> the right hand side or that are either specific
> to the left hand side, are associated by a
> bijection relation.
>
> I came up with names like "twin", "sibling" for
> this relation. But I got also inspired by the
> fact that builtins:variant/2 from Scryer Prolog
>
> leaves bindings. So looking for a name similar
> like "unify", but only its weak variant and it
> leaves a binding trace. My idea is to use "marry"!
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-10-15 01:35 +0200 |
| Subject | native implementation of variant/2 can be fast (Was: When do two Prolog terms marry?) |
| Message-ID | <vek9rh$e0ud$1@solani.org> |
| In reply to | #14231 |
Ok, I tried a native implementation of variant/2. I did it in Dogelog Player for Java. Thats a Prolog system that doesn't have unification for cyclic terms. So the situation is a little simpler. Comparing on the same machine and with the data we have already gathered it is shockingly fast! /* Dogelog Player 1.2.4, JDK 22 */ ?- time(test). % Zeit 211 ms, GC 0 ms, Lips 7567459, Uhr 15.10.2024 01:30 true. ?- time(test2). % Zeit 413 ms, GC 0 ms, Lips 10703217, Uhr 15.10.2024 01:30 true. > Here some results: > > - SWI-Prolog 9.3.11: > > ?- time(test). > % 2,126,498 inferences, 0.734 CPU in 0.752 seconds > (98% CPU, 2895657 Lips) > true. > > ?- time(test2). > % 2,159,795 inferences, 0.234 CPU in 0.236 seconds > (99% CPU, 9215125 Lips) > true. > > - Trealla Prolog 2.57.16: > > ?- time(test). > % Time elapsed 3.128s, 14827949 Inferences, 4.741 MLips > true. > > ?- time(test2). > % Time elapsed 1.079s, 7775516 Inferences, 7.206 MLips > true. > > - Scryer Prolog : > > ?- time(test3). > % CPU time: 5.653s, 5_192_831 inferences > true. > > ?- time(test2). > % CPU time: 1.544s, 6_116_163 inferences > true. > > Note: test3 is like test, only it uses builtins:variant/2.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-03 00:52 +0100 |
| Subject | KISS principle pays off (Was: A FFI for evaluable functions) |
| Message-ID | <vg6dvt$38jd$1@solani.org> |
| In reply to | #14223 |
I have dropped the idea to realize and use variant/2.
The idea is to use only numbervars/3. Here is a test,
testing the newest release of SWI-Prolog as well:
/* SWI-Prolog 9.3.14 */
?- time(test5).
% 39,918,731 inferences, 9.031 CPU in 9.022 seconds (100% CPU, 4420067 Lips)
true.
/* Dogelog Player 1.2.4 */
?- time(test5).
% Zeit 5696 ms, GC 0 ms, Lips 10186409, Uhr 03.11.2024 00:44
true.
The test code is:
test5 :-
(between(1,1000,_),
aggregate_all(count, distinct(gen3(_)), _),
fail; true).
gen3(X) :-
length(L, 25),
between(1,1000,_),
random(Y),
Z is floor(Y*1000),
X = [Z|L].
> Ok, I tried a native implementation of variant/2.
> I did it in Dogelog Player for Java. Thats a
> Prolog system that doesn't have unification for
>
> cyclic terms. So the situation is a little simpler.
> Comparing on the same machine and with the data
> we have already gathered it is shockingly fast!
>
> /* Dogelog Player 1.2.4, JDK 22 */
>
> ?- time(test).
> % Zeit 211 ms, GC 0 ms, Lips 7567459, Uhr 15.10.2024 01:30
> true.
>
> ?- time(test2).
> % Zeit 413 ms, GC 0 ms, Lips 10703217, Uhr 15.10.2024 01:30
> true.
>
>> Here some results:
>>
>> - SWI-Prolog 9.3.11:
>>
>> ?- time(test).
>> % 2,126,498 inferences, 0.734 CPU in 0.752 seconds
>> (98% CPU, 2895657 Lips)
>> true.
>>
>> ?- time(test2).
>> % 2,159,795 inferences, 0.234 CPU in 0.236 seconds
>> (99% CPU, 9215125 Lips)
>> true.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-06 09:51 +0100 |
| Subject | Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) |
| Message-ID | <vgfan1$i1nc$1@solani.org> |
| In reply to | #13684 |
Hi, Spain is one of the main recipients of EU recovery funds, with a total of 163 billion euros ($178 billion) earmarked for the country, approximately half in grants and the rest in loans. It has already received 37 billion euros. Madrid and software.imdea.org is no exception. Probably the same disaster as the Valencia floods. The money is just siphoned into some crooks pockets. The biggest crooks are at the moment ALP & friends, just publishing a series of failure reports. Every paper just reports some problems, never solutions. Most recent cringe example: BoostRLR: The beauty of Prolog for statistical relational learning https://www.informatik.uni-wuerzburg.de/fileadmin/10030600/2024/KI_2004_paper_174.pdf What the fuck does this mean: > In SWI-Prolog, this can rely on an efficient specialised > implementation of aggregate_all(count,_,_), while we provide > a dedicated low-level XSB implementation in a count module > that we include with our program, courtesy of David S. > Warren (personal communication). Why is change_arg/3 not common among Prolog systems. Why do we deal with aggregates like we are still in stone age. Aggregates are a well known discipline of database technology. Why only aggregate_all/2 and not also a memory savy solutions of aggregate/3. Aggregates are the bread and butter of statistics. Bye Mild Shock schrieb:> Results of a fuzzer comparison: > > library(nb_rbtrees) from 2014 in SWI-Prolog: > > /* SWI-Prolog 9.3.14 */ > ?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], rb_new(T), > (member(X,L), nb_rb_insert(T, X, true), > fail; true), rb_display(T, 0). > $BLK 12-true > $RED 5-true > $BLK 2-true > $BLK 1-true > $NIL > $NIL > $BLK 3-true > $NIL > $RED 4-true > $NIL > $NIL > $BLK 10-true > $RED 7-true > $BLK 6-true > $NIL > $NIL > $BLK 8-true > $NIL > $RED 9-true > $NIL > $NIL > $BLK 11-true > $NIL > $NIL > $BLK 15-true > $BLK 13-true > $NIL > $RED 14-true > $NIL > $NIL > $BLK 16-true > $NIL > $NIL > > On the other hand the rules by Okasaki give a > different resulting tree, which is better balanced, > has less overall depth and doesn’t have a root 12, > > rather the root 8. Implementation based on change_arg/3: > > /* Dogelog Player 1.2.5 */ > ?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], tree_new(T), > (member(X,L), tree_set(T, X, true), > fail; true), tree_display(T, 0). > $BLK 8-true > $BLK 6-true > $RED 3-true > $BLK 1-true > $NIL > $RED 2-true > $NIL > $NIL > $BLK 5-true > $RED 4-true > $NIL > $NIL > $NIL > $BLK 7-true > $NIL > $NIL > $BLK 12-true > $BLK 10-true > $RED 9-true > $NIL > $NIL > $RED 11-true > $NIL > $NIL > $RED 15-true > $BLK 13-true > $NIL > $RED 14-true > $NIL > $NIL > $BLK 16-true > $NIL > $NIL > > I think Okasaki is the more common red-black > trees implementation, if I am not mistaken Java’s > method fixAfterInsertion() from the class TreeMap, > > does also implement the Okasaki rules. Bug or > Feature that SWI-Prolog doesn’t use Okasaki?
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-06 10:09 +0100 |
| Subject | Re: Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) |
| Message-ID | <vgfbnj$i281$1@solani.org> |
| In reply to | #14256 |
Hi, My experience with change_arg/3 so far, one that is akin to nb_linkarg/3 from SWI-Prolog is as follows: - The lack of purity in that there is one more side effect, is compensated in that we don't need a FFI and dozen foreign function implemented gadgets, like this gadget, termed "dedicated low-level implementation". > In SWI-Prolog, this can rely on an efficient specialised > implementation of aggregate_all(count,_,_), while we provide > a dedicated low-level XSB implementation in a count module > that we include with our program, courtesy of David S. > Warren (personal communication). - Instead of million different gadgets, there is only one gadget, which is change_arg/3 itself. One can integrate it with the Prolog garbage collection. I could demonstrated the same that change_arg/3 can fully participate in minor and major garbage collections of the Prolog system using a write barrier. - Having only this gadget, one can implement nb_XXX datastructures such as findall/3 bag. The big advantage since it will rely on Prolog garbage collection, is that no slow setup_call_cleanup/3 is needed. You can complemently forget about an infrastructure for this monster, its all superseeded by garbage collection, you also don't need to call some free() - You can spin it further and implement more nb_XXX datastructures profiting from the same advantages again, this is ongoing work right now. Example datastrutures are library(util/hash) and the brand new library(util/tree). - You can spin it even further to the ultimate goal. You can then use these nb_XXX datastructures to have memory savy aggregates. And thats one of the plateaus we want to reach. We want to compete with Pandas from Python and participate in Billion Row Challenges. Bye Mild Shock schrieb: > Hi, > > Spain is one of the main recipients of EU recovery funds, > with a total of 163 billion euros ($178 billion) earmarked > for the country, approximately half in grants and the rest > in loans. It has already received 37 billion euros. > > Madrid and software.imdea.org is no exception. Probably > the same disaster as the Valencia floods. The money > is just siphoned into some crooks pockets. The biggest > crooks are at the moment ALP & friends, > > just publishing a series of failure reports. Every > paper just reports some problems, never solutions. > Most recent cringe example: > > BoostRLR: The beauty of Prolog for statistical > relational learning > https://www.informatik.uni-wuerzburg.de/fileadmin/10030600/2024/KI_2004_paper_174.pdf > > > What the fuck does this mean: > > > In SWI-Prolog, this can rely on an efficient specialised > > implementation of aggregate_all(count,_,_), while we provide > > a dedicated low-level XSB implementation in a count module > > that we include with our program, courtesy of David S. > > Warren (personal communication). > > Why is change_arg/3 not common among Prolog systems. > Why do we deal with aggregates like we are still in > stone age. Aggregates are a well known discipline > of database technology. > > Why only aggregate_all/2 and not also a memory savy > solutions of aggregate/3. Aggregates are the bread > and butter of statistics. > > Bye > > Mild Shock schrieb:> Results of a fuzzer comparison: > > > > library(nb_rbtrees) from 2014 in SWI-Prolog: > > > > /* SWI-Prolog 9.3.14 */ > > ?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], rb_new(T), > > (member(X,L), nb_rb_insert(T, X, true), > > fail; true), rb_display(T, 0). > > $BLK 12-true > > $RED 5-true > > $BLK 2-true > > $BLK 1-true > > $NIL > > $NIL > > $BLK 3-true > > $NIL > > $RED 4-true > > $NIL > > $NIL > > $BLK 10-true > > $RED 7-true > > $BLK 6-true > > $NIL > > $NIL > > $BLK 8-true > > $NIL > > $RED 9-true > > $NIL > > $NIL > > $BLK 11-true > > $NIL > > $NIL > > $BLK 15-true > > $BLK 13-true > > $NIL > > $RED 14-true > > $NIL > > $NIL > > $BLK 16-true > > $NIL > > $NIL > > > > On the other hand the rules by Okasaki give a > > different resulting tree, which is better balanced, > > has less overall depth and doesn’t have a root 12, > > > > rather the root 8. Implementation based on change_arg/3: > > > > /* Dogelog Player 1.2.5 */ > > ?- L = [16,10,12,13,15,5,11,8,14,1,7,6,3,2,4,9], tree_new(T), > > (member(X,L), tree_set(T, X, true), > > fail; true), tree_display(T, 0). > > $BLK 8-true > > $BLK 6-true > > $RED 3-true > > $BLK 1-true > > $NIL > > $RED 2-true > > $NIL > > $NIL > > $BLK 5-true > > $RED 4-true > > $NIL > > $NIL > > $NIL > > $BLK 7-true > > $NIL > > $NIL > > $BLK 12-true > > $BLK 10-true > > $RED 9-true > > $NIL > > $NIL > > $RED 11-true > > $NIL > > $NIL > > $RED 15-true > > $BLK 13-true > > $NIL > > $RED 14-true > > $NIL > > $NIL > > $BLK 16-true > > $NIL > > $NIL > > > > I think Okasaki is the more common red-black > > trees implementation, if I am not mistaken Java’s > > method fixAfterInsertion() from the class TreeMap, > > > > does also implement the Okasaki rules. Bug or > > Feature that SWI-Prolog doesn’t use Okasaki?
[toc] | [prev] | [next] | [standalone]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2024-11-06 10:43 +0100 |
| Subject | Re: Waste of EU money / bread and butter of statistics (Was: failure of formal verification [software.imdea.org]) |
| Message-ID | <vgfdnu$223f3$1@dont-email.me> |
| In reply to | #14256 |
On 06/11/2024 09:51, Mild Shock wrote: > What the fuck does this mean: The Nazi-retarded shithole is all but going to fix itself. > Why is change_arg/3 not common among Prolog systems. Only poisoned meatballs for the public. https://github.com/SWI-Prolog/swipl-devel/issues/1328 -Julio
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-06 12:57 +0100 |
| Subject | SICStus Prolog is overrated (Was: Waste of EU money / bread and butter of statistics) |
| Message-ID | <vgflk3$i8g0$1@solani.org> |
| In reply to | #14258 |
SICStus Prolog is overrated. A lot of things in Prolog logic programming are overrated, so that it has lost it to a lot of turf over the last decade. But of course clinging to an old code base, and reselling the same old shit over and over again, is a very lucrative business compared to real innovation. Until OpenAI comes and does LLM. I am pretty sure we will see some blocks stumbling. For example the paper I was citing was traditional machine lerning, it was even not deep learning. Mostlikely Prolog will be hit much more than it is already hit with Python & Co. taking over a lot of data science turf. LoL Julio Di Egidio schrieb: > On 06/11/2024 09:51, Mild Shock wrote: > >> What the fuck does this mean: > > The Nazi-retarded shithole is all but going to fix itself. > >> Why is change_arg/3 not common among Prolog systems. > > Only poisoned meatballs for the public. > > https://github.com/SWI-Prolog/swipl-devel/issues/1328 > > -Julio >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-06 13:03 +0100 |
| Subject | Crashing under its own bloath, Scryer Prolog (Was: SICStus Prolog is overrated) |
| Message-ID | <vgflvb$i8oj$1@solani.org> |
| In reply to | #14259 |
Hi, Whats also extremly cringe is the struggel that Scryer Prolog is experiencing. It has adopted a bloat of post Herbrand Prolog nonsense, due to Colmerauer, namely fucking cyclic term unification. Its crashing under its own bloath of nonsense, just go to GitHub and count the issues. Last time I looked it had like 200 issues, and now after a blink its already at 300 issues. 335 Open - Scryer Prolog - Issues https://github.com/mthom/scryer-prolog/issues WTF? Bye Mild Shock schrieb: > > SICStus Prolog is overrated. A lot of things > in Prolog logic programming are overrated, so > that it has lost it to a lot of turf over > > the last decade. But of course clinging to > an old code base, and reselling the same old > shit over and over again, is a very lucrative > > business compared to real innovation. > > Until OpenAI comes and does LLM. I am pretty > sure we will see some blocks stumbling. For > example the paper I was citing was traditional > > machine lerning, it was even not deep learning. > Mostlikely Prolog will be hit much more than > it is already hit with Python & Co. taking over > > a lot of data science turf. > > LoL > > Julio Di Egidio schrieb: >> On 06/11/2024 09:51, Mild Shock wrote: >> >>> What the fuck does this mean: >> >> The Nazi-retarded shithole is all but going to fix itself. >> >>> Why is change_arg/3 not common among Prolog systems. >> >> Only poisoned meatballs for the public. >> >> https://github.com/SWI-Prolog/swipl-devel/issues/1328 >> >> -Julio >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-06 13:12 +0100 |
| Subject | “Luce,” which is Italian for “light.” (Was: Crashing under its own bloath, Scryer Prolog) |
| Message-ID | <vgfmeh$i959$1@solani.org> |
| In reply to | #14260 |
Hi, But I don't have a final solution. I am still a seeker, a free seeker free from legacy and orthodoxy, using free speech. Just like Luce: The official mascot for the Catholic Church’s 2025 Jubilee Year is named “Luce,” which is Italian for “light.” https://www.catholicnewsagency.com/news/260129/meet-luce-the-vatican-s-cartoon-mascot-for-jubilee-2025 LoL Bye Mild Shock schrieb: > Hi, > > Whats also extremly cringe is the > struggel that Scryer Prolog is experiencing. > It has adopted a bloat of post Herbrand > > Prolog nonsense, due to Colmerauer, namely > fucking cyclic term unification. Its > crashing under its own bloath of nonsense, > > just go to GitHub and count the issues. > Last time I looked it had like 200 issues, > and now after a blink its already at 300 issues. > > 335 Open - Scryer Prolog - Issues > https://github.com/mthom/scryer-prolog/issues > > WTF? > > Bye > > Mild Shock schrieb: >> >> SICStus Prolog is overrated. A lot of things >> in Prolog logic programming are overrated, so >> that it has lost it to a lot of turf over >> >> the last decade. But of course clinging to >> an old code base, and reselling the same old >> shit over and over again, is a very lucrative >> >> business compared to real innovation. >> >> Until OpenAI comes and does LLM. I am pretty >> sure we will see some blocks stumbling. For >> example the paper I was citing was traditional >> >> machine lerning, it was even not deep learning. >> Mostlikely Prolog will be hit much more than >> it is already hit with Python & Co. taking over >> >> a lot of data science turf. >> >> LoL >> >> Julio Di Egidio schrieb: >>> On 06/11/2024 09:51, Mild Shock wrote: >>> >>>> What the fuck does this mean: >>> >>> The Nazi-retarded shithole is all but going to fix itself. >>> >>>> Why is change_arg/3 not common among Prolog systems. >>> >>> Only poisoned meatballs for the public. >>> >>> https://github.com/SWI-Prolog/swipl-devel/issues/1328 >>> >>> -Julio >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-06 13:33 +0100 |
| Subject | More Poisened Meat balls? [NIVIDIA & OpenAI] (Way: “Luce,” which is Italian for “light.”) |
| Message-ID | <vgfnnd$ia23$1@solani.org> |
| In reply to | #14261 |
Hi, About Deep learning. Do we really need GPU and Torch libraries, aren't there other methods do arrive at the same. Do we really need to invest in nuclear power plant and shove money up a California based company as this "historical" photo suggests (could be fake): Some pics from when Jensen delivered the first @Nvidia AI system to @OpenAI https://twitter.com/elonmusk/status/1759295781196927438 What is the key to modern Knowledge Management, how does modern Knowledge Engineering work. Wasn't there a perfection of outsourcing and text annotation jobs. Somehow this can be accelerated by subtle social media methods, that allow a form of hidden crowd sourcing? And like 80% of the civil non military scientific community has absolutely no clue whats going on? Bye Mild Shock schrieb: > Hi, > > But I don't have a final solution. I am > still a seeker, a free seeker free from > legacy and orthodoxy, using free speech. > > Just like Luce: > > The official mascot for the Catholic > Church’s 2025 Jubilee Year is named > “Luce,” which is Italian for “light.” > https://www.catholicnewsagency.com/news/260129/meet-luce-the-vatican-s-cartoon-mascot-for-jubilee-2025 > > > LoL > > Bye > > Mild Shock schrieb: >> Hi, >> >> Whats also extremly cringe is the >> struggel that Scryer Prolog is experiencing. >> It has adopted a bloat of post Herbrand >> >> Prolog nonsense, due to Colmerauer, namely >> fucking cyclic term unification. Its >> crashing under its own bloath of nonsense, >> >> just go to GitHub and count the issues. >> Last time I looked it had like 200 issues, >> and now after a blink its already at 300 issues. >> >> 335 Open - Scryer Prolog - Issues >> https://github.com/mthom/scryer-prolog/issues >> >> WTF? >> >> Bye >> >> Mild Shock schrieb: >>> >>> SICStus Prolog is overrated. A lot of things >>> in Prolog logic programming are overrated, so >>> that it has lost it to a lot of turf over >>> >>> the last decade. But of course clinging to >>> an old code base, and reselling the same old >>> shit over and over again, is a very lucrative >>> >>> business compared to real innovation. >>> >>> Until OpenAI comes and does LLM. I am pretty >>> sure we will see some blocks stumbling. For >>> example the paper I was citing was traditional >>> >>> machine lerning, it was even not deep learning. >>> Mostlikely Prolog will be hit much more than >>> it is already hit with Python & Co. taking over >>> >>> a lot of data science turf. >>> >>> LoL >>> >>> Julio Di Egidio schrieb: >>>> On 06/11/2024 09:51, Mild Shock wrote: >>>> >>>>> What the fuck does this mean: >>>> >>>> The Nazi-retarded shithole is all but going to fix itself. >>>> >>>>> Why is change_arg/3 not common among Prolog systems. >>>> >>>> Only poisoned meatballs for the public. >>>> >>>> https://github.com/SWI-Prolog/swipl-devel/issues/1328 >>>> >>>> -Julio >>>> >>> >> >
[toc] | [prev] | [next] | [standalone]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2024-11-06 14:17 +0100 |
| Subject | Re: More Poisened Meat balls? [NIVIDIA & OpenAI] (Way: “Luce,” which is Italian for “light.”) |
| Message-ID | <vgfq8o$223f3$2@dont-email.me> |
| In reply to | #14262 |
On 06/11/2024 13:33, Mild Shock wrote: > About Deep learning. Do we really need > GPU and Torch libraries, aren't there > other methods do arrive at the same. Of course: statistical methods, vectors and matrices, non-linear functions... > Do we really need to invest in nuclear > power plant and shove money up a We have needed nuclear badly for decades, we are still destroying the planet for energy... and that is just one thing we are destroying. You just conflate everything with everything, which is brainwashing 101 for the new generations: compensation is (in) consumption. Have fun, -Julio
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-07 00:59 +0100 |
| Subject | Not all Red-Black Trees are Okasaki (Was: Request for comments, Novacore the sequel to ISO modules) |
| Message-ID | <vggvs7$j3jh$1@solani.org> |
| In reply to | #13684 |
Ok, it seems that SWI-Prolog implements
something else than Okasaki Red-Black Trees.
I tried to find worst cases:
/* Okasaki Red-Black Trees */
?- between(16,32,N), fuzzer(N,D), write(N-D),
write(' '), flush_output, fail; nl.
16-6 17-6 18-6 19-6 20-6 21-6 22-7 23-7 24-7 25-7
26-7 27-7 28-7 29-7 30-7 31-8 32-8
/* SWI-Prolog Red-Black Trees */
?- between(16,32,N), fuzzer(N,D), write(N-D),
write(' '), flush_output, fail; nl.
16-6 17-6 18-6 19-6 20-6 21-6 22-6 23-6 24-6 25-6
26-6 27-7 28-7 29-7 30-7 31-7 32-7
In the above the pairs indicate number of nodes
and worst depth of tree. SWI-Prolog has shorter
trees! For example depth 6 is found up to 26 elements,
whereas Okasaki already gives up after 21 elements.
Mild Shock schrieb:
> The new multilingual strings are also an exercise in
> Novacore. There were a few issues that needed novel
> Prolog solutions, to make a Novacore solution.
>
> One problem was I didn't want to use library(format)
> and format/3 to format multilingual strings when
> generating error messages. This addresses more
>
> the later multilingual strings processing than the
> multilingual strings store itself. So how resolve this
> paradox? Here is my take, a mini format/3 boostraped
>
> from the Dogelog Player specific atom_split/3:
>
> % sys_inter_polate(+Stream, +Atom, +List)
> sys_inter_polate(Stream, Template, Args) :-
> atom_split(Template, '~', [Head|Tail]),
> put_atom(Stream, Head),
> sys_zipper_output(Args, Tail, Stream).
>
> % sys_zipper_output(+List, +List, +Stream)
> sys_zipper_output([Arg|Args], [Head|Tail], Stream) :-
> writeq(Stream, Arg),
> put_atom(Stream, Head),
> sys_zipper_output(Args, Tail, Stream).
> sys_zipper_output([], [], _).
>
> It only understands format specifier '~', but is sufficient:
>
> /* German Text */
> strings('syntax_error.singleton_var', de, 'Alleinstehende Variable(n) ~, anonyme Variable(n) (_) benutzen.').
>
> /* English and Fallback Text */
> strings('syntax_error.singleton_var', '', 'Singleton variable(s) ~, use anonymous variable(s) (_).').
>
> LoL
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <bursejan@gmail.com> |
|---|---|
| Date | 2023-11-19 10:54 -0800 |
| Message-ID | <ff5d9b5c-dea5-4834-8213-abf174ef3ebbn@googlegroups.com> |
| In reply to | #13157 |
We are now exploring file systems with novacore. And here and then we have a couple of primitives and then do some bootstrapping. It currently lands in library(random) until we find a better place: % directory_member(+Atom, -Atom) directory_member(F, N) :- directory_files(F, L), member(N, L). % ensure_directory(+Atom) ensure_directory(F) :- file_exists(F), file_property(F, type(directory)), !. ensure_directory(F) :- make_directory(F). Guess what, finding semantic and support of directory_files/2, file_exists/1 and file_property/2 is already non trivial.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.prolog
csiph-web