POV-Ray : Newsgroups : povray.newusers : Ignorance rules! Server Time
24 Jun 2021 09:24:40 EDT (-0400)
  Ignorance rules! (Message 11 to 20 of 28)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 8 Messages >>>
From: William F Pokorny
Subject: Re: Ignorance rules!
Date: 24 Jun 2020 13:53:11
Message: <5ef39307$1@news.povray.org>
On 6/23/20 2:25 PM, Bald Eagle wrote:
> 
...
> 
Aside: I see my response is one where the formatting got wonky. Unsure 
why it happens. I've looked for offending settings in thunderbird. Maybe 
particular newsgroups or original quoted text with certain characters a 
trigger? I don't know. Apologies, but I don't see the issue on sending.

-----------

First, reminding everyone 'povr' is not POV-Ray. I'm combining my 
responses and when I start to think about major revisions to POV-Ray's 
SDL, I begin to think seriously about bindings to lua, tcl and python.

--- The _<lowercase> arguments would be the way to avoid parameter 
collisions. Nothing required, but if you don't want trouble...

--- On the idea of per include file generated unique names(1) and 
sorting on include order as a way to decide which 'Thing1' you want. 
Includes very often include other files. It can be an unstable tangle. 
The 'topological sort' can change relative to low level includes based 
on adding other includes, user settings, macro settings, etc. We 
struggle with these same ordering issues in c, c++ header files as jr 
pointed out. Most programming languages have collision issues / scope 
issues which you have to understand(2) - even with namespace support(3).

(1) - In my tcl library I have a UniqueName command which uses a global 
counter to create unique names. The counter value gets used as a suffix 
to create, say, 'Union_0123' and there are options for padding and 
delimiting characters. This generated unique id approach works well in 
languages with good 'list' (c++ std::vector) support. It has the 
exposure things can blow up storage wise if you aren't careful. I've 
found it easy to duplicate.  Today, POV-Ray internally flattens / 
duplicates - excepting meshes and a few other things. Perhaps, not a bad 
approach practically - if we had the list support.

(2) - Excepting those languages which never allow re-definition/undef 
within any given scope. This is the central concept used in functional 
programming languages. I'm toying with povr working in this way - for 
non SDL programming elements (objects, textures, macros, functions). 
Namely all name collisions and undefs being illegal for classes of 
things not needed for program control.  Toying != knowing how. :-)

(3) - Most namespace languages to which I've been exposed support a 
'using <namespace>::min' sort of declaration. These often get used - 
because people don't like to type - but, allowing the shorthand can 
weaken the namespace protections.

--- On jr's point about no type checking. I think we are not too 
exposed. While there is no strict up front type checking, it looks to me 
like the parser tracks the current id types so you cannot incorrectly 
use the wrong type due a bad/unfortunate assignment somewhere.

--- On making the lower case named functions in math.inc inbuilt. I 
might with some/all. I'm ever refining. Everything takes time and nearly 
always more than I first imagine. Step one for me was just getting clear 
what they really were and moving them to functions.inc where I've 
already slowly been changing f_agate and similar wrappers to inbuilt 
functions.

--- On eval_pigment / Eval_Pigment (and alias capability). I've never 
liked eval_pigment! It's not inbuilt, but we talk about it like it is. 
The functionality is already inbuilt. It's this:

     #include "strings.inc"
     #declare Vec  = <1,2,3>;  //                       *** ***
     #declare FnPig00 = function { pigment { rgb <0,1,0,0.2,0.3> } }
     #declare Rslt = FnPig00(Vec.x,Vec.y,Vec.z);
     #debug concat("   ",CRGBFTStr(Rslt,2,2),"\n")

The problem with things like eval_pigment and alias capability is they 
hide the actual code/functionality mostly on the argument of less 
typing(4). If you want to type less, add hot key sequences to your 
editor to insert code templates.  There's a place for the ability to 
alias or redefine inbuilt functionality in a language, but it should not 
be generally used. It makes things harder to learn and harder to debug. 
I was once handed code to debug where the user had, almost completely, 
redefined the actual input language with aliases.

