Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
10
Erster Beitrag:
vor 4 Jahren, 3 Monaten
Letzter Beitrag:
vor 4 Jahren, 3 Monaten
Beteiligte Autoren:
DerekT, Riebens, Allard, Fabrice Harari, GuenterP, Ola

Currency inwindev 18

Startbeitrag von Allard am 27.04.2014 14:24

Hi,

I have several items set on curency. Defined by the project.

the edit fields and table etc are currency and euro and have a mask defined by the project.

The problem
I check if debet and credit are the same if not a fault is displayed because user hasnot made a valid entry. The edit and the table display 2 decimal. Now it seems that windev currency calculates with 4 decimals. For no reason at all windev calculates small diferences in the third of fourth decimal?
As a consequence the fault is displayed. But as onley 2 decimals are shown their seems to be no fault.

Question
How can I change the project settings of the currency, ( two decimals )as I set it to use the project settings there should be a palce where I can set the project values?

Does anyone know why this is. ( why windev uses 4 decimals ? )

I think it is veery odd this happens. The calculation are very simple and even if windev uses 4 decimals thare should not be small differences in the third and fourth decimal.

Thanks
Allard

Antworten:

Hi Allard

"For no reason at all windev calculates small diferences in the third of fourth decimal"

That is just not true if you are using currency fields. The only case where you have this kind of behavior is if you are using REALS...

Now, what COULD happen is that your code is doing calculations without TYPING each intermediate variable... By example, if you do:
A=B/4-D*E/F
the compiler will decompose your calculation into a series of intermediate steps and it will decide internally in what type of variable to store the result...

Because the compiler was written BEFORE currenclies were available and because they are trying very hard to maintain compatibility, very often in that case REALS will be used internally, and because reals are not able to represent all possible values in the spectrum, you will have small difference as you are describing.

So if you do calculations and want to be sure of the result, you can either do a ROUND of your result (as the differences are small and at decimal 3/4, that should do it) or separate yourself each calculation into a series of simple step always begin stored by you in a currency

Best regards

von Fabrice Harari - am 28.04.2014 12:10
The basic problem with Windev's currency type variable is that you cannot define the number of decimals for it, and therefore you need to round the calculation results "continuously".
I SO miss Clarion's "Decimal" type variable, which specifies the number of integers and decimals, and automatically rounds the results to the number of decimals specified, like
dPrice is Decimal(11.2)

best regards
Ola

von Ola - am 28.04.2014 20:42
Currencies are based on Real (according to the help file - A currency is a real coded on 10 bytes.)

A suggestion: Use Numeric to do calculations

Numer1 is numeric (11.2)
Number2 is numeric (11.2)

Number 1 = Currency 1
Number 2 = Currency2

myresult is numeric (11,2) = Number1 - Number2

Kind Regards

Ben

von Riebens - am 29.04.2014 08:30
Ola

Have you tried
dPrice is is numeric (5,7)

von DerekT - am 29.04.2014 08:30
Hi Riebens

Currencies are NOT based on reals.... Reals cannot store all values while currencies can, which clearly shows that their underlying implementation is completely different.

Best regards

von Fabrice Harari - am 29.04.2014 10:24
Quote
Fabrice Harari
Hi Riebens

Currencies are NOT based on reals.... Reals cannot store all values while currencies can, which clearly shows that their underlying implementation is completely different.

Best regards


Hi Fabrice, that's correct! 'Currency' is based on long integers in most programming languages where they're being used. It's the only way to circumvent the rounding funnies of reals. Std. rounding procedures of standard reals do not work correctly in some special cases. In old BASIC times I wrote a rounding routine in order to fix those funnies which are inherent to the standard of floating point representation. Btw, these funnies are different for 4-byte and 8-byte reals.

Example for 4-byte reals:
1. - convert real to string
2. - analyse and round
3. - convert back


DEF FNRD!(I!)
RUX$ = FUsing$(STR$(I!),"#######.#######")
FOR RUI% = 15 TO 11 STEP -1
IF VAL(MID$(RUX$,RUI%,1)) > 4 THEN
I! = I!+VAL("0."+STRING$(RUI%-10,"0")+"1")
RUX$ = FUsing$(STR$(I!),"#######.#######")
MID$(RUX$,RUI%,16-RUI%) = STRING$(16-RUI%,"0")
ELSE
MID$(RUX$,RUI%,1) = "0"
END IF
NEXT RUI%
FNRD! = VAL(RUX$)
END DEF


von GuenterP - am 29.04.2014 10:40
Quote
Fabrice Harari
Hi Riebens

Currencies are NOT based on reals.... Reals cannot store all values while currencies can, which clearly shows that their underlying implementation is completely different.

Best regards


Actually, I agree with you, I don't know why I wrote that. - Look at the changes I did to the message - According to the help file, A currency is a real coded on 10 bytes.

Kind Regards

Ben

von Riebens - am 29.04.2014 11:18
Hi
I found the error.

It was in a proces where I copy an invoice. I tested the copuing proces by copying verry fast many
invoices. ( Like 20 kopies in 2 seconds ) klik klik with the mouse. Just a test to see what happens if an idiot does some odd things.

Well it seems that if I do this indeed odd things happen. And the odd thing is windev creates 4 decimals. Well I solved the problem by a adding a question if the user is sure that he wants to make a copy. So all goes fine now

regards
Allard

von Allard - am 29.04.2014 14:19
Maybe Hourglass(true) Hourglass(false) either end of your copy code could be your friend

von DerekT - am 29.04.2014 16:41
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.