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

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

Fast multi byte read and write words

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

Contents

  Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-11-26 10:47 -0800
    Re: Fast multi byte read and write words Paul Rubin <no.email@nospam.invalid> - 2015-11-26 11:50 -0800
      Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-11-26 11:58 -0800
        Re: Fast multi byte read and write words Paul Rubin <no.email@nospam.invalid> - 2015-11-26 12:42 -0800
          Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-11-26 12:54 -0800
          Re: Fast multi byte read and write words Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 18:32 +0100
            Re: Fast multi byte read and write words Paul Rubin <no.email@nospam.invalid> - 2015-11-27 10:23 -0800
              Re: Fast multi byte read and write words Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 23:05 +0100
                Re: Fast multi byte read and write words Paul Rubin <no.email@nospam.invalid> - 2015-11-27 14:24 -0800
                Re: Fast multi byte read and write words Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-28 12:02 +0000
      Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-12-22 23:58 -0800
        Re: Fast multi byte read and write words humptydumpty <ouatubi@gmail.com> - 2015-12-23 00:14 -0800
          Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-12-23 00:49 -0800
    Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-11-28 10:44 -0800
      Re: Fast multi byte read and write words Coos Haak <chforth@hccnet.nl> - 2015-11-28 22:15 +0100
        Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-11-28 14:18 -0800
          Re: Fast multi byte read and write words Coos Haak <chforth@hccnet.nl> - 2015-11-29 00:04 +0100
    Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-11-29 02:18 -0800
      Re: Fast multi byte read and write words lehs <skydda.barnen@gmail.com> - 2015-11-29 07:50 -0800

#43838 — Fast multi byte read and write words

I working with a blog about Forth and math where I try to build up an environment for computational mathematics; first for one cell numbers and then for multiple cell numbers. The idea is to use Forth for experimental mathematics but a lot of experiments is only realistic for cell numbers, mostly because of speed.

I need to implement functions that gives the n-th prime number and that gives the number of primes smaller or equal than a given number. The fastest implementation would be precalculated tables, but the need of memory force me to limit those arrays.

The prime counting function π(x), equal to the number of primes ≤ x, need 1643280 bytes to cover all 16 bit output, if the table contains 16 bit numbers. In a 64 bit system using 64 bit numbers the need of memory would be four times as much. And for the function that gives the n-th prime number I would consider using 3 byte numbers, that would gives all primes up to the prime 16777213.

Of course it is possible to create words as

cs@ ( ad i -- n )
cs! ( n ad i -- )

that read i bytes at ad and put the number at the stack and conversly write tos using i bytes at ad.

But how to do that efficient? When neither w@, w!, sp0 nor sp@ are Forth standard?

http://forthmath.blogspot.se/p/single-cell-computational-arithmetic.html

[toc] | [next] | [standalone]

#43840

lehs <skydda.barnen@gmail.com> writes:
> The prime counting function π(x), equal to the number of primes ≤ x,
> need 1643280 bytes to cover all 16 bit output,

That's a terrible way to do it though.

https://en.wikipedia.org/wiki/Prime-counting_function#Algorithms_for_evaluating_.CF.80.28x.29

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

#43841

Den torsdag 26 november 2015 kl. 20:50:33 UTC+1 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > The prime counting function π(x), equal to the number of primes ≤ x,
> > need 1643280 bytes to cover all 16 bit output,
> 
> That's a terrible way to do it though.
> 
> https://en.wikipedia.org/wiki/Prime-counting_function#Algorithms_for_evaluating_.CF.80.28x.29

Can you be more specific? I need exact and fast functions and don't mind borrowing some memory from the windows "services".

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

#43843

lehs <skydda.barnen@gmail.com> writes:
> Can you be more specific? I need exact and fast functions and don't
> mind borrowing some memory from the windows "services".

I mean using good algorithms, you can compute pi(x) very quickly even
for quite large x.  I remember trying pi(1 billion) with Mathematica on
a PC many years ago and being surprised to get the answer right away.  I
just put "number of primes less than 100 billion" into Wolfram Alpha
online and got back 4118054813 in a few seconds, most of which was
probably network stuff, English parsing, etc.  But it won't do 1 trillion.

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

#43844

