OpenEuphoria

Re: atom[ic] representations

• Posted by Beaumont Furniss <bfurniss at IHUG.CO.NZ> May 19, 2000
• 586 views

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