"And" <49341109@ntnu.edu.tw> wrote:

> > However, one very important thing is the way decimals are written to the
> > example include files. My system uses 'dots' (example: 3.9432) instead
> > of 'commas' (example: 3,9432) like is done by your app. I guess that
> > some countries/systems do so standard, but not all.
>
> I use 'meter' as the length unit, so that output result is caused by my habit.
> The dots are decimal points.

Units don't appear to be the issue.   The representation of decimal fractions is
what Thomas is concerned about.

> I want to ask a question, a number contain commas can be read as 'one' number
> correct by POV-Ray?
> Can 3,9432 be a number?

Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
and the "+,-, and ." glyphs to represent numerical values.  Formatting those
values using str and probably a macro would be necessary to show the usual
commas between every step of 10^3.


> > If this is an issue for better international use, could you make
> > this an initial choice to make by the user? Or is there another way to
> > change this easily?
> >
> > --
> > Thomas
>
> Currently You might need use 'scale' to the pigment to convert it to your
> customary unit. I will add a list(menu) to select unit on the "Basic
> Profile"(first page) in the future version. But I need time to research this.

I think he means "Is there a way to specify whether to use "," or "." for the
data's output format.

Post a reply to this message

Op 04/07/2022 om 20:53 schreef Bald Eagle:
> "And" <49341109@ntnu.edu.tw> wrote:
> 
>>> However, one very important thing is the way decimals are written to the
>>> example include files. My system uses 'dots' (example: 3.9432) instead
>>> of 'commas' (example: 3,9432) like is done by your app. I guess that
>>> some countries/systems do so standard, but not all.
>>
>> I use 'meter' as the length unit, so that output result is caused by my habit.
>> The dots are decimal points.
> 
> Units don't appear to be the issue.   The representation of decimal fractions is
> what Thomas is concerned about.
> 
Exactly. The issue here is whether the 'comma' represents a 'Thousands 
separator' (example: 3,943,200.00) or - and I guess this is what is 
intended here - the 'decimal dot' (example: 3943200,00). Neither can be 
used by POV-Ray.

>> I want to ask a question, a number contain commas can be read as 'one' number
>> correct by POV-Ray?
>> Can 3,9432 be a number?
> 
> Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
> and the "+,-, and ." glyphs to represent numerical values.  Formatting those
> values using str and probably a macro would be necessary to show the usual
> commas between every step of 10^3.
> 
> 
>>> If this is an issue for better international use, could you make
>>> this an initial choice to make by the user? Or is there another way to
>>> change this easily?
>>>
>>> --
>>> Thomas
>>
>> Currently You might need use 'scale' to the pigment to convert it to your
>> customary unit. I will add a list(menu) to select unit on the "Basic
>> Profile"(first page) in the future version. But I need time to research this.
> 
> I think he means "Is there a way to specify whether to use "," or "." for the
> data's output format.
> 

As far as I understand this issue, the use of 'thousands separators' is 
only a visually attractive(?) trick, while calculations on those numbers 
ignore them (obviously). My advice would be to drop them altogether, 
especially for input to POV-Ray.

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>
> > > However, one very important thing is the way decimals are written to the
> > > example include files. My system uses 'dots' (example: 3.9432) instead
> > > of 'commas' (example: 3,9432) like is done by your app. I guess that
> > > some countries/systems do so standard, but not all.
> >
> > I use 'meter' as the length unit, so that output result is caused by my habit.
> > The dots are decimal points.
>
> Units don't appear to be the issue.   The representation of decimal fractions is
> what Thomas is concerned about.
>

Labeling titles and units on diagram is important I know. I will label them.


> > I want to ask a question, a number contain commas can be read as 'one' number
> > correct by POV-Ray?
> > Can 3,9432 be a number?
>
> Nope.  That would be a string.  AFAIK, all versions of POV-Ray use only numerals
> and the "+,-, and ." glyphs to represent numerical values.  Formatting those
> values using str and probably a macro would be necessary to show the usual
> commas between every step of 10^3.
>
>
> > > If this is an issue for better international use, could you make
> > > this an initial choice to make by the user? Or is there another way to
> > > change this easily?
> > >
> > > --
> > > Thomas
> >
>
> I think he means "Is there a way to specify whether to use "," or "." for the
> data's output format.


I'm not clear this time. POV-Ray cannot use a number contains commas as you
said, why I need add commas between every step of 10^3. I attach a picture, this
picture is what I saw on my output data. Is the same format on your output data?

Post a reply to this message

Attachments:
Download 'radial_speed_output.png' (96 KB)

Preview of image 'radial_speed_output.png'

Thomas de Groot <tho### [at] degrootorg> wrote:
> Exactly. The issue here is whether the 'comma' represents a 'Thousands
> separator' (example: 3,943,200.00) or - and I guess this is what is
> intended here - the 'decimal dot' (example: 3943200,00). Neither can be
> used by POV-Ray.
>

