Word128, Word256
Hi, Do you think we could have the range of sizes for Int* and Word* expanded to allow also 128 and 256 bits sizes? My reason is that I have a long standing issue trying to bind to C numerical libraries using complex numbers, as those are usually structs passed by value. See this from GNU GSL: typedef struct { double dat[2]; } gsl_complex; I imagine I could do: type GslComplex = Word128 -- size would depend on architecture and then write foreign declarations to have: get_real :: GslComplex -> CDouble get_imag :: GslComplex -> CDouble gsl_complex_sin :: GslComplex -> GslComplex gsl_complex_cos :: GslComplex -> GslComplex Do you think this is a reasonable request? Thanks for your attention, Maurício
jhc potentially has Word128, but it only has meaning when __int128_t is defined for a given target. (gcc + x86_64 for instance). What would something like Word256 mean? As in, the only reason to supply something like Word128 in the compiler is so FFI calls involving __int128_t will work, without a defined ABI type to map Word256 to, then a portable pure haskell implementation seems just as good. Your example doesn't seem to make sense, as the calling convention for __int128_t (what Word128 would map to) and double x[2] are unlikely to coincide. they are probably passed in different registers for instance. Adding the ability for the FFI to pass complex types directly would be useful. Something like 'CComplex CDouble' has been proposed before.. but that again would be independent of a Word128 type. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Something like 'CComplex CDouble' has been proposed before...
I know, I started most of the discussions :) The wiki says before asking for a ticket I should try to talk about it in the mailing list. My attempts never got much attention, but all replies gave favorable answers. Last week, though, I posted about it in haskell-prime and got no answers. I'm not sure what to do. Which would be the best option? 1) Since it's not important for enough people to make a big discussion, should I leave this for the future, maybe when Haskell become the language of choice for numerical work? Okay for me, as I sincerely believe this won't take much :) 2) Since all (few) answers were favorable, should I ask for a ticket to be created? How? Thanks, Maurício
On Sat, Oct 24, 2009 at 10:04:23PM -0200, Maurício CA wrote:
Something like 'CComplex CDouble' has been proposed before...
I know, I started most of the discussions :)
The wiki says before asking for a ticket I should try to talk about it in the mailing list. My attempts never got much attention, but all replies gave favorable answers. Last week, though, I posted about it in haskell-prime and got no answers.
I'm not sure what to do. Which would be the best option?
1) Since it's not important for enough people to make a big discussion, should I leave this for the future, maybe when Haskell become the language of choice for numerical work? Okay for me, as I sincerely believe this won't take much :)
2) Since all (few) answers were favorable, should I ask for a ticket to be created? How?
Well, before trying to get it standardized, you need to get it implemented and tested by at least one compiler to explore the design space and tradeoffs. I would happily accept any patches into jhc that a support for such types, I don't even think it would be that difficult to do. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Something like 'CComplex CDouble' has been proposed before...
2) Since all (few) answers were favorable, should I ask for a ticket to be created? How?
Well, before trying to get it standardized, you need to get it implemented and tested by at least one compiler to explore the design space and tradeoffs. I would happily accept any patches into jhc that a support for such types, I don't even think it would be that difficult to do.
One should say jhc code is really clear. It's the first compiler code I try to read and for a moment I actually believed I could write the patch :) Below is my completely naive attempt. If you want to tell me where to go from here, I'll try. (For instance: how do I get 'rt_bits_double_complex_' to exist.) However, I think this is far beyond my skills... Thanks for your thoughts, Maurício -------- hunk ./src/DataConstructors.hs 927 - (tc_World__, "void") + (tc_World__, "void"), + + (tc_CFComplex, "float complex"), + (tc_CDComplex, "double complex"), + (tc_CLDComplex, "long double complex") hunk ./src/data/names.txt 21 + +CFComplex Foreign.C.Types.CFComplex +CDComplex Foreign.C.Types.CDComplex +CLDComplex Foreign.C.Types.CLDComplex + hunk ./src/data/primitives.txt 24 -#Jhc.Float.Float, fbits<float>, float, FLT_MAX, FLT_MIN -#Jhc.Float.Double, fbits<double>, float, DBL_MAX, DBL_MIN +Jhc.Float.Float, fbits<float>, float, FLT_MAX, FLT_MIN +Jhc.Float.Double, fbits<double>, float, DBL_MAX, DBL_MIN hunk ./src/data/primitives.txt 43 +Foreign.C.Types.CFComplex, ubits<float complex>, float, 0, 0 +Foreign.C.Types.CDComplex, ubits<double complex>, float, 0, 0 +Foreign.C.Types.CLDComplex, ubits<long double complex>, float, 0, 0
On Mon, Oct 26, 2009 at 12:24:39AM -0200, Maurício CA wrote:
Well, before trying to get it standardized, you need to get it implemented and tested by at least one compiler to explore the design space and tradeoffs. I would happily accept any patches into jhc that a support for such types, I don't even think it would be that difficult to do.
One should say jhc code is really clear. It's the first compiler code I try to read and for a moment I actually believed I could write the patch :)
excellent :)
Below is my completely naive attempt. If you want to tell me where to go from here, I'll try. (For instance: how do I get 'rt_bits_double_complex_' to exist.) However, I think this is far beyond my skills...
A fairly good first attempt. The main issue is that 'primitives.txt' and its associated machinery is the old way of defining primitives that is slowly being phased out. Basically, what primitives.txt did was centralize a lot of 'compiler magic' as in, it created a lot of instances for things like Num and Storable that one might expect for built in types. However, as jhc progressed, it became clear that having things built into the compiler is a real pain. Hence, for newer primitives, they are simply implemented in pure haskell. as in, instead of some magic 'data Int' somewhere and a lot of compiler defined primitives, we have 'data Int = Int Word32_' and plain instance declarations like 'instance Num Int where ...' and so forth, with primitive operators being foreign imported. So, Double and Float have both been fully converted to the new way of doing things, so look at their implementation to see how complex versions of them should be handled. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
To have it defined is one thing. To actually implement i128 and i256 is
quite another thing. Are you willing to actually do all of the work
necessary to implement the unboxed i128 code?
Dream away!
2009/10/22 Maurício CA
Hi,
Do you think we could have the range of sizes for Int* and Word* expanded to allow also 128 and 256 bits sizes?
My reason is that I have a long standing issue trying to bind to C numerical libraries using complex numbers, as those are usually structs passed by value. See this from GNU GSL:
typedef struct { double dat[2]; } gsl_complex;
I imagine I could do:
type GslComplex = Word128 -- size would depend on architecture
and then write foreign declarations to have:
get_real :: GslComplex -> CDouble get_imag :: GslComplex -> CDouble gsl_complex_sin :: GslComplex -> GslComplex gsl_complex_cos :: GslComplex -> GslComplex
Do you think this is a reasonable request?
Thanks for your attention, Maurício
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
To have it defined is one thing. To actually implement i128 and i256 is quite another thing. Are you willing to actually do all of the work necessary to implement the unboxed i128 code?
Dream away!
John Meacham also told me that even if I get there, it wouldn't do what I want (use it to support complex numbers). Can you tell me what are the issues involved? From my naive view, something like CDComplex (mapping to C double _Complex) wouldn't be different than what's done for other basic types. Why am I wrong? Thanks, Maurício
Can you tell me what are the issues involved? From my naive view, something like CDComplex (mapping to C double _Complex) wouldn't be different than what's done for other basic types. Why am I wrong?
I think the compiler has to generate assembly code for all basic types. I can also imagine that types like a Word128 or Word256 are not natively supported in most common architectures. But I am no expert in this area.
participants (4)
-
John Meacham -
Maurício CA -
Roel van Dijk -
Scott Michel