Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

What does Calculate Sum(Val(Evaluate(My_Var))) stand for?

Status
Not open for further replies.

Rock4J

Programmer
Jan 14, 2013
94
MY
I'm trying to change the following foxpro code to visualbasic code:-

Select TableOrCursor
Calculate Sum(Val(Evaluate(A_Field_Name))) to My_Var

Can anybody help me?


Regards,
Rocky
 
A_Field_Name value are something like "61802222", "61802223", "61802224",.. ... and so on..

and I get a Runtime Error 6 (Over Flow) when i try this code in vb:

My_Var = 0
For i = 1 to msflexgrid1.rows - 1
My_Var = My_Var + msflexgrid(i, 0)
Next

Note:
(msflexgrid(i, 0) is values of A_Field_Name stored in the flexgrid)

I know that it is predictable that it turn out over-flow for such a big amount of A_Field_Name values.. but I want to understand the foxpro functions of the following:

Select TableOrCursor
Calculate Sum(Val(Evaluate(A_Field_Name))) to My_Var

Regards,
Rocky
 
Well, what do you not understand?

You certainly know what a sum() is, you programmed that in VB
You also certainly know VAL() is giving the numeric value of a string, becausee VAL() als is the same function in VB.
So it' sevaluatee, that's new to you? Evaluates takes a string with any expression and evaluates it, that means eg evaluate("1+1") compiles 1+1 and returns the result value 2, Evaluate(a_field_name) is very verbose for just the field,

For example if you set A_Field_Name="number" Evaluate("somechar") is the same as somechar, whatever somechar is. From the outset of being stored in a variable called A_Field_Name, somechar would be a field name.

So in the end it's just SUM(somechar), but the VAL is needed as somechar is a field containing strings and not numbers. You can't sum strings.

On the other side, if you use the + operator instead of sum, as you do in your VB loop, + can aalso mean concatenation. So you may get "618022226180222361802224..." instead of the numeric value. Have you debuged your code and see how My_var evolves?

How about defining it as double, this gives a very large value range. VFP will default to double with any numeric calculation, the decimal precision is a topic of it's own, as VFP stores that seperately to the numeric value of a variable, but that shouldn't matter here for your VB implementation.

Bye, Olaf.


 
...

Just one correction (I won't bother you with all other typos I made):

For example, if you set A_Field_Name="somechar", then Evaluate(A_Field_Name) is the same as Evaluate("somechar"), and that is the same as somechar, whatever somechar is. From the outset of being stored in a variable called A_Field_Name, somechar would be a field name.

Bye, Olaf.
 
You posted effectively the same question in the Old Foxpro forum area.

True, your question itself is not version-specific and, with that in mind, Olaf has given you the answer above.

But if your application is developed in the Old Foxpro (1 to 2.6) then you need to be posting your questions in the Old Foxpro-specific area ( Microsoft: FoxPro (old versions 1 to 2.6) Forum forum182 ) to get the most applicable replies.

If your application is developed in the Newer Visual Foxpro version(s) then you are not looking for the most applicable replies by posting in the Old Foxpro area.

Good Luck,
JRB-Bldr
 
Just a sample on how A_Field_Name can differ from Evaluate(A_Field_Name).

In this case I assume A_Field_Name itself is a field, not a variable.

Code:
Create Cursor curEvalsample (A_Field_Name C(30), bNumber1 B, bNumber2 B)
Insert into curEvalsample values ("0.42",1,2)
Insert into curEvalsample values ("bNumber1",4,8)
Insert into curEvalsample values ("bNumber2",16,32)
Calculate Sum(Evaluate(A_Field_Name)) To nVar

This results in the sum being 0.42+4+32=36.42. In this case, the field is not only containing numeric expressions, in record 2 and 3 I put other field names, so you can use Evaluate to be more dynamic about what you sum.

In your case there is an additional VAL(), that would not work with this sample data, as VAL() only works on strings, and all expression I put into the cExpression field evaluate to a number, not a string.

What I rather assume is, A_Field_Name is a variable containing a field name. The same CALCULATE can therefore sum different fields just by setting the A_Field_Name value:

Code:
Create Cursor curEvalsample2 (cExpression1 C(30), cExpression2 C(30))
Insert into curEvalsample2 values ("0.42","2")
Insert into curEvalsample2 values ("4","8")
Insert into curEvalsample2 values ("32","16")

A_Field_Name = "cExpression1"
Calculate Sum(Val(Evaluate(A_Field_Name))) To nVar1

A_Field_Name = "cExpression2"
Calculate Sum(Val(Evaluate(A_Field_Name))) To nVar2
Same expression, summing different fields. You could also use macro substitution in this case, as in Sum(Val(&A_Field_Name)), but Evaluate is faster.

Bye, Olaf.
 
Hi, thanks a lot for the information Olaf! and you too jrbbldr! :D

Sorry for the thread that I have posted in the "Microsoft: FoxPro (old versions 1 to 2.6)" forum. Because I do not really know about foxpro syntax and which version that it is allowed. regarding VFP version, I have VFP version 5.0 and 6.0 installed in my PC. That's all I know.

I actually did have tried to search about the "Evaluate" function in Google earlier, as what you says. I did read it. That's why I have disregard the Evaluate function in my VB code. I purposely change the actual code to this thread by replacing it with "A_Field_Name" and "My_Var" because I have studied the original VFP program and codes and the "A_Field_Name" are not a value that are have been calculated, it just values that stored in a Table. "A_Field_Name" values is actually something like an ID Number. and the numbers are in the range that I have shown earlier.

So if you want to see the exact code, then here it is:

Code:
Select SQL
Go Top
Calculate Cnt(),;
       Sum(Val(Evaluate(goApp.Fld_Epfno))),;
       Sum(Evaluate(goApp.Fld_Epf)),;
       Sum(Evaluate(goApp.Fld_CoEpf));
       To mTotEmp, mHshTot, mTotEpf, mTotCoEpf		

mTotEmp = Padl(AllTrim(str(mTotEmp,5)),5,"0")
mHshTot = Padl(AllTrim(Str(mHshTot,13)),13,"0")
mTotEpf = Padl(AllTrim(Str(mTotEpf,7)),7,"0")
mTotCoEpf = Padl(AllTrim(Str(mTotCoEpf,7)),7,"0")

Select Epforma3
Append Blank
Replace Epforma3.Dtype with "99" ,;
Epforma3.HshTot with mHshTot,;
Epforma3.TotEmp with padl(alltrim(mTotEmp),7,"0"),;
Epforma3.TotCoEpf with mTotCoEpf ,;
Epforma3.TotEpf with mTotEpf ,;
Epforma3.Fillers with Spac(69)

Regards,
Rocky
 
So you are talking about Sum(Val(Evaluate(goApp.Fld_Epfno)))

goApp is no table, but the global application object. This nomenclature is used in many foxpro frameworks. Fld_Epfno then is application property, and it may contain field name. It's more like the secand sample code I gave you. Depending on what is set in goApp.Fld_Epfno the sum can be on different fields without using macro substitution, without many version of similar code, just by changing the value of that Fld_Epfno property.

If you sum ID fields it might simply be an error in the application configuration, as it doesn't make much sense to sum keys, unless perhaps you want to have a checksum. The variable name used to store this sum is mHshTot, which might mean Hashtotal, a hash or checksum. Actually it's a bad checksum, as other combinations of records can have the same sum, eg record 1+2+3 = 6, records 2+4=6, too.

Anyway, your problem of overflow should be resolvable by summing into a float variable.

Bye, Olaf.
 
I know what will I get from:

Sum(Evaluate(goApp.Fld_Epf)),;
Sum(Evaluate(goApp.Fld_CoEpf));

That's why I feel strange why I get a 'over-flow' runtime error for:

Sum(Val(Evaluate(goApp.Fld_Epfno))),;

With the same method.

I hope you guys understand what I mean. :)