I cannot add Eval_Pigment to texture.inc. The only include files 
currently packaged with povr are:

     arraycoupleddf3s.inc  functions.inc  rand.inc    strings.inc
     arrays.inc            math.inc       shapes.inc  transforms.inc

My povr approach is includes will be in their own code repository. 
Except rarely where what's in the include is essential to core 
functionality. I've moved Eval_Pigment to math.inc for now as core 
functionality, but it's on my 'maybe it should just go away' list.

(4) - And, yep. I don't like the DBL, SNGL in our source code since 
v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
years back which then never got adopted. PRECISE_FLOAT now needs to be 
yanked at some point from povr and I'd like to drop DBL and SNGL too. 
Today you can find the bare 'foat/double' declarations in the source 
code depending on who wrote what. This makes it unlikely we can really 
ever change DBL to be anything but double, for example. Certainly not 
without a lot of type conversions even if, by some chance, everything 
works correctly.

--- On additional lower case constants becoming in-built. I'm not 
opposed so long as they are very common. V38 added tau.

Bill P.


Post a reply to this message

From: jr
Subject: Re: Ignorance rules!
Date: 24 Jun 2020 20:15:01
Message: <web.5ef3ebf5ea0d75ea4d00143e0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/23/20 2:25 PM, Bald Eagle wrote:
> >
> ...
> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
> responses and when I start to think about major revisions to POV-Ray's
> SDL, I begin to think seriously about bindings to lua, tcl and python.

so, it is late and I had too much coffee, probably..  :-)

how about replacing the SDL, wholesale?!

not knowing the codebase[*], but if the "SDL" was simply a (Tcl) "safe
interpreter", with all the SDL language constructs as commands, then we could
write something like:

set version 3.8

array set global_settings {
  assumed_gamma 1
}

light_source {-1 0 -1 10e5} {color {1 1 1} parallel}


:-)

[*] assuming that the source except 'frontend' and 'parser' stuff would be
(relatively) unaffected.

added, potential, incentives: storing the distribution .inc files,
pre-processed, in a Sqlite db; using a zip VFS for managing/distributing
projects with many files; "reflected channel" to read compressed .inc files (for
large meshes, or Hilbert curves :-)).

flights of fancy..

> ...
> (1) ... if we had the list support.

would be built in.  ;-)

> ...
> (3) - Most namespace languages to which I've been exposed support a
> 'using <namespace>::min' sort of declaration. These often get used -
> because people don't like to type - but, allowing the shorthand can
> weaken the namespace protections.

a typical "Problem Exists Between Chair And Keyboard" problem.

> --- On jr's point about no type checking. I think we are not too
> exposed. While there is no strict up front type checking, it looks to me
> like the parser tracks the current id types so you cannot incorrectly
> use the wrong type due a bad/unfortunate assignment somewhere.

sure, I just think that, just like for regular arrays, when an identifier has
been "cast" to type A, a subsequent assigning of type B should output a warning
(preferably cause an error).  because, in all likelihood, it'll be a typo or
logic error.

> ...
> --- On eval_pigment / Eval_Pigment (and alias capability). I've never
> liked eval_pigment! It's not inbuilt, but we talk about it like it is.

naive question.  calling the macro returns the colour in pigment at given point.
 but what good is that information, given that lighting is not part of the
process?


regards, jr.


Post a reply to this message

From: Bald Eagle
Subject: Re: Ignorance rules!
Date: 24 Jun 2020 21:05:01
Message: <web.5ef3f7dcea0d75eafb0b41570@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> so, it is late and I had too much coffee, probably..  :-)

Too much _something.
WTH is "too much coffee?"   :P


> how about replacing the SDL, wholesale?!

That has its merits, and may be a method of addressing all of the double/single
issues in the process...


> sure, I just think that, just like for regular arrays, when an identifier has
> been "cast" to type A, a subsequent assigning of type B should output a warning
> (preferably cause an error).  because, in all likelihood, it'll be a typo or
> logic error.

Could be.   But I like the flexibility afforded by re-casting things on the fly.
Learning good coding practices aside, allowing scenes to WORK (newbies to
POV-Ray in mind) is something we should encourage.
Issue warnings and suggestions - but full stop halts of parsing can be a real
bummer.

