Numbers and Representation - Lets talk about BigDecimal

37 views
Skip to first unread message

Henrik Lindberg

unread,
Sep 11, 2014, 9:13:10 PM9/11/14
to puppe...@googlegroups.com
Hi,
Instead of continuing on the old thread "A question about numbers and
representation", I decided to open a new thread avout BigDecimal to see
if we can come to closure on that separately.

Digging a bit more into Ruby, and how it handles floating point reveals
that there is in fact no automatic fluent transition to BigDecimal. All
floating point calculations are performed with the native double
representation on the platform ruby is executing on. Since Puppet does
not create any BigDecimal numbers no one has ever been able to create a
value with higher precision in Puppet than what the native double
provides (unless doing so in custom Ruby functions I should add).

Integer representation is in contrast fluently transformed between a a
native fixed (long) and big integer representation.

Thus, the puppet language specification is currently wrong as it states
that Puppet's floating point fluently transforms.

The implementation difficulties with BigInteger can be handled both in
serialization and in PuppetDB; not without possible performance issues,
but still quite doable. But lets leave that for another later thread.

If we however want to add support for BigDecimal a lot more work is
required simply because this must be exposed to the Puppet programmer or
we will be using BigDecimals with a preset precision. We could possibly
create BigDecimals if > 15 value digits are entered, but it would mean
using something like 1.00000000000000000000 if you wanted 22 digits
precision (if I counted correctly :-)).

Having some sort of fluent handling of BigDecimals would also require
that all inputs in string form are parsed and turned into a floating
point number the same way (or we will lose precision there).

The biggest hurdle is dealing with scale, precision and rounding.
Typically this is specified in a math context that is passed when
performing each operation. This can not be done on a global basis as
that just sets another fixed limit. If the global math context is
shareable/writeable, no one can trust the precision of the calculations
as someone else could have changed the context. Thus, a global context
would have to be always set before using it... (horrible).

Thus, the only reasonable way of handling BigDecimals is as a set of
functions for creating them with a given precision, handle operations
like add, divide, multiply, etc. and passing around a hash that
describes the math context.

I seriously doubt the effort of implementing this will pay off. There
has been no requests for it (we would not be having this discussion
unless I started talking about numeric representation), the only
floating point use in puppet manifests that I have seen are for very
simple calculations. Finally, the domain of floating point calculations
has such a great complexity that I think is not suitable for neither the
Puppet Language nor its users.

What I can imagine though are special data types if they are indeed
needed (i.e. something with a given fixed precision, and given rounding
rules). The one that typically comes up is the type Money, but that is
not something that I expect to be used much in Puppet.

Given all the above, I think we should simply stick with the native
double for floating point the same way it is implemented and has been
working all along.

- henrik
--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

Ken Barber

unread,
Sep 11, 2014, 9:21:48 PM9/11/14
to puppe...@googlegroups.com
> Instead of continuing on the old thread "A question about numbers and
> representation", I decided to open a new thread avout BigDecimal to see if
> we can come to closure on that separately.
>
> Digging a bit more into Ruby, and how it handles floating point reveals that
> there is in fact no automatic fluent transition to BigDecimal. All floating
> point calculations are performed with the native double representation on
> the platform ruby is executing on. Since Puppet does not create any
> BigDecimal numbers no one has ever been able to create a value with higher
> precision in Puppet than what the native double provides (unless doing so in
> custom Ruby functions I should add).

So wow, this never worked? I can't say I'm surprised. I wonder if
there are any real world cases where people have done this in ruby
plugins.

ken.

Trevor Vaughan

unread,
Sep 11, 2014, 9:24:13 PM9/11/14
to puppe...@googlegroups.com
I'm voting for putting all your notes somewhere very easy to find in the future and then leaving everything the way it has been working.

This way, we can start up where you left off if necessary and, otherwise, continue on with more pressing issues.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/luthal%247p1%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

Thomas Hallgren

unread,
Sep 12, 2014, 9:26:31 AM9/12/14
to puppe...@googlegroups.com
So in essence it would be perfectly fine to state that Puppet has a hard 64-bit double limit today and say that support
for larger numbers may be a future enhancement? That would simplify things.

- thomas

> ken.
>

Henrik Lindberg

unread,
Sep 12, 2014, 12:47:58 PM9/12/14
to puppe...@googlegroups.com
BigDecimal is only mentioned once in the puppet code base in the
vendored RGen gem (it supports BigDecimal attributes (unused by Puppet
though)).

In Facter the CFPropertyList util checks if BigDecimal is defined and
uses it to parse a number and return a CFReal (I did not dig further how
CFReal is used). I guess this means that a CFReal could surface from
Facter somhow, but not sure what it does internally.

Erik Dalén

unread,
Sep 13, 2014, 6:05:35 AM9/13/14
to Puppet Developers
If it does surface one Puppet would turn it into a string, unless CFReal is subclass of Number.

--
Erik Dalén

John Bollinger

unread,
Sep 15, 2014, 10:34:10 AM9/15/14
to puppe...@googlegroups.com


On Thursday, September 11, 2014 8:24:13 PM UTC-5, Trevor Vaughan wrote:
I'm voting for putting all your notes somewhere very easy to find in the future and then leaving everything the way it has been working.



Agreed.  If Puppet does not actually support BigDecimal now, then I don't think it's pressing to add support at this time.


John

Reply all
Reply to author
Forward
0 new messages