Add Format Specifier control in "Read Key (Double).vi"

[Priyadarsini]

The "Read Key (Double).vi" is not giving out proper values when a SI notation number is present in the ini file. For e.g. if the number is 1m it returns as 1 while the actual value should be 0.001. It will be helpful if the format specifier is provided as another control.

[crossrulz]

If you are updating the Read Key (Double), you might as well do it for all of the Read Key and the Write Key VIs as well.  I can imagine wanting to use a hex format for the U32.

[wiebe@CARYA]

Are you still using this library? I'd guested about everyone made there own libraries for reading INI files...

Why? For one it's very limited. Why can't I create a reference from string? Why can't I get a reference ini as string? Why can't I read\write clusters? Etc. Why isn't this a class? If only I could overwrite or extend the library, it would be somewhat useful. As it is, I only use it for really small projects (where my library would add more VI's then there are in the project).

I'd planned a presentation on the CLA summit, with the intent to make my library public, but there where enough other presentations... I'll have to wait for another excuse to bring it to 100%.

As for your idea... That is a good idea.

[AristosQueue (NI)]

Priyadarsini: You cannot wire 1m to that node. The wire breaks. What are you referring to?

[GregSands]

AQ - I'm pretty sure the OP was meaning "1m" = "1 milli-something", not "1 metre/er".

[AristosQueue (NI)]

GregS: If the value of the double is 1, then the function is correctly reading 1, and I don't know of any format string that is going to make it read "0.001". Are you saying that there's some format command such that

value = 1m

can be read as 0.001? If so, what % code is that?

[drjdpowell]

It’s %#p for SI notation:  0.001 —> “1m”, 1000—>”1k”, etc. 

[crossrulz]

For floating points, I like to use the SI notation as well (%p, usually using %#p for controls and indicators).  For some integer values, it is easier to to use Hex notation (%x, usually using %02x for U8, %08x for U32, etc).  It would be nice to be able to use these in the configuration file.

[crossrulz]

And just to add to why this is a good idea:

In my current job, I am dealing with RF a lot.  And every instrument and library wants the frequency in Hz.  It is A LOT simpler to put "1G" instead of "1000000000" (I think I counted those 0s correctly).  At least I can use "1e9" currently, which helps a little bit.

[AristosQueue (NI)]

Weird. I've never considered doing that with any .ini file I've ever worked with. I can see the utility, though. I'll add my kudos to the idea.

Having said that... I did discover that Write Key for double *does* allow for some formatting:

None of those are the SI format that you were asking for, but it might help others. We could certainly extend that enum or make it polymorphic to accept a % string.

The Write Key also allows you to wire a precision. That will be important in a moment...

As a workaround, you can call Format Into String or other converter function and then write the resulting string to the .ini file. You can wrap that in a subVI for reuse. Yes, it will add quote marks around your value, but it would help the readability problem that you're describing.

Also, I want to note something rather important that I learned recently...serialization and deserialization of floating-point numbers as decimal strings is REALLY HARD if you want the values to be stored and retrieved with maximum precision. For any given unique in-memory value of a floating-point number, most format codes will cause several different values to write the same decimal representation, so when you read them back, you've lost precision. It's terrible. To get a recoverable string, you need to really push the width and the precision values up high, like this:

The existing "Write Key.vi" polyVI does not do that for the floating-point types. It uses the default precision of (6). You can wire a greater value to that, however. If you're storing floating-point values, you probably want to do that, regardless of the string formatting.

[wiebe@CARYA]

>Having said that... I did discover that Write Key for double *does* allow for some formatting:

>None of those are the SI format that you were asking for, but it might help others. We could certainly extend that enum or make it polymorphic to accept a % string.

Wouldn't it suffice to add a "SI format" to the enum? Of maybe both, so you can use the format specifier string for weird stuff ("%x", "%.1f kg" or (oh no) "%,;%.6f")?

>As a workaround, you can call Format Into String or other converter function and then write the resulting string to the .ini file. You can wrap that in a subVI for reuse.

If only the library was a class... Then this could be done really nice. Change the read\write function, and your entire program will use the new features without having to go over each and every read\write VI and change it..

>Yes, it will add quote marks around your value, but it would help the readability problem that you're describing.

I'd expect "write raw string? (F)" to enable writing without quotes... But it doesn't, it just skips the escaping. There are some low level functions (Add Key.vi) that you where able to (re)use in the past, but now they are private (why o why)... It's like everything possible is done to make this library non-reusable.

>Also, I want to note something rather important that I learned recently...serialization and deserialization of floating-point numbers as decimal strings is REALLY HARD if you want the values to be stored and retrieved with maximum precision. For any given unique in-memory value of a floating-point number, most format codes will cause several different values to write the same decimal representation, so when you read them back, you've lost precision. It's terrible. To get a recoverable string, you need to really push the width and the precision values up high, like this:

The only way I found to do this is to convert the number to string with maximum precision and convert back to the number. Then, in a loop remove precision until the back conversion doesn't match the original anymore... It is difficult. I also needed to do this 3 times (for sgl, dbl and ext). But you are guaranteed the stored value will be read back as the (binary) exact float.