Am 06.03.2017 um 21:32 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>> Then it would be easy to read variables as Complex[n].real and Complex[n].imag
>>
>> Doesn't sound like array-related to me at all, rather a feature of
>> 2-dimensional vectors.
>>
>> You realize that those would be aliases for `.x` and `.y`, right?
> 
> Yes, and yes.
> ...red, .u, .x, and .real would all be the same.
> ...green, .v, .y, and .imag would all be the same as well.

Hmm... I personally think `.r` and `.i` would be neater.

We could also have `i` as a vector constant `<0,1>`, much like `y` is a
vector constant `<0,1,0>`.

Then again, how about having a /genuine/ complex number type instead?
You know, stuff like:

    #declare Foo = 3 + 4*i;
    #declare Bar = Foo * Foo;

Note how the latter operation wouldn't give the right answer when using
2D vector arithmetics as currently implemented.


>> You mean, something like, say, a... /macro/ ?!
>> Yeah, I think it would be neat if POV-Ray had something like that ;)
> 
> OOOOH!   YES!   Macros would be _cool_.  Can we have macros?  PWEEEEEZE!
> 
> :P

Good news: It just so happens that the newest beta already features them ;)

Post a reply to this message

On 3/6/2017 9:01 PM, clipka wrote:
> Am 06.03.2017 um 21:32 schrieb Bald Eagle:
>> clipka <ano### [at] anonymousorg> wrote:
>>
>>>> Then it would be easy to read variables as Complex[n].real and Complex[n].imag
>>>
>>> Doesn't sound like array-related to me at all, rather a feature of
>>> 2-dimensional vectors.
>>>
>>> You realize that those would be aliases for `.x` and `.y`, right?
>>
>> Yes, and yes.
>> ...red, .u, .x, and .real would all be the same.
>> ...green, .v, .y, and .imag would all be the same as well.
>
> Hmm... I personally think `.r` and `.i` would be neater.
>
> We could also have `i` as a vector constant `<0,1>`, much like `y` is a
> vector constant `<0,1,0>`.
>
> Then again, how about having a /genuine/ complex number type instead?
> You know, stuff like:
>
>      #declare Foo = 3 + 4*i;
>      #declare Bar = Foo * Foo;
>
> Note how the latter operation wouldn't give the right answer when using
> 2D vector arithmetics as currently implemented.
>
>

Thank goodness. My brain was boiling.


>>> You mean, something like, say, a... /macro/ ?!
>>> Yeah, I think it would be neat if POV-Ray had something like that ;)
>>
>> OOOOH!   YES!   Macros would be _cool_.  Can we have macros?  PWEEEEEZE!
>>
>> :P
>
> Good news: It just so happens that the newest beta already features them ;)
>

+1 for the set up. ;)

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Why, yes, of course: Start your scene with
>
>     #version version; // sic!
>     #if (version >= 3.71)
>         #define Tau_Is_Reserved = true;
>     #else
>         #define Tau_Is_Reserved = false;
>     #end
>     #version 3.7; // minimum version

I haven't had a lot of time to think this through, but was wondering if a "fix"
such as this could be conveniently added into an include file like "consts.inc"
?



> The reason behind this is consistency of 2-dimensional arrays with
> arrays-of-arrays:

That's a great way to explain that.
I'll have to try coding things in macros more often, as it seems to be an
excellent way to clarify a good _mechanism_ by which to do something and
identify a good way to structure the code.


> > Command aliases.  A way to tell the parser to treat all instances of a statement
> > as a command to do "X"  - just like in a Unix shell.
>
> You mean, something like, say, a... /macro/ ?!
> Yeah, I think it would be neat if POV-Ray had something like that ;)


I actually wanted to add a bit of clarification about this:
Writing a macro is similar to what I was thinking, but the real core of the idea
is to have REAL aliases.
https://en.wikipedia.org/wiki/Alias_(command)

Invoking a macro would have a different syntax than the SDL directive.
If I wanted to use, say, "define" instead of "declare",
my thought was to have something along the lines of  #alias {define, declare}

With a macro, I can't write
#define Q = 12345;
and have the parser recognize it.

I'm not pushing for this as a new feature, I just wanted to clearly state my
original suggestion.
And I do realize what a radioactive fustercluck The Parser is.

Post a reply to this message

Am 15.03.2017 um 17:52 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> Why, yes, of course: Start your scene with
>>
>>     #version version; // sic!
>>     #if (version >= 3.71)
>>         #define Tau_Is_Reserved = true;
>>     #else
>>         #define Tau_Is_Reserved = false;
>>     #end
>>     #version 3.7; // minimum version
> 
> I haven't had a lot of time to think this through, but was wondering if a "fix"
> such as this could be conveniently added into an include file like "consts.inc"
> ?

Since such a file would come with a particular POV-Ray version, what use
would it be?


