Hello,

Let an array of "4D" vectors.
This code works well :

#write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )




Now with and array of "5D" vectors.
Base on the same schema i code this :

#write ( FH, 
Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit 
)

And i get this error : "Expected 'string', colour identifier found instead".


On <https://wiki.povray.org/content/Reference_Talk:Vector_Expressions> 
from Bald Eagle, you can read :
#declare Vector = < 1, 2, 3, 4, 5>;
...
#declare Fifth_Component = Vector.transmit;// 5


The fifth element corresponds well to the keyword "transmit".
So why did this error occur?

I got around the issue like this :
#declare _x = Array[i].x;
#declare _y = Array[i].y;
#declare _z = Array[i].z;
#declare _f = Array[i].filter;
#declare _t = Array[i].transmit;
#write ( FH, _x,",",_y,",",_z,",",_f,",",_t )

However, I would like to understand what is wrong with my syntax.
Thank you for your help.






-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

On 10/20/25 03:53, kurtz le pirate wrote:
> Let an array of "4D" vectors.
> This code works well :
> 
> #write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )

Below the contents of a documentation scene I'm adding to the next yuqk 
release (R20). What's going on is part of a larger tangle due when and 
how the features involved were implemented over time.

Bill P.

//---
// Odd behavior with 'write' and 5D color vectors...

#declare V2 = <1,2>;
#declare V3 = <1,2,3>;
#declare V4 = <1,2,3,4>;
#declare V5 = <1,2,3,4,5>; // Internally this a 'color vector'

#fopen FH "zzz" write

// These are OK in yuqk or in v3.8 beta 2
#write (FH,V3.x,",",V3.y,",",V3.z)
#write (FH,V4.x,",",V4.y,",",V4.z,",",V4.t)
#write (FH,(V5.x),",",(V5.y),",",(V5.z))
#write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t))
#write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t)",",(V5.transmit))
#write (FH,V2)
#write (FH,V3)
#write (FH,V4)

// This fails in yuqk and in v3.8 beta 2 because 'write' only
// supports 2D, 3D and 4D vectors.
#if (0)
#write (FH,V5)
#end

// This fails in v3.8 beta 2 because 'write' only supports 2D, 3D
// and 4D vectors. Due how the dot operator works, incorrectly,
// for the v3.8 tuple feature the V5.transmit is first seen as a 5D
// color vector - before it is seen as a float due the dot operator.
#if (0)
#write (FH,V5.transmit)
#end

// These fail in yuqk due fixes with the tuple assignment feature of
// v3.8 which changes how the dot operators are evaluated. The yuqk
// fork always sees 'V5' before it thinks about the dot operator. In
// other words, with yuqk you must wrap all, 5D color vector, element
// to float conversions in ()s with write!
#if (0)
#write (FH,V5.x,",",V5.y,",",V5.z)
// #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.t)
// #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.transmit)
#end

#fclose FH

#error "Stop early"
//---

Bill P.

Post a reply to this message

Le 2025-10-20 à 03:53, kurtz le pirate a écrit :
> 
> 
> Hello,
> 
> Let an array of "4D" vectors.
> This code works well :
> 
> #write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
> 
> 
> 
> 
> Now with and array of "5D" vectors.
> Base on the same schema i code this :
> 
> #write ( FH, 
> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit )
> 
> And i get this error : "Expected 'string', colour identifier found 
> instead".
> 
> 
> On <https://wiki.povray.org/content/Reference_Talk:Vector_Expressions> 
> from Bald Eagle, you can read :
> #declare Vector = < 1, 2, 3, 4, 5>;
> ...
> #declare Fifth_Component = Vector.transmit;// 5
> 
> 
> The fifth element corresponds well to the keyword "transmit".
> So why did this error occur?
> 
> I got around the issue like this :
> #declare _x = Array[i].x;
> #declare _y = Array[i].y;
> #declare _z = Array[i].z;
> #declare _f = Array[i].filter;
> #declare _t = Array[i].transmit;
> #write ( FH, _x,",",_y,",",_z,",",_f,",",_t )
> 
> However, I would like to understand what is wrong with my syntax.
> Thank you for your help.
> 

Working from William's reply, I have this workaround :
Replace :
#write ( 
FH,Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit 
)

With :
#declare Trans = Array[i].transmit;
#write ( FH, 
Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Trans )

Post a reply to this message

