llvm dev - Jun 2014 - [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>

On 21 June 2014 00:40, Sean Silva <chisophugis at gmail.com>
wrote:
>
>
> 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
>
I would suggest that "high-dynamic-range" is also the wrong word. It
is not actually providing any extra dynamic range.
Having something that can go from 0 to 20 in steps of 2 has no better
dynamic range as something that can go from 0 to 10 in steps of 1.
Simply calling it "scaled unsigned integer" is more accurate.
Or "unsigned integer with scale factor".

I think it would also be a good idea to explain what maths operations
you are likely to want to do.
For example, if the number is 20, with scale factor 2, and you add 1
with scale factor 1 to it, the answer is undefined.
If all you are going to do is somehow reach a value and then is won't
change, and the only operations you are going to do are "compare"
operations, then that is something that is easier to understand for
other programmers.

Just out of curiosity, what is the requirement or use case that is
driving a "scaled unsigned integer" instead of say just using an
integer with more bits.

James

Hello James, hello folks!

 > Simply calling it "scaled unsigned integer" is more accurate.
 > Or "unsigned integer with scale factor".

Stupid question: Why only unsigned?
Doesn't such a construct make also sense for signed numbers?
What about scaled floats?

Best regards
Jasper

On Sun, Jun 22, 2014 at 1:48 AM, James Courtier-Dutton <
james.dutton at gmail.com> wrote:
> On 21 June 2014 00:40, Sean Silva <chisophugis at gmail.com> wrote:
> >
> >
> > 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
> >
>
> I would suggest that "high-dynamic-range" is also the wrong word.
It
> is not actually providing any extra dynamic range.
>
Dynamic range is the ratio between the largest and smallest representable
value (see http://en.wikipedia.org/wiki/Dynamic_range). So yes it does
provide more dynamic range; in fact, pretty much the entire purpose of
using floating point numbers is to extend the dynamic range (see
http://en.wikipedia.org/wiki/Floating_point).

What changes is the distribution of the numbers; they are no longer
uniformly distributed (see Knuth 4.2.4 "Distribution of Floating Point
Numbers" or google for "distribution of floating point numbers").

-- Sean Silva

> Having something that can go from 0 to 20 in steps of 2 has no better
> dynamic range as something that can go from 0 to 10 in steps of 1.
> Simply calling it "scaled unsigned integer" is more accurate.
> Or "unsigned integer with scale factor".
>
> I think it would also be a good idea to explain what maths operations
> you are likely to want to do.
> For example, if the number is 20, with scale factor 2, and you add 1
> with scale factor 1 to it, the answer is undefined.
> If all you are going to do is somehow reach a value and then is won't
> change, and the only operations you are going to do are "compare"
> operations, then that is something that is easier to understand for
> other programmers.
>
> Just out of curiosity, what is the requirement or use case that is
> driving a "scaled unsigned integer" instead of say just using an
> integer with more bits.
>
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140622/12956ff2/attachment.html>

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On
> Behalf Of James Courtier-Dutton
>
> I think it would also be a good idea to explain what maths operations
> you are likely to want to do.
> For example, if the number is 20, with scale factor 2, and you add 1
> with scale factor 1 to it, the answer is undefined.
"Undefined" is too strong a term here.  Typically with scaled
arithmetic
you'd do all operations in a sufficiently wide representation that you
compute the correct pure numerical result, and then possibly modify
that result as needed (may include rounding) to match the desired output 
scale.  You can do the operations with narrower representations if you 
can prove that the scaled result would be unaffected.

That is: adding 10 to 0.1 and asking for an integer result is not an 
undefined operation; it will yield the well-defined value 10.
> Just out of curiosity, what is the requirement or use case that is
> driving a "scaled unsigned integer" instead of say just using an
> integer with more bits.
It's more compact, and often the low-order bits of a large result are
not particularly relevant.
--paulr