Extended version of ESP32forth v 7.0.7.5

[Marc Petremann]

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

[dxforth]

Improved BETWEEN

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

[none albert]

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]

On 10/01/2023 10:33 pm, albert wrote:
> In article <tpjh0b$vlr$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 10/01/2023 8:50 pm, Marc Petremann wrote:
>>> Hello,
>>> Check out my ESP32forth 7.0.7.5 extended version.
>>> This version includes:
>>> - 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= ;
>>
>
> 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.

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]

> 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

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

[dxforth]

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

[Zbig]

> 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]

On 11/01/2023 12:39 pm, Zbig wrote:
>> 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?

[Jach Feng]

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

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

[dxforth]

On 11/01/2023 2:01 pm, Jach Feng wrote:
> dxforth 在 2023年1月11日 星期三上午9:19:02 [UTC+8] 的信中寫道：

>> 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]

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

>> 5 -5 5 between . -1 ok

That too is correct.

[Jach Feng]

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

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

[none albert]

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.

[dxforth]

Can you be more specific?

[dxforth]

On 11/01/2023 8:53 pm, albert wrote:
> In article <tpl7ue$vka$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 11/01/2023 12:39 pm, Zbig wrote:
>>>> 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]

> 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]

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

[none albert]

In article <16764445-4c34-4643...@googlegroups.com>,

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

[Zbig]

> 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.

[Heinrich Hohl]

On Wednesday, January 11, 2023 at 10:53:27 AM UTC+1, none albert wrote:
> 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]

In article <8fc349ed-3924-4cb5...@googlegroups.com>,

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

[none albert]

In article <4a429d24-89c6-4489...@googlegroups.com>,

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.

>
>Henry

[Zbig]

> 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?

[dxforth]

On 12/01/2023 10:49 am, dxforth wrote:
> ...

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

Speaking of which ...

WITHIN may be used to create BETWEEN. The temptation is to write:

: BETWEEN 1+ WITHIN ;

and some implementations do that e.g. Win32Forth. But the proper way is:

: BETWEEN 1+ SWAP WITHIN 0= ;

which has the same characteristics as the implementation I posted earlier.

The formal definition is:

BETWEEN

( n1|u1 n2|u2 n3|u3 -- flag )

Perform a comparison of a test value n1|u1 with a lower limit n2|u2 and an upper
limit n3|u3, returning true if either (n2|u2 <= n3|u3 and (n2|u2 <= n1|u1 and
n1|u1 <= n3|u3)) or (n2|u2 > n3|u3 and (n2|u2 < n1|u1 or n1|u1 < n3|u3)) is true,
returning false otherwise. An ambiguous condition exists if n1|u1, n2|u2, and
n3|u3 are not all the same type.

The rationale follows that of A.6.2.2440 WITHIN with the difference the limits are
inclusive. If n2|u2 and n3|u3 are reversed, then the limits become exclusive.

If Forth is about getting more bang for your buck, then these two functions have that.

[none albert]

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

[none albert]

In article <c1877a10-dc20-4070...@googlegroups.com>,

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.

[dxforth]

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.

[Zbig]

> 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?"
> .... ;

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

> 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]

On 14/01/2023 12:53 pm, Zbig wrote:
>> 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?"
>> .... ;

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?
>
>> 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.

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

[none albert]

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.

[dxforth]

On 15/01/2023 9:59 pm, albert wrote:
> In article <tpvkld$1r7m$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 14/01/2023 12:53 pm, Zbig wrote:
>>>> 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?"
>>>> .... ;
>>
>> 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?
>>>
>>>> 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.
>>
>> 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.

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.