Shop OBEX P1 Docs P2 Docs Learn Events
String to Float Conversions — Parallax Forums

String to Float Conversions

gmkukagmkuka Posts: 16
edited 2007-09-23 18:02 in Propeller 1
I've found other postings for string to decimal, etc conversions... But I've been unable to locate 'String to Float' conversions...

Any Ideas?

Comments

  • deSilvadeSilva Posts: 2,967
    edited 2007-09-15 07:37
    I think you have to modify something like "fromStr" in NUMBERS to suit your needs...
  • gmkukagmkuka Posts: 16
    edited 2007-09-15 19:04
    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'...
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-15 19:19
    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)
  • gmkukagmkuka Posts: 16
    edited 2007-09-15 20:09
    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...

    I'll keep you posted... Thanks...
  • gmkukagmkuka Posts: 16
    edited 2007-09-19 21:12
    To solve this 'String to Float' problem, I've written the attached 'StringToFloat_Demo.Spin'...

    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
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-19 21:26
    It looks interesting and is certainly instructive, as there are some threads going on at the moment discussinf "string handling" and such...

    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
  • gmkukagmkuka Posts: 16
    edited 2007-09-20 07:46
    With Hat in Hand, Hold off on using the previous 'StringToFloat'. Found some character combinations that give it a little trouble.

    I'll give it back when it is fixed.

    gmkuka
  • gmkukagmkuka Posts: 16
    edited 2007-09-22 20:52
    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...

    gmkuka
  • Mike GreenMike Green Posts: 23,101
    edited 2007-09-22 21:30
    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.
  • gmkukagmkuka Posts: 16
    edited 2007-09-23 18:02
    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...

    On with the project...

    gmkuka
Sign In or Register to comment.