On Saturday, February 18, 2023 at 5:13:05 PM UTC+1, Marcel Hendrix wrote:
> : XINVERT5 PARAMS| a b c d e | e d c b a ;
> : test 1 2 3 4 5 xinvert5 - - - * . ;

Yeah, if you don't mind using your stack as an array, this is quite a viable solution.
As a matter of fact - it would solve just about ANY issues one had with stack acrobatics.
Can't say I have never considered it. Can't say it wouldn't solve any issues. But
it doesn't quite feel like Forth.

And that's all I'm gonna say about THAT ;-)

Hans Bezemer

On Saturday, February 18, 2023 at 5:24:39 PM UTC+1, Hans Bezemer wrote:
> On Saturday, February 18, 2023 at 5:13:05 PM UTC+1, Marcel Hendrix wrote:
> > : XINVERT5 PARAMS| a b c d e | e d c b a ;
> > : test 1 2 3 4 5 xinvert5 - - - * . ;
>
> Yeah, if you don't mind using your stack as an array, this is quite a viable solution.
> As a matter of fact - it would solve just about ANY issues one had with stack acrobatics.
> Can't say I have never considered it. Can't say it wouldn't solve any issues. But
> it doesn't quite feel like Forth.
>
> And that's all I'm gonna say about THAT ;-)
>
> Hans Bezemer

When XINVERT5 or 3DUP are actually compiled in an application, the stack is not
used at all here, as evidenced by the decompilations (actually it depends on how
these words are called).

Are you saying that ">r over over r@ rot rot r>" does NOT directly or eventually
lead to stack manipulation in the way you do it?

-marcel

Marcel Hendrix schrieb am Samstag, 18. Februar 2023 um 17:13:05 UTC+1:
> : XINVERT5 PARAMS| a b c d e | e d c b a ;
> : test 1 2 3 4 5 xinvert5 - - - * . ;
>
> FORTH> see test
> Flags: ANSI
> $01348540 : test
> $0134854A push #10 b#
> $0134854C jmp .+10 ( $0124A102 ) offset NEAR
> $01348551 ;
> FORTH> test 10 ok
>

Nice example of compile-time evaluation!

Being curious, what happens with:

: test0 2 3 4 5 xinvert5 - - - * . :
1 test0

On Saturday, February 18, 2023 at 7:01:11 PM UTC+1, minf...@arcor.de wrote:
> Marcel Hendrix schrieb am Samstag, 18. Februar 2023 um 17:13:05 UTC+1:
> > : XINVERT5 PARAMS| a b c d e | e d c b a ;
> > : test 1 2 3 4 5 xinvert5 - - - * . ;
> >
> > FORTH> see test
> > Flags: ANSI
> > $01348540 : test
> > $0134854A push #10 b#
> > $0134854C jmp .+10 ( $0124A102 ) offset NEAR
> > $01348551 ;
> > FORTH> test 10 ok
> >
>
> Nice example of compile-time evaluation!
>
> Being curious, what happens with:
>
> : test0 2 3 4 5 xinvert5 - - - * . :
> 1 test0
FORTH> : test0 2 3 4 5 xinvert5 - - - * . :
<3>[FORTH>] 1 test0
Error -13
1 test0
------^
test0 ?

Or did you mean:

FORTH> : test0 2 3 4 5 xinvert5 - - - * . ; ok
FORTH> 1 test0 10 ok
FORTH> .s
Data: ---
System: ---
Float: --- ok
FORTH> see test0
Flags: ANSI
$01340980 : test0
$0134098A pop rbx
$0134098B sub rbx, 2 b#
$0134098F neg rbx
$01340992 sub rbx, 3 b#
$01340996 neg rbx
$01340999 sub rbx, 4 b#
$0134099D neg rbx
$013409A0 lea rbx, [rbx rbx*4] qword
$013409A4 push rbx
$013409A5 jmp .+10 ( $0124A102 ) offset NEAR
$013409AA ;

It only does a single pass :--)

You would normally do it like this:

FORTH> forget test0 ok
FORTH> : test0 2 3 4 5 xinvert5 - - - * ; ok
FORTH> : test2 1 test0 . ; see test2
Flags: ANSI
$01340A00 : test2
$01340A0A push #10 b#
$01340A0C jmp .+10 ( $0124A102 ) offset NEAR
$01340A11 ;

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>Are you saying that ">r over over r@ rot rot r>" does NOT directly or eventually
>lead to stack manipulation in the way you do it?

Linux/FORTH (C) 2005 Peter Fälth Version 1.6-982-823 Compiled on 2017-12-03