Den torsdag 26 november 2015 kl. 21:42:05 UTC+1 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > Can you be more specific? I need exact and fast functions and don't
> > mind borrowing some memory from the windows "services".
> 
> I mean using good algorithms, you can compute pi(x) very quickly even
> for quite large x.  I remember trying pi(1 billion) with Mathematica on
> a PC many years ago and being surprised to get the answer right away.  I
> just put "number of primes less than 100 billion" into Wolfram Alpha
> online and got back 4118054813 in a few seconds, most of which was
> probably network stuff, English parsing, etc.  But it won't do 1 trillion.

Yes I will try to use some algorithms for larger numbers, but it´s different between getting the answer right away and getting it in some microsecond.

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

#43873

Paul Rubin wrote:

> lehs <skydda.barnen@gmail.com> writes:
>> Can you be more specific? I need exact and fast functions and don't
>> mind borrowing some memory from the windows "services".
> 
> I mean using good algorithms, you can compute pi(x) very quickly even
> for quite large x.  I remember trying pi(1 billion) with Mathematica on
> a PC many years ago and being surprised to get the answer right away.  I
> just put "number of primes less than 100 billion" into Wolfram Alpha
> online and got back 4118054813 in a few seconds, most of which was
> probably network stuff, English parsing, etc.  But it won't do 1 trillion.

Probably a precomputed answer.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43877

Bernd Paysan <bernd.paysan@gmx.de> writes:
> Probably a precomputed answer.

No you can ask for pi(x) for arbitrary x in that range, and get the
answer pretty quick.  The Wikipedia page gives algorithms that should be
able to do it.

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

#43885

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Probably a precomputed answer.
> 
> No you can ask for pi(x) for arbitrary x in that range, and get the
> answer pretty quick.  The Wikipedia page gives algorithms that should be
> able to do it.

I was referring to the primes up to a high number, where another, higher 
limit didn't work.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43886

Bernd Paysan <bernd.paysan@gmx.de> writes:
> I was referring to the primes up to a high number, where another, higher 
> limit didn't work.

Yes, I think they set a limit at the point where even the fancy
algorithm would take too long for the computing resources they were
willing to put into a web query.

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

#43899

Bernd Paysan <bernd.paysan@gmx.de> writes:

>Paul Rubin wrote:

>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> Probably a precomputed answer.
>>
>> No you can ask for pi(x) for arbitrary x in that range, and get the
>> answer pretty quick.  The Wikipedia page gives algorithms that should be
>> able to do it.

>I was referring to the primes up to a high number, where another, higher
>limit didn't work.

I once published yaycp (yet another prime counting program) here.
It runs 300 mS on interpreted ciforth for 1,000,000,000.
So pretty much instantaneous results for that range are certainly
possible.
>--
>Bernd Paysan

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#44315

Den torsdag 26 november 2015 kl. 20:50:33 UTC+1 skrev Paul Rubin:
> lehs <skydda.barnen@gmail.com> writes:
> > The prime counting function π(x), equal to the number of primes ≤ x,
> > need 1643280 bytes to cover all 16 bit output,
> 
> That's a terrible way to do it though.
> 
> https://en.wikipedia.org/wiki/Prime-counting_function#Algorithms_for_evaluating_.CF.80.28x.29

I just can't understand how the algorithm from Wikipedia could be fast. Just to calculate phi very inefficient even for small "n":

\ phi(m,n)=phi(m,n-1)-phi(m/Pn,n-1)
: phi ( m n -- k )
  ?dup 0= if exit then                       \ m n
  2dup 1- recurse -rot                       \ k m n
  tuck pnr /                                 \ k n m Pn 
  swap 1- recurse - ;                        \ k 

In the algorithm system Pn is found simultaneously but in the test-phi above it comes from a table. There are 2^n recursions before termination and testing for typical n-values takes a minute even for pi(m) with m=50000 n=pi(y)=29, where:

m^(1/3) =< y =< m^(1/2)

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

#44316

