I use Laravel with vue/vuetify in frontend.
In a simple form, the user can set the settlement_factorwhich is a number with 2 decimals.
The field in the DB looks like
If I enter 1.68 the entry in the db is 1.68 but the system returns 1.68000000000002
Patch request value:
"settlement_factor": "1.68",
Response value
"settlement_factor": 1.6800000000000002,
But if I enter 1.67, the system returns 1.67 which is right:
Patch request value:
"settlement_factor": "1.67",
Response value
"settlement_factor": 1.67,
I use Laravel ressources to modify the response:
'settlement_factor' => $this->settlement_factor,
Why does the system change the value 1.68 to 1.68000000000002 but the other numbers are ok?
I have no Idea to find the error.
For a quick fix, I can add the round()function.
Don't use double for this. Double is a floating point number encoded
in 64 bits. The encoding of a decimal number in binary cannot always
be exact. 1.68 happens to be one of the numbers where the encoding is not exact so you see it displayed as 1.68000000000002.
Use Decimal (5,2) this would allow for 5 significant digits with 2 to the right of the decimal point. This would give you a range of 0 to 999.99. You can adjust these 2 number to fit the range you expect for the number. To match to the number you used, use Decimal (3,2) which gives you a range of 0.00 to 9.99.
Rounding will be managed by Decimal Type so you will not see the
encoding deviation like in Double.
Related
I need to display the field product_uom_qty under sale.order.line (of Sale order) and quantity under account.invoice.line (of an invoice) as an integer instead of the current floating point.
How can I do it?
Please let me know.
Thanks.
Since you are asking for Odoo 10:
Go to Settings in Debug mode.
Under the Technical > Database Structure > Decimal Accuracy click the menu.
Find Product Unit of Measure and edit it to 0 digits.
This will change whenever product_uom_qty is accessed with Decimal Accuracy precision, not just Sales Orders.
If you want to do it in the model, you can set digits like this.
fields.float('Quantity', digits=(x,y))
If you want to do it in the view, you can set digits like this.
<field digits="(x,y)" name="product_uom_quantity"/>
where x is the digits before the decimal point, and y is the digits after the decimal point. So, if you set y to 0 it will have no decimal point seemingly an integer.
You can set the widget attribute to integer.
Example:
<field name="product_uom_qty" widget="integer"/>
Been looking all over and nothing comes up as far as a Google Sheets formula.
Let's say we have a value of 3.6875 feet. We can use the number format # ??/??, but it will give us a fractional value in feet (in this case, 3 11/16 feet).
How do we "grab" the 11/16 and multiply it by 12 to get the inches value (8.25), and then the really tricky part, how do we display the whole enchilada as 3'8¹/⁴" (yes, including the superscript)?
A1= 3.6875
B1=INT(A1)&"'-"&TRIM(TEXT(ROUND(MOD(A1,1)*12*16,0)/16,"# ??/??")&"""")
Output: 3'-8 1/4 "
UPDATED:
You can have a table to search the superscript
The idea to get the superscript: with above output (3'-8 1/4"): is to extract the fraction (1/4), search for the equivalent superscript in the table (¹/⁴), then replace it (3'-8 ¹/⁴"):
So basically we will need:
REGEXEXTRACT
VLOOKUP
REGEXREPLACE
SPREADSHEET DEMO: HERE
=arrayformula(
if(len(A2:A),INT(A2:A)&"'-
"®EXREPLACE(TRIM(TEXT(ROUND(MOD(A2:A,1)*12*16,0)/16,"#??/??")&""""),
"\d{1}\/\d+",
VLOOKUP(IFNA(
REGEXEXTRACT(TRIM(TEXT(ROUND(MOD(A2:A,1)*12*16,0)/16,"# ??/??")&""""),
"\d{1}\/\d+"),
"0/0"),
TABLE!A:B,2,0)),""))
I've managed to format the following lines in XPath, from this format:
1000.50
30
to this:
100050
3000
The solution I've adopted is:
concat(substring-before([number], '.'), substring-after([number], '.'))
If the . is not present I directly multiply the number by 100.
I'm wondering if there is any better way to do that. My second thought was using Java.
What goes wrong if you just multiply by 100? So long as the result of multiplying by 100 is an exact integer, it should be formatted without a "." when converted to a string. If there are rounding errors that mean the result is not an exact integer, you might want to use round().
The concat() approach seems fragile to me: what if someone gives you input like 1000.5 or perhaps 1000.500?
I have a formula which is simply 28742.92 / 100.
I have rounding which is set to 0.00001 however it outputs the value 284.
Is it possible to output decimal values as it appears in a standard calculation e.g. 28742.92 / 100 = 284.7289
Many Thanks.
Right click on your numeric field and choose the 4th option from the top Customize field.
Once done, choose the way you want to format your number
I am writing a button calculator. I have the code split into model, view and a controller. The model knows nothing about formatting, it is only concerned with numbers. All formatting is done in the view. The model gets its input as keypresses, each keypress is a part of an enum:
typedef enum {
kButtonUnknown = 0,
kButtonMemoryClear = 100,
kButtonMemoryPlus = 112,
kButtonMemoryMinus = 109,
kButtonMemoryRecall = 114,
kButtonClear = 99,
…
};
When the user presses a button (say 1), the model receives a button code (kButtonNum1), adds the corresponding number to a string input buffer ("1") and updates the numeric output value (1.0). The controller then passes the numeric output value to the view that formats it (1).
This is all plain, simple and clean, but does not really work. The problem is that when user enters a part of a number (say 0.00, going to enter 0.001), the input does not survive the way through model to view and the display says 0 instead of 0.00. I know why this happens ("0.00"::string parses to 0::double and that gets formatted as 0). What I don’t know is how to design the calculator so that the code stays clean and simple and the numbers will show up on screen exactly as the user types them.
I’ve already come with some kind of solution, but that’s essentially a hack and breaks the beautiful and simple flow from the calculator model to the display.
Ideas?
Current solution keeps track of the calculator state. If the calculator is building a number, I take the calculator input buffer (a string) and directly set the display contents (also a string). Otherwise I take the proper path, ie. take the numeric calculator output, pass it to the view as a double and the view uses its internal formatter to create a string for the display. Example input:
input | display | mode
------+---------+------------
0 | 0 | from string
0. | 0. | from string
0.0 | 0.0 | from string
0.0+ | 0 | from number
This is ugly. (1) The calculator has to expose its input buffer and state. (2) The view has to expose its display and allow setting its contents directly using a string. (3) I have to duplicate some of the formatting code to format the string I got from the calculator input buffer. If user enters 12345.000, I have to display 12,345.000 and therefore I’ve got to have a commification code for strings. Yuck.
On my calculator (HP48SX) the numbers in the display are formatted according to the settings for displaying numbers. Right now, if I enter 0.00 (or any variant thereof) it is displayed as 0.0000. Perhaps you could separate display (ie formatting) from internal number representation ? In terms of MVC I guess that this would be implemented as state in the C.
EDIT in response to OP's comment. I don't fully understand the limitations of what you call a button calculator so you're on your own there. As for separation, I would design the calculator such that:
Model is always working with whatever you use for representing numbers: floats, doubles, decimals, what-have-you.
View is always working with strings which present numbers nicely and allow users to enter as they wish.
Controller translates from string to number, from number to string. In my original suggestion I envisaged that Controller itself would be stateful (storing current-numeric-format for example) and be addressable from the buttons. But you seem to have ruled that out.
Your problem, as I see it, is that if you don't store this state somewhere then you have no way of telling the calculator to use anything other than a fixed* format for displaying any number entered. By fixed* I mean a very limited form of flexibility, such as always displaying the number of decimal digits that were in the most recently entered number, rather than absolutely fixed such as 12 digits, no more and no less.
At last I’ve found a nicer solution. I have added an inputHint property to the formatter object that takes care of the output formatting in the view. This input hint receives the value of the calculator input buffer and affects the formatting. If there is a decimal dot in the input hint, the formatter is forced to always keep the decimal dot in output, therefore solving the case of "0." being formatted as "0". And if the input contains some fraction digits, the formatter is forced to keep the same number of fraction digits in output (solves the case of "0.00" being formatted as "0").
I still have to expose the calculator input buffer and state, but I don’t have to expose the view’s display as string and don’t have to maintain the duplicate formatting code path for strings.