1. atom[ic] representations
- Posted by Beaumont Furniss <bfurniss at IHUG.CO.NZ> May 18, 2000
- 589 views
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 .
2. Re: atom[ic] representations
- Posted by Robert Craig <rds at ATTCANADA.NET> May 18, 2000
- 593 views
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
3. Re: atom[ic] representations
- Posted by Beaumont Furniss <bfurniss at IHUG.CO.NZ> May 19, 2000
- 587 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