> > --- On eval_pigment / Eval_Pigment (and alias capability). I've never
> > liked eval_pigment! It's not inbuilt, but we talk about it like it is.

I like the capability, but I agree with the obfuscation.  I've learned SO much
from WP and the do-it-from-scratch ShaderToy community.  Perhaps eval pigment
should be an example scene illustrating how to write functions that process
patterns.
But also, given that we often use it with things like ("large") images in
image_pattern, I'd like to see a speed improvement by moving something like that
to source, so that an array of RGB values can be accessed and acted upon
speedily, via compiled code.

> naive question.  calling the macro returns the colour in pigment at given point.
>  but what good is that information, given that lighting is not part of the
> process?


Because you're not trying to jump ahead in time beyond when the lighting and
ambient occlusion get applied.  You're looking to inspect the "color
composition" of the base object.

perhaps for pattern purposes.
http://news.povray.org/povray.binaries.images/thread/%3Cweb.52ede41cd6fcc84f7a3e03fe0@news.povray.org%3E/?mtop=391443&m
off=7
http://news.povray.org/povray.binaries.images/message/%3C3b8946fd%40news.povray.org%3E/#%3C3b8946fd%40news.povray.org%3
E
http://news.povray.org/povray.binaries.images/thread/%3C5078802b%40news.povray.org%3E/

or for use as a map to place objects
http://www.povcomp.com/entries/124.php
http://news.povray.org/povray.binaries.images/message/%3C409135b4%40news.povray.org%3E/



Similar questions have been raised:
http://news.povray.org/povray.general/thread/%3C5be81e8e%241%40news.povray.org%3E/

If you want lighting, you can render, and then use eval pigment on the rendered
image, which obviously has the lighting effects in the final computation of the
pixel color value.


Post a reply to this message

From: jr
Subject: Re: Ignorance rules!
Date: 25 Jun 2020 07:50:00
Message: <web.5ef48eccea0d75ea4d00143e0@news.povray.org>
hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > so, it is late and I had too much coffee, probably..  :-)
>
> Too much _something.
> WTH is "too much coffee?"   :P

</grin>

> > ...  because, in all likelihood, it'll be a typo or logic error.
>
> Could be.   But I like the flexibility afforded by re-casting things on the fly.
> Learning good coding practices aside, allowing scenes to WORK (newbies to
> POV-Ray in mind) is something we should encourage.
> Issue warnings and suggestions - but full stop halts of parsing can be a real
> bummer.

the flip side is, every such "flexibility" comes, somewhere down the line, at
some cost.  for instance, allowing:
#declare A = "foo";
....
#declare A = <1,2,3>;

gives flexibility, but also means that (automatically) optimising code has
become too costly (in time), if not impossible altogether.


> > > --- On eval_pigment / Eval_Pigment (and alias capability).
> Similar questions have been raised:  ...

interesting thread, thanks.


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Ignorance rules!
Date: 25 Jun 2020 08:41:19
Message: <5ef49b6f$1@news.povray.org>
On 6/24/20 8:12 PM, jr wrote:
...
>> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
>> responses and when I start to think about major revisions to POV-Ray's
>> SDL, I begin to think seriously about bindings to lua, tcl and python.
> 
> so, it is late and I had too much coffee, probably..  :-)
> 
> how about replacing the SDL, wholesale?!
> 

Suppose the short answer is it's harder than it looks... And I agree 
with Bald Eagle about there never being enough coffee. When did I last 
drink water, straight... :-)

I have a somewhat complete set of tcl wrappers for POV-Ray 'SDL' 
creation which I use about as often as POV-Ray's SDL itself when 
creating scenes. It's an effort started as a small limited utility which 
grew into something to explore what a tcl scene description language 
might be like. It's an experiment so approaches drift and change. Some 
parts are now quite old/dated.

There are a good many subtle things POV-Ray's language (the parser) does 
to help us code that are not easy to replicate even supposing one knows 
what they all are... I guarantee I've still got lots of bugs in this 
aspect of my wrapping.

