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= ;
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
In article <tpjh0b$vlr$1@gioia.aioe.org>, dxforth <dxforth@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
Historically definitions of BETWEEN have included both limits e.g. A-Z
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.
On 11/01/2023 11:31 am, Zbig wrote: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.
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.Historically definitions of BETWEEN have included both limits e.g. A-Z
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年1月11日 星期三上午9:19:02 [UTC+8] 的信中寫道：
Historically definitions of BETWEEN have included both limits e.g. A-ZIt'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
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-ZIt'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.
5 -5 5 between . -1 ok
On 11/01/2023 5:52 pm, dxforth wrote:Sure, they are both correct. But the problem is not the result, the problem is the definition of the BETWEEN.
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.Ignore my response above. Assuming parameter order ( n lo hi ) -5 does
I had BETWEEN in my kernel in addition to WITHIN but I may now reconsider that. Thanks.
not lie within the range 5 to 5 and therefore returns false.
That too is correct.5 -5 5 between . -1 ok
In article <tpl7ue$vka$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 11/01/2023 12:39 pm, Zbig wrote:
Why use a definition that's longer and doesn't handle unsigned?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. >>
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.
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?
dxforth 在 2023年1月11日 星期三下午4:15:08 [UTC+8] 的信中寫道：
On 11/01/2023 5:52 pm, dxforth wrote:Sure, they are both correct. But the problem is not the result, the problem is the definition of the BETWEEN.
On 11/01/2023 2:01 pm, Jach Feng wrote:Ignore my response above. Assuming parameter order ( n lo hi ) -5 does
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.
not lie within the range 5 to 5 and therefore returns false.
That too is correct.5 -5 5 between . -1 ok
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.
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?
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.
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
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
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.
...
I'll take objectors seriously when they get rid of WITHIN.
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'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.
In article <tprfdj$3p7$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
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.
You call that "two for the price of one".
I call that "confusion, to the point of unusable".
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.
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.
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.
In article <tpvkld$1r7m$1@gioia.aioe.org>, dxforth <dxforth@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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 43:13:26 |
| Calls: | 6,709 |
| Calls today: | 2 |
| Files: | 12,243 |
| Messages: | 5,354,017 |