On 20/10/2025 12:49, William F Pokorny wrote:
> On 10/20/25 03:53, kurtz le pirate wrote:
>> Let an array of "4D" vectors.
>> This code works well :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
> 
> Below the contents of a documentation scene I'm adding to the next yuqk 
> release (R20). What's going on is part of a larger tangle due when and 
> how the features involved were implemented over time.
> 
> Bill P.
> 
> //---
> // Odd behavior with 'write' and 5D color vectors...
> 
> #declare V2 = <1,2>;
> #declare V3 = <1,2,3>;
> #declare V4 = <1,2,3,4>;
> #declare V5 = <1,2,3,4,5>; // Internally this a 'color vector'
> 
> #fopen FH "zzz" write
> 
> // These are OK in yuqk or in v3.8 beta 2
> #write (FH,V3.x,",",V3.y,",",V3.z)
> #write (FH,V4.x,",",V4.y,",",V4.z,",",V4.t)
> #write (FH,(V5.x),",",(V5.y),",",(V5.z))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t)",",(V5.transmit))
> #write (FH,V2)
> #write (FH,V3)
> #write (FH,V4)
> 
> // This fails in yuqk and in v3.8 beta 2 because 'write' only
> // supports 2D, 3D and 4D vectors.
> #if (0)
> #write (FH,V5)
> #end
> 
> // This fails in v3.8 beta 2 because 'write' only supports 2D, 3D
> // and 4D vectors. Due how the dot operator works, incorrectly,
> // for the v3.8 tuple feature the V5.transmit is first seen as a 5D
> // color vector - before it is seen as a float due the dot operator.
> #if (0)
> #write (FH,V5.transmit)
> #end
> 
> // These fail in yuqk due fixes with the tuple assignment feature of
> // v3.8 which changes how the dot operators are evaluated. The yuqk
> // fork always sees 'V5' before it thinks about the dot operator. In
> // other words, with yuqk you must wrap all, 5D color vector, element
> // to float conversions in ()s with write!
> #if (0)
> #write (FH,V5.x,",",V5.y,",",V5.z)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.t)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.transmit)
> #end
> 
> #fclose FH
> 
> #error "Stop early"
> //---
> 
> Bill P.

Thanks Bill.


I see "This fails in v3.8 beta 2 because 'write' only supports 2D, 3D 
and 4D vectors."

So in a way, it's not coming from me.
Phew!


One more thing to add (or not?) to your to-do list for v4.




-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

On 20/10/2025 13:20, Alain Martel wrote:
> Le 2025-10-20 à 03:53, kurtz le pirate a écrit :
>>
>>
>> Hello,
>>
>> Let an array of "4D" vectors.
>> This code works well :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
>>
>>
>>
>>
>> Now with and array of "5D" vectors.
>> Base on the same schema i code this :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit
)
>>
>> And i get this error : "Expected 'string', colour identifier found 
>> instead".
>>
>>
>> On <https://wiki.povray.org/content/Reference_Talk:Vector_Expressions> 
>> from Bald Eagle, you can read :
>> #declare Vector = < 1, 2, 3, 4, 5>;
>> ...
>> #declare Fifth_Component = Vector.transmit;// 5
>>
>>
>> The fifth element corresponds well to the keyword "transmit".
>> So why did this error occur?
>>
>> I got around the issue like this :
>> #declare _x = Array[i].x;
>> #declare _y = Array[i].y;
>> #declare _z = Array[i].z;
>> #declare _f = Array[i].filter;
>> #declare _t = Array[i].transmit;
>> #write ( FH, _x,",",_y,",",_z,",",_f,",",_t )
>>
>> However, I would like to understand what is wrong with my syntax.
>> Thank you for your help.
>>
> 
> Working from William's reply, I have this workaround :
> Replace :
> #write 
> (
FH,Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit
)
> 
> With :
> #declare Trans = Array[i].transmit;
> #write ( FH, 
> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Trans )
> 

Yes Alain, shorter as my workaround but in the same spirit.




-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Do we have a comprehensive list of unfixed bugs for various POV-Ray features?

It might be helpful to have some method by which we list known limitations and
bugs in the actual documentation until such time that they get fixed.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Do we have a comprehensive list of unfixed bugs for various POV-Ray features?
>
> It might be helpful to have some method by which we list known limitations and
> bugs in the actual documentation until such time that they get fixed.

That's what github is for. Once a bug is identified as a bug (here on the forum)
post it and the information gathered on github. Or post it directly on github
and discuss there. Personally I prefer here,

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Do we have a comprehensive list of unfixed bugs for various POV-Ray features?


> That's what github is for. Once a bug is identified as a bug (here on the forum)
> post it and the information gathered on github. Or post it directly on github
> and discuss there. Personally I prefer here,