On Wednesday, December 23, 2015 at 7:58:52 AM UTC, lehs wrote:
> Den torsdag 26 november 2015 kl. 20:50:33 UTC+1 skrev Paul Rubin:
> > lehs <> writes:
> > > The prime counting function π(x), equal to the number of primes ≤ x,
> > > need 1643280 bytes to cover all 16 bit output,
> > 
> > That's a terrible way to do it though.
> > 
> > https://en.wikipedia.org/wiki/Prime-counting_function#Algorithms_for_evaluating_.CF.80.28x.29
> 
> I just can't understand how the algorithm from Wikipedia could be fast. Just to calculate phi very inefficient even for small "n":
> 
> \ phi(m,n)=phi(m,n-1)-phi(m/Pn,n-1)
> : phi ( m n -- k )
>   ?dup 0= if exit then                       \ m n
>   2dup 1- recurse -rot                       \ k m n
>   tuck pnr /                                 \ k n m Pn 
>   swap 1- recurse - ;                        \ k 
> 
> In the algorithm system Pn is found simultaneously but in the test-phi above it comes from a table. There are 2^n recursions before termination and testing for typical n-values takes a minute even for pi(m) with m=50000 n=pi(y)=29, where:
> 
> m^(1/3) =< y =< m^(1/2)


Maybe store phi(m,n) as an array?

Have a nice day,
humptydumpty

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

#44317

Den onsdag 23 december 2015 kl. 09:14:39 UTC+1 skrev humptydumpty:
> On Wednesday, December 23, 2015 at 7:58:52 AM UTC, lehs wrote:
> > Den torsdag 26 november 2015 kl. 20:50:33 UTC+1 skrev Paul Rubin:
> > > lehs <> writes:
> > > > The prime counting function π(x), equal to the number of primes ≤ x,
> > > > need 1643280 bytes to cover all 16 bit output,
> > > 
> > > That's a terrible way to do it though.
> > > 
> > > https://en.wikipedia.org/wiki/Prime-counting_function#Algorithms_for_evaluating_.CF.80.28x.29
> > 
> > I just can't understand how the algorithm from Wikipedia could be fast. Just to calculate phi very inefficient even for small "n":
> > 
> > \ phi(m,n)=phi(m,n-1)-phi(m/Pn,n-1)
> > : phi ( m n -- k )
> >   ?dup 0= if exit then                       \ m n
> >   2dup 1- recurse -rot                       \ k m n
> >   tuck pnr /                                 \ k n m Pn 
> >   swap 1- recurse - ;                        \ k 
> > 
> > In the algorithm system Pn is found simultaneously but in the test-phi above it comes from a table. There are 2^n recursions before termination and testing for typical n-values takes a minute even for pi(m) with m=50000 n=pi(y)=29, where:
> > 
> > m^(1/3) =< y =< m^(1/2)
> 
> 
> Maybe store phi(m,n) as an array?
> 
> Have a nice day,
> humptydumpty

But m should be at the size of a single cell number. Then it would be better to make an array of the prime counting function  :)

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

#43908

Den torsdag 26 november 2015 kl. 19:47:34 UTC+1 skrev lehs:
> I working with a blog about Forth and math where I try to build up an environment for computational mathematics; first for one cell numbers and then for multiple cell numbers. The idea is to use Forth for experimental mathematics but a lot of experiments is only realistic for cell numbers, mostly because of speed.
> 
> I need to implement functions that gives the n-th prime number and that gives the number of primes smaller or equal than a given number. The fastest implementation would be precalculated tables, but the need of memory force me to limit those arrays.
> 
> The prime counting function π(x), equal to the number of primes ≤ x, need 1643280 bytes to cover all 16 bit output, if the table contains 16 bit numbers. In a 64 bit system using 64 bit numbers the need of memory would be four times as much. And for the function that gives the n-th prime number I would consider using 3 byte numbers, that would gives all primes up to the prime 16777213.
> 
> Of course it is possible to create words as
> 
> cs@ ( ad i -- n )
> cs! ( n ad i -- )
> 
> that read i bytes at ad and put the number at the stack and conversly write tos using i bytes at ad.
> 
> But how to do that efficient? When neither w@, w!, sp0 nor sp@ are Forth standard?
> 
> http://forthmath.blogspot.se/p/single-cell-computational-arithmetic.html

I found a solution myself:

: mb! ( n ad i -- )  2>r here ! here 2r> cmove ;
: mb@ ( ad i -- n )  here swap cmove here @ ;

Thanks for the information about fast algorithms! I might adept yapcp...

lehs
http://forthmath.blogspot.se

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

#43915

Op Sat, 28 Nov 2015 10:44:24 -0800 (PST) schreef lehs:

> Den torsdag 26 november 2015 kl. 19:47:34 UTC+1 skrev lehs:
>> I working with a blog about Forth and math where I try to build up an environment for computational mathematics; first for one cell numbers and then for multiple cell numbers. The idea is to use Forth for experimental mathematics but a lot of experiments is only realistic for cell numbers, mostly because of speed.
>> 
>> I need to implement functions that gives the n-th prime number and that gives the number of primes smaller or equal than a given number. The fastest implementation would be precalculated tables, but the need of memory force me to limit those arrays.
>> 
>> The prime counting function π(x), equal to the number of primes ≤ x, need 1643280 bytes to cover all 16 bit output, if the table contains 16 bit numbers. In a 64 bit system using 64 bit numbers the need of memory would be four times as much. And for the function that gives the n-th prime number I would consider using 3 byte numbers, that would gives all primes up to the prime 16777213.
>> 
>> Of course it is possible to create words as
>> 
>> cs@ ( ad i -- n )
>> cs! ( n ad i -- )
>> 
>> that read i bytes at ad and put the number at the stack and conversly write tos using i bytes at ad.
>> 
>> But how to do that efficient? When neither w@, w!, sp0 nor sp@ are Forth standard?
>> 
>> http://forthmath.blogspot.se/p/single-cell-computational-arithmetic.html
> 
> I found a solution myself:
> 
>: mb! ( n ad i -- )  2>r here ! here 2r> cmove ;
>: mb@ ( ad i -- n )  here swap cmove here @ ;
> 
> Thanks for the information about fast algorithms! I might adept yapcp...

variable aa  0 aa !  ok
variable bb  0 bb !  ok
: mb! ( n a i -- ) 2>r here ! here 2r> cmove ;  ok
: mb@ ( a i -- ) here swap cmove here @ ;  ok
  ok
hex  ok
  ok
0 aa !       12 aa 2 mb! aa 2 mb@ . 12  ok
0 aa !     1234 aa 2 mb! aa 2 mb@ . 1234  ok
0 aa !   123456 aa 2 mb! aa 2 mb@ . 123456  ok
0 aa ! 12345678 aa 2 mb! aa 2 mb@ . 12345678  ok

