On 11/8/23 17:24, Bald Eagle wrote:
> I figure I'll put this here, rather than embedding it in the midst of other
> threads.

:-) The feature wish lists never get shorter. Elsewhere you'd mentioned 
stl import. I started a longer response there, but got side tracked.

The short version of it is:

- I believe hgpovray38 has a simple import method inbuilt today.

- My direction with yuqk is generally away from larger extensions like 
this being jammed into the POV-Ray core code. They make for a mess as 
seen by the user and those supporting / changing the internal code. I 
recently removed the julia_fractal shape, for example. We are not set up 
well for larger extensions except where they can be implemented as SDL 
coded includes or they work as inbuilt / user functions.

> 
> I'm currently working out some code to create some piece-wise functions with
> very specific constraints.
> 
> During development, I noticed some odd mismatches, seemingly resulting from the
> manner in which 3-argument select () statements work.
> 
> Using the 4-argument form and (repeating the equation to evaluate after a comma)
> doesn't seem to correct this.
> 
> Specifically, each section of the piece-wise function never reaches the end of
> its domain, and instead, the next section of the nested select statement starts
> getting evaluated.
> I shifted the 2nd segment up a bit to illustrate the problem in the attached
> image. (disregard the file name)
> 
> https://wiki.povray.org/content/Reference:Numeric_Expressions
> select(A, B, C [,D])
> It can be used with three or four parameters Select compares the first argument
> with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
> floats or fun(c)tions.
> When used with three parameters, if A < 0 it will return B, else C (A >= 0).
> When used with four parameters, if A < 0 it will return B. If A = 0 it will
> return C. Else it will return D (A > 0).
> 

On my list to look at your select questions / ideas in more detail. What 
always pops to my mind when folks mention select() and bugs is whether 
we are switching on signed zeros - my head just isn't immediately 
remembering enough to say more at the moment.

> 
> 
> Maybe that's something that I'm doing wrong, or maybe there's a hidden issue
> with select () that's never been uncovered yet.
> 
> But it did make me think that there ought to be a way to reverse which "side" of
> the evaluation A = 0 gets included in:
> 
> When used with three parameters (in the reverse case), if A <= 0 it will return
> B, else C (A > 0).
> 
> 
> Also, in past projects I have run into situations where I'd like to use matrix
> transforms but with variable arguments.
> 
> Exposure of the elements of a matrix to SDL would be helpful when trying to
> apply multiple matrix transforms to something and intermediate stages need to be
> debugged, or simple matrix calculations need to be performed, letting
> POV-Ray/yuqk do the heavy lifting.
> 
> Freya Holmer just put out another video on multiplying vectors, and mentioned
> how when working with octonions, simply swizzling vector components allowed
> rapid calculations to be performed using that "trick".
> 
> Vector swizzling (Vec.zxy) would be handy
> 
> Vector functions would be positively worth paying for.
> Both user-defined, and inbuilt.
> vectors allowed as arguments, vector components as arguments, and vector
> results.
> sin (<x, y, z>) ought to give me a result of <sin x, sin y, sin z>
> 
> Allowing arrays to be referenced or processed by functions would be great as
> well.

A general capability not likely anytime soon.

I have added additional encodings into and out of a double's space to 
the yuqk fork. These effectively very tiny arrays which can be passed 
around in the parser and VM inside the double float space.

In some situations you can use an image_map created from a function as a 
function accessible array. There is an example of this in the 
histogram.pov file shipped now in the yuqk documentation tarball.

> 
> Vector sizes and elements in things like prisms ought to be versatile and/or
> standardized.  Having to convert points to a 2D vector is a PITA.
> 

The tuple / batch / bulk / list assignment methods are supposed to help 
some with this sort of vector type issue. Though I confess, I've not 
thought much about how to set it up efficiently / generally.

#local V = <0,0,0>; // 3D vector
#local <A,B> = V;   // Tuple method grabs first two elements of V
#local V = <A,B>;   // UV vector
prism {
   linear_spline
   0, 1, 10,
   V,
   ....

> Access to data types would be great.

The yuqk fork offers what is in setidtypes.inc.

> agnostic input data type for #read would be excellent as well.

Yeah, we really should be able to import STL with SDL itself...

> There's also the issue of determining the number of elements in a vector.

See setidtypes.inc

> 
> Lots of functions in math.inc that ought to be inbuilt.

I'd add shapes.inc, color.inc ...

Some of this has been done (see yuqk's math.inc), but yes, extending the 
core function set where we can makes sense.

> 
> Lots more I'm sure.  Don't worry, I'll think of them   ;)
> 
> - BW
>

Post a reply to this message