Floats and Doubles
hello, I have been using some of the functions of the classes Real and Fractional and I have observed that with the funcion "toRational" we can obtain the fraction that represents a given number. For instance: *P2> toRational (5.2::Float) 5452595 % 1048576 Why we obtain this numbers instead of "52 % 10" or "26 % 5"? I have also obtained the following results with the functions "fromRational" and "toRational": *P2> (fromRational ((toRational 4) - ( toRational (5.2::Float) )))::Double -1.198092651367 *P2> (fromRational ((toRational 4) - ( toRational (5.2::Double) )))::Double -1.2002 *P2> (fromRational ((toRational 4) - ( toRational 5.2 ))) -1.2002 *P2> (fromRational ((toRational 4) - ( toRational (5.2::Float) )))::Float -1.198 Are all these results ok? If this is the case, why? Thanks, Ignacio ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Floats and Doubles
> I have been using some of the functions of the classes Real and > Fractional and I have observed that with the funcion > "toRational" we can > obtain the fraction that represents a given number. For instance: > *P2> toRational (5.2::Float) > 5452595 % 1048576 > Why we obtain this numbers instead of "52 % 10" or "26 % 5"? Because you asked for the number to be converted to a Float first, and 5.2 can't be represented exactly in a single-precision float. If you don't go via Float, you get the exact result: Prelude> 5.2 :: Rational 26 % 5 > I have also obtained the following results with the functions > "fromRational" and "toRational": > *P2> (fromRational ((toRational 4) - ( toRational > (5.2::Float) )))::Double > -1.198092651367 > *P2> (fromRational ((toRational 4) - ( toRational > (5.2::Double) )))::Double > -1.2002 > *P2> (fromRational ((toRational 4) - ( toRational 5.2 ))) > -1.2002 > *P2> (fromRational ((toRational 4) - ( toRational > (5.2::Float) )))::Float > -1.198 These are all symptoms of rounding. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floats and Doubles
Yes, they all seem to be right. You get these funny effects because numbers like 5.2 do not have an exact representation with floating point numbers in base to (like Float and Double most likely have on your machine). The number 5.2 is stored as a slightly different number as a Float, but the toRational function is exact so it gives you the number corresponding to the internal representation. Take a course on numerical analysis. :) -- Lennart Juan Ignacio Garcia Garcia wrote: hello, I have been using some of the functions of the classes Real and Fractional and I have observed that with the funcion "toRational" we can obtain the fraction that represents a given number. For instance: *P2> toRational (5.2::Float) 5452595 % 1048576 Why we obtain this numbers instead of "52 % 10" or "26 % 5"? I have also obtained the following results with the functions "fromRational" and "toRational": *P2> (fromRational ((toRational 4) - ( toRational (5.2::Float) )))::Double -1.198092651367 *P2> (fromRational ((toRational 4) - ( toRational (5.2::Double) )))::Double -1.2002 *P2> (fromRational ((toRational 4) - ( toRational 5.2 ))) -1.2002 *P2> (fromRational ((toRational 4) - ( toRational (5.2::Float) )))::Float -1.198 Are all these results ok? If this is the case, why? Thanks, Ignacio ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floats and Doubles
Lennart Augustsson wrote: > The number 5.2 is stored as a slightly different number as a Float, but the toRational function is exact so it gives you the number corresponding to the internal representation. Take a course on numerical analysis. :) Nope. Take a course entitled: Why all you zombies must remain forever slaves of IEEE-something (477?), and why you should be happy with this. Jerzy Karczmarczuk ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floats and Doubles
If that is a serious question, then the answer is that if you want to take advantage of floating point hardware you are in general limited to those representations that the hardware understands. Also, most floating point representations have a binary field for what is effectively the significant digits of the number you are representing, and thus there are some conversion and roundoff errors built into the representation. It is of course possible to use something more akin to a BCD representation, and if you are willing to live with the performance impact, then that is fine. That should be, however, another type, because in many cases the performance loss is unacceptable and the roundoff errors are insignificant. On Tuesday 12 November 2002 07:10 am, Jerzy Karczmarczuk wrote: > Lennart Augustsson wrote: > > The number 5.2 is stored > > > > as a slightly different number as a Float, but the toRational function > > is exact > > so it gives you the number corresponding to the internal representation. > > Take a course on numerical analysis. :) > > Nope. Take a course entitled: >Why all you zombies must remain forever slaves of IEEE-something (477?), >and why you should be happy with this. > > Jerzy Karczmarczuk > > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp [EMAIL PROTECTED] 1-480-661-1849 (GMT-7) ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RFC: External library infrastructure
Hi Folks, It has occurred to us that the GHC community really needs an infrastructure (i.e. like a build system, but more) that people can use for shipping their own libraries independently of GHC. Several people have asked recently if they can ship their libraries with GHC - for a while we were quite receptive to this, but GHC is getting rather "heavy" both in terms of build time and maintenance effort, and we feel it's time to cut back a bit. But we don't want to leave library developers out in the cold. Suppose we had an infrastructure which someone could plug their library source code into, and immediately get - a source tarball which will configure/build/install on a Unix/cygwin system with GHC installed, and provide a GHC package when installed. - skeleton binary packages for RPM, Windows installer, *BSD ports, Gentoo ebuild, etc. The binary packages will require some programmer intervention (such as setting the dependencies correctly), but much of the work can be done automatically. Furthermore, we'd provide links to compatible library packages from the GHC web pages. It doesn't particularly matter whether fptools is used as a starting point, or we pick another existing build system or start from scratch. The important thing is that someone who wants to ship a library can pick up this infrastructure and quickly provide all the above functionality with very little extra work. Comments? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: External library infrastructure
Simon Marlow <[EMAIL PROTECTED]> writes: > Hi Folks, It has occurred to us that the GHC community really needs > an infrastructure (i.e. like a build system, but more) that people > can use for shipping their own libraries independently of GHC. I'd like to throw the following into the pot: The Hugs and GHC developers work pretty hard to keep the two compilers compatible. For example, the next Hugs release will ship with libraries from the same source tree as GHC uses and the same foreign function interface as GHC and the GHC folk recently gave up a feature they dearly wanted in the foreign function interface in the name of portability. So as people try to come up with a distribution and build mechanism that will work for GHC, it would be good to think about how that same mechanism would work for Hugs too. For example, an extension of GHC's existing package mechanism might work well because it would be easy for Hugs to extract the pieces it needs and the package mechanism has little irrelevant stuff. In contrast a variation on the existing Makefile system would work poorly because the complexity for the library developer of buying into the infrastructure far exceeds the complexity of the task (which for Hugs is overcoming a few minor platform dependencies using autoconf or the like, building any foreign function interface libraries, and overcoming a few remaining Hugs-GHC incompatabilities). We might also want to develop a common testing infrastructure for libraries which, ideally, would work with all compilers. [Of course, much of the above is true if you replace 'Hugs' with 'NHC' but I'm not certain of the exact status of NHC at the moment so I'll let them speak for themselves.] -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: External library infrastructure
Alastair Reid <[EMAIL PROTECTED]> writes: > [Of course, much of the above is true if you replace 'Hugs' with 'NHC' > but I'm not certain of the exact status of NHC at the moment so I'll > let them speak for themselves.] I concur wholeheartedly with everything Alastair says. Between the three Haskell implementations, we have already puts lots of effort into ensuring that the "standard" population of the hierarchical library namespace is as portable as possible. A mechanism to make the packaging of third-party libraries as painless as possible is highly desirable, and rather than target it solely at ghc, I think we should similarly aim for the maximum portability. This can only help the exposure that new libraries get, and reduce the burden on the independent developer. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: RFC: External library infrastructure
> I'd like to throw the following into the pot: > > The Hugs and GHC developers work pretty hard to keep the two > compilers compatible. For example, the next Hugs release will ship > with libraries from the same source tree as GHC uses and the same > foreign function interface as GHC and the GHC folk recently gave up > a feature they dearly wanted in the foreign function interface in > the name of portability. > > So as people try to come up with a distribution and build mechanism > that will work for GHC, it would be good to think about how that > same mechanism would work for Hugs too. Absolutely. I didn't mean to sound so GHC-centric. It would be great if the same infrastructure supports multiple compilers/interpreters. > For example, an extension > of GHC's existing package mechanism might work well because it would > be easy for Hugs to extract the pieces it needs and the package > mechanism has little irrelevant stuff. In contrast a variation on > the existing Makefile system would work poorly because the > complexity for the library developer of buying into the > infrastructure far exceeds the complexity of the task (which for > Hugs is overcoming a few minor platform dependencies using autoconf > or the like, building any foreign function interface libraries, and > overcoming a few remaining Hugs-GHC incompatabilities). Could you be more concrete? What extension of the package mechanism did you have in mind? (personally I had in mind a standard autoconf + Makefiles story for the build system, but I'm sure there are better ways). It'll be tricky to balance the requirements of a glorious all-encompassing infrastructure with keeping a low "buy-in" cost (as you put it), but that must be one of the goals or we won't have achieved anything. > We might also want to develop a common testing infrastructure for > libraries which, ideally, would work with all compilers. Right on. I'd like to propose we start from GHC's current testing system. It's a small collection of Python scripts (about 900 lines), and is designed to be compiler-independent, although I haven't used it with anything except GHC yet. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: External library infrastructure
G'day all. On Tue, Nov 12, 2002 at 05:25:42PM +, Alastair Reid wrote: > So as people try to come up with a distribution and build mechanism > that will work for GHC, it would be good to think about how that > same mechanism would work for Hugs too. If you will allow me to AOL... Me too! Cheers, Andrew Bromage ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: External library infrastructure
> Could you be more concrete? What extension of the package mechanism
> did you have in mind? (personally I had in mind a standard autoconf
> + Makefiles story for the build system, but I'm sure there are
> better ways).
I was thinking "add all the things that make packages insufficient
to use as an infrastructure" :-)
One thing is autoconf support for those doing ffi.
We might also want conditionals in package specs (cpp enough?).
I don't see Makefiles as part of a cross-compiler story. Rather, I
see an enhanced package system that includes a subset of makefile
functionality (e.g., Hugs' import chasing and GHC's --make
functionality).
It would be good to have a portable way of specifying most compiler
flags which affect language features. For example,
features = {FFI, MPTC}
would be translated into -ffi and for GHC and -98 for Hugs
and would trigger an error in NHC which lacks MPTC. Flags would only
be standardized as we agree on them and there's be a way to provide
flags in a compiler-specific way to deal with the rest.
>> We might also want to develop a common testing infrastructure for
>> libraries which, ideally, would work with all compilers.
> Right on. I'd like to propose we start from GHC's current testing
> system. It's a small collection of Python scripts (about 900
> lines), and is designed to be compiler-independent, although I
> haven't used it with anything except GHC yet.
That sounds good. I think we already plan (but haven't scheduled :-))
to do that for the compiler testing side so hopefully a more widely
useful library testing system could come out of it?
--
Alastair
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Record of STRefs better than STRef to a Record?
Hi all,
If I use an STRef to a record, will a new record be created each time I want
to update a single field? Or can I expect GHC to optimize it and have the
field of the record updated in place?
Right now I'm using a record of STRefs, like:
data E s = E{
refi :: STRef s Int,
refc :: STRef s Char
}
but it can get a little messy, since thread s propagates to every datatype
that uses the record type in it's definition.
Thanks,
J.A.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Record of STRefs better than STRef to a Record?
G'day all.
On Wed, Nov 13, 2002 at 04:05:42AM +, Jorge Adriano wrote:
> If I use an STRef to a record, will a new record be created each time I want
> to update a single field?
Basically, yes.
> Right now I'm using a record of STRefs, like:
> data E s = E{
> refi :: STRef s Int,
> refc :: STRef s Char
> }
>
> but it can get a little messy, since thread s propagates to every datatype
> that uses the record type in it's definition.
You could always use IORefs, if you don't mind having the IO monad
threaded through.
Cheers,
Andrew Bromage
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