Regards,
Rocky
 
Well, what is the variable type of My_VAr in VB? As said VFP is using double, that can be up to 8.9884656743115E307
You would need to sum a lot of IDs to get there.
If your VB type has a lower range, you get an overflow error.

Bye, Olaf.
 
I set My_Var Type as Long.. I will check goApp.fld_Epfno too in the meanwhile.. :D

Regards,
Rocky
 
Alright Olaf, I get it. Thanks so much.. :)

By the way, here is what I get about the GoApp:

GoApp in the main program code is

Code:
    goApp=CREATEOBJECT("cApplication")

And,

Code:
    goApp.Fld_Epfno = Config.Fld_Epfno

Where 'Config' is a Table which have a field named 'Fld_Epfno' which store a Fieldname of a table(s). And "I KNOW" that the value of 'Fld_Epfno' is 'Epfno' which stores the list numbers that I have mention earlier.

That's why I have used the words 'A_Field_Name' for 'GoApp.Fld_Epfno' at the first place.

I just don't get yet why do they need the Sum of that numbers which is somekind of ID numbers. :D

Thanks so much my friends.. God bless.. :)

Regards,
Rocky
 
> I just don't get yet why do they need the Sum of that numbers which is somekind of ID numbers. :D

I already interpreted the name mHshTot from your original code to be a hash value. It's very likely to be that, as it's an otherwise meaningless sum of IDs, as you recognized. But the question you had initially was technical, about the error you had, not about the semantic meaning of such a value.

A hash has no meaning in the sense of any computed total of financial statistics or such, it's just a value calculated as a fingerprint, stamp for the data it came from, so eg you can verify doing the same sums again later, if the hash matches it came from the same records, and if the other sums changed, it's a sign they didn't changed because there is new data, but data was corrected or manipulated. More typical usages of a hashs are to store a password hashed instead of cleartext and even instead of encrypted passwords. You can google the meaning and explanation of hash in IT yourself.

Simply summing values is a bad hash algorithm, I already criticized it. The bad part is not, that different input values lead to the same hash value, but if your hash values already exceed LONG value range, even the larger value range of double would mean no change in th hash sum, if just a few new records in the ID range of about 10^7 are added, as the sum range already is far beyond 10^18 and adding several 10^7 to a total in the range higher than 10^18 still remeans in the range 10^18.

After all you may skip calculating that hash value, if you don't find any code also reading it back, using it in some manner, comparing it perhaps, as data varification. If there is no code doing that, the hash is only stored into mHshTot for manual inspection, then you may also replace the summing with any other better hash algorithm creating some fingerprint.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top