Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #41328 > unrolled thread

Numeric limits in 8th

Back to article view | Back to comp.lang.forth

Contents

  Numeric limits in 8th Ron Aaron <rambamist@gmail.com> - 2015-08-16 07:35 +0300
    Re: Numeric limits in 8th Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-08-17 07:54 +0100
      Re: Numeric limits in 8th Ron Aaron <rambamist@gmail.com> - 2015-08-17 10:41 +0300
        Re: Numeric limits in 8th Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-08-21 22:59 +0100

#41328 — Numeric limits in 8th

One of the design decisions for "8th" was that numbers should "just 
work".  That is, the user should not usually have to be concerned 
whether to use an integer or float.

Similarly, the user should not have to be concerned that an operation 
might "overflow".  Rather, even calculating the US external debt in mils 
should be handled transparently.

This goal is achieved by promoting numbers from smaller to larger 
representations behind the scenes as needed.  Thus, the user need not be 
concerned that dividing by 3 leaves a floating-point value -- all such 
entities are "just numbers", in general.

But for efficiency's sake, "big integers" are limited to a very large 
but not infinite size.  So we added a caveat to our (upcoming) manual:

http://8th-dev.com/forum/index.php/topic,483.0.html

Note that all numbers take up just one 'cell' on the stack.

[toc] | [next] | [standalone]

#41349

On Sun, 16 Aug 2015 07:35:53 +0300
Ron Aaron <rambamist@gmail.com> wrote:

> One of the design decisions for "8th" was that numbers should
> "just work".  That is, the user should not usually have to be
> concerned whether to use an integer or float.
> 
> Similarly, the user should not have to be concerned that an
> operation might "overflow".  Rather, even calculating the US
> external debt in mils should be handled transparently.
> 
> This goal is achieved by promoting numbers from smaller to
> larger representations behind the scenes as needed.  Thus, the
> user need not be concerned that dividing by 3 leaves a
> floating-point value -- all such entities are "just numbers",
> in general.
> 
> But for efficiency's sake, "big integers" are limited to a
> very large but not infinite size.  So we added a caveat to our
> (upcoming) manual:
> 
> http://8th-dev.com/forum/index.php/topic,483.0.html
> 
> Note that all numbers take up just one 'cell' on the stack.

As with Ilya's Forth this provides significant user benefit
in usage simplification. 

For smaller systems it might be good to use a variable length
representation of stack items. This would reduce the stack
memory size, and required memory bandwidth, also remove the upper
limit on data item size. 

It does require caching for the items near the stack top
which need to be accessed or re-ordered, but these may be few.

The Python engine only needs access to the top two or three
stack items, how many does 8th require?

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[toc] | [prev] | [next] | [standalone]

#41350

On 08/17/2015 09:54, Jan Coombs <Jan-54 wrote:
> As with Ilya's Forth this provides significant user benefit
> in usage simplification.

Hello, Jan -

Yes, I think so.

> For smaller systems it might be good to use a variable length
> representation of stack items. This would reduce the stack
> memory size, and required memory bandwidth, also remove the upper
> limit on data item size.

I think using variable-sized items on the stack would greatly complicate 
matters, and make the code bigger ultimately.  As it stands, each stack 
location contains exactly one-item, and no item requires more than one 
stack location.

The backing representation of the item - that is, what is pointed to by 
the stack item - can be most anything.  Of course there are advantages 
to keeping that small as well, though that's not always possible.

"Smaller systems" is a bit of an issue, as that's not within the design 
parameters of 8th.  We are venturing into the embedded arena, but only 
for larger systems (Raspberry Pi, for example, will be released very soon).


> It does require caching for the items near the stack top
> which need to be accessed or re-ordered, but these may be few.
>
> The Python engine only needs access to the top two or three
> stack items, how many does 8th require?

Generally not more than two.  The default stack is 2000 deep, but that 
can be controlled by an option on the command-line.

[toc] | [prev] | [next] | [standalone]

#41448

On Mon, 17 Aug 2015 10:41:26 +0300
Ron Aaron <rambamist@gmail.com> wrote:

> On 08/17/2015 09:54, Jan Coombs <Jan-54 wrote:
> > As with Ilya's Forth this provides significant user benefit
> > in usage simplification.
>     [...]
> > For smaller systems it might be good to use a variable length
> > representation of stack items. This would reduce the stack
> > memory size, and required memory bandwidth, also remove the
> > upper limit on data item size.
> 
> I think using variable-sized items on the stack would greatly
> complicate matters, and make the code bigger ultimately.  As
> it stands, each stack location contains exactly one-item, and
> no item requires more than one stack location.
> 
> The backing representation of the item - that is, what is
> pointed to by the stack item - can be most anything.  Of
> course there are advantages to keeping that small as well,
> though that's not always possible.

When complexity appears somewhere, it may have disappeared
elsewhere: 

In python the immediate backing representation for a stack item
is a small object, containing just a reference count, and a
pointer to the remainder of the backing representation. 

When DUP or DROP create or destroy stack items, then the python
engine must adjust the reference count. 8th must have some
equivalent complexity for garbage collection?

If a variable size item is stored entirely in the stack then
this creates additional complexity in stack management, but
removes the complexity of garbage collection. 

> "Smaller systems" is a bit of an issue, as that's not within
> the design parameters of 8th.  We are venturing into the
> embedded arena, but only for larger systems (Raspberry Pi, for
> example, will be released very soon). 

Understood, I was stretching my mind, and did not intend to bend
your practicality.  I hope that your well-stocked toolbox gains
many deserving users.
 
> > The Python engine only needs access to the top two or three
> > stack items, how many does 8th require?
> 
> Generally not more than two.  The default stack is 2000 deep,
> but that can be controlled by an option on the command-line.

Thanks, that's interesting, and refreshingly different from the
many languages which need to index the stack for parameter
passing. 

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web