GDL prob with text anchor pt rot and maintain text orient

When I delete the numbers after the period I get a format error message.

When I delete the period and the numbers after script is ok, but angle of line changes and length altered slightly . Original line was 12" long.

When I delete the period the second Y value I now get a very long line.
1.4E+15 in the coordinates box (tracker doesn't show in the gdl windows). I wrote the number as it showed in the coordinates box.

Back in the main window of AC with this line placed I the x,y and r values all have E+ numbers when measuring the line.


Same with changing millimeters to meters for modeling.

When I change units to feet & inches, I get a real value for the x499811'-5 13/16" but the Y and r values are empty.

So no exponents in imperial measuring in AC.

Erika wrote:
Juha,
You jumped ahead to the anchor point problem. Some symbols have two lines of text. How do you keep them from running into one another when the scale changes? Or when someone changes the font size?


thanks!

You can REQUEST the height of the text once you have defined it.
You would think that if you add 2mm high text it would be 2mm high - but no, you have to allow for the line spacing.

REQUEST ("Height_of_style", "name", height) will give you the height in meters.
You can then divide by 1000 to get millimeters and multiply by a scale factor for various scales.

Here is a bit of code from one of my objects with multiple lines of text that will adjust to suit any scale.

DEFINE STYLE "style_large" fnt_sltn,
txt_title_size, 5, 1
xx=REQUEST ("Height_of_style", "style_large", style_large_hgt)
style_large_hgt=style_large_hgt/1000 * GLOB_SCALE *(100/GLOB_SCALE)

Of course I work in metric so will have to leave you to sort out the Imperial side of things.


The E-014 as has been mentioned means add 14 more decimal places to the number.
i.e almost zero.
I quite often just substitue 0.0 for the entire figure as it is easier to read the script.
It appears often with auto scripted objects but only when the point is close to zero.

Here is a 1000mm radius arc (drawn 90° anti-clockwise) with centre at 0,0
A line joins the ends of the arc (i.e. the segment).
Two more lines are drawn from the origin to the ends of the arc.

ARC2 0, 0, 1, 0, 90
LINE2 0, 0, 1, 0
LINE2 0, 0, 6.123031769112E-017, 1
LINE2 1, 0, 6.123031769112E-017, 1

Archicad has decided that the end of the arc is not quite at zero even though it was drawn snapping to the vertical constraint.
It seems sometimes zero is not always exactly zero.

Barry.

Thanks Barry. I'll give that a try.

Peter, that's an interesting discussion in the link. I will see if decimal feet or inches might have the e's show up in Imperial.

Barry wrote:
The E-014 as has been mentioned means add 14 more decimal places to the number.
i.e almost zero.

For one explanation of scientific notation, including the use of "E", see:
Scientific Notation
and scroll down to E notation.

David

Hi All,

Braza wrote:
...
The exponential numbers occur just with elements created using the special constrains (holding shift key to create orthogonal lines)...

I looks like the special constrains doesn't really locks the X as zero... but something very close to zero... which is that weird exponencial number.

When I use just x and y inputs to generate a line or an arc the autoscript code is clean... no weird numbers...

...

The ArchiCAD engine try to give the coordinate as much precision as it can... so it gives you that great number of decimals...

It would be great if someone from GS could give us some light here...

Sorry for my being late but in the final production phase of AC13 I'm pretty busy.

You figured out quite exactly what's happening. ArchiCAD stores the coordinates of placed elements at the highest available precision but it runs on computers which use a binary representation. So totally round decimal numbers get infinite binaries (which get truncated, of course) and finite binary numbers could produce infinite decimals (which get rounded, too). So 3.5 times 2 almost never equals 7 on computers - it's rather 6.999... or 7.00...00157... for example. If the difference is smaller than the rounding limit, you get 7 and don't notice anything. And as you guessed, computers use the scientific representation for very small and very large numbers. This usually happens for values very close to zero.

Consequence nr.1. When I create a script using AC drawing tools, I like to remove the 'almost zero' values, i.e. 1.34E-14 and its friends.

Consequence nr.2. Never compare real numbers using the equal and not-equal operators but use a small epsylon like the Technical Standards recommends.

Regards,
Zsolt