POV-Ray : Newsgroups : povray.general : Script language speed Server Time
7 Aug 2024 13:20:54 EDT (-0400)
  Script language speed (Message 31 to 40 of 42)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>
From: Redbeard
Subject: Re: Script language speed
Date: 8 Nov 2001 01:03:15
Message: <3bea2023@news.povray.org>
"Jon A. Cruz" <jon### [at] geocitiescom> wrote in message
news:3BE9710A.59F6A388@geocities.com...
>
... useful java references snipped
> or
> import org.xml.sax.Parser;
> import org.apache.xerces.parsers.SAXParser;
> ...
> Parser thing = new SAXParser();
>
> And here are the example docs I was just looking at:
> http://xml.apache.org/xerces-j/apiDocs/overview-summary.html
>
> Anyway, I find it more usefull than C++ namespaces where you have a single
> top-level collection of naming shared by the entire world. Among other things,
you
> start to see names decorated with package naming like:
>
> xmlSaxParser thing = new apacheXercesSAXParser();
>
> And don't get the option of short-cutting.
>
Actually, C++ namespaces are more useful than that.  Unfortunately, they are not
wide implemented (properly) yet.  It would be more like[1]:
    namespace apache_Xerces
    {
        class SAXParser ...
    }
    ...
    [other file]
    using apache_Xerces::SAXParser; // SAXParser can be used undecorated.
    using namespace apache_Xerces;  // Imports entire namespace.

I'll agree that Java's approach is probably better.  Namespaces were one of the
more debated issues in the C++ standardization process.  It's not the best, but
it's better than what existed before.

Michael

[1] It's been a while and I'm rusty, so don't take me for 100% correct.  Some of
the using directives may be incorrect.


--
camera{location<8,20>look_at<6,0,4>}light_source{<8,8>rgb 1}difference{union{
#macro M(D,J)#local R=asc(substr(D,J,1))-32;<div(R,10)*2,mod(R,10)>#end#macro
E(D,B,R)prism{-D,4+D,R#local C=1;#while(C<R+1)M(B,C)#local C=C+1;#end}#end E(
0," (2:FPKAD80* U_dZU"18)sphere{2,2}#macro T(N)cylinder{<9,-N,3><9,4+N,3>3-N}
#end T(0)}T(2)E(1"45LNXUK4"8)pigment{rgb x+y/2}}//(c)2001 MDJohnson(Redbeard)


Post a reply to this message

From: Warp
Subject: Re: Script language speed
Date: 8 Nov 2001 05:12:35
Message: <3bea5a92@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> wrote:
: Well, I think POV-ray stores the absolute position os macros ina file, so
: the macro would have to start at the exact location again.

  Does this mean that if I make a pov-file which writes another pov-file
containing a macro, then I include it (so POV-Ray reads the macro), then
I write the file again, but so that the macro changes place in the file,
and then call the macro, POV-Ray will issue some type of parse error?

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -


Post a reply to this message

From:
Subject: Re: Script language speed
Date: 8 Nov 2001 05:20:18
Message: <uvmkut4k634fe3aiu2ske1ku7e8c1n0ieo@4ax.com>
On 8 Nov 2001 05:12:35 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  Does this mean that if I make a pov-file which writes another pov-file
>containing a macro, then I include it (so POV-Ray reads the macro), then
>I write the file again, but so that the macro changes place in the file,
>and then call the macro, POV-Ray will issue some type of parse error?

Have you not readed thread
http://news.povray.org/0ok4utgnfkrc4tc0elpvt4a0ggn41cnkvk@4ax.com ?

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Script language speed
Date: 8 Nov 2001 05:43:00
Message: <3bea61b4$1@news.povray.org>
In article <3bea5a92@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Does this mean that if I make a pov-file which writes another pov-file
> containing a macro, then I include it (so POV-Ray reads the macro), then
> I write the file again, but so that the macro changes place in the file,
> and then call the macro, POV-Ray will issue some type of parse error?

I don't know what will happen!  I never tried it.  All I know is how POV-Ray
stores the macro position.  And you don't want it to parse the while file
again just to call a macro, do you?


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Rune
Subject: Re: Script language speed
Date: 8 Nov 2001 08:07:23
Message: <3bea838b@news.povray.org>
"Warp" wrote:
>   Does this mean that if I make a pov-file which
> writes another pov-file containing a macro, then
> I include it (so POV-Ray reads the macro), then
> I write the file again, but so that the macro
> changes place in the file, and then call the macro,
> POV-Ray will issue some type of parse error?

Correct, though the parse error is different dependent on the details and
sometimes you don't get an error at all. I suppose that's because it's a
situation not considered by POV-Ray, so it doesn't have a specific way to
handle it.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk


Post a reply to this message

From: Jon A  Cruz
Subject: Re: Script language speed
Date: 8 Nov 2001 11:17:12
Message: <3BEAAFC2.8E01E69E@geocities.com>
Redbeard wrote:

> "Jon A. Cruz" <jon### [at] geocitiescom> wrote in message
> news:3BE9710A.59F6A388@geocities.com...
>
> > Anyway, I find it more usefull than C++ namespaces where you have a single
> > top-level collection of naming shared by the entire world. Among other things,
> you
> > start to see names decorated with package naming like:
> >
> > xmlSaxParser thing = new apacheXercesSAXParser();
> >
> > And don't get the option of short-cutting.
> >
> Actually, C++ namespaces are more useful than that.  Unfortunately, they are not
> wide implemented (properly) yet.  It would be more like[1]:
>     namespace apache_Xerces
>     {
>         class SAXParser ...
>     }
>     ...
>     [other file]
>     using apache_Xerces::SAXParser; // SAXParser can be used undecorated.
>     using namespace apache_Xerces;  // Imports entire namespace.

Ahh, but what you see there is just a single name that lives in the top-level
namespace. (terms are just close, probably not precise to the actual ANSI spec).

You just put an underscore in the middle of that namespace. With Java, you could
have "org.apache", "org.apache.xerces", "org.apache.xml", each one being the
equivalent of nestled subdirectories. With C++ names, you'd have one top-level
directory with "apache", "apache_xerces" and "apache_xml" all living as
subdirectories in that main directory. In practice there's not so much difference,
but semanticly there is.

But I think the most important dinstinction is how those names are chosen. With
C++, each developer anywhere in the world picks what he hopes will be a short but
unique name for his work. Pick the same name for a namespace as someone else, and
you'll have trouble if you ever try to integrate with his code. But the Java trick
of standardizing on reversed domain names solves that problem quite nicely, and on
a world-wide basis.

--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html


Post a reply to this message

From: Redbeard
Subject: Re: Script language speed
Date: 8 Nov 2001 11:23:36
Message: <3beab188$1@news.povray.org>
"Jon A. Cruz" <jon### [at] geocitiescom> wrote in message
news:3BEAAFC2.8E01E69E@geocities.com...
> Ahh, but what you see there is just a single name that lives in the top-level
> namespace. (terms are just close, probably not precise to the actual ANSI
spec).
>
> You just put an underscore in the middle of that namespace. With Java, you
could
> have "org.apache", "org.apache.xerces", "org.apache.xml", each one being the
> equivalent of nestled subdirectories. With C++ names, you'd have one top-level
> directory with "apache", "apache_xerces" and "apache_xml" all living as
> subdirectories in that main directory. In practice there's not so much
difference,
> but semanticly there is.
>
> But I think the most important dinstinction is how those names are chosen.
With
> C++, each developer anywhere in the world picks what he hopes will be a short
but
> unique name for his work. Pick the same name for a namespace as someone else,
and
> you'll have trouble if you ever try to integrate with his code. But the Java
trick
> of standardizing on reversed domain names solves that problem quite nicely,
and on
> a world-wide basis.
>
As I said, I think Java has a better and more flexible way of doing it.  One
limitation of using the reversed domain name, though, is that not everyone has
one.

I namespaces (or packages, or whatever) should be considered for POV-Ray 4.0,
but I don't how best to implement.  There are other ways to do it beyond what
we've discussed here.

Michael

--
#macro M(D)#local J=strlen(D);#local _=""#while(J>0)#local _=concat(_,substr(D
,J,1))#local J=J-1;#end _#end sphere{z*9,5pigment{rgb x}}#macro N(D,J)text{ttf
"timrom.ttf"M(D)1,0 translate-J}#end#macro O(E,K)#local _=N(E,K)light_source{-
z*9rgb 1projected_through{_}}#end O("leahciM"<1.6,-.3.9>)O("nosnhoJ"<1.6.9.9>)


