1. Another number question
- Posted by Jason Gade <jaygade at ?a?oo.com> May 16, 2008
- 668 views
Can we guarantee that all positive integral atoms from 2^30 to 2^53 correspond to their actual number, with no loss of precision in that range? If not, what is the highest integral atom that can be represented without losing precision? I'm asking with regards to Kat's query about improving seek(). -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
2. Re: Another number question
- Posted by Matt Lewis <matthewwalkerlewis at gmail?co?> May 16, 2008
- 609 views
Jason Gade wrote: > > Can we guarantee that all positive integral atoms from 2^30 to 2^53 correspond > to their actual number, with no loss of precision in that range? If not, what > is the highest integral atom that can be represented without losing precision? > > I'm asking with regards to Kat's query about improving seek(). The proper way to do this is to use a long long. A 64-bit integer. You could pretend that this was a double, and use float64_to_atom or something similar. Or just allocate the memory and use a pointer. Depends on how you're implementing it. Matt
3. Re: Another number question
- Posted by Fernando Bauer <fmbauer at hotm?il?com> May 16, 2008
- 626 views
Jason Gade wrote: > > Can we guarantee that all positive integral atoms from 2^30 to 2^53 correspond > to their actual number, with no loss of precision in that range? Yes, according to this test:
function PreviousIntegerDistance(atom a) atom i i = 1 while a = a-i do i += 1 end while return i end function function NextIntegerDistance(atom a) atom i i = 1 while a = a+i do i += 1 end while return i end function for i = 10 to 70 do printf(1,"2^%d = %g -> Interval = (-%d,%d)\n",{i,power(2,i),PreviousIntegerDistance(power(2,i)),NextIntegerDistance(power(2,i))}) end for
Regards, Fernando >If not, what > is the highest integral atom that can be represented without losing precision? > > I'm asking with regards to Kat's query about improving seek(). > > -- > A complex system that works is invariably found to have evolved from a simple > system that works. > --John Gall's 15th law of Systemantics. > > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > > j.
4. Re: Another number question
- Posted by Jason Gade <jaygade at y?hoo?com> May 16, 2008
- 666 views
Matt Lewis wrote: > > Jason Gade wrote: > > > > Can we guarantee that all positive integral atoms from 2^30 to 2^53 > > correspond > > to their actual number, with no loss of precision in that range? If not, > > what > > is the highest integral atom that can be represented without losing > > precision? > > > > I'm asking with regards to Kat's query about improving seek(). > > The proper way to do this is to use a long long. A 64-bit integer. You > could pretend that this was a double, and use float64_to_atom or something > similar. Or just allocate the memory and use a pointer. Depends on how > you're implementing it. > > Matt Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At this point, the limitation is the fseek() call in the C library, which takes a 32-bit integer, limiting the size of the seek to 4GB. Now, maybe one of these days Kat will have to deal with 18 exabyte files, but that day is not today. If we go with 2^53, then that limits her to only 9 petabyte files. Cry me a river. My idea is this: Euphoria already converts the atom to an unsigned long int. fseek() can also take a relative number using SEEK_CUR (not exposed to Euphoria). So if the atom is larger than an unsigned long int then the C code could loop over relative values to the proper position. Another option is to either allow an optional third parameter to Euphoria's seek() and make the programmer loop herself or make a new command/macine_func that does that. A third option is to use platform-dependent function calls. I like the first option -- seek() already takes an atom. There's no reason that it can't be bigger than 4GB and still work. Fernando Bauer wrote: > > Jason Gade wrote: > > > > Can we guarantee that all positive integral atoms from 2^30 to 2^53 > > correspond > > to their actual number, with no loss of precision in that range? > > Yes, according to this test: > > }}} <eucode> > function PreviousIntegerDistance(atom a) > atom i > i = 1 > while a = a-i do i += 1 > end while > return i > end function > > function NextIntegerDistance(atom a) > atom i > i = 1 > while a = a+i do i += 1 > end while > return i > end function > > for i = 10 to 70 do > printf(1,"2^%d = %g -> Interval = > (-%d,%d)\n",{i,power(2,i),PreviousIntegerDistance(power(2,i)),NextIntegerDistance<font > color="#0000FF">(power(2,i))}) > end for > </eucode> {{{ > > Regards, > Fernando > Thanks Fernando, I'll check it out. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
5. Re: Another number question
- Posted by Kat <KAT12 at coos?hs.net> May 16, 2008
- 677 views
Jason Gade wrote: > > Matt Lewis wrote: > > > > Jason Gade wrote: > > > > > > Can we guarantee that all positive integral atoms from 2^30 to 2^53 > > > correspond > > > to their actual number, with no loss of precision in that range? If not, > > > what > > > is the highest integral atom that can be represented without losing > > > precision? > > > > > > I'm asking with regards to Kat's query about improving seek(). > > > > The proper way to do this is to use a long long. A 64-bit integer. You > > could pretend that this was a double, and use float64_to_atom or something > > similar. Or just allocate the memory and use a pointer. Depends on how > > you're implementing it. > > > > Matt > > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At this > point, the limitation is the fseek() call in the C library, which takes a > 32-bit > integer, limiting the size of the seek to 4GB. Both windoseXP and various *nix have functions that can be called with bigger integers. What size, i don't know, but bigger than 32, and prolly 64. > Now, maybe one of these days Kat will have to deal with 18 exabyte files, but > that day is not today. If we go with 2^53, then that limits her to only 9 > petabyte > files. Cry me a river. The curent harddrives can handle "only" 48 bits, and i suspect more than a few handle 40 bits. The next step above that is likely going to be RAIDs configured as one "drive" and will be at 64 bits merely for the convienence of the cpu, even tho the drive tables could take 72 bits (3 x 24). But basically, there's OS api calls that exist that Eu isn't using for this, and i am not sure how to pass an integer that Eu can't handle anyhow. Or get one back. Kat
6. Re: Another number question
- Posted by Jason Gade <jaygade at y?hoo.com> May 16, 2008
- 599 views
Kat wrote: > > Jason Gade wrote: > > > > Matt Lewis wrote: > > > > > > Jason Gade wrote: > > > > > > > > Can we guarantee that all positive integral atoms from 2^30 to 2^53 > > > > correspond > > > > to their actual number, with no loss of precision in that range? If not, > > > > what > > > > is the highest integral atom that can be represented without losing > > > > precision? > > > > > > > > I'm asking with regards to Kat's query about improving seek(). > > > > > > The proper way to do this is to use a long long. A 64-bit integer. You > > > could pretend that this was a double, and use float64_to_atom or something > > > similar. Or just allocate the memory and use a pointer. Depends on how > > > you're implementing it. > > > > > > Matt > > > > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At this > > point, the limitation is the fseek() call in the C library, which takes a > > 32-bit > > integer, limiting the size of the seek to 4GB. > > Both windoseXP and various *nix have functions that can be called with bigger > integers. What size, i don't know, but bigger than 32, and prolly 64. > > > Now, maybe one of these days Kat will have to deal with 18 exabyte files, > > but > > that day is not today. If we go with 2^53, then that limits her to only 9 > > petabyte > > files. Cry me a river. > > The curent harddrives can handle "only" 48 bits, and i suspect more than a few > handle 40 bits. The next step above that is likely going to be RAIDs > configured > as one "drive" and will be at 64 bits merely for the convienence of the cpu, > even tho the drive tables could take 72 bits (3 x 24). I don't know what the hardware can handle, but I know that until recently most software could only handle 32 bits. I'm not sure if many OS's use more than 64 bits for offset_t, though. > > But basically, there's OS api calls that exist that Eu isn't using for this, > and i am not sure how to pass an integer that Eu can't handle anyhow. Or get > one back. > > Kat I think that Matt wrote a library for sending either 32-bit integers or larger to OS API calls... Maybe it was only full 32-bits. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
7. Re: Another number question
- Posted by CChris <christian.cuvier at agriculture?g?uv.fr> May 16, 2008
- 592 views
Kat wrote: > > Jason Gade wrote: > > > > Matt Lewis wrote: > > > > > > Jason Gade wrote: > > > > > > > > Can we guarantee that all positive integral atoms from 2^30 to 2^53 > > > > correspond > > > > to their actual number, with no loss of precision in that range? If not, > > > > what > > > > is the highest integral atom that can be represented without losing > > > > precision? > > > > > > > > I'm asking with regards to Kat's query about improving seek(). > > > > > > The proper way to do this is to use a long long. A 64-bit integer. You > > > could pretend that this was a double, and use float64_to_atom or something > > > similar. Or just allocate the memory and use a pointer. Depends on how > > > you're implementing it. > > > > > > Matt > > > > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At this > > point, the limitation is the fseek() call in the C library, which takes a > > 32-bit > > integer, limiting the size of the seek to 4GB. > > Both windoseXP and various *nix have functions that can be called with bigger > integers. What size, i don't know, but bigger than 32, and prolly 64. > > > Now, maybe one of these days Kat will have to deal with 18 exabyte files, > > but > > that day is not today. If we go with 2^53, then that limits her to only 9 > > petabyte > > files. Cry me a river. > > The curent harddrives can handle "only" 48 bits, and i suspect more than a few > handle 40 bits. The next step above that is likely going to be RAIDs > configured > as one "drive" and will be at 64 bits merely for the convienence of the cpu, > even tho the drive tables could take 72 bits (3 x 24). > > But basically, there's OS api calls that exist that Eu isn't using for this, > and i am not sure how to pass an integer that Eu can't handle anyhow. Or get > one back. > > Kat I had added a comment in the doc for c_func() a long time ago about passing a 64 bit integer. Just pretend, when define_c_func()ing, that the C routine has two C_POINTER args. c_func() passing low dword first, then high dxord. You can get a long long back using large_return.e in the archive. Feedback appreciated. CChris
8. Re: Another number question
- Posted by Matt Lewis <matthewwalkerlewis at gma?l.c?m> May 16, 2008
- 614 views
Jason Gade wrote: > > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At this > point, the limitation is the fseek() call in the C library, which takes a > 32-bit > integer, limiting the size of the seek to 4GB. > > Now, maybe one of these days Kat will have to deal with 18 exabyte files, but > that day is not today. If we go with 2^53, then that limits her to only 9 > petabyte > files. Cry me a river. Hey, not my fault you don't want to do it right. :) I know I've worked with the windows API for large files. Haven't done the same for linux/bsd. Matt
9. Re: Another number question
- Posted by Jason Gade <jaygade at y?ho?.com> May 16, 2008
- 635 views
Matt Lewis wrote: > > Jason Gade wrote: > > > > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At this > > point, the limitation is the fseek() call in the C library, which takes a > > 32-bit > > integer, limiting the size of the seek to 4GB. > > > > Now, maybe one of these days Kat will have to deal with 18 exabyte files, > > but > > that day is not today. If we go with 2^53, then that limits her to only 9 > > petabyte > > files. Cry me a river. > > Hey, not my fault you don't want to do it right. :) > > I know I've worked with the windows API for large files. Haven't done the > same for linux/bsd. > > Matt Well, for me "doing it right" means making it pretty much transparent and working the way the user expects it to work. That is, the user gives a number and the pointer seeks to the proper spot in the file, subject only to the OS/filesystem limitations. In a way I think this would be transitional as well, as machines do eventually move more and more to 64-bit. More research is required, I think. Right now I'm mostly just brainstorming anyway. One thought I had this morning, though, was to create a 64-bit integer type internal to the interpreter, and routines or macros or whatever to convert an atom to a 64-bit integer. Then that groundwork will be laid for the future. Still taking baby steps with the source -- I still haven't gotten set back up with subversion or anything and I still spend more time elsewhere on the internet discussing non-programming stuff than I spend doing any programming. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
10. Re: Another number question
- Posted by Kat <KAT12 at ?oosahs.n?t> May 18, 2008
- 621 views
Jason Gade wrote: > > Matt Lewis wrote: > > > > Jason Gade wrote: > > > > > > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At > > > this > > > point, the limitation is the fseek() call in the C library, which takes a > > > 32-bit > > > integer, limiting the size of the seek to 4GB. > > > > > > Now, maybe one of these days Kat will have to deal with 18 exabyte files, > > > but > > > that day is not today. If we go with 2^53, then that limits her to only 9 > > > petabyte > > > files. Cry me a river. > > > > Hey, not my fault you don't want to do it right. :) > > > > I know I've worked with the windows API for large files. Haven't done the > > same for linux/bsd. > > > > Matt > > > Well, for me "doing it right" means making it pretty much transparent and > working > the way the user expects it to work. That is, the user gives a number and the > pointer seeks to the proper spot in the file, subject only to the > OS/filesystem > limitations. > > In a way I think this would be transitional as well, as machines do eventually > move more and more to 64-bit. > > More research is required, I think. Right now I'm mostly just brainstorming > anyway. > > One thought I had this morning, though, was to create a 64-bit integer type > internal to the interpreter, and routines or macros or whatever to convert an > atom to a 64-bit integer. > > Then that groundwork will be laid for the future. > > Still taking baby steps with the source -- I still haven't gotten set back up > with subversion or anything and I still spend more time elsewhere on the > internet > discussing non-programming stuff than I spend doing any programming. This might be done easier and faster by one of the developers of Falcon who is on this list, since Falcon already has internal 64bit integers. And some of the Asian, S American, and Europeans here asked for unicode strings (and asked years ago), and Falcon has unicode strings/sequences, and you can even name your functions and varnames in unicode16 as well if you can enter/display 16bit in the editor you use. And developer(s) of Falcon are on Euphorum. So i am wondering which way the technology is moving: Euphoria to/from D/Falcon/wxBasic/Blender/etc. And why. And can i get "goto" ? I am not objecting to the cross-development that seems to be going on, just that when someone is working on more than one open source language, and a feature is asked for, why it isn't possible to say "oh, i already wrote that for X language" instead of people sitting here saying they'll work on it, or waiting on it to be added to Euphoria. Basicly, where, in a way, Euphoria going to be fixed in RDS's 1985 vision, and people here who already added requested features into other languages, can neither say they did, nor add those features to Euphoria. I am just curious, so i asked. Kat
11. Re: Another number question
- Posted by Jason Gade <jaygade at yahoo?c?m> May 18, 2008
- 639 views
- Last edited May 19, 2008
Kat wrote: > > Jason Gade wrote: > > > > Matt Lewis wrote: > > > > > > Jason Gade wrote: > > > > > > > > Well, if Euphoria /had/ 64-bit integers that wouldn't be a problem. At > > > > this > > > > point, the limitation is the fseek() call in the C library, which takes > > > > a > 32-bit</font></i> > > > > integer, limiting the size of the seek to 4GB. > > > > > > > > Now, maybe one of these days Kat will have to deal with 18 exabyte > > > > files, but > > > > that day is not today. If we go with 2^53, then that limits her to only > > > > 9 > petabyte</font></i> > > > > files. Cry me a river. > > > > > > Hey, not my fault you don't want to do it right. :) > > > > > > I know I've worked with the windows API for large files. Haven't done the > > > same for linux/bsd. > > > > > > Matt > > > > > > Well, for me "doing it right" means making it pretty much transparent and > > working > > the way the user expects it to work. That is, the user gives a number and > > the > > pointer seeks to the proper spot in the file, subject only to the > > OS/filesystem > > limitations. > > > > In a way I think this would be transitional as well, as machines do > > eventually > > move more and more to 64-bit. > > > > More research is required, I think. Right now I'm mostly just brainstorming > > anyway. > > > > One thought I had this morning, though, was to create a 64-bit integer type > > internal to the interpreter, and routines or macros or whatever to convert > > an > > atom to a 64-bit integer. > > > > Then that groundwork will be laid for the future. > > > > Still taking baby steps with the source -- I still haven't gotten set back > > up > > with subversion or anything and I still spend more time elsewhere on the > > internet > > discussing non-programming stuff than I spend doing any programming. > > This might be done easier and faster by one of the developers of Falcon who > is on this list, since Falcon already has internal 64bit integers. I have the feeling that I've asked this before, but what is "Falcon"? > And some of the Asian, S American, and Europeans here asked for unicode > strings > (and asked years ago), and Falcon has unicode strings/sequences, and you can > even name your functions and varnames in unicode16 as well if you can > enter/display > 16bit in the editor you use. And developer(s) of Falcon are on Euphorum. Unicode strings should be doable. > So i am wondering which way the technology is moving: Euphoria to/from > D/Falcon/wxBasic/Blender/etc. > And why. And can i get "goto" ? I am not objecting to the cross-development > that seems to be going on, just that when someone is working on more than one > open source language, and a feature is asked for, why it isn't possible to say > "oh, i already wrote that for X language" instead of people sitting here > saying > they'll work on it, or waiting on it to be added to Euphoria. Basicly, where, > in a way, Euphoria going to be fixed in RDS's 1985 vision, and people here who > already added requested features into other languages, can neither say they > did, nor add those features to Euphoria. I am just curious, so i asked. > > Kat I don't know how to answer your question as I don't know who here is implementing features in other open source languages, other than in their own forks of Euphoria. I think that Irv Mullins left here to work on Qu, and Derek Parnell does stuff with the D language. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
12. Re: Another number question
- Posted by Jeremy Cowgar <jeremy at cowgar?c?m> May 18, 2008
- 628 views
- Last edited May 19, 2008
Jason Gade wrote: > > > I don't know how to answer your question as I don't know who here is > implementing > features in other open source languages, other than in their own forks of > Euphoria. She is speaking of me as I implemented a DBI module for Falcon which was accepted into the core, and thus I was listed as an author. But, as her and I spoke on IRC, I have done nothing with the internals of Falcon, so in reference to the statement that since Falcon has 64bit integers and unicode that I should be able to therefore implement unicode and 64bit integers in Euphoria is wrong and she understands that now from our IRC conversations. -- Jeremy Cowgar http://jeremy.cowgar.com
13. Re: Another number question
- Posted by Kat <KAT12 at co?sahs.net> May 18, 2008
- 617 views
- Last edited May 19, 2008
Jeremy Cowgar wrote: > > Jason Gade wrote: > > > > > > I don't know how to answer your question as I don't know who here is > > implementing > > features in other open source languages, other than in their own forks of > > Euphoria. > > She is speaking of me as I implemented a DBI module for Falcon which was > accepted > into the core, and thus I was listed as an author. But, as her and I spoke on > IRC, I have done nothing with the internals of Falcon, so in reference to the > statement that since Falcon has 64bit integers and unicode that I should be > able to therefore implement unicode and 64bit integers in Euphoria is wrong > and she understands that now from our IRC conversations. Yes. But there was a 2nd part to the post, and to the discussion on irc, and that is both languages are open sourced, even tho Falcon is built with C++ and Eu is built with C, perhaps what is called on the various api for OSs Falcon supports, or how it supports unicode strings all over itself, or strings in general, is of some aid in doing the same with C for Euphoria. Ergo, Jason, maybe tis a path for you to know. Kat
14. Re: Another number question
- Posted by Jeremy Cowgar <jeremy at ?owg?r.com> May 18, 2008
- 619 views
- Last edited May 19, 2008
Kat wrote: > > Yes. > > But there was a 2nd part to the post, and to the discussion on irc, and that > is both languages are open sourced, even tho Falcon is built with C++ and Eu > is built with C, perhaps what is called on the various api for OSs Falcon > supports, > or how it supports unicode strings all over itself, or strings in general, is > of some aid in doing the same with C for Euphoria. Ergo, Jason, maybe tis a > path for you to know. > Giancarlo and I have talked about implementing Unicode some as I was asking him in regards to an editor. Unicode strings in Falcon are implemented 100% as a class which makes it incompatible with C. I am not sure about anything in regards to how 64bit integers are implemented. You can look into Falcon, but it being C++, I would venture to say if you need examples of how it is implemented you would be much better going to a language written in C for that example, but I am not sure it's really examples that we need. We need man power. -- Jeremy Cowgar http://jeremy.cowgar.com
15. Re: Another number question
- Posted by Jason Gade <jaygade at yaho?.?om> May 18, 2008
- 622 views
- Last edited May 19, 2008
Is there a link for this "Falcon" language? Anyway, implementing 64-bit integers internal to the interpreter (not exposed to the user) should be relatively easy. Unicode strings might be a little more difficult. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
16. Re: Another number question
- Posted by Jeremy Cowgar <jeremy at cow?ar?com> May 18, 2008
- 604 views
- Last edited May 19, 2008
Jason Gade wrote: > > Is there a link for this "Falcon" language? > > Anyway, implementing 64-bit integers internal to the interpreter (not exposed > to the user) should be relatively easy. > > Unicode strings might be a little more difficult. > Well, I hate to go advertising other languages as I really enjoy and think we should concentrate on Euphoria, but a link to it can be found from my home page. -- Jeremy Cowgar http://jeremy.cowgar.com
17. Re: Another number question
- Posted by Jason Gade <jaygade at yaho?.c?m> May 18, 2008
- 611 views
- Last edited May 19, 2008
Jeremy Cowgar wrote: > > Jason Gade wrote: > > > > Is there a link for this "Falcon" language? > > > > Anyway, implementing 64-bit integers internal to the interpreter (not > > exposed > > to the user) should be relatively easy. > > > > Unicode strings might be a little more difficult. > > > > Well, I hate to go advertising other languages as I really enjoy and think we > should concentrate on Euphoria, but a link to it can be found from my home > page. > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> Thanks, found it. Heh. I have no problems with cribbing ideas from other languages, as long as those ideas make sense within the context of what Euphoria already is. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
18. Re: Another number question
- Posted by Jeremy Cowgar <jeremy at cowga?.co?> May 18, 2008
- 651 views
- Last edited May 19, 2008
Jason Gade wrote: > > Heh. I have no problems with cribbing ideas from other languages, as long as > those ideas make sense within the context of what Euphoria already is. > Ah, indeed. Might as well learn from as many sources as possible. Everyone has good ideas. I think you will find Falcon has quite a few nice features, but it's a totally different language. -- Jeremy Cowgar http://jeremy.cowgar.com