Just putting this out there as a suggestion - things I've recently thought could
be useful or have been bouncing around in the back of my mind.

New dot operators - .real and .imag, for when programming arrays of complex
numbers
#declare Complex = array [n] {<Real, Imag>, ....}

Then it would be easy to read variables as Complex[n].real and Complex[n].imag


I was running a scene in 3.7 after I wrote it in 3.7 Beta 2 and used the new
Built-In Variable tau.
I don't think a statement like #ifdef (tau) works.
Perhaps some way to determine from SDL if a name is reserved by POV-Ray?

Transposed array format.   Because the down then over format drives me nuts.
I think in over then down, especially when reading the definition in SDL,
because it's written on the screen over, then down.  :(

Secondary comment type which invokes a different color in the editor.
Could be useful for highlighting things if there was red text in a sea of green
commenting.

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.

Post a reply to this message

Am 06.03.2017 um 16:20 schrieb Bald Eagle:
> Just putting this out there as a suggestion - things I've recently thought could
> be useful or have been bouncing around in the back of my mind.
> 
> New dot operators - .real and .imag, for when programming arrays of complex
> numbers
> #declare Complex = array [n] {<Real, Imag>, ....}
> 
> 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?


> I was running a scene in 3.7 after I wrote it in 3.7 Beta 2 and used the new
> Built-In Variable tau.
> I don't think a statement like #ifdef (tau) works.

You're correct. That's why you get a warning if you try.

> Perhaps some way to determine from SDL if a name is reserved by POV-Ray?

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

;)

Of course this won't work with earlier 3.7.1 development versions; but
that's how things go with those alpha versions: You can't count on
scenes running on any given alpha to later run on the real deal (or even
the very next alpha).


> Transposed array format.   Because the down then over format drives me nuts.
> I think in over then down, especially when reading the definition in SDL,
> because it's written on the screen over, then down.  :(

POV-Ray's format is standard in pretty much each and every programming
language, and I know of none that provides an alternative format.

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

    declare Foo = array[2][3] {
      { "0.0", "0.1", "0.2" },
      { "1.0", "1.1", "1.2" },
    }
    declare Bar = Foo[A][B];

has the same effect as:

    declare Foo = array[2] {
      array[3] { "0.0", "0.1", "0.2" },
      array[3] { "1.0", "1.1", "1.2" },
    }
    declare Bar = Foo[A][B];


> Secondary comment type which invokes a different color in the editor.
> Could be useful for highlighting things if there was red text in a sea of green
> commenting.

Sounds like more of a feature suggestion for an editor than POV-Ray /per
se/, provided you make that secondary comment type a subset of the
standard comment type. E.g, you could hack your editor's syntax
highlighting scheme to mark comments starting with `/*!` or `//!`
differently.

As we consider the Windows GUI pretty much obsolete and not worth
putting any effort into it in terms of "nice to have" features (we'd
much rather invest our time and energy into a new Qt-based GUI), and
also because this would actually have to be implemented in the editor
DLLs which we're /very/ reluctant to change now (due to the licensing
issues involved), I can almost guarantee that you won't see this feature
implemented in that thing we currently call "POV-Ray for Windows".


> 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 ;)

Post a reply to this message

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.


> 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

Post a reply to this message

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