BUG : Text conversion to float

The following method of converting strings to numbers is not working I think.


Here is how I did :

and the result I got :


I am not sure it is normal, I thought it was bug. Some other python-like code does produce a valid output.

For example : %<str(types(DocumentText(“key”)))>%

outputs : <type ‘str’>

But I could not get the float() method working.

Thanks for any feedback

Environment :

Rhino 8 SR6 2024-4-10 (Rhino 8, 8.6.24101.05001, Git hash:master @ 32c244aa711e0034e75bec2e87d093c764820b96)
License type: Commerciale, build 2024-04-10
License details: Cloud Zoo

Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 32GB)
.NET 7.0.0

This seems to work here:


(or whatever you are adding, subtracting, etc.)

Yes, it does work this way because the Volume function outputs a number. As long as the output of the function is a number adding or multiplying works fine. (eg. Volume, Area, CurveLength)

Test :

Volume = %<Volume(“1138c632-5107-432e-8ea3-9633245317e7”,“False”)>%
Volume type = %<type(Volume(“1138c632-5107-432e-8ea3-9633245317e7”,“False”))>%
Volume type2string = %<str(type(Volume(“1138c632-5107-432e-8ea3-9633245317e7”,“False”)))>%

Output :


The drawback of using the Volume function directly is that the lengthy ID code is needed. And when this same quantity shows up in different places it becomes less convenient to deal with the ID code or individually select the object each time I need to refer to it.

Initially, I wanted to have all the area and volume quantities saved in a single place (for example DocumentUserText). Ideally I would retrieve those values, not as strings, but as floats using float(). This way I can add them together to print the sum of the areas or volumes.

If I could substitute the ID code “1138c632-5107-432e-8ea3-9633245317e7” by something more human readable it would be nice too. I would get something like :

Volume 1 = %<Volume(“name_box_1”,“False”)>%
Volume 2 = %<Volume(“name_box_2”,“False”)>%
Volume tot = %<Volume(“name_box_1”,“False”) + Volume(“name_box_2”,“False”)>%

Hi Basile -

I’ve added this thread to this ticket: RH-55283 Working with text field syntax is awkward

Thank you Wim, RH-55283 looks very promising. I do like the idea of graphical editing in text editor but I would be perfectly fine if I could find how to access any values in a python-like language.

The integration in the text editor of some python interpreter is not perfectly clear to me. The python float() function is actually working perfectly fine with strings.

Test : %<str(float(“3.3”)*float(“2.0”))>%
Output : 6.6

But I can’t figure out why DocumentText(“some_key”) fails in being a valid input for the float() function since it seems to evaluate as a string.

Test : %<str(type(DocumentText(“some_key”)))>%
Output : <type ‘str’>

Hi -

I’m afraid I have no idea what you are trying to do and what “Output : xxx” means…

FWIW, here’s an example forcing a value from document text to be an integer:


Hi @wim,

Going back to the original post in this thread, there is a bug with number conversion of AttributeUserText.

Per the R8 documentation quoted, the float function correctly converts a user entered AttributeUserText field with, say, the key “Density” to a number. However it fails to convert an AttributeUserText field where the value is the result of a built in function, such as “Volume”.


p.s. For simplicity I have left out the maths operations that require the conversion, you can of course simply display the UserText string directly if no ops are involved.

Thank you Wim,

In my last post I tried to decompose the sequential steps involved in the conversion from text to number. Finally my exploration was not very successful and I got a little disappointed with the following observations :

  1. the float() function was successfully converting a string (e.g. “3.3”) into a number
  2. the output type of DocumentText() seems to be a string
  3. but when the DocumentText() function is placed as an argument of the float() function I get an unexpected output (“####”), which does not make sense to me since the float() function was able to convert a string and the DocumentText() function apparently output a string.

Thank you Jeremy,

I think you clarified what was causing the problem I ran into. The Document User Text value that I was trying to insert with the DocumentText() function was itself the result of a built-in function ( e.g. Volume() ).
The conversion of a Document User Text numeric string into a number is possible unless the value comes from a built-in function.