: foo >r over over r@ rot rot r> ; : bar {: a b c :} a b c a b c ;
see foo see bar
mov eax , [ebp] mov eax , [ebp]
mov [ebp-Ch] , eax mov [ebp-Ch] , eax
mov eax , [ebp+4h] mov eax , [ebp+4h]
mov [ebp-8h] , eax mov [ebp-8h] , eax
mov [ebp-4h] , ebx mov [ebp-4h] , ebx
lea ebp , [ebp-Ch] lea ebp , [ebp-Ch]
ret near ret near

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

"minf...@arcor.de" <minforth@arcor.de> writes:
>Software-wise, backtracking requires keeping complete search states in memory for each branch.

Only for those on the path from the root to the current node of the
search tree.

>Those states comprise the (so-far pruned) domains of each variable, those are big objects.

It depends. For small domains like in SEND+MORE=MONEY and your
Magic Hexagon example, they are not big.

>There is a rather compact Python constraint solver:
>https://files.pythonhosted.org/packages/37/8b/5f1bc2734ca611943e1d6733ee244238679f6410a10cd45ede55a61a8402/python-constraint-1.4.0.tar.bz2
>Sources are in subfolder /constraint/__init.py__

More than 1500 lines. Compact?

>Standard Forth would have to be tooled up too much to hope to come close to it.

I expect to need much less than 1500 lines for a semi-general approach
that you just need to feed the constraints, domains, and a labeler to
solve stuff like SEND+MORE=MONEY, the Magic Hexagon, and Sudokus. Of
course, if you want more involved solvers, you can invest a lot more
lines of code.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

On Saturday, February 18, 2023 at 7:37:08 PM UTC+1, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> >Are you saying that ">r over over r@ rot rot r>" does NOT directly or eventually
> >lead to stack manipulation in the way you do it?

Because iForth re-analyzes the stack at will, this is difficult to benchmark.
For foo and bar, SEE <name> just sees what they do when interpreted, not
when they are compiled.

FORTH> : foo >r over over r@ rot rot r> ; : bar params| a b c | a b c a b c ; ok
FORTH> see foo see bar
Flags: TOKENIZE, ANSI
: foo >R OVER OVER R@ ROT ROT R> ;
Flags: TOKENIZE, ANSI
: bar (3)PARAMS %a %b %c %a %b %c ; ok
FORTH> ' foo idis
$0133DC80 : foo
$0133DC8A pop rbx
$0133DC8B pop rdi
$0133DC8C mov rax, [rsp] qword
$0133DC90 push rdi
$0133DC91 push rbx
$0133DC92 push rax
$0133DC93 push rdi
$0133DC94 push rbx
$0133DC95 ;
FORTH> ' bar idis
$01340500 : bar
$0134050A pop rbx
$0134050B pop rdi
$0134050C mov rax, [rsp] qword
$01340510 push rdi
$01340511 push rbx
$01340512 push rax
$01340513 push rdi
$01340514 push rbx
$01340515 ;
FORTH> : test 1 2 3 foo bar ; ok
FORTH> see test
Flags: TOKENIZE, ANSI
: test 1 2 3 [trashed] [trashed] ; ok
FORTH> ' test idis
$01340580 : test
$0134058A push 1 b#
$0134058C push 2 b#
$0134058E push 3 b#
$01340590 push 1 b#
$01340592 push 2 b#
$01340594 push 3 b#
$01340596 push 1 b#
$01340598 push 2 b#
$0134059A push 3 b#
$0134059C ;

-marcel

Anton Ertl schrieb am Samstag, 18. Februar 2023 um 19:51:55 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >There is a rather compact Python constraint solver:
> >https://files.pythonhosted.org/packages/37/8b/5f1bc2734ca611943e1d6733ee244238679f6410a10cd45ede55a61a8402/python-constraint-1.4.0.tar.bz2
> >Sources are in subfolder /constraint/__init.py__
>
> More than 1500 lines. Compact?

Take away the comments and it becomes more digestible.

> >Standard Forth would have to be tooled up too much to hope to come close to it.
>
> I expect to need much less than 1500 lines for a semi-general approach
> that you just need to feed the constraints, domains, and a labeler to
> solve stuff like SEND+MORE=MONEY, the Magic Hexagon, and Sudokus. Of
> course, if you want more involved solvers, you can invest a lot more
> lines of code.

I like your optimism. ;-)

On 18/02/2023 11:51 am, dxforth wrote:
> On 18/02/2023 12:36 am, minf...@arcor.de wrote:
>>
>> Here's with non-recursive permutation algorithm. Quick timing showed no speed
>> increase significant for practical purposes. Only benefit would be less 'stress' on the
>> return stack.
>
> Haven't measured it but appears to be less of an issue than the time taken
> to generate the permutations which rises factorially.  The latter is likely
> to get you first.
>

Some figures for recursive version. For 10 items it used 27 cells of return
stack and 12 cells for 5 items. My DO LOOP has an overhead of 2 cells of
return stack.

