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?
- Thread starter Rock4J
- Start date
- Thread starter
- #2
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
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
Olaf Doschke
Programmer
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.
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.
Olaf Doschke
Programmer
...
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.
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
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
Olaf Doschke
Programmer
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.
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:
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.
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 nVarThis 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 nVar2Bye, Olaf.
- Thread starter
- #7
Hi, thanks a lot for the information Olaf! and you too jrbbldr! 
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:
Regards,
Rocky
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
Olaf Doschke
Programmer
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.
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.
- Thread starter
- #9
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
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
Olaf Doschke
Programmer
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.
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.
- Thread starter
- #11
Olaf Doschke
Programmer
Well, Long can get up to 9.2E+18, which is far less than 9E+307
Use a floating point type, not an integer type.
In VB this can even go up to 1.79769313486231570E+308
Bye, Olaf.
Use a floating point type, not an integer type.
In VB this can even go up to 1.79769313486231570E+308
Bye, Olaf.
- Thread starter
- #13
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
And,
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.
Thanks so much my friends.. God bless..
Regards,
Rocky
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_EpfnoWhere '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.
Thanks so much my friends.. God bless..
Regards,
Rocky
Olaf Doschke
Programmer
> I just don't get yet why do they need the Sum of that numbers which is somekind of ID numbers.
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.
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
Similar threads