>>> Command aliases.  A way to tell the parser to treat all instances of a statement
>>> as a command to do "X"  - just like in a Unix shell.
>>
>> You mean, something like, say, a... /macro/ ?!
>> Yeah, I think it would be neat if POV-Ray had something like that ;)
> 
> 
> I actually wanted to add a bit of clarification about this:
> Writing a macro is similar to what I was thinking, but the real core of the idea
> is to have REAL aliases.
> https://en.wikipedia.org/wiki/Alias_(command)

"In computing, alias is a command in various command line interpreters
(shells) [...]"

Q: Is POV-Ray a command line interpreter?
A: No. It is an interpreted programming language.

=> "alias (command)" not applicable to this context.

> Invoking a macro would have a different syntax than the SDL directive.
> If I wanted to use, say, "define" instead of "declare",
> my thought was to have something along the lines of  #alias {define, declare}
    __
 ~ (__() ~ ~
  ~     ~

     ^
     |
Can of worms, opened.

Post a reply to this message

On 3/15/2017 6:23 PM, clipka wrote:
>      __
>   ~ (__() ~ ~
>    ~     ~
>
>       ^
>       |
> Can of worms, opened.


I like it. :)

-- 

Regards
     Stephen

Post a reply to this message

On 15-3-2017 20:06, Stephen wrote:
> On 3/15/2017 6:23 PM, clipka wrote:
>>      __
>>   ~ (__() ~ ~
>>    ~     ~
>>
>>       ^
>>       |
>> Can of worms, opened.
>
>
> I like it. :)
>

Now, why did he not make a regular POV-Ray scene of this, I wonder? 
Shame on the POV-Ray developer indeed! ;-)

-- 
Thomas

Post a reply to this message

On 3/16/2017 8:02 AM, Thomas de Groot wrote:
> On 15-3-2017 20:06, Stephen wrote:
>> On 3/15/2017 6:23 PM, clipka wrote:
>>>      __
>>>   ~ (__() ~ ~
>>>    ~     ~
>>>
>>>       ^
>>>       |
>>> Can of worms, opened.
>>
>>
>> I like it. :)
>>
>
> Now, why did he not make a regular POV-Ray scene of this, I wonder?
> Shame on the POV-Ray developer indeed! ;-)
>

It is the new ascii art, output. ;-)

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> > Yes, and yes.
> > ...red, .u, .x, and .real would all be the same.
> > ...green, .v, .y, and .imag would all be the same as well.
>
> Hmm... I personally think `.r` and `.i` would be neater.
>
> We could also have `i` as a vector constant `<0,1>`, much like `y` is a
> vector constant `<0,1,0>`.
>
> Then again, how about having a /genuine/ complex number type instead?
> You know, stuff like:
>
>     #declare Foo = 3 + 4*i;
>     #declare Bar = Foo * Foo;
>
> Note how the latter operation wouldn't give the right answer when using
> 2D vector arithmetics as currently implemented.

I like it.   A dedicate complex number system would be very nice.
I'm still more of a fan of .real and .imag.
(I'm actually a bigger fan of _both_ so folks can choose to use one or the
other)

Post a reply to this message

What would it take to get a "Point" or "Vector" object{} ?

I thought it might be useful as a "tag" to follow objects around ("Where did my
xyz go???")
The corners of a box could be defined with those vectors/points, and then when
it was transformed, the actual corners of the box - not the bounding box could
be easily accessible by the user.

It would be handy to just define that and plop it into a union to be transformed
like any other object{}, with the same exact syntax - especially for new users
who would have a hard time struggling with all of that vtransform stuff - it's
cumbersome and confusing until you've used it enough times to get the hang of
it.

Post a reply to this message

Am 21.03.2017 um 15:12 schrieb Bald Eagle:
> What would it take to get a "Point" or "Vector" object{} ?
> 
> I thought it might be useful as a "tag" to follow objects around ("Where did my
> xyz go???")
> The corners of a box could be defined with those vectors/points, and then when
> it was transformed, the actual corners of the box - not the bounding box could
> be easily accessible by the user.
> 
> It would be handy to just define that and plop it into a union to be transformed
> like any other object{}, with the same exact syntax - especially for new users
> who would have a hard time struggling with all of that vtransform stuff - it's
> cumbersome and confusing until you've used it enough times to get the hang of
> it.

What you suggest would be inconsistent with the existing primitives.
Remember that

    #declare Foo = sphere {...}
    #declare Bar = union { object{Foo} ... translate ... }

will /not/ modify `Foo`, but rather add a nameless copy of it to `Bar`; so

    #declare Foo = point {...}
    #declare Bar = union { object{Foo} ... translate ... }

should, for the sake of consistency, not modify `Foo` either, making the
whole thing pretty useless.

Post a reply to this message