1. Another number question
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
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
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
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
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
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
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
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
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
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