An expected reply, and exactly the kind of thing I'm trying to avoid.
Just look at the 30-year collection of information that we have here on the
newsgroup.  Too vast, too spread out, and currently unreliably searchable.
And I don't want to go to github and have to then sift through all of that.

What I'd like is a consolidated, up-to-date list that anyone can look at
"at-a-glance" and be able to readily assess the state of every keyword and
primitive, and distribution include file, etc.

Right here on our own, locally-controlled server space.
Because I prefer "here" as well.

I should be able to scroll down to, or search for #read, and only see _existing_
bugs (unless I want to view the bug report and remediation history).  Every new
POV-Ray task should not trigger a new, epic quest.

3rd party stuff is undeniably useful.  However I disdain _reliance_ upon it.
Just look at the Object Collection fiasco.

Here again, I will shamelessly make a plug for some kind of project management
system.

- BW

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > Do we have a comprehensive list of unfixed bugs for various POV-Ray features?
> > That's what github is for. Once a bug is identified as a bug (here on the forum)
> > post it and the information gathered on github. Or post it directly on github
> > and discuss there. Personally I prefer here,
> ...
> What I'd like is a consolidated, up-to-date list that anyone can look at
> "at-a-glance" and be able to readily assess the state of every keyword and
> primitive, and distribution include file, etc.
> Right here on our own, locally-controlled server space.
> Because I prefer "here" as well.

+1 wrt "here".

a wiki page, with simple "bullet" list ?


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Here again, I will shamelessly make a plug for some kind of project management
> system.
>

Github has that and many other tools, but you have to pay.
https://github.com/features/issues I'm not a github user so I know little of it.

I asked their "thing" for a summary:

Copilot said: Here is a summary of the issues

Here is a summary of the issues for POV-Ray, ordered by severity (highest to
lowest). Please note: this is based on public issue titles, labels, and visible

project maintainers.
Critical Bugs & Vulnerabilities

    Potential Vulnerabilities (Cloned Functions)
        Fix potential vulnerable cloned function
        Fix potential vulnerable cloned functions
        Fix potential vulnerable cloned function Severity: Security-related,
likely the most urgent.

    Bug: Functionality Failure
        [BUG] function "trace" fails to find intersections in distances of more
than 10⁷ units Severity: Major feature broken for large distances.

    Build/Compatibility Failures
        [BUILD][UNIX] Failure on macOS w/ Xcode 16.4, error: unknown type name
'Fixed'
        [BUILD][UNIX] Build fails with strict-aliasing violations
        [BUILD][UNIX] Test for Boost Libraries fail on Apple silicon (Homebrew
path change) Severity: Prevents build on certain platforms.

    Bug: Parse/Error Handling
        [BUG] Parse error when using povray built by GCC 13, no error with GCC
12
        [BUG] doesn't give an error if a polygon is not 2D
        [BUG][UNIX] Failed to parse command line option with space in filename
Severity: Could lead to silent failures or unpredictable behavior.

    Bug: Memory/Allocation
        Assigned interior causes a bad allocation error Severity: May cause
crashes or data corruption.

    Bug: Incorrect Rendering
        Photons do not work properly with true inverse power fading
        Option "Keep Single Instance" is not working for *.inc files
        Error in POV-RAY output generated from Project Chrono Demo Severity: Can
result in incorrect output or broken features.

Medium Severity

    Performance/Optimization
        Usage of Enhanced Math Library for better performance
        AVX512 version for POVRAY Severity: Performance improvements, not
critical but useful.

    Feature Requests: Important for Users
        [FEATURE] support all Opentype font formats
        [FEATURE] LaTeX support
        Can we develop POV-RayMCP similar to BlenderMCP? Severity: Not bugs, but
could be important for project adoption.

Low Severity / Minor Issues

    Minor Bugs and UI Issues
        Debug string is not displayed in console if start with more than 14
hyphens
        Need to run POVRAY on a single thread
        Updates to screen.inc
        Issue a parse warning for out-of-domain arguments to the srgb keywords
        remove unecessary nullptr check before 'delete' and 'delete[]'
        Apply translate and rotate to user_defined cameras.
        Fixing some missing stuff in VS 2022
        What about 3.7 branch ? Severity: Minor bugs, enhancements, or
low-priority tasks.

Note:

    This list is based on 30 issues (API limit). For a complete and up-to-date
list, view all POV-Ray issues on GitHub.

on user impact, security, or strategic goals.
    If you want a more detailed triage or deeper analysis of a specific issue,
let me know!


ingo

Post a reply to this message