It seems to me that the '2' is ignored, '1','3' and '4' give the same
answers 8-(
Little or big endian don't make a difference here.
Try handling byte-for-byte.

> 
> lehs
> http://forthmath.blogspot.se

groet Coos

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

#43917

Den lördag 28 november 2015 kl. 22:15:04 UTC+1 skrev Coos Haak:
> Op Sat, 28 Nov 2015 10:44:24 -0800 (PST) schreef lehs:
> 
> > Den torsdag 26 november 2015 kl. 19:47:34 UTC+1 skrev lehs:
> >> I working with a blog about Forth and math where I try to build up an environment for computational mathematics; first for one cell numbers and then for multiple cell numbers. The idea is to use Forth for experimental mathematics but a lot of experiments is only realistic for cell numbers, mostly because of speed.
> >> 
> >> I need to implement functions that gives the n-th prime number and that gives the number of primes smaller or equal than a given number. The fastest implementation would be precalculated tables, but the need of memory force me to limit those arrays.
> >> 
> >> The prime counting function π(x), equal to the number of primes ≤ x, need 1643280 bytes to cover all 16 bit output, if the table contains 16 bit numbers. In a 64 bit system using 64 bit numbers the need of memory would be four times as much. And for the function that gives the n-th prime number I would consider using 3 byte numbers, that would gives all primes up to the prime 16777213.
> >> 
> >> Of course it is possible to create words as
> >> 
> >> cs@ ( ad i -- n )
> >> cs! ( n ad i -- )
> >> 
> >> that read i bytes at ad and put the number at the stack and conversly write tos using i bytes at ad.
> >> 
> >> But how to do that efficient? When neither w@, w!, sp0 nor sp@ are Forth standard?
> >> 
> >> http://forthmath.blogspot.se/p/single-cell-computational-arithmetic.html
> > 
> > I found a solution myself:
> > 
> >: mb! ( n ad i -- )  2>r here ! here 2r> cmove ;
> >: mb@ ( ad i -- n )  here swap cmove here @ ;
> > 
> > Thanks for the information about fast algorithms! I might adept yapcp...
> 
> variable aa  0 aa !  ok
> variable bb  0 bb !  ok
> : mb! ( n a i -- ) 2>r here ! here 2r> cmove ;  ok
> : mb@ ( a i -- ) here swap cmove here @ ;  ok
>   ok
> hex  ok
>   ok
> 0 aa !       12 aa 2 mb! aa 2 mb@ . 12  ok
> 0 aa !     1234 aa 2 mb! aa 2 mb@ . 1234  ok
> 0 aa !   123456 aa 2 mb! aa 2 mb@ . 123456  ok
> 0 aa ! 12345678 aa 2 mb! aa 2 mb@ . 12345678  ok
> 
> It seems to me that the '2' is ignored, '1','3' and '4' give the same
> answers 8-(
> Little or big endian don't make a difference here.
> Try handling byte-for-byte.
> 
> > 
> > lehs
> > http://forthmath.blogspot.se
> 
> groet Coos
It should be

: mb@ ( ad i -- n )  here 0 over ! swap cmove here @ ;

and it might be better to use an other buffer than HERE.

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

#43918

Op Sat, 28 Nov 2015 14:18:08 -0800 (PST) schreef lehs:

> Den lördag 28 november 2015 kl. 22:15:04 UTC+1 skrev Coos Haak:
>> Op Sat, 28 Nov 2015 10:44:24 -0800 (PST) schreef lehs:
>> 
>>> Den torsdag 26 november 2015 kl. 19:47:34 UTC+1 skrev lehs:
>>>> I working with a blog about Forth and math where I try to build up an environment for computational mathematics; first for one cell numbers and then for multiple cell numbers. The idea is to use Forth for experimental mathematics but a lot of experiments is only realistic for cell numbers, mostly because of speed.
>>>> 
>>>> I need to implement functions that gives the n-th prime number and that gives the number of primes smaller or equal than a given number. The fastest implementation would be precalculated tables, but the need of memory force me to limit those arrays.
>>>> 
>>>> The prime counting function π(x), equal to the number of primes ≤ x, need 1643280 bytes to cover all 16 bit output, if the table contains 16 bit numbers. In a 64 bit system using 64 bit numbers the need of memory would be four times as much. And for the function that gives the n-th prime number I would consider using 3 byte numbers, that would gives all primes up to the prime 16777213.
>>>> 
>>>> Of course it is possible to create words as
>>>> 
>>>> cs@ ( ad i -- n )
>>>> cs! ( n ad i -- )
>>>> 
>>>> that read i bytes at ad and put the number at the stack and conversly write tos using i bytes at ad.
>>>> 
>>>> But how to do that efficient? When neither w@, w!, sp0 nor sp@ are Forth standard?
>>>> 
>>>> http://forthmath.blogspot.se/p/single-cell-computational-arithmetic.html
>>> 
>>> I found a solution myself:
>>> 
>>>: mb! ( n ad i -- )  2>r here ! here 2r> cmove ;
>>>: mb@ ( ad i -- n )  here swap cmove here @ ;
>>> 
>>> Thanks for the information about fast algorithms! I might adept yapcp...
>> 
>> variable aa  0 aa !  ok
>> variable bb  0 bb !  ok
>>: mb! ( n a i -- ) 2>r here ! here 2r> cmove ;  ok
>>: mb@ ( a i -- ) here swap cmove here @ ;  ok
>>   ok
>> hex  ok
>>   ok
>> 0 aa !       12 aa 2 mb! aa 2 mb@ . 12  ok
>> 0 aa !     1234 aa 2 mb! aa 2 mb@ . 1234  ok
>> 0 aa !   123456 aa 2 mb! aa 2 mb@ . 123456  ok
>> 0 aa ! 12345678 aa 2 mb! aa 2 mb@ . 12345678  ok
>> 
>> It seems to me that the '2' is ignored, '1','3' and '4' give the same
>> answers 8-(
>> Little or big endian don't make a difference here.
>> Try handling byte-for-byte.
>> 
>>> 
>>> lehs
>>> http://forthmath.blogspot.se
>> 
>> groet Coos
> It should be
> 
>: mb@ ( ad i -- n )  here 0 over ! swap cmove here @ ;

Yes!

> 
> and it might be better to use an other buffer than HERE.

Mostly because a traditional WORD would use HERE.

groet Coos

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

#43931

Den torsdag 26 november 2015 kl. 19:47:34 UTC+1 skrev lehs:
> I working with a blog about Forth and math where I try to build up an environment for computational mathematics; first for one cell numbers and then for multiple cell numbers. The idea is to use Forth for experimental mathematics but a lot of experiments is only realistic for cell numbers, mostly because of speed.
> 
> I need to implement functions that gives the n-th prime number and that gives the number of primes smaller or equal than a given number. The fastest implementation would be precalculated tables, but the need of memory force me to limit those arrays.
> 
> The prime counting function π(x), equal to the number of primes ≤ x, need 1643280 bytes to cover all 16 bit output, if the table contains 16 bit numbers. In a 64 bit system using 64 bit numbers the need of memory would be four times as much. And for the function that gives the n-th prime number I would consider using 3 byte numbers, that would gives all primes up to the prime 16777213.
> 
> Of course it is possible to create words as
> 
> cs@ ( ad i -- n )
> cs! ( n ad i -- )
> 
> that read i bytes at ad and put the number at the stack and conversly write tos using i bytes at ad.
> 
> But how to do that efficient? When neither w@, w!, sp0 nor sp@ are Forth standard?
> 
> http://forthmath.blogspot.se/p/single-cell-computational-arithmetic.html

So there are big-endians and little-endians..! I can´t test big, but if someone could I would be glad to know:

\ little-endian
: mb! ( n ad i -- )  2>r here ! here 2r> cmove ;
: mb@ ( ad i -- n )  here 0 over ! swap cmove here @ ;

\ big-endian
: mb! ( n ad i -- )  2>r here ! here cell + r@ - 2r> cmove ;
: mb@ ( ad i -- n )  here 0 over ! cell + over - swap cmove here @ ;

lehs
http://forthmath.blogspot.se

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

#43935

Den söndag 29 november 2015 kl. 11:18:13 UTC+1 skrev lehs:
> Den torsdag 26 november 2015 kl. 19:47:34 UTC+1 skrev lehs:
> > I working with a blog about Forth and math where I try to build up an environment for computational mathematics; first for one cell numbers and then for multiple cell numbers. The idea is to use Forth for experimental mathematics but a lot of experiments is only realistic for cell numbers, mostly because of speed.
> > 
> > I need to implement functions that gives the n-th prime number and that gives the number of primes smaller or equal than a given number. The fastest implementation would be precalculated tables, but the need of memory force me to limit those arrays.
> > 
> > The prime counting function π(x), equal to the number of primes ≤ x, need 1643280 bytes to cover all 16 bit output, if the table contains 16 bit numbers. In a 64 bit system using 64 bit numbers the need of memory would be four times as much. And for the function that gives the n-th prime number I would consider using 3 byte numbers, that would gives all primes up to the prime 16777213.
> > 
> > Of course it is possible to create words as
> > 
> > cs@ ( ad i -- n )
> > cs! ( n ad i -- )
> > 
> > that read i bytes at ad and put the number at the stack and conversly write tos using i bytes at ad.
> > 
> > But how to do that efficient? When neither w@, w!, sp0 nor sp@ are Forth standard?
> > 
> > http://forthmath.blogspot.se/p/single-cell-computational-arithmetic.html
> 
> So there are big-endians and little-endians..! I can´t test big, but if someone could I would be glad to know:
> 
> \ little-endian
> : mb! ( n ad i -- )  2>r here ! here 2r> cmove ;
> : mb@ ( ad i -- n )  here 0 over ! swap cmove here @ ;
> 
> \ big-endian
> : mb! ( n ad i -- )  2>r here ! here cell + r@ - 2r> cmove ;
> : mb@ ( ad i -- n )  here 0 over ! cell + over - swap cmove here @ ;
> 
> lehs
> http://forthmath.blogspot.se

\ implementation
variable ebuf
1 ebuf ! ebuf c@ negate
[if] \ little-endian
: mb! ( n ad i -- )  2>r ebuf ! ebuf 2r> cmove ;
: mb@ ( ad i -- n )  ebuf 0 over ! swap cmove ebuf @ ;
[else] \ big-endian
: mb! ( n ad i -- )  2>r ebuf ! ebuf cell + r@ - 2r> cmove ;
: mb@ ( ad i -- n )  ebuf 0 over ! cell + over - swap cmove ebuf @ ;
[then]
\ reverse endian for testing
: rev-end  ( ad -- )
  cell over + swap 2dup 2>r
  do i c@ loop 2r>
  do i c! loop ;

[toc] | [prev] | [standalone]

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

csiph-web