>
> As far as I understand this issue, the use of 'thousands separators' is
> only a visually attractive(?) trick, while calculations on those numbers
> ignore them (obviously). My advice would be to drop them altogether,
> especially for input to POV-Ray.
>
> --
> Thomas

What the length unit does you use? Because my outputting number is usually small
with this program(while meter is the length unit).

Post a reply to this message

Op 5-7-2022 om 09:53 schreef And:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Exactly. The issue here is whether the 'comma' represents a 'Thousands
>> separator' (example: 3,943,200.00) or - and I guess this is what is
>> intended here - the 'decimal dot' (example: 3943200,00). Neither can be
>> used by POV-Ray.
>>
> 
>>
>> As far as I understand this issue, the use of 'thousands separators' is
>> only a visually attractive(?) trick, while calculations on those numbers
>> ignore them (obviously). My advice would be to drop them altogether,
>> especially for input to POV-Ray.
>>
>> --
>> Thomas
> 
> What the length unit does you use? Because my outputting number is usually small
> with this program(while meter is the length unit).
> 
The length units I use are from the metric system; whether they are mm, 
cm, m, or km, is of no importance and only relevant within a given scene 
of course.

Where things go wrong, starts with the exported ****_radial_speed.inc 
file where

#local r_pos = array[7][4] {
{ 0,00, 0,053815, 0,10493, 0,161445 },
{ 0,161445, 0,217235, 0,273236, 0,336914 },
{ 0,336914, 0,397284, 0,47667, 0,533589 },
{ 0,533589, 0,571795, 0,600867, 0,622288 },
{ 0,622288, 0,662945, 0,675592, 0,719823 },
{ 0,719823, 0,749311, 0,79926, 0,843443 },
{ 0,843443, 0,891902, 0,946315, 0,99775 },
}

#local year_pos = array[7][4] {
{ 0,00, 2,60, 5,20, 7,80 },
{ 7,80, 10,366667, 12,933333, 15,50 },
{ 15,50, 17,933333, 20,366667, 22,80 },
{ 22,80, 24,433333, 26,066667, 27,70 },
{ 27,70, 30,80, 33,90, 37,00 },
{ 37,00, 39,066667, 41,133333, 43,20 },
{ 43,20, 45,466667, 47,733333, 50,00 },
}

and all other exported include files where something like this is 
written. POV-Ray does not like it. :-)

It would be OK if this were:

#local r_pos = array[7][4] {
{ 0.00, 0.053815, 0.10493, 0.161445 },
{ 0.161445, 0.217235, 0.273236, 0.336914 },
{ 0.336914, 0.397284, 0.47667, 0.533589 },
{ 0.533589, 0.571795, 0.600867, 0.622288 },
{ 0.622288, 0.662945, 0.675592, 0.719823 },
{ 0.719823, 0.749311, 0.79926, 0.843443 },
{ 0.843443, 0.891902, 0.946315, 0.99775 },
}

#local year_pos = array[7][4] {
{ 0.00, 2.60, 5.20, 7.80 },
{ 7.80, 10.366667, 12.933333, 15.50 },
{ 15.50, 17.933333, 20.366667, 22.80 },
{ 22.80, 24.433333, 26.066667, 27.70 },
{ 27.70, 30.80, 33.90, 37.00 },
{ 37.00, 39.066667, 41.133333, 43.20 },
{ 43.20, 45.466667, 47.733333, 50.00 },
}

which, I suppose, is what you intend.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> The length units I use are from the metric system; whether they are mm,
> cm, m, or km, is of no importance and only relevant within a given scene
> of course.
>
> Where things go wrong, starts with the exported ****_radial_speed.inc
> file where
>
> #local r_pos = array[7][4] {
> { 0,00, 0,053815, 0,10493, 0,161445 },
> { 0,161445, 0,217235, 0,273236, 0,336914 },
> { 0,336914, 0,397284, 0,47667, 0,533589 },
> { 0,533589, 0,571795, 0,600867, 0,622288 },
> { 0,622288, 0,662945, 0,675592, 0,719823 },
> { 0,719823, 0,749311, 0,79926, 0,843443 },
> { 0,843443, 0,891902, 0,946315, 0,99775 },
> }
>
> #local year_pos = array[7][4] {
> { 0,00, 2,60, 5,20, 7,80 },
> { 7,80, 10,366667, 12,933333, 15,50 },
> { 15,50, 17,933333, 20,366667, 22,80 },
> { 22,80, 24,433333, 26,066667, 27,70 },
> { 27,70, 30,80, 33,90, 37,00 },
> { 37,00, 39,066667, 41,133333, 43,20 },
> { 43,20, 45,466667, 47,733333, 50,00 },
> }
>
> and all other exported include files where something like this is
> written. POV-Ray does not like it. :-)
>
> It would be OK if this were:
>
> #local r_pos = array[7][4] {
> { 0.00, 0.053815, 0.10493, 0.161445 },
> { 0.161445, 0.217235, 0.273236, 0.336914 },
> { 0.336914, 0.397284, 0.47667, 0.533589 },
> { 0.533589, 0.571795, 0.600867, 0.622288 },
> { 0.622288, 0.662945, 0.675592, 0.719823 },
> { 0.719823, 0.749311, 0.79926, 0.843443 },
> { 0.843443, 0.891902, 0.946315, 0.99775 },
> }
>
> #local year_pos = array[7][4] {
> { 0.00, 2.60, 5.20, 7.80 },
> { 7.80, 10.366667, 12.933333, 15.50 },
> { 15.50, 17.933333, 20.366667, 22.80 },
> { 22.80, 24.433333, 26.066667, 27.70 },
> { 27.70, 30.80, 33.90, 37.00 },
> { 37.00, 39.066667, 41.133333, 43.20 },
> { 43.20, 45.466667, 47.733333, 50.00 },
> }
>
> which, I suppose, is what you intend.
>
> --
> Thomas