Post a reply to this message

From: Ben Chambers
Subject: Re: Script language speed
Date: 9 Nov 2001 03:05:14
Message: <3beb8e3a@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3be69fc4@news.povray.org...
>   Firstly, the main reason is that the POV-Ray scripting language is an
> _interpreted_ language. This makes comparison with _compiled_ languages
> (eg. C++) very unfair.

Hmm... I wonder if we could make a POV-Ray "compiler"?  As in, it would
parse your scene, and then create an executable which would render that
scene (and that scene only) at a resolution specified on the command line?
This would allow for various speedups and optimizations to be done, wouldn't
it? :)

Of course I realize it would be a nightmare to try and code, so maybe we'll
wait until pov4 comes out...

...Chambers


Post a reply to this message

From: Warp
Subject: Re: Script language speed
Date: 9 Nov 2001 03:57:38
Message: <3beb9a82@news.povray.org>
Ben Chambers <bdc### [at] hotmailcom> wrote:
: Hmm... I wonder if we could make a POV-Ray "compiler"?  As in, it would
: parse your scene, and then create an executable which would render that
: scene (and that scene only) at a resolution specified on the command line?
: This would allow for various speedups and optimizations to be done, wouldn't
: it? :)

  If you want to code a compiler for every possible platform and OS, be my
guest.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -


Post a reply to this message

From:
Subject: Re: Script language speed
Date: 9 Nov 2001 04:02:18
Message: <uo6nut04nkaq2bq781joijd5qbsqs7e064@4ax.com>
On 9 Nov 2001 03:57:38 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  If you want to code a compiler for every possible platform and OS, be my
> guest.

I wonder what size could have executable with all tracing loops unrolled ;-)

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35


Post a reply to this message

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

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