Extended version of ESP32forth v 7.0.7.5

Post by Marc Petremann
Hello,
Check out my ESP32forth 7.0.7.5 extended version.
- SPI port command
- management of "STRING"s
- Improved DUMP
Link: https://esp32.arduino-forth.com/article/extendedESP32forth

Improved BETWEEN

: BETWEEN ( n1|u1 n2|u2 n3|u3 -- flag ) OVER - -ROT - U< 0= ;

none) (albert

2023-01-10 11:33:32 UTC

Improved BETWEEN
: BETWEEN ( n1|u1 n2|u2 n3|u3 -- flag ) OVER - -ROT - U< 0= ;

That is related to my post on comparision of times.
You will find that
MIN-INT MAX-INT whatever
don't leaves true most of the time, as you might expect.
The mixing of signed numbers and unsigned numbers has to be left
to special occasions, (things that wrap around as hands on a clock).

This is best
: BETWEEN ( n1 n2 n3 -- flag ) >R R@ < SWAP R> >= AND ;
Don't cater for unsigned numbers.

Use those only for masks or in the unlikely
case your memory extend beyond 0x7FFF,FFFF,FFFF,FFFF
and you have to compare negative and positive memory addresses.

Groetjes Albert

--
Don't praise the day before the evening. One swallow doesn't make
spring. You must not say "hey" before you have crossed the bridge.
Don't sell the hide of the bear until you shot it. Better one bird in
the hand than ten in the air. - the Wise from Antrim -

dxforth

2023-01-11 00:12:06 UTC

Improved BETWEEN
: BETWEEN ( n1|u1 n2|u2 n3|u3 -- flag ) OVER - -ROT - U< 0= ;

It's no BETWEEN I'm familiar with under that name. It tests:

n2 < n3 <= n1

corresponding to the stack diagram:

( hi lo n -- flag )

5 -5 0 between . -1 ok
5 -5 -5 between . 0 ok
5 -5 5 between . -1 ok

Zbig

2023-01-11 00:31:53 UTC

Post by dxforth
n2 < n3 <= n1
( hi lo n -- flag )
5 -5 0 between . -1 ok
5 -5 -5 between . 0 ok
5 -5 5 between . -1 ok

Looks rather good to me. If one looks at number line, zero indeed has its place between -5 and 5.

dxforth

2023-01-11 01:18:57 UTC

Post by dxforth
n2 < n3 <= n1
( hi lo n -- flag )
5 -5 0 between . -1 ok
5 -5 -5 between . 0 ok
5 -5 5 between . -1 ok

Looks rather good to me. If one looks at number line, zero indeed has its place between -5 and 5.

Historically definitions of BETWEEN have included both limits e.g. A-Z

Zbig

2023-01-11 01:39:14 UTC

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

Oh, so just there's a need to replace '<' by '<=' in Albert's definition.

dxforth

2023-01-11 02:46:37 UTC

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

Oh, so just there's a need to replace '<' by '<=' in Albert's definition.

Why use a definition that's longer and doesn't handle unsigned?

none) (albert

2023-01-11 09:53:21 UTC

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

Oh, so just there's a need to replace '<' by '<=' in Albert's definition.

Why use a definition that's longer and doesn't handle unsigned?

Because it is easier to understand.
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.

Groetjes Albert

dxforth

2023-01-11 10:10:52 UTC

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

Oh, so just there's a need to replace '<' by '<=' in Albert's definition.

Why use a definition that's longer and doesn't handle unsigned?

Because it is easier to understand.
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.

I'm too lazy to use the correct cpu instruction so I should shift to
a bigger cpu?

Zbig

2023-01-11 11:02:07 UTC

Post by none) (albert
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.

But even on that bigger processor unsigned can be used to handle even
larger numbers. Although personally I don't feel (at least at the moment)
any particular need to use unsigned on 64-bit — still maybe it can be useful
for specific purposes (some astronomical calculations etc.)?
Is it good idea to get rid of unsigned „just like that”, totally?

dxforth

2023-01-11 23:49:17 UTC

Post by none) (albert
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.

I'll take objectors seriously when they get rid of WITHIN.

dxforth

2023-01-13 11:30:58 UTC

Post by dxforth
...
I'll take objectors seriously when they get rid of WITHIN.

none) (albert

2023-01-13 12:32:29 UTC

Post by dxforth
...
I'll take objectors seriously when they get rid of WITHIN.

You call that "two for the price of one".
I call that "confusion, to the point of unusable".

Groetjes Albert

dxforth

2023-01-14 01:22:16 UTC

Post by dxforth
...
I'll take objectors seriously when they get rid of WITHIN.

You call that "two for the price of one".
I call that "confusion, to the point of unusable".

I make no apology for providing a full definition of what BETWEEN does. It's
what I would like to see were I a user.

none) (albert

2023-01-12 09:19:13 UTC

Post by none) (albert
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.

But even on that bigger processor unsigned can be used to handle even
larger numbers. Although personally I don't feel (at least at the moment)
any particular need to use unsigned on 64-bit â still maybe it can be useful
for specific purposes (some astronomical calculations etc.)?
Is it good idea to get rid of unsigned âjust like thatâ, totally?

The difference between 63 and 64 bit of precision is astronomically low,
if that is what you mean.

Groetjes Albert

Zbig

2023-01-12 10:24:53 UTC

Post by none) (albert
The difference between 63 and 64 bit of precision is astronomically low,
if that is what you mean.

It's actually still the same, as between 15 and
16 bit of precision: ~100% of the range.

none) (albert

2023-01-12 11:36:56 UTC

Post by none) (albert
The difference between 63 and 64 bit of precision is astronomically low,
if that is what you mean.

It's actually still the same, as between 15 and
16 bit of precision: ~100% of the range.

Precision is logaritmic. It was 0.03% to begin with,
now it is astronomically low.
I cannot be bother to calculate it.

Groetjes Albert

Zbig

2023-01-12 11:50:01 UTC

Post by none) (albert
Precision is logaritmic. It was 0.03% to begin with,
now it is astronomically low.
I cannot be bother to calculate it.

Indeed I confused precision with range.

You wrote: „we must exterminate the incessant use of unsigned”.
Actually why we have to do that? What makes us do it?

none) (albert

2023-01-13 12:59:11 UTC

Post by none) (albert
Precision is logaritmic. It was 0.03% to begin with,
now it is astronomically low.
I cannot be bother to calculate it.

Indeed I confused precision with range.
You wrote: âwe must exterminate the incessant use of unsignedâ.
Actually why we have to do that? What makes us do it?

I forgive Willem Ouwerkerk who is working with 16 bit embedded micro's.

Who is working on a 64 bit system, can use normal integers.
It is bad to have a definition like TYPE (adr u -- ).
Really? Print more that 100 gazillion characters in one go?
Make an implementation of TYPE portable:
: TYPE DUP 0< ABORT" Have you tried walking to China too, on foot?"
.... ;

Make a distinction between mask and integers.
shifting works on masks, inverting works on mask.
It has been pointed out that multiple precision is the one exception
that really need unsigned numbers.

Groetjes Albert

Zbig

2023-01-14 01:53:57 UTC

Post by none) (albert
Who is working on a 64 bit system, can use normal integers.
It is bad to have a definition like TYPE (adr u -- ).
Really? Print more that 100 gazillion characters in one go?
: TYPE DUP 0< ABORT" Have you tried walking to China too, on foot?"
.... ;

You mean printing „only” 50 gazillion characters in one go makes any
practical difference?

Post by none) (albert
Make a distinction between mask and integers.
shifting works on masks, inverting works on mask.
It has been pointed out that multiple precision is the one exception
that really need unsigned numbers.

In Forth that distinction is a matter of interpretation.

dxforth

2023-01-15 01:25:00 UTC

Forth-79/83 TYPE uses a signed count and prints nothing in the case of 0< .
Presumably this was to handle computed counts - rather than '+n should be
enough for anyone'.

Post by Zbig
You mean printing „only” 50 gazillion characters in one go makes any
practical difference?

In Forth that distinction is a matter of interpretation.

When I see forth code in which addresses are compared using signed operators
it raises a red flag.

none) (albert

2023-01-15 10:59:50 UTC

Forth-79/83 TYPE uses a signed count and prints nothing in the case of 0< .
Presumably this was to handle computed counts - rather than '+n should be
enough for anyone'.

You mean printing âonlyâ 50 gazillion characters in one go makes any
practical difference?

In Forth that distinction is a matter of interpretation.

When I see forth code in which addresses are compared using signed operators
it raises a red flag.

Me too. In the circumstance that I sit on a 16 bit Forth where the memory is
fully occupied and I'm using a largish arrays.
On all other cases I'll rather keep my red flags dry for if it really matters.

Groetjes Albert

dxforth

2023-01-15 12:37:26 UTC

Forth-79/83 TYPE uses a signed count and prints nothing in the case of 0< .
Presumably this was to handle computed counts - rather than '+n should be
enough for anyone'.

Post by Zbig
You mean printing „only” 50 gazillion characters in one go makes any
practical difference?

In Forth that distinction is a matter of interpretation.

When I see forth code in which addresses are compared using signed operators
it raises a red flag.

Unsigned numbers and operators didn't vanish when 32-bit systems arrived. All
other things being equal, it means there's a right operator to use and a wrong
operator.

Heinrich Hohl

2023-01-12 11:26:32 UTC

Post by none) (albert
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.
Groetjes Albert

Even in the 64 bit era, unsigned numbers are still required.

Unsigned numbers offer twice the range in case a sign bit is not required.
But this is not the only reason why we need them.

The other reason is math and algorithms. There are algorithms that only work
with unsigned numbers, e.g. pseudo random number generators. We will always
need unsigned multiplication and division for certain algorithms, no matter how
large the word size is.

Henry

none) (albert

2023-01-12 11:39:53 UTC

Post by Heinrich Hohl

Post by none) (albert
And because we must exterminate the incessant use of unsigned of
the 16 bit era. If you want more than 32 kbyte of memory switch to
a bigger processor.
Groetjes Albert

Even in the 64 bit era, unsigned numbers are still required.
Unsigned numbers offer twice the range in case a sign bit is not required.
But this is not the only reason why we need them.
The other reason is math and algorithms. There are algorithms that only work
with unsigned numbers, e.g. pseudo random number generators. We will always
need unsigned multiplication and division for certain algorithms, no matter how
large the word size is.

It is good to realize that most unsigned numbers are not numbers but bitmaps.
Only in a rare case, multiple precisions arithmetic, you need them.

Post by Heinrich Hohl
Henry

Groetjes Albert

Jach Feng

2023-01-11 03:01:15 UTC

dxforth 在 2023年1月11日星期三上午9:19:02 [UTC+8] 的信中寫道：

Post by dxforth
n2 < n3 <= n1
( hi lo n -- flag )
5 -5 0 between . -1 ok
5 -5 -5 between . 0 ok
5 -5 5 between . -1 ok

Looks rather good to me. If one looks at number line, zero indeed has its place between -5 and 5.

Historically definitions of BETWEEN have included both limits e.g. A-Z

It's a much reasonable decision of this historical definition of BETWEEN to avoid the following ridiculous result which makes laugh of other programming languages.

-5 5 5 between . 0 ok
5 -5 5 between . -1 ok

dxforth

2023-01-11 06:52:25 UTC

Post by Jach Feng
dxforth 在 2023年1月11日星期三上午9:19:02 [UTC+8] 的信中寫道：

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

It's a much reasonable decision of this historical definition of BETWEEN to avoid the following ridiculous result which makes laugh of other programming languages.
-5 5 5 between . 0 ok

Admittedly it isn't expected and where 1+ WITHIN would have been better.
I had BETWEEN in my kernel in addition to WITHIN but I may now reconsider
that. Thanks.

dxforth

2023-01-11 08:15:05 UTC

Post by Jach Feng
dxforth 在 2023年1月11日星期三上午9:19:02 [UTC+8] 的信中寫道：

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

It's a much reasonable decision of this historical definition of BETWEEN to avoid the following ridiculous result which makes laugh of other programming languages.
-5 5 5 between . 0 ok

Admittedly it isn't expected and where 1+ WITHIN would have been better.
I had BETWEEN in my kernel in addition to WITHIN but I may now reconsider
that. Thanks.

Ignore my response above. Assuming parameter order ( n lo hi ) -5 does
not lie within the range 5 to 5 and therefore returns false.

Post by Jach Feng
5 -5 5 between . -1 ok

That too is correct.

Jach Feng

2023-01-11 08:59:52 UTC

dxforth 在 2023年1月11日星期三下午4:15:08 [UTC+8] 的信中寫道：

Post by Jach Feng
dxforth 在 2023年1月11日星期三上午9:19:02 [UTC+8] 的信中寫道：

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

It's a much reasonable decision of this historical definition of BETWEEN to avoid the following ridiculous result which makes laugh of other programming languages.
-5 5 5 between . 0 ok

Admittedly it isn't expected and where 1+ WITHIN would have been better.
I had BETWEEN in my kernel in addition to WITHIN but I may now reconsider
that. Thanks.

Ignore my response above. Assuming parameter order ( n lo hi ) -5 does
not lie within the range 5 to 5 and therefore returns false.

Post by Jach Feng
5 -5 5 between . -1 ok

That too is correct.

Sure, they are both correct. But the problem is not the result, the problem is the definition of the BETWEEN.

dxforth

2023-01-11 10:00:39 UTC

Post by Jach Feng
dxforth 在 2023年1月11日星期三下午4:15:08 [UTC+8] 的信中寫道：

Post by Jach Feng
dxforth 在 2023年1月11日星期三上午9:19:02 [UTC+8] 的信中寫道：

Post by dxforth
Historically definitions of BETWEEN have included both limits e.g. A-Z

It's a much reasonable decision of this historical definition of BETWEEN to avoid the following ridiculous result which makes laugh of other programming languages.
-5 5 5 between . 0 ok

Admittedly it isn't expected and where 1+ WITHIN would have been better.
I had BETWEEN in my kernel in addition to WITHIN but I may now reconsider
that. Thanks.

Ignore my response above. Assuming parameter order ( n lo hi ) -5 does
not lie within the range 5 to 5 and therefore returns false.