With respect to actual bindings, the source code is better partitioned 
than it was - thanks mostly to Christoph. Still, any bindings reasonably 
complete are a ways off from doable in my opinion. This doesn't mean 
it's not possible to create particular bindings today. Somewhere I have 
an experiment where I was binding particular shape functions for testing 
purposes. A kind of tcl unit test, but it's work since gone cold.

The aim with what I have is that every scene entity is a definable item 
with an ID. POV-Ray started with this approach and then dropped this 
concept when certain features were added - radiosity, warps, etc. - over 
time. Not sure of all the whys. With define-ability in place you can 
define RadiosityQuick and RadiosityFinal for example and then pick in 
the 'SDL/Tcl' which to use by name.

The start of a scene with my wrappers looks like:

set FID "FIDmain"
DefVersion        Version      $FID "3.8" -unofficial povr
DefGlobalSettings Global00     $FID -assumed_gamma 1.0
DefBackground     Background00 $FID -color Grey50

DefLight Light00 $FID -location 50.0,150.0,-250.0 -color White
#... ending with:
Scene tmp.pov $FID -i Version -i Background00 -i Global00
	-i Camera00 -i Light00

Every command has inbuilt help; fairly extensive checking; most have 
inbuilt examples which can be used for testing and some have specific
test scenes too. Where you see -color the color definition is created on 
the fly when not already done from a large library of color names. What 
gets included in any particular scene/include file is based on 
dependencies from the -i, -d and -c Scene flags.

Anyway. Details not that important. The point is I've been playing with 
a wrapper for a long time (10 years on and off now) - and while 
extensive, it's not complete. Parts of it I look at today and want to 
rework, but where it's mostly working, I leave it. It's an experiment.

It's not quite what you posted example wise, but I do sometimes wonder 
how far one might get creating a tcl intepreter supporting POV-Ray's 
commands as is. Meaning, aiming more for a parser replacement without 
trying to address existing shortcomings from the start.

Bill P.


Post a reply to this message

From: Bald Eagle
Subject: Re: Ignorance rules!
Date: 25 Jun 2020 14:00:00
Message: <web.5ef4e5c7ea0d75eafb0b41570@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> the flip side is, every such "flexibility" comes, somewhere down the line, at
> some cost.  for instance, allowing:
> #declare A = "foo";
> ....
> #declare A = <1,2,3>;
>
> gives flexibility, but also means that (automatically) optimising code has
> become too costly (in time), if not impossible altogether.

I don't know how it gets optimized, or why allowing recasting would break that.

If I can envision a macro that checks if an identifier that I'm trying to use is
defined - and if it is, then first I undefine it, and then proceed as usual -
then I would imagine that such a  thing could be done in C / c++.

It would be very nice indeed if we had a way in SDL (or povr) to determine the
type of an identifier.  This would be _extremely_ useful when importing data
with #read and probably other cases as well.

As much as I like the programming aspect of POV-Ray, it is of course, a
raytracer, and the point is to make renders, not pedantically ram "best coding
practices" down some newbie doodler's throat.

At that point, perfect becomes the mortal enemy of good, and we lose a lot of
otherwise new USERS - which POV-Ray will die without.  Having recently been
thrust into coding the Arduino, which is supposed to be designed for "beginners"
and kids - dealing with all of the esoteric BS involved with strings and serial
input, buffers, types, etc --- it's a REAL PITA to even perform otherwise simple
tasks.  And I'll bet some people simply give up out of frustration.

Do we really want to repel people with an even steeper learning curve?

I mean, I see us stuck between accessibility, speed, and accuracy.
And the multithreaded source code has already become a vast, organically
interwoven behemoth.  It's hard to say what the best route to take is.


Post a reply to this message

From: Thorsten
Subject: Re: Ignorance rules!
Date: 26 Jun 2020 01:43:35
Message: <5ef58b07$1@news.povray.org>
On 24.06.2020 19:53, William F Pokorny wrote:
> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
> years back which then never got adopted. PRECISE_FLOAT now needs to be 
> yanked at some point from povr and I'd like to drop DBL and SNGL too. 
> Today you can find the bare 'foat/double' declarations in the source 
> code depending on who wrote what. This makes it unlikely we can really 
> ever change DBL to be anything but double, for example. Certainly not 
> without a lot of type conversions even if, by some chance, everything 
> works correctly.

