On Jun 18, 2014, at 8:38 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:>> >> On 2014 Jun 18, at 13:29, Owen Anderson <resistor at mac.com> wrote: >> >> Numerical analysis is hard. Every numerics expert I have ever worked with considers trying to re-invent floating point a cardinal sin of numerical analysis. Just don’t do it. You will miss important considerations, and you will pay the price for it later. Plus, anyone in the future who wants to modify your code has to learn a new set of non-standard floating point numerics, and without a well-defined specification it’s not always clear what the correct semantics in a particular case are. > > Okay. To me this sounds like dogma, but I'll defer to your judgement.Is there any way we have this utility and just not claim that it is for use with a numerics package? The only claim we’re making is that it is a useful utility for writing compiler heuristics. We can do that without waking any Dragons, and Duncan’s design is quite straightforward. I think calling it a “soft-float” implementation was a mistake (even though that’s what it is), and has completely derailed this thread. The goal is to factor and reuse the code that we need to reinvent every time we need to extend the dynamic range of some of cost metric. The question here is whether that in itself a worthwhile goal, independent of how the compiler models language level floats. I have nothing *against* repurposing APFloat. After all, we only have a couple metrics in tree that need this new utility. But let’s be clear that APFloat's purpose is completely different, so it’s not like we’re reinventing any existing utility. I honestly think we should consider not calling this a Float at all just to avoid the obvious confusion. I’m fine calling it a ScaledNumber or something. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140618/3af59c6b/attachment.html>
Duncan P. N. Exon Smith
2014-Jun-19 23:56 UTC
[LLVMdev] [RFC] Add a scaled number class (was: Add a simple soft-float class)
> On 2014-Jun-18, at 21:14, Andrew Trick <atrick at apple.com> wrote: > > Is there any way we have this utility and just not claim that it is for use with a numerics package? The only claim we’re making is that it is a useful utility for writing compiler heuristics. We can do that without waking any Dragons, and Duncan’s design is quite straightforward. > > I think calling it a “soft-float” implementation was a mistake (even though that’s what it is), and has completely derailed this thread. > > The goal is to factor and reuse the code that we need to reinvent every time we need to extend the dynamic range of some of cost metric. The question here is whether that in itself a worthwhile goal, independent of how the compiler models language level floats. I have nothing *against* repurposing APFloat. After all, we only have a couple metrics in tree that need this new utility. But let’s be clear that APFloat's purpose is completely different, so it’s not like we’re reinventing any existing utility. > > I honestly think we should consider not calling this a Float at all just to avoid the obvious confusion. I’m fine calling it a ScaledNumber or something.Thanks Andy for refocusing the discussion. This is not a float. This is not a replacement for a APFloat, and it is not a numerics library (or the start of one). It's a number with a scale that has simple integer-like semantics, useful for extending the dynamic range of cost metrics. Owen and I talked off-line, and he's okay with this going in the tree with a couple of conditions: 1. The name matters. The biggest danger here is that someone sees this and thinks it's appropriate for general numerics, or otherwise "bigger than it is". A couple of ideas are "UnsignedScalar" (too generic?) and "CostMetric" (too specific?). 2. Header docs should clearly describe the restricted problem domain appropriate to this class, and should forward those looking for a soft-float to `APFloat`. For now I'm going with `CostMetric` in `include/llvm/Support/CostMetric.h` and `lib/Support/CostMetric.cpp`. I'll start by extracting helper functions into the same files in the `llvm::CostMetrics` namespace, and then eventually rename the class to `llvm::CostMetric` and move it over. *enable-bikeshed-mode* [All the names are wrong. Paint them?]
Chandler Carruth
2014-Jun-20 00:08 UTC
[LLVMdev] [RFC] Add a scaled number class (was: Add a simple soft-float class)
I don't really have a problem with the direction, but... On Fri, Jun 20, 2014 at 12:56 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote:> For now I'm going with `CostMetric` in `include/llvm/Support/CostMetric.h` > and > `lib/Support/CostMetric.cpp`. >It's not a metric as it isn't measuring anything. You implement metrics in terms of this. ;] Anyways, I much prefer any bikeshed paint color which emphasizes that this is a number rather than being overly specific. I like ScaledNumber or ScaledQuantity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/1e424e58/attachment.html>
Evan Cheng
2014-Jun-20 00:15 UTC
[LLVMdev] [RFC] Add a scaled number class (was: Add a simple soft-float class)
On Jun 19, 2014, at 4:56 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:> >> On 2014-Jun-18, at 21:14, Andrew Trick <atrick at apple.com> wrote: >> >> Is there any way we have this utility and just not claim that it is for use with a numerics package? The only claim we’re making is that it is a useful utility for writing compiler heuristics. We can do that without waking any Dragons, and Duncan’s design is quite straightforward. >> >> I think calling it a “soft-float” implementation was a mistake (even though that’s what it is), and has completely derailed this thread. >> >> The goal is to factor and reuse the code that we need to reinvent every time we need to extend the dynamic range of some of cost metric. The question here is whether that in itself a worthwhile goal, independent of how the compiler models language level floats. I have nothing *against* repurposing APFloat. After all, we only have a couple metrics in tree that need this new utility. But let’s be clear that APFloat's purpose is completely different, so it’s not like we’re reinventing any existing utility. >> >> I honestly think we should consider not calling this a Float at all just to avoid the obvious confusion. I’m fine calling it a ScaledNumber or something. > > Thanks Andy for refocusing the discussion. > > This is not a float. This is not a replacement for a APFloat, and it is not a > numerics library (or the start of one). It's a number with a scale that has simple > integer-like semantics, useful for extending the dynamic range of cost metrics. > > Owen and I talked off-line, and he's okay with this going in the tree with a couple > of conditions: > > 1. The name matters. The biggest danger here is that someone sees this and thinks > it's appropriate for general numerics, or otherwise "bigger than it is". > > A couple of ideas are "UnsignedScalar" (too generic?) and "CostMetric" (too > specific?). > > 2. Header docs should clearly describe the restricted problem domain appropriate > to this class, and should forward those looking for a soft-float to `APFloat`. > > For now I'm going with `CostMetric` in `include/llvm/Support/CostMetric.h` and > `lib/Support/CostMetric.cpp`. I'll start by extracting helper functions into the > same files in the `llvm::CostMetrics` namespace, and then eventually rename the class > to `llvm::CostMetric` and move it over.I agree with taking a pragmatic approach on this. Making APFloat sucking less so we can eventually replacing this UnsignedFloat package should be a longer term goal. But it should not block short term progress. Evan> > *enable-bikeshed-mode* [All the names are wrong. Paint them?] > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Sean Silva
2014-Jun-20 23:40 UTC
[LLVMdev] [RFC] Add a scaled number class (was: Add a simple soft-float class)
On Thu, Jun 19, 2014 at 5:56 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote:> > > On 2014-Jun-18, at 21:14, Andrew Trick <atrick at apple.com> wrote: > > > > Is there any way we have this utility and just not claim that it is for > use with a numerics package? The only claim we’re making is that it is a > useful utility for writing compiler heuristics. We can do that without > waking any Dragons, and Duncan’s design is quite straightforward. > > > > I think calling it a “soft-float” implementation was a mistake (even > though that’s what it is), and has completely derailed this thread. > > > > The goal is to factor and reuse the code that we need to reinvent every > time we need to extend the dynamic range of some of cost metric. The > question here is whether that in itself a worthwhile goal, independent of > how the compiler models language level floats. I have nothing *against* > repurposing APFloat. After all, we only have a couple metrics in tree that > need this new utility. But let’s be clear that APFloat's purpose is > completely different, so it’s not like we’re reinventing any existing > utility. > > > > I honestly think we should consider not calling this a Float at all just > to avoid the obvious confusion. I’m fine calling it a ScaledNumber or > something. > > Thanks Andy for refocusing the discussion. > > This is not a float. This is not a replacement for a APFloat, and it is > not a > numerics library (or the start of one). It's a number with a scale that > has simple > integer-like semantics, useful for extending the dynamic range of cost > metrics. > > Owen and I talked off-line, and he's okay with this going in the tree with > a couple > of conditions: > > 1. The name matters. The biggest danger here is that someone sees this > and thinks > it's appropriate for general numerics, or otherwise "bigger than it > is". > > A couple of ideas are "UnsignedScalar" (too generic?) and "CostMetric" > (too > specific?). > > 2. Header docs should clearly describe the restricted problem domain > appropriate > to this class, and should forward those looking for a soft-float to > `APFloat`. > > For now I'm going with `CostMetric` in `include/llvm/Support/CostMetric.h` > and > `lib/Support/CostMetric.cpp`. I'll start by extracting helper functions > into the > same files in the `llvm::CostMetrics` namespace, and then eventually > rename the class > to `llvm::CostMetric` and move it over. > > *enable-bikeshed-mode* [All the names are wrong. Paint them?] >my 2c: describe it as "an approximate, high-dynamic-range unsigned integer". That doesn't lend itself to something easy to type, but "ApproxHDRUint" might be doable. Plus, it sounds sort of scary. Having something in the name that suggests that it is an integer should ward off any attempt to use it for numerics. -- Sean Silva> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140620/3bed23d1/attachment.html>