var vString as String  // test number)
var Digit9 as Int //(should match last digin of test number)

vString = ThisElement

//-------------------------------------------------------------------
Digit9 = 10 - (@Mod(
@TN(@Mid(vString,1,1)) +
@TN(@Mid(vString,3,1)) +
@TN(@Mid(vString,5,1)) +
@TN(@Mid(vString,7,1)) +
@Int(@TN(@Mid(vString,2,1))*2/10) +
@Mod(@TN(@Mid(vString,2,1))*2, 10) +
 @Int(@TN(@Mid(vString,4,1))*2/10) +
 @Mod(@TN(@Mid(vString,4,1))*2,10) +
 @Int(@TN(@Mid(vString,6,1))*2/10) +
 @Mod(@TN(@Mid(vString,6,1))*2,10) +
@Int(@TN(@Mid(vString,8,1))*2/10) +
@Mod(@TN(@Mid(vString,8,1))*2,10), 10))

Writeln ("This should be the last Digit: " + digit9)

Writeln (@TN(@Mid(vString,1,1))  )
Writeln (@TN(@Mid(vString,3,1))  )
Writeln (@TN(@Mid(vString,5,1)) )
Writeln (@TN(@Mid(vString,7,1))   )
Writeln ( @str(@Int(@TN(@Mid(vString,2,1))*2/10) + @Mod(@TN(@Mid(vString,2,1))*2, 10))   )
Writeln ( @str(@Int(@TN(@Mid(vString,4,1))*2/10) + @Mod(@TN(@Mid(vString,4,1))*2, 10))   )
Writeln ( @str(@Int(@TN(@Mid(vString,6,1))*2/10) + @Mod(@TN(@Mid(vString,6,1))*2, 10))   )
Writeln ( @str(@Int(@TN(@Mid(vString,8,1))*2/10) + @Mod(@TN(@Mid(vString,8,1))*2, 10))   )

 

Calculation of individual digits are right. Logic is also correct. Final answer is still not right. It could be mistake in codeing as the last part of @mod becomes a little complicated.
Moreover, this does not address to usages of variables and why Integer type variable gives different results than double type as this does not use any number kind of variables.

Thanks.....spend no more time on it.

I will dig in when I have access to Sesame again.....

At the time I did it, I did not think you had a working solution, I was trying to provide one for you, and you have already resolved that.  And this formula does not directly address the Int/Mod types of issues.

Mark, thanks a lot for your explanation. Yes, document clearly states that but then I thought it is a simple mathematical calculation so, it should not have problem with Integer. The other thing I have noted that when double and Integer variables are compared in a statement or used in calculations, it does not seem to give predictable result. Need to know a little bit more about these two variables. Once in the past, you advised me to replace Integer variable with double and calculation worked fine after that. I still did not understand why one will work while other would fail to work.

982235293, 104875984, 056439797, 017861469, 117036830, 089342307, 081296006, 106250525, 103293056, 145000147, 982089534, 982089526,

Bob, I have a question about getting information from subform using x-family command. Please look at my last post in the following link. Your help, input and feedback are very much appreciated.

http://www.lantica.com/Forum2/cgi-bin/yabb/YaBB.pl?board=gen_disc;action=display...

Quote:

Using integers it is a simple calculation, and given that it is likely to be used with integers, I may well add a @mod command that does use integers.

The reason that things are different when using integers or doubles has to do with two things: accuracy and completeness. An integer is (in Windows) a 32 bit number that is perfectly accurate but very limited in range. A signed integer can only hold numbers from -2,000,000,000 to 2,000,000,000. If an integer exceeds those value in either direction it rolls over. This is because it is a straight binary expression of the numbers 2 to the power of 31, where the 32nd bit indicates if the number is positive or negative. An unsigned integer can range from zero to 4,000,000,000ish. And, of course, an integer cannot hold any fractional portion.

A "double" is an approximation of a "real" number as expressed in scientific notation rendered to a binary form in 64 bits. This gives a double a much larger range than a 32 bit integer, as well as the ability to store a fractional portion - all at the cost of accuracy. That is not to say that doubles are inaccurate unto themselves. With the exception of some early Pentium chips, doubles are accurate to 1.7976931348623157E+308 - which may seem pretty accurate. But that large range degrades on conversion to either integers or to doubles with fewer decimal places (like money).  In either case the double must either be rounded (using IEEE's somewhat strange rounding standards) or truncated to a "whole" number. At each conversion back and forth that reduction in information results in a less accurate double.

If you pass integers to a function or subroutine that is expecting doubles, SBasic does the best it can to convert that integer to a double. It then uses those doubles to do the actual math, and then converts back again to an integer for the result. Each of these conversions - and the case of @mod, the last of these conversions results in the loss of at least 32 of 64 bits worth of information. For example the @mod for 11.56217 % 4.92715 is 1.7078 (or so), yet the integer conversion of the same number is not one or two - it is 11 % 4, which is 3. As you can see, for each of the math operations with a double based @mod, some of the accuracy is truncated for the eventual use as an integer. @mod has a minimum of 3 operations on possibly fractional numbers, and a maximum of five operations (if the first number specified as a parameter is negative).

In this case, the absolute best advise, is to always use the type that the function or subroutine expects - converting only once after you get the result back as a double. That will avoid multiple internal conversions. If you must use integers, then you should either wait for me or Andreas to provide you with a built-in that accepts integers, or you can easily write one for yourself in global code:

function MyMod(aa as int, bb as int) as int
var cc as int
var dd as int

dd = 0
if(bb <> 0)
{
  cc = aa / bb
  dd = aa - (cc * bb)
}
return dd
end function
 

Quote:


Thanks Bob. No need to look. It works just fine, like any other database or form. This will provide solution to the query FlipGilbert presented in the following link.

http://www.lantica.com/Forum2/cgi-bin/yabb/YaBB.pl?board=gen_disc;action=display...