1. atom[ic] representations

After attempting to find how an atom is stored I decided to come to the
 source .
  I attempted to determine the structure through code similar to this:

     atom x,addr
     sequence s,r

     x=1   --   given numerous values , in a loop.
     s={0} R={} addr=0

     s=s+x
     addr=allocate_string(s)
     r=peek({addr,8})
     print(1,r)

   r[1] varied with varing x , as did a few other r[] values ; however
  not to the extent that I'd expect. To avoid getting overly involved
  in an investigation into this ; perhaps someone can illucidate .

new topic     » topic index » view message » categorize

2. Re: atom[ic] representations

Beaumont Furniss writes:
> After attempting to find how an atom is stored
> I decided to come to the source .
> I attempted to determine the structure through code
> similar to this:

You are attempting to do the impossible.
Euphoria does not allow you to peek into
memory at the way that Euphoria variables
or data are stored. This is not C.
The best you can do is use atom_to_float64(),
which I believe you were already doing.
atom_to_float64() is not that slow. If you think it is,
make some measurements and show us.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

3. Re: atom[ic] representations

date:         Thu, 18 May 2000 00:00:49 -040

 EU>Beaumont Furniss writes:
 EU>> After attempting to find how an atom is stored
 EU>> I decided to come to the source .
 EU>> I attempted to determine the structure through code
 EU>> similar to this:

 EU>You are attempting to do the impossible.
 EU>Euphoria does not allow you to peek into
 EU>memory at the way that Euphoria variables
 EU>or data are stored. This is not C.
 EU>The best you can do is use atom_to_float64(),
 EU>which I believe you were already doing.
 EU>atom_to_float64() is not that slow. If you think it is,
 EU>make some measurements and show us.

  Usually atom_to_float32() or atom_to_float64() and the inverse
          float32_to_atom() or float64_to_atom() are quite suitable.

   However when I use these on 4 megabytes , or more of data , then ;
  relative to poking & peeking integers , as strings , or using
  allocate_string() or mem_copy() to transfer data . These appear to
  be slow .

   using the code given previously , I was still able to assign an
  atom to a string , s=s+x , then poke , addr=allocate_string(s) the string
 ,or something, into memory ; then read the value from memory ,
  r=peek({addr,8}) and find that r[1]=x , the original value poked.

  So if an atom , within a string , isn't being poked ; what is ?

  The documentation does say that a variable amount of memory is used ,
 depending upon the magnitude of the atom .

  I suppose I'm just curious to know what atom_to_float64() does , and
 whether there's anyway of improving upon this , machine.e routine ;
 that's written in machine code.







 EU>Rapid Deployment Software
 EU>http://www.RapidEuphoria.com

Net-Tamer V 1.11 - Test Drive

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu