Allow points with decimal places

I am still opposed to actually use a float to store the points.

The reason is simple. It is not exact. So you could give 0.01 points and it would be saved as 0.0099754665 (just an example). That sums up... Some use this module to allow to buy stuff or buy points with real money. So we need to be sure that we are exact...

What we could think about is an option to consistently implement a option to specify the number of decimal places *but continue to save it as an integer*. However, that will be a non-trivial task, because we need to take care of both input and output.

- Output: This is relatively easy. We just need a userpoints_format_points() function that needs to be used everywhere where points are printed which converts for example 100 to "1.00", when you have two decimal places.

- Input: This could be trickier. Think of the dozens of modules out there with configuration options for setting the amount of points you get for something. I think the easiest option would be to implement a custom form field, so that all these modules can simply do "'#type' => 'userpoints_points'". That form field will do two things: Verify that the amount is entered in the correct way. If you have set it to two decimal places, you *must* specify the points value everywhere as "2.00" and not "2". To be sure that the admin is aware what exactly he is setting it to. b) It must implement a value callback to return "2.00" as 200.

We also need to think about what changing that setting implies. My suggestion would be that setting it from "0" (the default) to "2" means that if a user had 100 points now, he simply has "1.00" now. Everything else is too complex.

Am I missing something or has the three year discussion (starting back at version 5) about decimal places with userpoints still not made it into code on version 7? I installed version 7 but it still appears the points fields are intergers, not decimals. Am I to assume, at this time, If I want decimals I must manually change the field format type to decimal and hack(remove) references to (int) in the code? If this is the case I will but I somewhat surprised we still don't have a decimal point setting in this new version, unless I'm missing something?

Also, I changed format of fields in userpoints table and transaction table. For now, I am able to use points with decimals. But it appears the total points is not a running calculation of transaction points because the transaction table is not storing decimal values yet the userpoints total field is? I am giving .01 point for making a comment. When I do this, 0.00 is stored in transaction table and .01 is added to the total in userpoints total field. I cant seem to get the .01 to be inserted properly into the transaction table?

No it is not compatible and it is very likely that calculations are casted to an integer. Just changing the database schema won't be enough.

Features don't magically emerge when discussing them, someone needs to implement it. See #1 for how I envision this to work in Drupal 7, patches are welcome.

@berdir The upgrade to Drupal 7 is something we should take advantage of. Continuing with integer is not a good solution to this problem. I think we are all aware that this module should have been built with float/decimal to begin with.

Whenever possible we should store real data in the database and not modify/format it with code (i.e. by storing 150 even though we know it is truly 1.50). Not only does this ensure data integrity over time but it also allows other modules to utilize our data correctly. A good example here is Views. Unless we write a new data handler and always intercept views the views module will write a SQL query that will return 150 and all modules that work with views will see that data amount. Instead the database should return 1.50, decimal and all.

I'm well aware that this change to the database will modify the API and require changes to the core of this module, which will ripple through all contributed modules. However, the upgrade to Drupal 7 gives us the perfect opportunity to make this change. Those modules have to be upgraded to work with Drupal 7 and having them modify (pretty slightly) to work with float/decimal will not be too much additional work.

In short. Let's move this to float/decimal and phase out the use of integer.

PHP does not have an exact decimal variable type.

There is only float (not exact, rounding errors could happen, which is not acceptable when using userpoints as a virtual currency) and integer.

So, I don't see a way to use anything else than integer. This is IMHO how all systems deal with currencies: Use the smallest available currency (e.g. 100 cents instead of 1.00 dollars).

Providing a field handler to be used with views is easy, we for example already need one for the category anyway (For the general category, that is not actually a term).

*Even* if we would use float for this, we'd still have to use a common theme function/display function to ensure a consistent amount of decimal places everywhere. For Views and everywhere else.

Ubercart uses a decimal format with 3 decimal places. Not suggesting this is the best way but I'm confused at the comment "php does not "have an exact decimal variable type". How much would it cost to move the discussion to implementation? I'd be willing to chip in, soon.

@berdir Using integer as a method of storing currency is one method but I haven't found it to be the most common or a standard. Ubercart uses a numeric database type (i.e. MySQL decimal), zencart (php based) uses decimal. You also don't have to define a format if you set your database to store only 2 decimal places. Without the use of float/decimal in the database you have to filter the input and output. For example, when one enters .03 as a point value you would need to translate that to 3 before entering it into the database. Then on output you modify that back to .03 for display. Finally views already understand floats and has a formatter for it, which defaults to 2 places. So you don't need to modify it.

ubercart isn't exactly the project that I would use as an example :)

Drupal Commerce does use an integer, for example:

      'amount' => array(
        'description' => 'The price amount.',
        'type' => 'int',
        'not null' => TRUE,
        'default' => 0,
      ),
      'currency_code' => array(
        'description' => 'The currency code for the price.',
        'type' => 'varchar',
        'length' => 32,
        'not null' => TRUE,
      ),

As said before, PHP does not have a fixed decimal data type. If you have a fixed decimal in your database with 2 decimal places, it will be converted to a float in PHP. And with a float, when you add 3.0 and 3.0, you will eventually end up with 5.99 oder 6.01, depending on how it's rounded.

See also: http://stackoverflow.com/questions/3819508/best-practice-for-working-wit...

Ok, so where do we go from here? Can I pay someone to do the patch you're suggesting? As stated above, sooner than later?

@Berdir I can see your point and if you'd like to continue with integer I could get behind it. Although I'm not a fan of it by any means.

The next question that has to be resolved is how to deal with all of the past points. If we decide that 1 point is now actually 100 (with two decimal points), we have to go to all previously awarded points and multiply by 100 and hard code a 2 place decimal (cringe). This means updating the transaction table and also the summary table. There also needs to be a routine for deciding how to prevent this update from running twice or creating a "transaction" in order to roll back if an update of all rows were to fail part way through

Yes, changing the amount of decimal places is a problem. In theory, it is also a problem for a DECIMAL storage type, but we could work around that by always storing 5 decimal places and just allowing 0-5 to choose from.

I can see a few options here:

- Not deal with it at all. Just telling users what effect it has when that option is changed. Not really a solution but very easy to implement ;)
- Store the amount of decimal places for every transaction and user. Then we only need to convert old rows if they are changed. Requires an additional column and I don't see a way to make this work for all the variable_get() configurations. Unless we add a userpoints_variable_get_points() or so and save them as an array.
- Changing all existing transactions. Rather complicated and very slow if you have many transactions and users.
- Always store points with *5. Still requires an initial conversion for existing sites and a lot of overhead of all the users which don't need it (which I assume is most of the users).
- Store the decimal places in a separate column. That basically means creating a custom DECIMAL storage type. That I just thought of and I kinda like this solution. The advantage is that we can work around PHP's limitation of not having a decimal variable type (Not by default that is, although there are extensions like bcmath). And there is very little overhead for users which do not use this. And modules which don't support decimal places (in their configuration and so on) still work. Since points configurations are stored as a string, we could actually support storing '12.5' points as a variable and then take it apart in the API.

Anyone available for hire to get this patch done sooner than later?

Thanks

@berdir I read your stack overflow link, and it seems you're correct. In the long run, for sure.

If I use a decimal format in the database, until the patch or a revision is made for integer, will I be able to convert the records afterward? I'd expect if I am storing 45.50 points in a decimal format, the new integer format will store it as 4550. Is this correct? And if so, wouldn't I need to run a query to multiply all of my points fields by 100 before I convert or update the decimal format to an integer? Would it be as simple(or difficult) as changing the 45.50 to 4550 and then changing the format back to integer before updating to the new module?

I really need to use a 2 decimal point format now. I am looking for the least painful way to use the data now and also when version 7.x,2.x has the new format.

Thanks

@Berdir

A separate column would provide the best backwards compatibility but because you would rarely (if ever) have an instance where one row has a decimal place of 2 and another row with a decimal place of 3 this column would be unnecessary overheard going forward.

I think it is best to just focus on writing a simple transactional routine that updated all past rows. On the plus side this same routine can be used anytime someone wanted to adjust the granularity of the decimal places.

For example (pseudo code)
-----
function userpoints_add_decimal_place(dec_places) {
$records = db_query('select txn, point from userpoints_txn');
foreach ($record as $records) {
$point = $record['point'] * dec_places; (this needs to be 10, 100, 1000, etc.)
db_query('UPDATE {userpoints_tax} SET point = %d WHERE txn >= %d', array($point, $record['txn']))
}
-----

Of course we should use db_update() in D7 and preferably this would be in a transaction. Due to the lack of transaction perhaps this routine could create a temporary table to track all rows updated so they could be rolled back if need be.

Sub

Are we moving forward with this? Just curious. Not sure what else I should do. I can't write code but I've offered to pay more than once. And i've gotten no response. The "free" drupal system sure does cost as far as, time waiting. #Yawn

Money is not the issue, time is. I started a new job this week, am moving and was away some time. Also, I first want to get out a stable 7.x-1.0 version. Only after that I'm going start a 7.x-2.x branch and work on new features.

Thanks Berdir. My comment wasn't for you, specifically. Maybe I don't know how the processes go around here. I'm posting my comment, in general, hoping someone with coding experience, who wants to make money, will see the comment. Do you know of a company who does Drupal independent work for this stuff?

It looks like a lot of pressure is put on you, and a lot of patience, and waiting is required for people like me. What does a company usually do if they need a feature? I'd assume the following?

1. Wait
2. Pay module maintainer for customization
3. Build own module
4. Pay coder to hack some code
5. Is it possible for someone who knows what the're doing to build a separate module that turns userpoints into decimals? Or allows you to input 135.05 at the user interface, code multiplies it by 100, then stores in database as 10305 and then that module would also divide the data by 100 anytime it's being presented to a user? Could someone do a separate module that would do that? If so, this may be my quickest route?

Thanks

Providing a better title and changing the targetted version.

Sub
is it possible to have an approximate timeline ? just to have an idea if we can expect the changes to be made in a matter of day(s), week(s), month(s)....
I would understand if there is no timeline at all :-)

Thanks !

I just paid MasterChief for a module which allows decimals. I installed it tonight. It works very well. I had one issue and I emailed him about it. Should be solved tomorrow. He did an excellent job!

I did an initial review of the patch attached in #1289348: New upgrade not compatible with Master chiefs decimal customization, below is my feedback.

- Nice work, looks pretty good
- More detailed review below
- Tons of trailing spaces and tabs instead of two spaces. you can see the for example with http://drupal.org/project/dreditor or when using "git diff" in a colored bash terminal.
- I've unfortunately rewritten userpoints_userpointsapi() completely, so these parts will need to be updated.
- Your patch made it work which is great, what we need to do now is make it easy to use for developers, so that it will be easy for the dozens of modules with integrate with userpoints to become compatible with this.
- Views, rules and services integration will need to be updated too as a starting point.

diff --git userpoints.admin.inc userpoints.admin.inc
index 1154b56..92438b4 100644
--- userpoints.admin.inc

You need to use git diff without the -p0 option, as this is required now for official patches.

+++ userpoints.admin.incundefined
@@ -296,9 +296,15 @@ function userpoints_admin_txn_validate($form, &$form_state) {
+  ¶
+  $points = userpoints_split_floats($form_state['values']['points']);
+  ¶
+  if ($points['points'] == "") {
+    form_set_error('points', t('You need to use this format => "0.XX"', userpoints_translation())); ¶

My suggestion would be that we define a new form elements called 'userpoints_points' through hook_elements_info(). Then we can use that everywhere where points are set. We can use userpoints_split_floats() in a #value_callback.

However, I'm not yet sure how to store points settings as variables. Doing it as an array there would be rather unconfortable unless we provide a helper function somehow.

+++ userpoints.admin.incundefined
@@ -798,6 +805,37 @@ function userpoints_admin_settings($form, &$form_state) {
+  $form[$group] = array(
+    '#type'        => 'fieldset',
+    '#collapsible' => TRUE,
+    '#collapsed'   => TRUE,
+    '#title'       => t('Decimal settings'),

#group definition is missing to make this a vertical_tab. Have a look at the other fieldset definitions.

Also, a summary would be great for this, have a look at userpoints_admin.js for examples.

+++ userpoints.admin.incundefined
@@ -798,6 +805,37 @@ function userpoints_admin_settings($form, &$form_state) {
+    '#options'       => array(0 => 0, 1 => 1, 2 => 2, 3 => 3, 4 => 4, 5 => 5, 6 => 6, 7 => 7, 8 => 8),

Do we really want to allow up to 8 decimal places? Just a question, not sure..

Also, you don't need to specify the key explicitly, this is the default key value (0...)

+++ userpoints.admin.incundefined
@@ -798,6 +805,37 @@ function userpoints_admin_settings($form, &$form_state) {
+    '#size'          => 1,
+    '#title'         => t('Decimal point'),
+    '#default_value' => variable_get(USERPOINTS_DECIMAL_POINT, '.'),
+    '#description'   => t('Set the decimal point that will be used.'),
+  );
+  $form[$group][USERPOINTS_THOUSANDS_SEPARATOR] = array(
+    '#type'          => 'textfield',

I haven't seen it yet, but I assume that #size 1 looks rather strange. I'd suggest to make this a bit bigger (3 or so) and add a #max_length key of 1 so that it can't be bigger (#size is just the textfield size, not the allowed characters)

+++ userpoints.admin.incundefined
@@ -798,6 +805,37 @@ function userpoints_admin_settings($form, &$form_state) {
+    '#default_value' => variable_get(USERPOINTS_THOUSANDS_SEPARATOR, ','),

I think we should default to an empty thousands separator here, because that's what we've done before. And if not, we should try to get the locale default for it as the default value.

+++ userpoints.installundefined
@@ -30,12 +30,24 @@ function userpoints_schema() {
+	  'points_dec' => array(

Tab here.

+++ userpoints.installundefined
@@ -73,12 +85,24 @@ function userpoints_schema() {
+	  'points_dec' => array(
+	    'description' => 'Decimal Points',
+		'type' => 'int',
+		'not null' => TRUE,
+		'default' => 0,

More tabs

+++ userpoints.installundefined
@@ -331,4 +361,45 @@ function userpoints_update_7004(&$sandbox) {
+  db_add_field('userpoints_total', 'points_dec', array(
+    'type'        => 'int',
+    'not null'    => TRUE,
+    'default'     => 0,

Make sure you're using the same description as above here. (Which is kinda strange but so is the current max_points description).

+++ userpoints.installundefined
@@ -331,4 +361,45 @@ function userpoints_update_7004(&$sandbox) {
+  db_add_index('userpoints', 'points_dec', array('points'));
+  db_add_index('userpoints_total', 'points_dec', array('points'));

Not sure if we need these indexes, we only do if there are query conditions on these fields, which I doubt.

Also, if we *do* want them, they need to be added to hook_schema() too.

+++ userpoints.installundefined
@@ -331,4 +361,45 @@ function userpoints_update_7004(&$sandbox) {
 }
\ No newline at end of file

What it says :)

+++ userpoints.moduleundefined
@@ -31,6 +31,10 @@ define('USERPOINTS_CATEGORY_DEFAULT_TID', 'userpoints_category_default_tid');
+define('USERPOINTS_DECIMAL_POINT', 'userpoints_decimal_point');
+define('USERPOINTS_THOUSANDS_SEPARATOR', 'userpoints_thousands_separator');

I'm not too fond of using constants for variable names and will probably drop them at some point it 7.x-2.x. It might make sense to do this from the beginning here.

+++ userpoints.moduleundefined
@@ -873,6 +878,11 @@ function userpoints_userpointsapi($params) {
+  // Split the full points from the decimals
+  $points = userpoints_split_floats($params['points']);
+  $params['points'] = $points['points'];
+  $params['points_dec'] = $points['points_dec'];    ¶

Note that this will need to be updated as I've completely rewritten this in 7.x-2.x. The total calculations and the message formatting will need to be updated too as it has moved, but it hasn't changed much (yet).

+++ userpoints.moduleundefined
@@ -1290,7 +1335,7 @@ function userpoints_get_points_list($account = NULL) {
+      $points = userpoints_catenate(userpoints_get_current_points($account->uid, $tid == 'uncategorized' ? 0 : $tid), userpoints_get_current_points($account->uid, $tid == 'uncategorized' ? 0 : $tid), TRUE);

This is kinda long. I suggest we add a wrapper function or something which allows to get the catenated points for a given uid/tid.

+++ userpoints.moduleundefined
@@ -1682,6 +1728,61 @@ function userpoints_get_default_tid() {
+ * Prepares a decimal string for correct storage
+ * @param <type> $params ¶

should be removed, $string instead of $params and a description of the param should be added on the line below, indented tw spaces. Also, maybe use a better variable name than $string?

+++ userpoints.moduleundefined
@@ -1682,6 +1728,61 @@ function userpoints_get_default_tid() {
+/**
+ * Splits float inputs into fulls and decimals
+ * @param <type> $points
+ * @return <type>
+ */

Same here, a empty space above @param, no type, param description, and a return description.

+++ userpoints.moduleundefined
@@ -1682,6 +1728,61 @@ function userpoints_get_default_tid() {
+  $points = bcadd(bcdiv($decimals, 100000000, $places), $fulls, $places);

We can unfortunately not realy on bcmath being installed, so we need to find a way to do this without it.

+++ userpoints.moduleundefined
@@ -1682,6 +1728,61 @@ function userpoints_get_default_tid() {
+  if ($format) return number_format($points, $places, variable_get(USERPOINTS_DECIMAL_POINT, '.'), variable_get(USERPOINTS_THOUSANDS_SEPARATOR, ','));

Always use expanded version of if conditions with { } and a separate line for the inner code.

+++ userpoints.pages.incundefined
@@ -50,10 +50,16 @@ function userpoints_list_transactions($form, &$form_state, $account = NULL, $tid
+  $unapproved_decimal_query = db_select('userpoints_txn', 'p')
+    ->condition('uid', $account->uid)
+    ->condition('status', USERPOINTS_TXN_STATUS_PENDING);
+  $unapproved_decimal_query->addExpression('SUM(points_dec)');

I think this does not need a separate query, simply add another expression on the existing unapproved query and then use fetchObject() and get points and points_dec from there. (Make sure you're using an explicit alias for the expression so that you can address it).

Berdir,

Can you tell me where we are as far as this being implemented into Userpoints? I do not want to update to a new version since I am using MasterChef's module he created for me.

Thanks

Hi Guys,

I am using userpoints and am new to drupal. Now i noticed today there was an issue with floats in user points so i did some search and arrived to this thread. I read that a fix was done by MasterChef's for IWasBornToWin. I am wondering if that fix has been brought back to this module? If not, can you guys suggest how i can tackle this problem and i will do the fix and submit the code?

Thanks.

Hi Guys,

Some more info on the version: I am using drupal 6.22 and userpoints version 6.x-1.2 and ubercart userpoints 6.x-2.0-beta2

Thanks.

@sachitsac

All of this is referring to Drupal and Userpoints version 7

Nothing has happened since my last review and this currently isn't far up in my own to do list. If there is something going to happen, it will be posted here.

If no on else works on this I will only get back to this after other tasks of the 7.x-2.x roadmap have been implemented. And as said before, this will not find it's way back into the 7.x-1.x.

In Commerce, we store things as integers, in the *minor units* (like cents in USD). The *presentation* is turned into a format like $1.99, but the storage is always integers.

IMO currency can never be stored with a float.

Any more action on this? Berdir, do you have an ETA for 7.2 userpoints...and will the new patch with decimals be in it?

I've noticed a version 7.2 out. Did decimals make this? I'm still using masterchief's custom module I paid him to do for me. Don't want to upgrade and overwrite if 7.2 isn't ready.

Hi,

I'm also using Masterchief patch to allow decimals in my userpoints but I see that views module doesn't show decimals.

How can I solve this?

Thanks!

# 37 Views does show decimals. I use it. Did you check the formatter, either in the display section of the field at the node, or in the formatter section of the view.

Berdir,

Per your instructions on #33, someone did work on this. I paid Masterchief for decimals and he submitted patch to you over 6 mos ago. I asked 2 months ago if his decimal patch is in new 7.2? I've been using his module for 6 mos and it works great. Is it committed yet? Will it be, why isn't it, etc.? I'd appreciate a quick response...thanks.

I Was Born to Win,

Sorry, but I don't know how to show userpoints decimals in views. I can't find the option to change the formatter :(

Also, I print the function print userpoints_get_current_points($user->uid); on different templates and don't recognise decimal numbers. Only show the integer. How can I solve it?

On the other hand, It works well on the transaction list page. I can see all the operations correctly.

I found another error when changing the decimal point that will be used on decimal settings to a comma. I'm trying to use userpoints as a complementary currency system in Spain and I found Userpoints Donation contrib module to make transactions. Well, if I use points as a "decimal point" there aren't problems between transactions but If I select commas this is what it happens:

ECX002 just earned a eco and now has 1,55 ecos in the General category.
You just had a eco deducted and now have -1,00 ecos in the General category.

System transfers 1,55 points to the other user but only deducts 1 from me! :P
I could use dots, but in Spain decimal numbers are expressed in commas... for me is a problem.

I think that all of this issues will be solved with the new userpoints version, but I need something basic now to start the project.

Any ideas? Could you help me?

Thanks for your time!

I don't think @Masterchief's patch is a good design direction. If support for decimal userpoints is needed, that should be made available as an optional supporting module, and the decimal settings should be used for display and input only. That is: no changes to userpoints_get_current_points and userpoints_userpointsapi should be needed, but a (themeable) function for displaying userpoints should be added to the main module.

Based on my reading of @Masterchief's code, I'm assuming that the decimal settings are global. I'll put together a module implementing this today. Code will be available at http://drupal.org/sandbox/michaek/1545604

@michaek:

Yes, a theme function that is consistently used would be great, could also happen in a separate issue. It might not get us 100% there, however, see comment #1. Basically, it's impossible to change the decimal places without messing things up. Another point are form fields, there needs to be a usable way to deal with them, that validate input and convert it (e.g. that you don't have to write 500 when you have two decimal places)

Feel free to work on it in a sandbox, I do prefer patches to review however.

I've pushed my work regarding the suggestions in #40. If you're interested in browsing the commits in a more legible environment, I've also pushed to github, https://github.com/michaek/drupal_userpoints

@Berdir: I understand your feeling about patches. If you need one, I can roll it from this commit: https://github.com/michaek/drupal_userpoints/commit/7be09e5d46ddadff83e1...

Yes, looks interesting.

- Some minor coding style issues, like missing spaces around the =>.

- Views integration need to be updated, and Services maybe too.

- As mentioned above, the problem with this approach is that changing the amount of decimal places changes the value of all existing values and settings. That is unfortunate, to say the least. It makes it e.g. impossible to start with 2 decimal places and after a year to decide that you need smaller values and change it. There are ways to fix this, but remember that there aren't only the values in the tables, there are also all kinds of settings and additional places where userpoints might be stored. So we'd need a hook or something to tell other modules that we're changing the decimal places, if we want to support changing it.

- You changed the add points form field with hook_form_alter(). That's a start. Remember that there is also rules integration that should be updated, and a *long* list of contributed modules, which often add one to many form fields to configure how many points you receive for a certain action. See userpoints_nc for an example, or userpoints_donation for one that adds a user facing form that deals with points. If you want to support all of them from within your module, you're going to write *many* hook_form_alters(). What I have been thinking about is providing a specialized form element (#type => userpoints) that contains the proper #element_validate, #value_callback and #process definitions to deal with decimal places in a transparent way.

It doesn't make sense to do the last two points in an optional module. E.g. the userpoints element type must be in userpoints.module so that other modules can rely on it. So, here is my suggestion: Open a separate issue for the theme function and provide a patch for it. There is probably even an old issue for this in the queue. This is a non-controversal, relatively simple change. This allows you to and others to start using the additional module without having to patch userpoints and gives us time to discuss and implement the above things.

I don't think there's any obstacle to changing the decimal values at any time. All the values are still stored as integers, and this only changes the display (and form processing when adding points manually). I would expect all API use to continue using integers.

I didn't look closely at views or services. I'd prefer not to use form_alter, but to create a custom alter hook for point values, but that seemed out of scope for this feature. It would be a better design moving forward.

I'm not looking to become a maintainer of this approach, I just thought I would contribute a more flexible and less invasive design. I truly hope my days working with Drupal are numbered.

Imagine having decimal places set to two. A user has 7500,50 points, stored as 750050. Now you change decimal places to 3. Which means that your user suddenly only has 750,050 points anymore.

Nobody is asking you to maintain anything. I'm also not forcing you to work with Drupal. But *I* need to maintain it. And to do that, I need a solution that I can maintain. All those additional modules are an important part of the Userpoints ecosystem, if they don't work well and don't integrate properly with the features that Userpoints has, then Userpoints itself becomes less useful.

All I'm asking you is splitting this up to get the theme function in, asap.

I don't assume that there's any need to change the number of points if you change the decimal places, as the number decimal places is just an element of the display. If someone does need to make that change, the person making the change should make changes to the underlying data on their own. Changing the underlying data shouldn't be part of this feature, as it's (conceptually and practically) all about display.

If, however, you really need only the theme function, here's how to get it: it's all the changes that aren't in the userpoints_decimal directory. The only thing I changed in the main module was the addition of the theme function.

Yawn....Berdir, for about a year now I have asked about decimals. Others have asked longer. You then direct me to Master Chief. I paid him for a module. it works. I, along with others have long begged for a decimal solution. Getting you to respond in any timely fashion is like getting a root canal. I realize you're slammed busy and contribute a lot to Drupal and I'm very grateful. But when I write you private messages, in different issue logs, don't get replies, and then see you on this thread now talking to someone else about a whole other [hopeful] solution I have to start wondering where your thoughts are? You've totally ignored my questions on #32, 33, and #38. So, as I asked you over a year ago, what do you suggest now?

I've been building a site around Master chiefs customized module for almost a year now. And the only response you now give is to Michael, who jumps in and claims Masterchiefs solution [the one you recommended over a year ago] is now not good and here you are having a conversation with him about it?

Here's an idea - don't suggest I pay for, and master chief write modules, that you aren't willing to reply to questions about. And, as you would tell others, if you and Michael want to discuss other options, start you own new issue! This LONG issue is still about doing decimals in userpoints. Sorry for being blunt but i'm actually tired of waiting for you to decide how and when we will do this. And I'm certainly not happy about spending my money and getting ignored by you only to see you comment about something else to someone else.

@IWasBornToWin: I understand your frustration, but...

I have not ignored you. I have reviewed the patch in #28 and informed about the things that need to be improved. These *will* need to be fixed before anything is going to be commited. I have explained so again in #33. What I've written there is still true, I do not need to repeat that every few weeks. If work happens on this topic, it will be posted to this issue, as you've just seen.

michaek provided an alternative solution, which is based on a theme function. That function *is* useful, with and without decimal places. That's why I asked him to provide that theme function as a patch in a separate issue.

@michaek: Yes, and what I'm asking you is to provide your theme function related changes as a patch in a separate issue. The development process of this module is issue and patch based, that integrates nicely with our automated testing environment on d.o so that your patch will be tested automatically. There already is an issue, all you need to do is attach the patch and update it to 7.x-2.x: #310737: Have a centralized theme function for points display

Thanks for replying berdir. Just to ensure I understand you correctly, are you saying if the fixes are completed in the patch that it will get committed? It didn't initially seem that way since michaek claimed MasterChiefs patch wasn't a good solution and then you started new dialogue with him. But you're saying michaek's suggestion can be used either way and MasterChiefs module will still be committed once fixed, regardless of michaek's opinion of it?

My concern is, besides having already paid for this module, i'm building (and creating data) in the new tables from MasterChiefs module. Provided it will end up in 7.2 userpoints (some day, preferably sooner) then I am fine. But if I'm building and adding data to some wild fantacy that will not end up being used then I'm very concerned.

I will contact Masterchief but I'm going to wait until you give me clarity - fixed patches = solution for decimals?

Thanks again for replying. I appreciate all your hard work.

Hello, quite a few interesting posts in the issue queue about using decimals for userpoints. I'd just like to know if there is a simple theme function snippet someone can provide for showing my userpioints with a decimal? Also - would this snipped be able to add a comma for points greater than 1000? ex: 250055 user points displayed as - 2,500.55 on the front end via a theme function?

I understand userpoints are stored as integers, and that works very well for me. I'm not a hardcore developer, so I don't necessarily want to be hacking and patching the userpoints module itself to actually store the number in MySQL as a decimal. I'd very much appreciate if anyone has a template.php snippet they can share that will allow me to format userpoints with a decimal just on the front-end display.

Thank you,
--Tony

Berdir - I am paying Masterchief more money to correclt patch the decimals module I bought from him. He will fix the errors you pointed out in #28 of this post. He will be done by June 22. I am hoping this will get the patch committed to core?

Awesome, Masterchief....thumbs up :)

All removed functions should now exist as methods on the UserpointsTransaction class.

There are still a lot ofs of trailing spaces and, more important, tabs in your code. Please clean them up. Many IDE's can be configured to enforce spaces instead of tabs and avoid trailing spaces. If you do git diff in a terminal that supports colors, you should be able to see them as well.

I'll try to give you a detailed review soon. It would also be really useful if you could open an issue for the theme function implemented by michaek and make that a separate issue. If we can get that in first (not the separate module he's suggesting, just the changes in userpoints module), then this will hopefully make this issue easier. Just take his code, make a patch of it and upload it. There are a few coding style issues that you could clean up while you're at it, see comment #43.

Thanks for all your help MasterChief, Berdir!

Where are we on getting latest patch committed Berdir, Masterchief?

Thanks

Berdir? Can we please get new patch committed?

Berdir, we could really use some love here. We've asked for decimals forever, we've done as you asked, I think? I've paid twice now. It would really be cool (for many userpoint users) if we could use what I've paid for. It works really well. The whole community has asked for these decimals for a while. Any chance you could commit MasterChiefs patch to the latest Dev please? Thanks

@MasterChief, @IWasBornToWin - I'm starting from scratch with 7.x-1.0 on a production site. My client has one category of actions for which he wants to assign .25 point per webform submission. I'm not sure how to proceed -- try to apply MasterChief's patch, or set up a rule that will give a user 1 point for every 4 submissions, or...? Does either of you have any suggestions for me? Thanks.

If you want to do decimals, You have to apply Masterchiefs patch. And then you can assign decimals to different actions. And/or use rules.
I use rules a lot because I" give different points per user level for the same action. You'd be quicker, in my opinion, of applying patch and assigning .25 per post than trying to give 1 point ever 4 posts.

Berdir, Masterchief, did we ever find out about using Master chief's patch in latest version? Berdir I'm changing status so hopefully you will answer us? Thank you.

I wish to have this feature as well. But I tried to apply the patch mentioned in #28 against version 7.x-1.0 but it failed.

May I know which version of userpoints does the patch apply to?

It applies to 7.x-1.0. I just applied the patch from http://drupal.org/node/1289348 successfully.

For those that want to be able to override the display of userpoints by using a theme function, I backported the changes that went into the 7.x-2.x branch to 7.x-1.x. #1918008: Backport theme_userpoints_points to 7.x-1.x

THANK YOU @mrfelton! I asked about this back in June 2012, such a seemingly simple thing - I just wanted the theme to show the userpoints with a decimal, but writing a patch for 7.x-1.x was beyond me. Thank you for taking the time to backport and post this functionality, your efforts are very much appreciated!

@Berdir

So, I don't see a way to use anything else than integer. This is IMHO how all systems deal with currencies: Use the smallest available currency (e.g. 100 cents instead of 1.00 dollars).

@rfay

In Commerce, we store things as integers, in the *minor units* (like cents in USD). The *presentation* is turned into a format like $1.99, but the storage is always integers.
IMO currency can never be stored with a float.

Could we then create a module which is called let's say 'Fake Decimal' and does what is necessary for all of these modules: provides a field which behaves and looks like decimal but is in fact integer with minor units? It will become the dependency for Userpoints and all of the E-Commerce modules including Commerce.
Do you like the idea? I am willing to create such module. I will post an update here in case of any success.

Well, looks like there is no need in creating new, cause there is already plenty of related modules.
The most close and reasonable options (in my view) are:

• Format Number API together with Formatted Number: Look good as a starting point as they don't have 'exact decimal' field type - though their UI is quite rich and meaningful.
• Fraction: Probably the best solution: it relies on bcmath calculations (that is avoiding PHP conversion to float, make calculations using strings as input) if it is available - so there is no trouble with rounding errors. It fallbacks to regular float in case if bcmath is not available - but - please note! - the storage is done using integers. So I suggest to use this module as a dependency as it should work out-of-the-box in a way we all feel good.

Commerce is suggested to use Fraction as well: #1125706: Price Implementation for Commerce 2.x (see https://drupal.org/node/1125706#comment-7154004 for reference) - though the decision is not approved yet.
There is another module that depends on Fraction: Ledger - I've suggested them to rely on Userpoints (see #2075785: Why don't you use Userpoints? It has account balances and transaction types.), which will really makes sense in case Userpoints adopts dependency on Fraction.
Probably we could turn Fraction into an extension of "Format Number API": that is add optional parameter to
function format_number($number, $decimals = 0) {
as
function format_number($number, $decimals = 0, $exact = FALSE) {
and in case if $exact is TRUE run the logic, which is currently encapsulated into Fraction.
Nevertheless, Userpoints should depend on Fraction. Thoughts?

Done. Didn't add any update/migration, because there is introduced new dependency (on Fraction module) and therefore I am in doubt whether it should be implemented in 2.x or in a separate branch (let's say 3.x).
This patch should fail because it depends on Fraction patch: #2077643: Integration with Entity API.
Please review, looks like it does what is desired in a preferable manner.

I insist that it needs review though it failed testing.
Please keep in mind that besides it requires the forementioned patch, it introduces new dependency - and therefore couldn't be tested by testbot, it is due to the logic of calculating dependencies by testbot: https://drupal.org/node/1710704#comment-6304512 .
We should decide here how to deal with this patch: either create a new branch for it, or it is appropriate to commit it to 2.x. My vote is for separate branch, because adding new dependency couldn't be considered as compatible change.
About the solution:

• All calculations are preferably done with integers to avoid rounding errors. Where it is not possible and in order to divide by denominator, Fraction functionality is used, which uses bcmath library when possible and fallbacks to default PHP float otherwise.
• Storing is done using Fraction field type, which turns each decimal into 2 integers: 'numerator' and 'denominator'. Though Fraction field allows other denominators, this solution uses 100 everywhere. Further development could make it configurable - whilst I don't see (yet) any use case where it could be useful for Userpoints.
• So the only use case, where rounding error is possible:
• Your PHP installation doesn't have bcmath library.
• Viewing any piece of Userpoints data, containing amounts: they could be erroneously rounded - that is +/-0.01.

Please note!: Rounding errors could only occur in case of viewing amounts - all data is stored absolutely correctly! You shouldn't be worried about loosing preciseness.

• There is no switch between 'integer mode' and 'decimal mode': integers are handled using Fraction too. I guess there could be created a setting, which restricts the input to only integers - but there isn't for now.
• Tests are extended in order to make them covering decimal input. I've tested them locally - and they passed.

7.x-2.x is a development branch and supposed to change, so no need for a new branch. I'll try to look at the code asap, don't have much time for Userpoints atm.

Is this patch applied and implemented in 7.x-2.x ?

It is very usefull.

I update patch #79 from PatchRanger. There was some problem with saving right points to database, because function declared as

function toDecimal($precision = 0, $auto_precision = FALSE)

and by default, rounded values was saved in database.

Main changes from

$points = ...->toDecimal();

to

$settings = userpoints_get_field_precision();
$points = ...->toDecimal($settings['precision'], $settings['auto_precision']);

My texteditor trim whitespaces at end of line (also at lines with single whitespace), so patch was broken, and got error, like 'malformed patch at line 652'.
Upload correct file.

Re: Patch userpoints-decimal_support-1165256-85-D7.diff
gives:
faultCode0faultStringFatal error:Call to undefined function fraction_from_decimal() in /hsphere/local/home/xxxxxxxxxxxxxxxxx/sites/all/modules/userpoints/userpoints.transaction.inc on line 366

has Dependency: Fraction

edited: I see that it was discussed already

Sent 0.1 point
came error:

UserpointsTransactionIncompleteException: in UserpointsTransactionController->save() (line 1227 of /hsphere/local/home/xxxxxxxxxxxxxx/sites/all/modules/userpoints/userpoints.transaction.inc).

Sent 1.1 point to user with 3 points

Message: User just earned a point and now has 4 points in the General category.

When click on details, came error:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table xxxxxx.field_data_points' doesn't exist: SELECT SUM(fdp.points_numerator) AS expression FROM {userpoints_txn} p LEFT OUTER JOIN {field_data_points} fdp ON p.txn_id = fdp.entity_id WHERE (uid = :db_condition_placeholder_0) AND (status = :db_condition_placeholder_1) AND (fdp.points_denominator = :db_condition_placeholder_2) ; Array ( [:db_condition_placeholder_0] => 86 [:db_condition_placeholder_1] => 1 [:db_condition_placeholder_2] => 100 ) in userpoints_list_transactions() (line 110 of /hsphere/local/home/xxxxxxxx/sites/all/modules/userpoints/userpoints.pages.inc).

Also noted if more then one transaction type exists - "Points" fields become blank in all tables. Probably that indexes are not handled properly.

bcmath library and Fraction module installed

Try make clean install 7.x-2.x-dev and apply patch before making any transactions.

Very sad that Userpoints does not properly support decimals.

I tried a clean install of 7.x-2.x-dev, installed Fraction, and patched Userpoints (#85) without too much drama. But the minute I tried to add on Userpoints Nodes and Comments it all falls apart again (unless I set the point award to 0 - but then what's the point). I would be happy to raise that over at userpoints_nc but not until the patch actually gets rolled into dev. Any possibility of this happening at some point in the foreseeable future?

This could be an amazingly powerful module if it supported decimals but I am not sure the author has much time to dedicate to this particular issue (which will be 4 years old in the coming months).

Great module in concept. Please update to dev for decimals soon.

Just another way of thinking about the use of userpoints is by defining your concept of decimals.

1 userpoint can be a decimal or whatever type of scale you want to use.

For my purposes, I declared 15min increments to be 1 userpoint. And by using computed field module, I am removing the exact amount of time from my userpoint bucket through rules.

For example,

1.25hrs = 5 15min userpoints

Then my rules removes 5 points from my userpoints bucket. I am now in the process of simply changing the way the amount is rendered to the user.

33 userpoints gets displayed to the user as 8.25 hrs.

As I said before, just another way of thinking.

6 years have passed and no solution has been found?

6 years have passed and no solution has been found?