On Friday, February 17, 2023 at 6:29:07 PM UTC+1, Hans Bezemer wrote:
> On Friday, February 17, 2023 at 6:05:51 PM UTC+1, Marcel Hendrix wrote:
> > On Friday, February 17, 2023 at 2:36:38 PM UTC+1, minf...@arcor.de wrote:
> > > minf...@arcor.de schrieb am Mittwoch, 15. Februar 2023 um 10:16:33 UTC+1:
[..]
> "Me> Assume every character is actually a figure, which calculation is
> made here: SEND+MORE=MONEY"
>
> ChatGPT> In the SEND+MORE=MONEY puzzle, the goal is to assign each letter a
> digit from 0 to 9 in such a way that the resulting mathematical equation is correct.
> Each letter represents a distinct digit, and the leftmost digit in any number cannot
> be 0.
[..]
Note that chatGPT's repetition of the description is much more precise than the original.
It correctly identified that "figure" is probably meant to be "number" or "digit in base 10".
It figured out that "every character is..." probably excludes '+' and '=', and that although
characters ("every") appear multiple times, this does not mean they represent different
digits. That is an impressive feat of understanding sloppy text input -- without knowing
the background of the typist(*), the chance of getting this right is almost zero.

However, the most import part of the input is clearly "SEND+MORE=MONEY", and
chatGPT has been trained what that is, or can find it somewhere (just like a human
being would look it up with his Google glasses). This implies it also can find
answers to this puzzle, and can regurgitate or rewrite the most suitable (in a
technical sense) one. A more challenging question would be to create a puzzle
with a different trigger phrase, like "zend-meer=pecunia". I suspect it will find
the connection to the original, but it is now forced to write its own program
(although it probably just tries randomly, depending on its computing resources).

-marcel

*) I guess it does know a lot about the questioner, based on e-mail address
and Google history.

On Sunday, February 19, 2023 at 11:32:50 AM UTC+1, Marcel Hendrix wrote:
> However, the most import part of the input is clearly "SEND+MORE=MONEY", and
> chatGPT has been trained what that is, or can find it somewhere (just like a human
> being would look it up with his Google glasses). This implies it also can find
> answers to this puzzle, and can regurgitate or rewrite the most suitable (in a
> technical sense) one. A more challenging question would be to create a puzzle
> with a different trigger phrase, like "zend-meer=pecunia". I suspect it will find
> the connection to the original, but it is now forced to write its own program
> (although it probably just tries randomly, depending on its computing resources).

I'm way ahead of you (GPT responses abridged):

Me> Now solve for this one: TILES+PUZZLES=PICTURE
GPT> And the sum TILES + PUZZLES = PICTURE can be written as: 97546 + 5045021 = 5142567
Me> That's incorrect. Both TILES and PUZZLES end with an "S" - yet the numbers are different in the addition. Try again.
GPT> This works! Therefore, the solution is TILES=19357, PUZZLES=73315, and PICTURE=926722.
Me> Wrong again. Both TILES and PUZZLES end in an "S". Yet the numbers of the addition are different.
GPT> Therefore, TILES + PUZZLES = PICTURE is true when TILES is 95831 and PUZZLES is 762215.
Me> What about 91542+3077542=3169084?
GPT> I'm sorry, but 91542+3077542 does not equal 3169084. The sum of those two numbers is actually 3169084.
Me> Really? Add 91542+3077542 and compare it to 3169084.
GPT> I apologize, you are correct, my previous response was in error. The sum of 91542 and 3077542 is 3169084, but this is not a valid solution to the TILES + PUZZLES = PICTURE puzzle, as you pointed out. I'm sorry for any confusion I may have caused. I will try again to find a valid solution to TILES + PUZZLES = PICTURE.