Oh, this is important. I just fix it(but need you testing). Thank you.

No any other change. except in demo scene, I rotate<0,0,0> instead of
rotate<0,0,90> the wood-block.

Post a reply to this message

Attachments:
Download 'wooddesignprogram alpha ver20220705.rar.dat' (966 KB)

compress to .zip

Post a reply to this message

Attachments:
Download 'wooddesignprogram alpha ver20220705.zip' (980 KB)

Op 05/07/2022 om 09:29 schreef And:

> I'm not clear this time. POV-Ray cannot use a number contains commas as you
> said, why I need add commas between every step of 10^3. I attach a picture, this
> picture is what I saw on my output data. Is the same format on your output data?
> 

This looks ok to me and is what I expected.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 05/07/2022 om 09:29 schreef And:
>
> > I'm not clear this time. POV-Ray cannot use a number contains commas as you
> > said, why I need add commas between every step of 10^3. I attach a picture, this
> > picture is what I saw on my output data. Is the same format on your output data?
> >
>
> This looks ok to me and is what I expected.
>
> --
> Thomas

That's great.

Post a reply to this message

Almost error-free! :-)

In output file: example1_bumps_pattern_detail.inc  there are still five 
instances of offensive comma's that need to be replaced by dots. I show 
them here below with an arrow:

//----start code----
#include "bumps_detail_pattern_macros.inc"
#declare f_height_for_bumps_extent =
generate_bump_follow_height_trend_f(20.0);

// ------------ fiber ------------
#declare f_thin_fiber_mockup0 =
generate_thin_circled_pattern_f_input_t_theta_h(
10.0, 60.0, 3.0, 3.0, 0.015, 5,
0.007, 0,32,                      <=== 0,32 should be 0.32
0.00, 2.50, 0.14, 0.15,
seed(44),
0.014, 20.00
);

#declare f_thin_fiber_mockup1 =
generate_thin_circled_pattern_f_input_t_theta_h(
10.0, 60.0, 3.0, 3.0, 0.017, 4,
0.011, 0,32,                      <=== 0,32 should be 0.32
0.00, 2.50, 0.14, 0.15,
seed(45),
0.014, 20.00
);


#declare f_thin_fiber =
function(x, y, z, time_value) {
+0,50*f_thin_fiber_mockup0(           <=== 0,50 should be 0.50
     time_value,
     f_theta(x,y),
     f_height_for_bumps_extent(x, y, z)
)
+0,50*f_thin_fiber_mockup1(           <=== 0,50 should be 0.50
     time_value,
     f_theta(x,y),
     f_height_for_bumps_extent(x, y, z)
)
}

// ------------- large color ---------------------------

#declare f_large_color_block_mockup =
generate_thin_circled_pattern_f_input_t_theta_h(
10.0, 60.0, 3.0, 3.0, 2.32, 4,
0.144, 0,32,                      <=== 0,32 should be 0.32
0.00, 2.50, 0.14, 0.15,
seed(25),
0.014, 20.00
);

#declare f_large_color_block =
function(x, y, z, time_value) {
f_adjust_sharp_distribution(
     x, y, z,
     f_large_color_block_mockup(
         time_value,
         f_theta(x,y),
         f_height_for_bumps_extent(x, y, z)
     )
)
}
//----end code----

With these corrected, the application works!

I guess that those numbers may change with the input by the user (I did 
not see that happen, though). You know best where those particular 
numbers come from.

Next, I shall try to give my views/ideas on the layout, comprehensive 
use, etc, of the application.

-- 
Thomas

Post a reply to this message