Hidden variables?

[dunbarx]

I was right about the 17th decimal place.

And still a little naive about computers, in that I stubbornly thought that if 11.025 * 26 = 184.65, then dammit, 11.025 * 26 = 184.65.

But of course it does not.

I added a note in QCC about raising such arguments to integers. I will see if I want to make a general library function that does this automatically, and so allow all real numbers to "div" correctly in all cases.

Craig

[dunbarx]

I have div all over the place. Always did.

I am going to examine all my code and substitute a "fullDiv" function (in tribute to Rinaldi, a certain old HC XCMD genius) so that all arguments are raised to integer values and then restored. It just means multiplying everything by, say, 1000 if the most highly decimalated (?!) argument has three places. Simple, like me.

Craig

[FourthWorld]

When you need precision, use the more precise operator, "/".

If you need truncation, consider using "trunc" on the result of "/".

[dunbarx]

Richard.

Right, in general

But my task really called for div and mod together to do what I wanted. Still does.

I could certainly have rewritten to use "/" or trunc, and, to isolate the decimal portion of a value, either

Code: Select all

 var- trunc(var) 

or even

Code: Select all

char (offset(".",var) + 1) to the number of chars of var of var

I have always wanted a function that returned only the decimal portion of a real.

Craig

[[-hh]]

The essential problem here is the truncation.
This is the definition:

Code: Select all

a div b = trunc(a/b) for numbers a and b, b not zero

The problem revealed by Craig's example, where 11466=26*441, is

trunc(11466/441) yields 26 -- correct
trunc((11466/40)/(441/40)) yields 25 -- wrong

Note also:
trunc(11466/40/441*40) yields 25 -- wrong
trunc(11466/40*40/441) yields 26 -- correct

We have different results because the arguments of trunc are different in their last decimals from the different order of the components in their computation.

[[-hh]]

I have always wanted a function that returned only the decimal portion of a real.

You have it already (if x is not an integer):
x mod 1 = decimal part of a number x (if x is not an integer)
x mod 1 = 0 (if x is an integer)

Edit. Corrected above for the case that x is an integer.
For an integer the decimal part is empty and the remainder when dividing by one is zero.

[[-hh]]

Hi Craig,

This shows the next 'problem', or better: the same problem.
put (11466/40/441*40) mod 1 -- yields 1 (wrong)

Consequently
put (11466/40/441*40) div 1 -- yields 25 (wrong)
put (11466/40/441*40) is an integer -- yields false (wrong)

At any rate, it remains true

Code: Select all

x = x div y + x mod y  -- for any numbers x and y, y not zero

Hermann

[dunbarx]

Hermann.

Hi,

I have written several "anti-trunc" gadgets over the years. I just always wanted a native one: "decPortion(real)"

Craig

[[-hh]]

Craig,

the problem remains the same as the real numbers are only a model, CPUs are discrete.
By using "native" you only shift the number of the decimal where the problem occurs. For any given precision there is an example like your's that reveals the same problem.

Hermann

[dunbarx]

Hermann.

I am just curious, which do you find more elegant:

x mod 1
or
x - trunc(x)

In my experience I often need to know the number of "groups" and "remainders". That is, if I have 150 paranoid androids, I have 12 dozen and 6 singles. It was only recently that this requirement became important outside the realm of integers.

Anyway, the reason I want a native function is that both of the above prepend a "0" in front of what I really want, which is the naked decimal. In other words, I want the "remainder", in the way I mentioned above, not some number, derived from a calculation, however arithmetically correct.

I have always obtained this with the offset function, used in the way I mentioned even farther above. I am too lazy to simply lose the "0".

Craig

[[-hh]]

Craig,

you have good arguments, as always, here for an 'exact' math remainder. The "mod" operator in LCB may be already closer to what you want.

"x-trunc(x)" (or "x - the trunc of x" in LCB) is without doubt an expression that is for most users more clear than "x mod 1".

For an integer x the remainder when dividing by one is zero while the decimal part is empty. So, "char 1+offset(".",x) to len(x) of x" is a more direct approach in that case.

Why don't you give a flash talk at LC Global about this problem or a similar focused problem (you have a lot at hand)?

Hermann

[I personally prefer to use div and mod, applied to integers only (what is, as you said elsewhere, for a fixed number of numbers achievable by myltiplying with a large number).

My most frequent use case is to walk trough the four-byte-chunks of imageData:
If k is enumerating such four-byte-chunks (pixel colors) and
if w is the width of the image then
k div w is the number of full rows and
k mod w is the column index of the current row (1+i).]

[dunbarx]

Hermann.

just so you know, I find your posts far more cogent than mine.

Craig

[LCMark]

The issue here is that non-integers are being passed to div/mod... So just don't do that...

The div operator is there so that you can express the need to do integer division - you need to make sure you don't pass it numbers with fractional parts. If you want division on numbers with fractional parts use /.

If you have numbers-which-might-have-a-fractional-part, then round(tNumber, 0) is a reasonable way to get it as an integer.

I think this issue will only arise if somewhere in the inputs to the calculation, you are accidentally letting a non-integer creep in. If you actually do need to work with things with fractional parts, then div is probably *not* what you need.

Using trunc is not quite right - as trunc just removes the fractional part. In this case, one value is something like 25.9999999999453 - so trunc'ing it will give you 25. If you round(tNumber, 0), however you will get 26.

[dunbarx]

Thank you, Mark.

My issue, and this has been so for decades, are often of the form I mentioned above, that is, to partition groups of things according to my own particular needs. It has to do with the lengths of physical objects and the process of fitting other objects inside them.

Thus I need not an arithmetical gadget, but rather a physical one; I do not need precision in the arithmetical sense, I need to pack a suitcase. Div and mod have served perfectly for this, where "/" would be useless. I ran into trouble, as discussed, when the suitcase started to contain real numbers of shirts and socks, instead of integer numbers of that sort of millenary.

Craig