Why does saved numeric have to be multiplied by 100 if you do MD2 for example. If you happen to view raw 300 as MD0 the number is 300 which is correct but viewing it as MD2 it is 3.00

I notice that raw data can save decimals so why multiply. There is no reason for this that I can see. if you save 300 it should be 300 and if you save 3.00 it should be 3 and if i wanted to see 300 with 2 decimal places it would be 300.00 not 3.00

The reason I am asking why is because I have records that have all sorts of different MDxs and is hard to know one from the other when looking at raw data. and have to remember to multiply by 100 to get the correct numbers. The flex-ability of this language is gone with numerics.

Matthew,

This is standard conversion logic for databases that store money. It's helpfull when reporting and viewing the data on forms to always show it with a certain format. If you know ahead of time that you will be storing money in a particular field then you define it as MD2,MD2,$ meaning it divides the stored value by 100 for output and multiplies by 100 on input. Other databases or languages store money data as binary numbers. This kind of format would make it very cumbersome to view the raw data.

If you don't want to define a column as MD2 or you are storing raw numbers you could always go with Float but then you lack the "standardization" on reports and forms.

HTH,

John

This is an historical convention brought forward from the PICK operating system and aids in rapid data entry and easy scaling of mathematical operations. Integer math is faster than floating point math. It also ensures that no inaccuracies are left there by floating point conversions which at the end of the day are not as accurate as integer operations. The concept of a mantissa and an implied exponent is as old as the hills - I remember studying it in the very early '80s on my then Computer Studies course.

It is however hard to know what is in use with raw data but the same can be said for Date and Time values.

You have to bear in mind that Revelation have to effectively be backwards compatible with systems written in the mid '80s when PCs actually had to have a separate numeric coprocessor fitted if you wanted to do any meaningful arithmetic manipulation. In fact this requirement didn't really disappear until the 486 family.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

The problem I have is to remember to times 100 or divide by 100 just to get the decimal to line up when adding to the fields or removing from the fields.

Like one field is MD0 and the second field is MD2 and the third is MD4.

Then after you align then decimal after adding them together you have to save it as MD0.

1=300-invalue (300-visual)

2=300-invalue (3.00-visual)

3=300-invalue (3.00-visual)

4=300-invalue (300-visual)

adding the INVALUE and you get 1200 not 606, if you did not multiply by 100 on 1 and 4

I guess me being not of the PICK era will have to live with this.

You don't have to multiply in the same way as you don't have to divide to store it. You have to OCONV. So at it's most long winded you'd

(assuming you'd inserted DICT_EQUATES)

@Ans = Oconv(@Record<1>,Xlate("DICT.TABLE", ColName1, DICT_CONV$, "X"))
@Ans += Oconv(@Record<2>,Xlate("DICT.TABLE", ColName2, DICT_CONV$, "X"))
@Ans += Oconv(@Record<3>,Xlate("DICT.TABLE", ColName3, DICT_CONV$, "X"))
@Ans += Oconv(@Record<4>,Xlate("DICT.TABLE", ColName4, DICT_CONV$, "X"))

This actually has advantages especially when dealing with custom conversions but this is a conceptual rather than practical discussion which could play and play.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

View this thread on the Works forum...