Thanks, I was afraid of that... I don't need any of the 'ee' stuff, just 6 places with a decimal in there someplace... Which I believe will be a little easier...
I'm building a data logger with the Prop Demo as host, collecting data from a TI MSC1210 performing 24 bit A/D with some 8051 munching going on.. and then collecting the Prop Demo data via Hyperterm. The fp data is ascii 'Calibrated Scale' data for the 8 input channels... i.e String to Float.
Thank so much for the quicky response...
The single line program
· CogStop(0)
Downloaded to eeprom has solved my confusion problem of ... is it 'RAM'?... Or is it 'EEPROM'...
Absultely easy if the ste string has less than 10 digits and the decimal is implicite and on a known position (say always 2 digits from the end)
floatval := FDiv( FFloat(fromStr(str)) , 100)
The dp is not necessarily stable, but the number is < 10 digits... I'll just skate thru the string looking for the dp all the while counting locations and then make your sample value of '100' whatever it has to be... And this is not a high volume repetitive usage function so speed is not so much an issue...
Attached is the latest StringToFloat conversion. Entirely rewritten using 'SimplePrecedence' techniques.
As a result, the size of the routine is 75Longs, as previously thought 1/2 the size for the function... Three support routines exist that consume 3, 28 and 38 Bytes. Total consumption is 371 bytes.
Call the routine for the conversion... If there is an error, indicated by a negative number returned, immediately call GetErrorIndex, the return value indexes the input pointer, indicating the offending character.
The last couple of days, I've been beating it up with all kinds of good and bad sequences... It's been solid...
Thanks for doing this. It's nice to have. If you ever get around to redoing it, you'll get better accuracy if you accumulate the mantissa as an integer value, then convert it to floating point once and factor in the exponent once. You have to account for the number of digits after the decimal point and adjust for the exponent after you've "filled up" the integer value, but that's not hard.
Thanks Mike for the response to V2 of the StringToFloat post.
Accumulating the Mantissa using an integer as a long would be dynamic range limiting. You may be able to create a 'Double Long' ie 64 bits. Thats still a little short of 2*10^19... Half the 10^38 range of the single float. So I don't know..
I actually only acccumate the Mantissa once, essentially because of the simple precedence, one character at a time, without returning to the recent scene of the parsing crime. This allows for building the mantissa with up to 38 input digits of a number and not have a problem with it... Assuming we haven't violated the 6...7 digit resolve of the single float. I did 'Build' the floating value of the equivalent 'Digit Count' for the dp/mantissa correction as an Integer in with a float out...also used the same routine to construct a 'Mantissa Equivalent' for folding in the influence of the string exponent...
V1 of StringToFloat was a Bang Bang get it done somehow... And actually for my requirements it was fine... My format did not include the scientific notation or that stuff... But, while fooling with it, it didn't like certain texts... So I stopped and wrote V2 from the ground up... And so far, enjoying it's success...
It's reasonably small... And, It hasn't boomed in my underware...
Comments
I'm building a data logger with the Prop Demo as host, collecting data from a TI MSC1210 performing 24 bit A/D with some 8051 munching going on.. and then collecting the Prop Demo data via Hyperterm. The fp data is ascii 'Calibrated Scale' data for the 8 input channels... i.e String to Float.
Thank so much for the quicky response...
The single line program
· CogStop(0)
Downloaded to eeprom has solved my confusion problem of ... is it 'RAM'?... Or is it 'EEPROM'...
floatval := FDiv( FFloat(fromStr(str)) , 100)
I'll keep you posted... Thanks...
Give it a whirl... The text speaks of the inner workings, formats and the like...
The actual conversion in PUB StringToFloat uses ~170 Longs. I have no gauge as to what this means.
Keep me posted...
gmkuka
However I should have expected somewhat of half the size... But maybe I err...
190 LONGS are 190/8192 ~1/40 = 2,5% of the whole RAM
I'll give it back when it is fixed.
gmkuka
As a result, the size of the routine is 75Longs, as previously thought 1/2 the size for the function... Three support routines exist that consume 3, 28 and 38 Bytes. Total consumption is 371 bytes.
Call the routine for the conversion... If there is an error, indicated by a negative number returned, immediately call GetErrorIndex, the return value indexes the input pointer, indicating the offending character.
The last couple of days, I've been beating it up with all kinds of good and bad sequences... It's been solid...
gmkuka
Accumulating the Mantissa using an integer as a long would be dynamic range limiting. You may be able to create a 'Double Long' ie 64 bits. Thats still a little short of 2*10^19... Half the 10^38 range of the single float. So I don't know..
I actually only acccumate the Mantissa once, essentially because of the simple precedence, one character at a time, without returning to the recent scene of the parsing crime. This allows for building the mantissa with up to 38 input digits of a number and not have a problem with it... Assuming we haven't violated the 6...7 digit resolve of the single float. I did 'Build' the floating value of the equivalent 'Digit Count' for the dp/mantissa correction as an Integer in with a float out...also used the same routine to construct a 'Mantissa Equivalent' for folding in the influence of the string exponent...
V1 of StringToFloat was a Bang Bang get it done somehow... And actually for my requirements it was fine... My format did not include the scientific notation or that stuff... But, while fooling with it, it didn't like certain texts... So I stopped and wrote V2 from the ground up... And so far, enjoying it's success...
It's reasonably small... And, It hasn't boomed in my underware...
On with the project...
gmkuka