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