And then I gave up :(

Hans Bezemer

On Saturday, February 18, 2023 at 10:09:19 PM UTC+1, minf...@arcor.de wrote:
> > More than 1500 lines. Compact?
> Take away the comments and it becomes more digestible.
To become "digestible" you've got to scrap a darn lot of lines.

To give you an idea:
Preprocessor, 495 lines, 440 SLOC
BASIC interpreter, 1055 lines, 929 SLOC

Hans Bezemer

On Sunday, February 19, 2023 at 2:40:56 PM UTC+1, Hans Bezemer wrote:
> On Sunday, February 19, 2023 at 11:32:50 AM UTC+1, Marcel Hendrix wrote:
[..]
> I'm way ahead of you (GPT responses abridged)
>
> Me> Now solve for this one: TILES+PUZZLES=PICTURE
> GPT> And the sum TILES + PUZZLES = PICTURE can be written as: 97546 + 5045021 = 5142567
> Me> That's incorrect. Both TILES and PUZZLES end with an "S" - yet the numbers
> are different in the addition. Try again.

This matches with what I tried before. Also, if you insist your own (wrong) answer
is correct, it will back down after a single attempt to point out it is right. That is, of
course, a useless strategy.

What I don't understand is why it gives wrong answers at all. It may be a time-out
when randomly trying to find an answer, but why would it pretend its best result at
that point is correct? If you just ask for another solution it eventually finds a
correct one.

Of course, we are not able to understand the machinations of a superior intelligence.

-marcel

On Sunday, February 19, 2023 at 3:01:19 PM UTC+1, Marcel Hendrix wrote:
> This matches with what I tried before. Also, if you insist your own (wrong) answer
> is correct, it will back down after a single attempt to point out it is right. That is, of
> course, a useless strategy.
Completely true! Although I haven't been so devious to persist on wrong answers.
I'm essentially a nice guy :)
> Of course, we are not able to understand the machinations of a superior intelligence.
I don't get the impression I'm talking to a person - even when it sometimes
baffles me with its responses. For instance, I feed it a random program and it really
and consistently nails what the darn thing is supposed to do. It may be my programming
style, but still..

But it's just not like a real human would behave. So much for the Turing test..

Hans Bezemer

On Sunday, February 19, 2023 at 9:22:24 AM UTC-5, Hans Bezemer wrote:

> But it's just not like a real human would behave. So much for the Turing test..

That's an interesting insight Hans.
The future of AI may resemble aviation in that way.
Clearly our aircraft are not birds, yet they can fly.
So maybe we will always observe these things as aliens.

Anton Ertl schrieb am Samstag, 18. Februar 2023 um 19:51:55 UTC+1:
> I expect to need much less than 1500 lines for a semi-general approach
> that you just need to feed the constraints, domains, and a labeler to
> solve stuff like SEND+MORE=MONEY, the Magic Hexagon, and Sudokus.

I guess that you know Markus Triska. So you might really have some ideas
of how to do labeling in Forth?

BProlog program to solve the Hexagon (apart from labeling everything else
is straightforward):

go :- LD = [A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S],
domain(LD,1,19),
all_distinct(LD),

% sums of rows and diagonals:
A + B + C #= 38,
D + E + F + G #= 38,
H + I + J + K + L #= 38,
M + N + O + P #= 38,
Q + R + S #= 38,
A + D + H #= 38,
B + E + I + M #= 38,
C + F + J + N + Q #= 38,
G + K + O + R #= 38,
L + P + S #= 38,
C + G + L #= 38,
B + F + K + P #= 38,
A + E + J + O + S #= 38,
D + I + N + R #= 38,
H + M + Q #= 38,
% no rotations:
A #< C, A #< H, A #< L, A #< Q, A #< S, C #< H,

labeling([ff], LD),

writeln(LD),
nl.

"minf...@arcor.de" <minforth@arcor.de> writes:
>I guess that you know Markus Triska.

Yes.

>So you might really have some ideas
>of how to do labeling in Forth?

Not from him. I did my last work in the field of CLP in 1993, several
years before Markus Triska appeared on the scene. I learned from

@book(vanhentenryck89,
Author = "Van Hentenryck, Pascal",
Title = "{Constraint Satisfaction in Logic Programming}",
Series = "{Logic Programming Series}",
Year = "1989",
Publisher= "MIT Press",
Address = "Cambridge, Massachusetts"
)

and from Thomas Graf who worked with Van Hentenryck and others on the
early CLP language CHIP
<https://en.wikipedia.org/wiki/CHIP_(programming_language)> at ECRC.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

Anton Ertl schrieb am Dienstag, 21. Februar 2023 um 18:46:45 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >I guess that you know Markus Triska.
> Yes.
> >So you might really have some ideas
> >of how to do labeling in Forth?
> Not from him. I did my last work in the field of CLP in 1993, several
> years before Markus Triska appeared on the scene. I learned from
>
> @book(vanhentenryck89,
> Author = "Van Hentenryck, Pascal",
> Title = "{Constraint Satisfaction in Logic Programming}",
> Series = "{Logic Programming Series}",
> Year = "1989",
> Publisher= "MIT Press",
> Address = "Cambridge, Massachusetts"
> )

At that time I got hooked by Turbo Prolog and wrote longish applications
in it, until DOS memory limitations clanked me out. :-(
It's "successor" Visual Prolog never had that appeal and is/was way too fat.

> and from Thomas Graf who worked with Van Hentenryck and others on the
> early CLP language CHIP
> <https://en.wikipedia.org/wiki/CHIP_(programming_language)> at ECRC.
> - anton

CLP DSLs have come a long way since then. Today MiniZinc seems to get
the most attention:
https://www.minizinc.org