Except, that is not why they are there: DBL is in the source code 
because there was a time when you could not depend on "double" actually 
doing what you wanted it to do. A time when certain CPUs had 80 bit 
floating point numbers, and other odd things with software emulated 
floating-point. In this world it was essentially that the floating-point 
representation could be changed. These days are long over, but the code 
just happens to be so old that it still has these leftovers.

Thorsten


Post a reply to this message

From: jr
Subject: Re: Ignorance rules!
Date: 26 Jun 2020 07:30:01
Message: <web.5ef5dbceea0d75ea4d00143e0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/24/20 8:12 PM, jr wrote:
> ...
> >> First, reminding everyone 'povr' is not POV-Ray. I'm combining my
> >> responses and when I start to think about major revisions to POV-Ray's
> >> SDL, I begin to think seriously about bindings to lua, tcl and python.
> >
> > so, it is late and I had too much coffee, probably..  :-)
> > how about replacing the SDL, wholesale?!
>
> Suppose the short answer is it's harder than it looks... And I agree
> with Bald Eagle about there never being enough coffee. When did I last
> drink water, straight... :-)

:-)

> ...
> It's not quite what you posted example wise, but I do sometimes wonder
> how far one might get creating a tcl intepreter supporting POV-Ray's
> commands as is. Meaning, aiming more for a parser replacement without
> trying to address existing shortcomings from the start.

thanks for giving me/us some insight in to your "personal" tools.

on parser replacement, I guess that's what I meant by a "safe" interpreter
pre-loaded with commands; the example was just off the top the head.  in fact,
had I thought ahead, I'd written:

set version 3.8
include colors.inc
array set global_settings {...}
light_source location {-1 1 -1 10e5} color white mods {parallel shadowless}

ie use 'dict' style lists as arguments, throughout.

anyway, personally, I look forward to more Tcl .. influence on development.

(re lists.  I think a distribution .inc file implementing an i/f similar to Tcl
lists would (could?) be sufficient/"good enough")


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Ignorance rules!
Date: 26 Jun 2020 08:47:54
Message: <5ef5ee7a$1@news.povray.org>
On 6/26/20 1:43 AM, Thorsten wrote:
> On 24.06.2020 19:53, William F Pokorny wrote:
>> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
>> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
>> years back which then never got adopted. PRECISE_FLOAT now needs to be 
>> yanked at some point from povr and I'd like to drop DBL and SNGL too. 
>> Today you can find the bare 'foat/double' declarations in the source 
>> code depending on who wrote what. This makes it unlikely we can really 
>> ever change DBL to be anything but double, for example. Certainly not 
>> without a lot of type conversions even if, by some chance, everything 
>> works correctly.
> 
> Except, that is not why they are there: DBL is in the source code 
> because there was a time when you could not depend on "double" actually 
> doing what you wanted it to do. A time when certain CPUs had 80 bit 
> floating point numbers, and other odd things with software emulated 
> floating-point. In this world it was essentially that the floating-point 
> representation could be changed. These days are long over, but the code 
> just happens to be so old that it still has these leftovers.
> 

Yes, thanks. A good point.

It's easy to forget while playing with code today that those who created 
POV-Ray were working in a much tougher, unstable environment. Plus we 
now have ready access to so much more information - Wikipedia, papers, 
on line code, etc.

Bill P.


Post a reply to this message

From: Thorsten
Subject: Re: Ignorance rules!
Date: 26 Jun 2020 13:05:16
Message: <5ef62acc$1@news.povray.org>
> Yes, thanks. A good point.
> 
> It's easy to forget while playing with code today that those who created 
> POV-Ray were working in a much tougher, unstable environment. Plus we 
> now have ready access to so much more information - Wikipedia, papers, 
> on line code, etc.

Ah, the same things existed back then. They were called books ;-)

Thorsten


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 8 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.