Why units are duplicate in Table Region?




units (1).sm (21 KiB) downloaded 109 time(s).



Best regards

Carlos

It's a bug

thank you for reporting, I'll fix it ASAP.

Thank you very much for your reply.

Best regards

Carlos

Hi Davide,

the values "Resizing/Limits on data size changes" are not stored between sessions (close/reopen SMath).

with SMath: "0.98.6484"

Wrote

Hi Davide,

the values "Resizing/Limits on data size changes" are not stored between sessions (close/reopen SMath).

with SMath: "0.98.6484"

I cannot reproduce. Do you have checked the "set as default" checkbox and then clicked on the "ok" button?

Davide,
I have identified an abnormal behavior using the comma as a decimal point

sergio

[albumimg]1479[/albumimg]

Wrote

Davide,
I have identified an abnormal behavior using the comma as a decimal point

sergio

[albumimg]1479[/albumimg]

Yes, this comes from a conflict in behaviors...var2str() was thinked to be used in plots as main target, hence preserving the localisation options... table region symbolic strings needs a standard input (period as decimal separator)

Hello,

Thanks for the work with this plugin, it has proven to be a very useful and much needed feature.

I am however having one small issue. My table displays fine within SMath, but when I print, depending on how many characters there are, the table cuts off.
This is only when I print.

Is there something in the settings I am missing?
All settings are default in the attached example.

Thank you!

Wrote

Hello,

Thanks for the work with this plugin, it has proven to be a very useful and much needed feature.

I am however having one small issue. My table displays fine within SMath, but when I print, depending on how many characters there are, the table cuts off.
This is only when I print.
...
Is there something in the settings I am missing?
All settings are default in the attached example.

Thank you!

Confirmed. Unfortunately string scaling is driven internally by the .NET framework (here the ssue is how letters are spaced), so there aren't easy fixes. I'll think if I can do something however, thank you for reporting.

I have seen that by adding some final spaces the string becomes completely visible. It is not a solution but can be used in some cases.
Even the formatted label has a similar behavior but in that case the string wraps.

sergio

PompelmoTell - Yes, I did figure this "fix" out as well. Depending on the length of the original string, more spaces need to be added to the end. Not the best of solutions given that I am working with large amounts of data of varying length.

What is confusing to me, is that if the string is longer, it will print more of it, but also remove more characters at the end. if the string is shorter, it removes less characters but the end result is a shorter string than the previously mentioned. There doesn't seem to be be a fixed length when printing and it depends on the original length.

Lets hope the champion Davide Carpi has a solution to this!

Davide,

Any news on a permanent fix for the string length cut off on the table region mentioned above?

Thanks!

I observe a peculiar behavior when "Temp" is changed from 20 Celsius to, say, 40 Celsius.
See how the table value responds when input "Temp" is changed to 40 Celsius.
Where have I gone wrong? Apparently, this happens only with Temp units (needs further checks).

Units_Table_r2 (1).sm (17 KiB) downloaded 101 time(s).

This seems to be related to offset between Celsius and Kelvin.

I can produce the correct output (with incorrect input) by changing units of Temp to Δ°C OR by changing value in Table1 to Temp-273.15K.





Note that by setting the units in the un column to 1 from °C, the temperature is shown in Kelvin as the first table in the .sm.

Somehow the conversion from K to °C is not being performed properly within table region.

Wrote

Where have I gone wrong ?

Not easy to get Table that makes sense ... kind of pest !



Table Region [Project].sm (7 KiB) downloaded 98 time(s).

alyles,

The way the unit summary matrix works is that it actually does a unit conversion as seen in the image below.
the "in" unit shown in the un matrix is converted to the default unit in the same way the "a" and "b" variables are. Then the un matrix divides the T matrix to cancel out the units and display the values in the units chosen in the un matrix.
In the image shown below, the 6in are converted to 0.5ft when placed into the table, then the cm unit in the un matrix is converted to 0.0328ft and divides the 0.5ft value, making it 15.24 as shown.
Note that the unit summary matrix is not being displayed. They will not display as entered into the unit summary matrix because they are converted to the default unit as explained prior.

If you want the units to display, you will need to add a right stub with the units as "S:'unit" as shown before.

It would appear that there is something wrong with the conversion being made for temperature.

ndtma,

To answer your question as to where you went wrong. Well, you didn't go wrong. The issue, I believe (I may be wrong), is that the way the "unit summary" matrix is designed to work, it assumes that the conversion can be made with a multiplying factor, but since the temperature scales do not share the same zero, there is no factor to multiply for the conversion in some cases.

I think what it comes down to is a matter of how the conversions actually happen. This goes for any portion of Smath Studio. See below. From Celsius to Fahrenheit, Smath won't make the conversion unless there is an actual number in front of it. Similarly, from Celsius to Kelvin, without the number in front of the unit the conversion is broken.
From Kelvin to Fahrenheit oddly enough, the conversion seems to work. I'm not sure how these are set up within Smath.. but there you have it. Food for thought I guess.

What's wrong missing post 76 "Project"
Another style table few day ago.

I tried to install the plugin but got an error message. Now the plugin cannot be disabled or removed?

Is there a problem or have I done / not done something?

Kriss