[Oops, I'm realizing that I mentally conflated this IEEE 754 floating
point thread with the other "Some Floating Point Issues" thread due to the
similarity of the topics and the fact that my mailer sorted them in-line
with one another. The first bullet below, specifically, refers to the
"Some Floating Point Issues" thread. To my knowledge, nobody has
undertaken the features that are enumerated there, but not for any
philosophical reason...
Belatedly: Damian, I know it's a long way to travel from .au, but if you
were to find yourself at CHIUW in June, sitting you down with someone on
the Chapel team to pair-program some of these capabilities would be a
great activity for the code camp day...]
-Brad
On Tue, 19 May 2015, Brad Chamberlain wrote:
>
> Hi Damian --
>
> Michael's done a great job of getting much of this thread covered, and I
> haven't been able to keep up with it (just gave it a quick review now).
> Here are a few quick reactions (apologies if I've overlapped with things
> you guys have already established -- it really was a quick read):
>
> * Personally, I don't have any opposition to supporting more standard
> module/library-based support for floating point utility functions and
> values along the lines of what you're proposing. As I've mentioned,
> there's always been a strong sense that we need to do more for the
> floating point community, but it isn't something that's become a
> priority or show-stopper to date. We'd be particularly happy for any of
> it to be contributed back to the project from the community, and
> would consider prioritizing it ourselves (or adding enabling features
> that would permit the community to [more easily] develop such features),
> particularly if they aided in adoption (and I think that they ultimately
> would).
>
> * You're correct that the real(*) versions of abs() in Math.chpl aren't
> as trivial as fiddling with a bit --- unless the fabs calls that they
> use will do so, either directly or as optimized by the C compiler.
>
> * Generally, my answer for doing C-style unions or casts would be to do
> that in a C (static inline?) function or macro and call it from Chapel.
> I.e., leave the gross stuff in C rather than Chapel.
>
> * Regarding your bits(n) type proposal. This concept comes up with some
> regularity, and doesn't give me as many grey hairs (maybe due to
> naivete?) as many other things. I think it would be reasonably
> straightforward to add, particularly once we have user-defined coercions
> and casts in the language. The stickiest issue would probably be
> a religious debate about whether the presence of such a type would
> suggest supporting fewer bit-style operators on plain old ints/uints
> (where my intuition would be to support the current set of int/uint ops
> for convenience rather than any need to be "pure" about which types
> permit bit manipulation and which don't; though I guess one could
> extend that argument to real()s and ask why we don't permit bit
> manipulations on them...).
>
> -Brad
>
>
> On Mon, 18 May 2015, Damian McGuckin wrote:
>
>>
>> Hi Michael,
>>
>> On Mon, 18 May 2015, Michael Ferguson wrote:
>>
>>> I do have one question for you about this. The C function frexp breaks
>>> up a floating point number into a normalized fraction (stored as a
>>> double) and an exponent.
>>
>> Yes.
>>
>> frexp(double mantissa, int *exponent)
>> frexpf(float mantissa, int *exponent)
>> frexpl(long double mantissa, int *exponent)
>>
>> I always try to avoid with a passion such call function overhead. They do
>> tend to confuse optimizers. That is not currently a big issue for Chapel
>> because Chapel does not by itself create assembler. However, in the future
>> when the language gets to be a full-blown compiler, it will be an issue.
>> Going back to try and fix the problem in hindsight is always difficult and
>> frustrating.
>>
>> In C++ which has the C concept of bit fields, I can to do something like
>>
>> #include <ieee754.h>
>>
>> float f = (float) 10.5; // copy 10.5 from memory into a register
>> union ieee754_float ft = {f}; // copy/write-back to memory here
>> unsigned int negative = ft.ieee.negative;
>> unsigned int mantissa = ft.ieee.mantissa;
>> unsigned int exponent = ft.ieee.exponent;
>>
>> No overhead except for a copy/write-back into the memory used by 'ft'.
>> Note that I think those unions in 'ieee754.h' need an extra integral
>> field, not that I have any input to the standards committee.
>>
>>> Do you know how to convert that behavior to returning the mantissa
>>> as an integer?
>>
>> Yes. But this may not often be an issue. I normally want to either throw
>> away, or re-use (as-is), the mantissa.
>>
>> I want lean and lucid. So probably too messy for what I want.
>>
>>> Is it important to you to get an integer mantissa versus a normalized
>>> fraction?
>>
>> It makes it easier to put things back together again. So I will say yes
>> but that not be the full answer.
>>
>>> Do you know why the fractional mantissa strategy was chosen for C?
>>
>> Yes. But that's a topic for discussion on another day, preferably over a
>> cold decent beer to help drown/cool any disagreement heat in words that
>> might be flying around. I lament that we still have mathematical libraries
>> which have an interface which dates back long before I even knew what a
>> computer was!! Let's go offline if you want to discuss that one. And we
>> might need a referee!
>>
>>> I think it would be straightforward to implement something in the
>>> runtime that calls these C functions.
>>
>>> Alternatively, we could use the implementation similar to what you have
>>> described as some C functions (that are inline) in the runtime.
>>
>> That sounds interesting. How do you create/write C functions that then get
>> effectively expanded in-line in the C code which Chapel creates?
>>
>>> Either way, I think that the best approach here is to implement it as
>>> part of the runtime (rather than give Chapel the ability to use C
>>> unions, e.g.).
>>
>> Ultimately, that sounds an extremely sound approach. Not reall my field of
>> expertise.
>>
>>> You could implement it in C for now.
>>
>> OK. However, but how far do you take that argument? Such discussions can
>> degrade to the point where something like writing the module Norm should
>> be done in C. That becomes a deal-breaker and defeats the Chapel-ification
>> purpose. Or heaven forbid, you use some in-line assembler within Chapel.
>> But then you then need versions for X86-64, ARM, SPARC, MIPS, ..... Yuk.
>> Not my scene. Oops, probably time for another discussion over a beer, or
>> considering it is in-line assembler, something stronger????
>>
>>> I suppose an alternative would be to use the Chapel support for C
>>> interoperability to memcpy from the real(64) to a uint(64) and then do
>>> your shifting and extracting.
>>
>> Hmmmm. That would kill the ootimizer too. But following on from that, If
>> you added a new concept to Chapel (to give Brad a few more grey hairs) and
>> had a neutral type (bits) that allows copies in/out at will, i.e. without
>> casting as in ...
>>
>> var lf : real(64);
>> .....
>> ...assign value to lf ...
>> .....
>> var vlf : bits(64) = lf;
>> ....
>> var ieeelf : int(64) = vlf;
>>
>> or even something like
>>
>> var lf : real(64);
>> .....
>> ...assign value to lf ...
>> .....
>> var ieeelf : int(64) = lf:bits(64);
>>
>> this might be an option because most optimizers would probably sort out
>> any irrelevant or redundant operations/transformations.
>>
>>> I still think it would be better to do the whole operation in C myself.
>>
>> See my earlier comment.
>>
>>> P.S. I'm hoping that the hex floats patch will go in this week...
>>
>> Beauty. That's cool.
>>
>> Thanks - Damian
>>
>> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
>> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
>> Views & opinions here are mine and not those of any past or present employer
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Chapel-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/chapel-users
>>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Chapel-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-users
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
