In my first-ever attempt at trying to decide on an object-oriented
programming language to learn (other than POV-Ray itself, that is!), I've
been looking at both Java and Python. In doing so, I'm beginning to see
similarities between the POV-ray scene description language and some of
Java (and perhaps some of Python as well, but I'm not sure yet!) POV
*seems* to use good parts of both...as well as improvements of it own...
but that's my rather uninformed opinion at this point.  I find the POV-ray
SDL easier and easier to work with, and would like to branch out into
learning one of the major, similarly-constructed languages. (Not C++ -- not
yet, anyway -- that's just too arcane for me right now. Big learning curve.)

My (really basic) question is this: Which OOP language is the POV-ray SDL
most similar to? (This question probably begs other questions, but it will
do for now.)

Ken W.

Post a reply to this message

Kenneth wrote:
> My (really basic) question is this: Which OOP language is the POV-ray SDL
> most similar to? (This question probably begs other questions, but it will
> do for now.)

None, because POV-Ray's current SDL is not an object-oriented language at
all. The syntax looks a lot like that of C/C++/Java of course, but that is
primarily due to the commenting style and the '{' and '}' everywhere.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Kenneth wrote:
> > My (really basic) question is this: Which OOP language is the POV-ray SDL
> > most similar to? (This question probably begs other questions, but it will
> > do for now.)
>
> None, because POV-Ray's current SDL is not an object-oriented language at
> all. The syntax looks a lot like that of C/C++/Java of course, but that is
> primarily due to the commenting style and the '{' and '}' everywhere.
>
>  Thorsten

Fascinating. Thanks. Looks like I need to do a bit more research on what an
OOP language really is.

Ken W.

Post a reply to this message

> Fascinating. Thanks. Looks like I need to do a bit more research on what an
> OOP language really is.

Indeed yes.

The only "object oriented" thing about the SDL is that you create 
"objects" with it - as in, things that you can see on the screen.

"Object oriented programming" is a way of programming where you build 
program objects. Each such object belongs to a particular class and this 
defines what data the object contains and which operations can be 
performed upon it.

http://en.wikipedia.org/wiki/Object-oriented_programming

It would probably *be* useful if POV-Ray's SDL *was* OOP - but that is a 
debate that has been had many times, essentially without a consensus 
arrising.

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> The only "object oriented" thing about the SDL is that you create 
> "objects" with it - as in, things that you can see on the screen.

  The "objects" in POV-Ray have nothing to do with object-oriented
programming. The similarity in the name is just coincidence and is
not indicative in any way.
  Of course you made a pun there, but I just wanted to make sure that
nobody gets confused.

  There are basically three requirements for an OOP language:

1) Modules.
2) Inheritance.
3) Dynamic binding.

  In some OOP languages 2 and 3 are replaced with a delegation mechanism,
but basically it's almost the same thing (ie. doesn't make too much of a
difference in object-oriented design).

  The POV-Ray SDL lacks all 3 of those. (Well, ok, #include files could be
seen as *very* primitive modules, but just barely.)

  Modula is an excellent example of a programming language which has
(very advanced) modules but which is not an OOP language. Its modules
have public and private sections and you can make instances of these
modules in the exact same way as you can make instances of Java or C++
classes. This module mechanism resembles so much the classes of Java and
C++ that most people would erroneously call it an OOP language even
though technically it isn't.

  Besides modules, an OOP language needs inheritance and dynamic binding
mechanisms. This means that modules can have an "is-a" relationship and
that you can handle more concrete instances (iow. lower in the inheritance
hierarchy) with generic code designed for more abstract instances (iow.
upper in the inheritance hierarchy), which means that the exact same
code can handle different objects if they have a common base class.
Dynamic binding means that the objects can specialize (ie. reimplement)
functions of the base class, and these functions will be called instead
of the base class functions even in code which only handles objects of
the base class type.

> It would probably *be* useful if POV-Ray's SDL *was* OOP - but that is a
> debate that has been had many times, essentially without a consensus
> arrising.

  I don't think there even has been any question which requires some
consensus. Some people just resist change and don't want the current
SDL to be modified (even if the new one resembles it). Also some people
have the strange misconception that "supports feature X" means the same
as "you must learn to use feature X or you can't do anything at all".

-- 
                                                          - Warp

Post a reply to this message

>> The only "object oriented" thing about the SDL is that you create 
>> "objects" with it - as in, things that you can see on the screen.
> 
>   The "objects" in POV-Ray have nothing to do with object-oriented
> programming. The similarity in the name is just coincidence and is
> not indicative in any way.

Indeed, a ray tracer's idea of an "object" and a programmer's idea of an 
"object" are completely unrelated. Both can be highly variable, so they 
are given the generic name "object".


As an aside, if the SDL ever becomes object-oriented, the whole subject 
will become a whole lot more confusing. ;-)

(I think if that ever happened, we would need to sit down and have a 
careful think about terminology to try and keep people un-confused.)

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> As an aside, if the SDL ever becomes object-oriented, the whole subject 
> will become a whole lot more confusing. ;-)

  Not really. C++ doesn't talk about "objects" anywhere in its syntax,
and neither has the SDL to do so (when referring to class instances).
Even the documentation could avoid the word "object" in relation to
class instances (and talk about "instances" instead).

-- 
                                                          - Warp

Post a reply to this message

What I'd be very interested in is if a future version of the POV SDL could
be parsed into some intermediate, platform-independent "bytecode"-like
format.

This would have benefits for parallel rendering, since a fast machine could
parse the scene, then distribute the pre-parsed scene info to other nodes.

Even better would be if the parsing could be done in parallel and the
results
recombined.. but I'm not holding my breath for that part :)

George
http://www.gammaburst.net

Post a reply to this message

George Pantazopoulos <go### [at] tomyaboutpage> wrote:
> This would have benefits for parallel rendering, since a fast machine could
> parse the scene, then distribute the pre-parsed scene info to other nodes.

  Parsing the SDL is actually often not the slowest part of the whole
parsing step. The vast majority of time usually goes into allocating
and setting up the objects and such.

  The exception is when the SDL has loops which loop a lot, in which
case a bytecode would speed up this interpretation. (For example, I once
compared the speed of an SDL code which just prints an ascii mandelbrot
set to stdout with a completely equivalent Perl code, and the latter was
approximately 13 times faster. This is because Perl compiles to bytecode
and then interprets that.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> George Pantazopoulos <go### [at] tomyaboutpage> wrote:
> > This would have benefits for parallel rendering, since a fast machine could
> > parse the scene, then distribute the pre-parsed scene info to other nodes.
>
>   Parsing the SDL is actually often not the slowest part of the whole
> parsing step. The vast majority of time usually goes into allocating
> and setting up the objects and such.
>
>   The exception is when the SDL has loops which loop a lot, in which
> case a bytecode would speed up this interpretation. (For example, I once
> compared the speed of an SDL code which just prints an ascii mandelbrot
> set to stdout with a completely equivalent Perl code, and the latter was
> approximately 13 times faster. This is because Perl compiles to bytecode
> and then interprets that.)
>
> --
>                                                           - Warp

Would it be possible to imagine such a thing: Develop Java POV-equivalent
classes and an adaptation layer though JNI that would parse Java code and
build the actual POV scene, and then render it by the actual POV engine
(adapted and activated by JNI)? Or am I off-track? It would be possible to
benefit all the power of the java syntax and modularity (and a debugger for
our macros).

Could one imagine something like this

import org.pov.*;
import org.pov.vegetation.*;
import org.pov.hormann.isowood.*;
import org.pov.tran.clouds.*;
import org.pov.someguru.WonderfulFeature4;
import org.pov.cabasson.PoorFeature1;

public class MyScene extends BasicOutDoorScene // Which extends POVScene,
and already has a light_source, a sun, and methods for the seasons and
Earth rotation ....
{
    public static main (int argc, String [] argv)
    {
        SetHandedness(LEFT_HANDEDNESS);

        GlobalSetting gs = new GlobalSettings();
        Radiosity rad = new RadiositySettings(); // Empty constructor with
defaults
        rad.setPretrace(0.04, 0.01);
        rad.setErrorbound(0.6);

        gs.setRadiosity(rad); // Or
gs.setRadiosity(Radiosity.OUT_DOOR_LOW_QUALITY)

        BuildScene();

        Render(640, 480);
    }

    private void BuildScene() // virtual method
    {
        final RADIUS = Double.parseDouble(argv[0]).doubleValue();

        Sphere s = new Sphere (0, RADIUS); // promotion is implemented by
method overloading: could be new Sphere (new Position(0,0,0), RADIUS) or so
....

        s.translate(10, 0, 0);
        s.rotate(-20, 0, 0);
        Pigment p = new Pigment(new Rgbt(1));
        Interior interior = new Interior();
        interior.setIor(Consts.GLASS_IOR);
        interior.setFadeColor(Colors.Blue);
        interior.setFadeDistance(s.getRadius()/2);
        s.setPigment(p);
        s.setInterior(interior);
        set.setPhotons(new ObjectPhotons(...));
        this.add(s);

        Plane ground = new Plane
        (
            y, 0,
            new Pigment
            (
                CHECKER,
                new ColorMap
                (
                    .../...
                ),
                new Turbulence(0.5, 2.0, 0.65, 8)
            )
        )
        ground.getPigment().setWarp(BLACK_HOLE, new Position(...));
        ground.getPigment().scale(2.0);
        this.add(ground);

        /// Etc ....

    }
}

If the java classes are well chosen, I think the java-equivalent syntax of a
scene could be as clear as sdl. Maybe more, when the scene would use lots of
complicated macros. Btw, JNI allows a DLL to call java code, then the sdl
function{} feature would execute at java speed (quite fast with HotSpot).

Then this scene would be rendered with a command line like:

java org.pov.MyScene 1.0

But I would not mind if you called me insane ... cos' I am  already  LOL

    Bruno

Post a reply to this message

>> As an aside, if the SDL ever becomes object-oriented, the whole subject 
>> will become a whole lot more confusing. ;-)
> 
>   Not really. C++ doesn't talk about "objects" anywhere in its syntax,
> and neither has the SDL to do so (when referring to class instances).
> Even the documentation could avoid the word "object" in relation to
> class instances (and talk about "instances" instead).

Yeah, that sounds like it would work. Just need to be careful to *stick* 
to that terminology and it should be fine...


BTW, I was thinking about just inventing my own new SDL language and 
writting a program that can convert it to standard POV-Ray SDL. But, 
unfortunately, this would of course involve writing a parse, so that 
project never really got anywhere...

Post a reply to this message

Orchid XP v3 wrote:
> BTW, I was thinking about just inventing my own new SDL language and 
> writting a program that can convert it to standard POV-Ray SDL.

http://sourceforge.net/projects/lome

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

>> BTW, I was thinking about just inventing my own new SDL language and 
>> writting a program that can convert it to standard POV-Ray SDL.
> 
> http://sourceforge.net/projects/lome

Mmm, looks *highly* active...

Post a reply to this message

Orchid XP v3 wrote:
>>> BTW, I was thinking about just inventing my own new SDL language and 
>>> writting a program that can convert it to standard POV-Ray SDL.
>>
>>
>> http://sourceforge.net/projects/lome
> 
> 
> Mmm, looks *highly* active...

No. I wrote it. I put it up. Use it if you please. Don't use it if you 
don't want to. But if you're looking for a new SDL language that 
includes converters to standard POV-Ray SDL, there it is. Source and 
everything.

And no, it won't *be* highly active before someone else wants a similar 
thing. So go ahead, and give me your improvements, instead of just 
complaining. ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

>>> http://sourceforge.net/projects/lome
>>
>> Mmm, looks *highly* active...
> 
> No. I wrote it. I put it up.

Really?

Interesting; I didn't know it was possible to do that...

> Use it if you please. Don't use it if you 
> don't want to. But if you're looking for a new SDL language that 
> includes converters to standard POV-Ray SDL, there it is. Source and 
> everything.
> 
> And no, it won't *be* highly active before someone else wants a similar 
> thing. So go ahead, and give me your improvements, instead of just 
> complaining. ;-)

OK, how about... some instructions? (Or am I just looking at the wrong 
page?)

Post a reply to this message

> OK, how about... some instructions? (Or am I just looking at the wrong
> page?)

Yes. You want to be looking at the page with the source code on it.

:->

-- 
"After all, one can't complain.  I have my friends. Somebody spoke to me
only  yesterday.  And was it  last week or  the week before  that Rabbit
bumped into  me and said  'Bother!'  The Social Round.  Always something
going on."  -- A. A. Milne, 'Winnie-the-Pooh'  http://surreal.istic.org/

Post a reply to this message

>> OK, how about... some instructions? (Or am I just looking at the wrong
>> page?)
> 
> Yes. You want to be looking at the page with the source code on it.
> 
> :->

o__O

Looks like I need to learn C# really fast... heh.

Post a reply to this message

Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> Could one imagine something like this

  Please don't take this in the wrong way, but your example gives me
cold shivers.
  No Java, please. Something more suitable for POV-Ray and less "javaish".

  Of course nothing stops you from creating a library for Java which can
be used to create POV-Ray scenes, but that's a different matter.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> BTW, I was thinking about just inventing my own new SDL language and 
> writting a program that can convert it to standard POV-Ray SDL. But, 
> unfortunately, this would of course involve writing a parse, so that 
> project never really got anywhere...

  A project like that would be more or less a waste of time.
  A new SDL language should be such that it can be interpreted even
at render time (in order to create, among other things, shaders).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> > Could one imagine something like this
>
>   Please don't take this in the wrong way, but your example gives me
> cold shivers.
>   No Java, please. Something more suitable for POV-Ray and less "javaish".
>
>   Of course nothing stops you from creating a library for Java which can
> be used to create POV-Ray scenes, but that's a different matter.
>
> --
>                                                           - Warp

Never mind! It was just a flash idea, and I wrote this in 5 min before I
left my office!

    Bruno

Post a reply to this message

Orchid XP v3 wrote:
>> No. I wrote it. I put it up.
> Really?

For real and for true!

> Interesting; I didn't know it was possible to do that...

Why wouldn't it be?

> OK, how about... some instructions? (Or am I just looking at the wrong 
> page?)

Download the package. There are pretty extensive documents describing 
how it works, as well as a sample set of macros and a sample 
several-floors-of-a-castle included.

Note that at the moment, it generates .BAT files to do the tracing 
(since there's apparently no programatic interface to POV's render 
queue). Changing that to output a shell script instead should be pretty 
trivial.

Feedback encouraged!


-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:

> "Object oriented programming" is a way of programming where you build
> program objects. Each such object belongs to a particular class and this
> defines what data the object contains and which operations can be
> performed upon it.
>
> http://en.wikipedia.org/wiki/Object-oriented_programming
>

Thanks for the link. I *think* I did take a look at it awhile ago, but
didn't quite understand it. I'll have another go.

Still trying to understand why POV-Ray isn't an OOP; all the comments so far
are quite interesting and helpful, though. Much to absorb and think about.
At some point, I know I'll have that A-HA! moment.

Ken

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>
>   The POV-Ray SDL lacks all 3 of those. (Well, ok, #include files could be
> seen as *very* primitive modules, but just barely.)
>

Yes, I think this is what gave me the (admittedly fuzzy) idea that POV was
comparable to Java or Python; that is, an OOP language.

I'd be interested in your comments on Java.  It *seems* to have some handy
features...like inherent "garbage collection," for instance, that make
programming with it supposedly much easier (than C++, that is.) Especially
easier for someone new to OOP languages, like myself. The POV SDL insulates
me from "all that stuff" too, which is quite nice! (Sorry if I'm showing my
ignorance of the subject; the SDL seems to, anyway.)

Ken

Post a reply to this message

>> BTW, I was thinking about just inventing my own new SDL language and 
>> writting a program that can convert it to standard POV-Ray SDL. But, 
>> unfortunately, this would of course involve writing a parse, so that 
>> project never really got anywhere...
> 
>   A project like that would be more or less a waste of time.

...so in other words, pretty much like *every* project I start? ;-)

>   A new SDL language should be such that it can be interpreted even
> at render time (in order to create, among other things, shaders).

Well at the moment everybody is focused on finishing the new beta. I'm 
not on the dev team, but I imagine they won't be finished any time soon, 
given the scope of the changes.

Also, as far as I'm aware, making a brand new SDL that breaks all 
existing scenes isn't high up on their priority list either.

Theoretically I could make a patch to the existing POV-Ray source code - 
except that since I can't read C that might be slightly difficult...

So my plan was to write a preprocessor. Obviously it's never going to 
add any new features to POV-ray, but it could make it easier to describe 
scenes algorithmicly.

Post a reply to this message

> The POV SDL insulates me from "all that stuff" too, which is quite
> nice! (Sorry if I'm showing my ignorance of the subject; the SDL seems
> to, anyway.)

Well, there's no need to handle GC, destructors, or finalizers in SDL
because objects in a scene are created once and then cannot be changed
or destroyed. So there isn't really anything to insulate you from.

-- 
In LaTeX, you \begin{document}.  In Soviet Russia, document \begin{you}!
http://surreal.istic.org/                      It's like a DEATH CIRCUS!

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> I'd be interested in your comments on Java.  It *seems* to have some handy
> features...like inherent "garbage collection," for instance, that make
> programming with it supposedly much easier (than C++, that is.)

  The POV-Ray SDL doesn't have an explicit "garbage collection" engine
because there is no 'new', no references nor nothing, yet it manages
quite well. In fact, most scripting and programming languages do not
have the kind of "GC" that Java has and they do just fine. GC (as in Java)
is in no way a requirement for safe code.

  You mention GC as if it was some kind of requirement for safe OOP
languages. There's no such connection. It's only necessary for languages
where objects are allocated dynamically and don't go out of scope by
themselves. I'm not even sure *why* Java has such objects. It could
perfectly work without them (just remove 'new' and use internally
some kind of reference-counting copy-on-write system).

-- 
                                                          - Warp

Post a reply to this message

>   You mention GC as if it was some kind of requirement for safe OOP
> languages. There's no such connection. It's only necessary for languages
> where objects are allocated dynamically and don't go out of scope by
> themselves. I'm not even sure *why* Java has such objects.

And I'm not sure how you would do a whole bunch of simple things 
*without* such objects.

> It could
> perfectly work without them (just remove 'new' and use internally
> some kind of reference-counting copy-on-write system).

I have no idea why after all these years people still think reference 
counting is a good idea. It's so trivial to find an example where it 
utterly fails...

Post a reply to this message

>> The POV SDL insulates me from "all that stuff" too, which is quite
>> nice! (Sorry if I'm showing my ignorance of the subject; the SDL seems
>> to, anyway.)
> 
> Well, there's no need to handle GC, destructors, or finalizers in SDL
> because objects in a scene are created once and then cannot be changed
> or destroyed. So there isn't really anything to insulate you from.

Not 100% true. There are situations where you can overwrite stuff 
(mainly to do with variables), but they are all easy to handle. There's 
no need for a whole GC engine just for that.

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> And I'm not sure how you would do a whole bunch of simple things 
> *without* such objects.

  Exactly like hundreds of programming languages do.

> I have no idea why after all these years people still think reference 
> counting is a good idea. It's so trivial to find an example where it 
> utterly fails...

  Care to give this trivial example?

-- 
                                                          - Warp

Post a reply to this message

> > I have no idea why after all these years people still think
> > reference counting is a good idea. It's so trivial to find an
> > example where it utterly fails...
> 
>   Care to give this trivial example?

See the entry 'Moon instructs a student' in:

http://www.catb.org/jargon/html/koans.html


To answer Andy's question, though:

I have no idea why after all these years people still think quicksort is
a good idea. It's so trivial to find an example where it takes O(n^2)
time.

-- 
In LaTeX, you \begin{document}.  In Soviet Russia, document \begin{you}!
http://surreal.istic.org/      Carry me home, my teacher, carry me home.

Post a reply to this message

>> And I'm not sure how you would do a whole bunch of simple things 
>> *without* such objects.
> 
>   Exactly like hundreds of programming languages do.

OK, well how would you build (say) a linked list structure if the new 
node goes out of scope as soon as you get to the end of the function 
that creates it and adds it to the list?

>> I have no idea why after all these years people still think reference 
>> counting is a good idea. It's so trivial to find an example where it 
>> utterly fails...
> 
>   Care to give this trivial example?

OK, how about a double-linked list?

Every node (except the end ones) always has 2 other nodes pointing to 
it. Hence the reference count will never reach zero. QED.

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> OK, well how would you build (say) a linked list structure if the new 
> node goes out of scope as soon as you get to the end of the function 
> that creates it and adds it to the list?

  It goes out of scope, but it has two references pointing to it
(one in the function and another in the list data structure). When
it goes out of scope in the function that simply decreases the
reference count by one.

> OK, how about a double-linked list?

> Every node (except the end ones) always has 2 other nodes pointing to 
> it. Hence the reference count will never reach zero. QED.

  The nodes at the ends of the list have only one.

-- 
                                                          - Warp

Post a reply to this message

Daniel Hulme <pho### [at] isticorg> wrote:
> I have no idea why after all these years people still think quicksort is
> a good idea. It's so trivial to find an example where it takes O(n^2)
> time.

  It's certainly not very trivial to find such an example of the choice
of pivot in the paritioning is smart. Simply making a median-of-3 pivot
choice makes finding such an example non-trivial. Moreover, if the
middle item of the median choice is taken with some randomization to it,
good luck finding a patological example.

  Moreover, quicksort is handy because it can easily be enhanced to
sort small partitions with insertion sort, making it noticeably faster.
(Heapsort, for instance, cannot be enhanced like this. Mergesort can be,
but the problem with mergesort is its additional memory requirements,
at least when sorting arrays.)

  Oh, but of course there's the array where every value is the same.
It's rather trivial to stop partitioning when no swaps were made.

  Sure, it's still possible for a pathological case to happen, but
finding one is not trivial.

-- 
                                                          - Warp

Post a reply to this message

> Daniel Hulme <pho### [at] isticorg> wrote:
> > I have no idea why after all these years people still think
> > quicksort is a good idea. It's so trivial to find an example where
> > it takes O(n^2) time.
> 
>   It's certainly not very trivial to find such an example of the
> choice of pivot in the paritioning is smart.

Thank you for illustrating my point :->

-- 
"Oh, Eeyore, you are wet!" said Piglet, feeling him.
Eeyore shook himself,  and asked somebody to explain to Piglet what hap-
pened when you had been inside a river for a long time.
    A. A. Milne, 'The House at Pooh Corner'    http://surreal.istic.org/

Post a reply to this message

Daniel Hulme <pho### [at] isticorg> wrote:
> > Daniel Hulme <pho### [at] isticorg> wrote:
> > > I have no idea why after all these years people still think
> > > quicksort is a good idea. It's so trivial to find an example where
> > > it takes O(n^2) time.
> > 
> >   It's certainly not very trivial to find such an example of the
> > choice of pivot in the paritioning is smart.

> Thank you for illustrating my point :->

  Your point? You said it's trivial to find such an example, and I said
it isn't. How does that illustrate your point? Unless you were being
sarcastic or something.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>>Every node (except the end ones) always has 2 other nodes pointing to 
>>it. Hence the reference count will never reach zero. QED.

>   The nodes at the ends of the list have only one.

Not necessarily. They're pointed to by the object that represents the 
list as a whole. What pointer would you drop to make the list 
garbage-collect with a reference-count GC?

If you have a "file" that points to its buffer, and its buffer points to 
its file, you have a loop. If you have a declaration object that points 
to the definition object and the definition object points to the 
declaration object, you have a loop. If the window instance points to 
the screen instance and the screen instance points to the window 
instance, you have a loop. If the treenode points to its children and 
the children point back up to the parent, you have a loop.

Plus, reference counting has very bad performance as well as being 
non-real-time and uninterruptable.

None of which has much to do with POV-Ray as such. ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

>>>> I have no idea why after all these years people still think
>>>> quicksort is a good idea. It's so trivial to find an example where
>>>> it takes O(n^2) time.
>>>   It's certainly not very trivial to find such an example of the
>>> choice of pivot in the paritioning is smart.
> 
>> Thank you for illustrating my point :->
> 
>   Your point? You said it's trivial to find such an example, and I said
> it isn't. How does that illustrate your point? Unless you were being
> sarcastic or something.

I think he's hinting that finding the right pivot is the "hard" part of 
the algorithm, and if you get that wrong you get poor performance...

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> I think he's hinting that finding the right pivot is the "hard" part of 
> the algorithm, and if you get that wrong you get poor performance...

  But that doesn't make quicksort a bad sorting algorithm.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Not necessarily. They're pointed to by the object that represents the 
> list as a whole. What pointer would you drop to make the list 
> garbage-collect with a reference-count GC?

  How do languages where there no concept of "new" (as in Java or C++)
nor a Java-style GC of dynamically allocated objects do it?

> Plus, reference counting has very bad performance as well as being 
> non-real-time and uninterruptable.

  Very bad performance? I think that incrementing/decrementing a counter
each time an object is copied doesn't increase too much of its slowness.
(Naturally in situations where you have to locally copy things a lot
you would not use dynamically allocated copies anyways, assuming the
language supports local instances.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

> Darren New <dne### [at] sanrrcom> wrote:
> 
>>Not necessarily. They're pointed to by the object that represents the 
>>list as a whole. What pointer would you drop to make the list 
>>garbage-collect with a reference-count GC?
> 
> 
>   How do languages where there no concept of "new" (as in Java or C++)
> nor a Java-style GC of dynamically allocated objects do it?

They don't dynamically allocate and deallocate memory, I guess. I'm not 
sure what your questions means. What I'm saying is that having circular 
links between objects is not at all uncommon in languages that allow 
such. It's the natural way to represent many semi-independent entities 
(like screens/windows, frames/scrollbars, RPG objects/rooms, tree nodes, 
etc.).

Obviously, if you don't have dynamically-allocated objects, then you 
don't have to worry about circular references with reference-counting 
garbage collection. If you have dynamically-allocated objects *and* no 
GC, then obviously it's up to the programmer to free things without 
assistance, and programmed reference counting won't fix that.

>>Plus, reference counting has very bad performance as well as being 
>>non-real-time and uninterruptable.
> 
> 
>   Very bad performance? I think that incrementing/decrementing a counter
> each time an object is copied doesn't increase too much of its slowness.

Not true. You have to also account for the object's reference count 
overflowing, for example. Plus, you actually have to *free* the objects 
when the counter goes to zero. Generational GC doesn't have to do 
anything with objects that have been freed (which admittedly makes 
finalizers messy, but they are messy to handle "correctly" in any 
language and model). You can allocate 100,000 individual objects and 
free them all with one instruction. There's a reason why nobody uses 
reference-counted garbage collection for real any more.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

Darren New wrote:
> Not true. You have to also account for the object's reference count
> overflowing, for example.

Sorry, can't help responding to this: If your reference counter variable
size is the same as your native pointer size, it can *never* overflow.

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> Darren New wrote:
> 
>>Not true. You have to also account for the object's reference count
>>overflowing, for example.
> 
> Sorry, can't help responding to this: If your reference counter variable
> size is the same as your native pointer size, it can *never* overflow.

Yes, but that's very inefficient, especially if you have objects that 
are persisted elsewhere (e.g., if you have objects distributed across 
many computers, or stored in named files, or in an OO database). Most 
reference-counted systems allocate between five and eight bits for 
reference counts. Incidentally, that's another reason reference counting 
isn't used much - the size penalty. And you still have to be able to do 
mark-and-sweep to account for circular references anyway.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> You have to also account for the object's reference count 
> overflowing, for example.

  It's impossible for a reference counter to overflow. You can't allocate
that much memory. You can't have pointers pointing to that many objects
in the first place.

  If you had to manage more data than the pointer size of the architecture
can point to, then everything handling the data will be bigger&slower
anyways. A reference counter won't matter much.

> You can allocate 100,000 individual objects and 
> free them all with one instruction.

  Assuming no memory fragmentation, of course.

  Besides, a reference-counting system doesn't have to *free* the
objects immediately when the last reference dies. It can mark the
object as "to be freed" and put it somewhere to wait.

  Btw, how does the GC engine know that the object is not used anymore?

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > Sorry, can't help responding to this: If your reference counter variable
> > size is the same as your native pointer size, it can *never* overflow.

> Yes, but that's very inefficient, especially if you have objects that 
> are persisted elsewhere (e.g., if you have objects distributed across 
> many computers, or stored in named files, or in an OO database).

  Oh, of course handling more data than the natural pointer size of the
system is very efficient. It's just the reference counter which is
inefficient because it has to be able to count more than the natural
word size. Everything else is efficient even though everything else
also needs to handle values larger than the natural word size. Yes,
makes sense. Or then not.

  Besides, not everything *has* to be reference-counted.

> Most 
> reference-counted systems allocate between five and eight bits for 
> reference counts.

  Doesn't sound like a very smart thing to do. Sounds like over-optimization.

> Incidentally, that's another reason reference counting 
> isn't used much - the size penalty.

  And incidentally many (most? all?) garbage-collected languages will force
every single class to be allocated dynamically (which will add at the
very least the type or size of the object to be stored alongside it
so that it can be properly freed), which in turn forces every object
to be handled through at least one reference (which will add the size
of a pointer to the total memory consumption of the object), plus they
also usually automatically make every object dynamically bound (which
will add at least the size of some kind of pointer to the total memory
consumption of the object).
  Even by a rather conservative estimate we could estimate that each
object requires at least 12 bytes of overhead in such a language. But
of course that is nothing to worry about. The size of a reference count
on the other hand is something to be very worried about.

-- 
                                                          - Warp

Post a reply to this message

> Orchid XP v3 <voi### [at] devnull> wrote:
> > I think he's hinting that finding the right pivot is the "hard" part
> > of the algorithm, and if you get that wrong you get poor
> > performance...
> 
> But that doesn't make quicksort a bad sorting algorithm.

Exactly. So, the lesson we learn from this is the following: An
algorithm or system for which you have to work hard to avoid
pathological cases can still be useful.

Now, if we remember the above, and apply it to Andy's statement:

> I have no idea why after all these years people still think reference 
> counting is a good idea. It's so trivial to find an example where it 
> utterly fails...

then it is easy to see why after all these years people still think
reference counting is a good idea.

I thought my original reply was both concise and clear, but maybe I was
the only one to think that.

It is often said in teaching that if you tell someone something he'll
forget it almost immediately, but if you make him work it out for
himself he will remember for longer.

-- 
"Listen to your users, but ignore what they say." - Nathaniel Borenstein
http://surreal.istic.org/          Calm down, it's only ones and zeroes.

Post a reply to this message

Warp wrote:
>   Oh, of course handling more data than the natural pointer size of the
> system is very efficient. It's just the reference counter which is
> inefficient because it has to be able to count more than the natural
> word size. Everything else is efficient even though everything else
> also needs to handle values larger than the natural word size. Yes,
> makes sense. Or then not.

Thank you for that lovely strawman.

>   Besides, not everything *has* to be reference-counted.

Um, yes?  So?   You're correct: Where something isn't reference-counted, 
the size of the reference counter adds no overhead.

>>Most 
>>reference-counted systems allocate between five and eight bits for 
>>reference counts.

>   Doesn't sound like a very smart thing to do. Sounds like over-optimization.

When you're trying to put 20,000 objects into 64K of ram, yes, it's 
actually quite a smart thing to do.

>>Incidentally, that's another reason reference counting 
>>isn't used much - the size penalty.
> 
>   And incidentally many (most? all?) garbage-collected languages will force
> every single class to be allocated dynamically

Only semantically.

> (which will add at the
> very least the type or size of the object to be stored alongside it
> so that it can be properly freed)

Only if the semantics of the language aren't already requiring that 
information.

>, which in turn forces every object
> to be handled through at least one reference (which will add the size
> of a pointer to the total memory consumption of the object)

That would be incorrect.

>, plus they
> also usually automatically make every object dynamically bound (which
> will add at least the size of some kind of pointer to the total memory
> consumption of the object).

That would also be incorrect.

>   Even by a rather conservative estimate we could estimate that each
> object requires at least 12 bytes of overhead in such a language.

Your ignorance of modern technology in this field is showing.

> of course that is nothing to worry about. The size of a reference count
> on the other hand is something to be very worried about.

I didn't say they weren't something to be worried about. I said that 
it's *a* thing to be worried about.

Reference counting doesn't solve the problem of knowing when to collect 
the garbage. It's inefficient in both time and space, it causes 
unpredictable performance by requiring large amounts of time to free 
arbitrarily large structures all at once due to cascading reference 
counts going to zero, and virtually nobody who knows anything about 
garbage collection uses it anymore.

That you could design a system that's even *more* inefficient than 
reference counting by not having followed the research over the last 20 
years or so of how to do things right should surprise nobody.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

Warp wrote:
>   It's impossible for a reference counter to overflow.

Unless your reference counter is smaller than the size of a pointer. 
Yes, you can build a reference counting system that doesn't overflow, by 
allocating a huge amount of space to a counter that is usually less than 
4 bits. But since you *still* need some other sort of garbage collection 
anyway, why would you waste that much space?

>>You can allocate 100,000 individual objects and 
>>free them all with one instruction.
> 
>   Assuming no memory fragmentation, of course.

How do you think allocation in a garbage collected system works? Of 
*course* there's no fragmentation.

>   Besides, a reference-counting system doesn't have to *free* the
> objects immediately when the last reference dies. It can mark the
> object as "to be freed" and put it somewhere to wait.

Um, why would it have to "put it somewhere"? The problem isn't "freeing 
the object". The problem is running through all the pointers in the 
object whose reference went to zero and marking those as freed also.

Once you do what you describe, then you've lost the simplicity of 
reference counting, and now you're doing some other sort of garbage 
collection. (Which sort depends on how/when you free the objects.)

And you still haven't solved the major problem, which is that reference 
counting DOES NOT WORK.  Reference counting, even with sufficiently 
large counters, does not free all the garbage, even if you do it 
inefficiently.

>   Btw, how does the GC engine know that the object is not used anymore?

There are a number of ways, from simplistic to convoluted. Generally, GC 
engines assume they can find the live pointers.

If you're actually interested in the topic, there are good references 
freely available. If you're just interested in arguing, I'm not.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

Darren New wrote:
> Most reference-counted systems allocate between five and eight bits for
> reference counts.

Care to provide some credible links/evidence for this claim? It is new to
me, and probably 99% of those using reference counting...

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Care to provide some credible links/evidence for this claim?

Smalltalk-80: The Language and Implementation. Or look into any LISP 
implementation.

As for a newer reference? Not too many around, as people don't use 
reference counting seriously, because it's so flawed. Providing newer 
references would be like providing references for bad cache coherency 
performance of bubble sorts.

 > It is new to
> me, and probably 99% of those using reference counting...

There's a difference between "a reference-counted garbage-collection 
system" and "a program using reference counting."  Certainly, if you 
implement it yourself and you have full control over every way you're 
going to use it and you don't allocate enough objects that the added 
overhead is worth avoiding, then you can use a big counter. People who 
build systems that include GC for others to use generally don't get that 
luxury. Indeed, people that build systems that include GC generally 
don't use reference counting at all, as it (along with mark/sweep) is 
pretty much the most primitive lamest inefficient version of GC 
possible. But sure, if you're limited by what you can implement in C or 
C++ at the application level, it's not too bad, as long as you remember 
to manually break cycles everywhere and you're not trying to make it fast.

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

>   And incidentally many (most? all?) garbage-collected languages will force
> every single class to be allocated dynamically (which will add at the
> very least the type or size of the object to be stored alongside it
> so that it can be properly freed), which in turn forces every object
> to be handled through at least one reference (which will add the size
> of a pointer to the total memory consumption of the object), plus they
> also usually automatically make every object dynamically bound (which
> will add at least the size of some kind of pointer to the total memory
> consumption of the object).

Eiffel is a GC language.

Eiffel allows you to select whether instances of a particular class 
should be allocated statically or dynamically.

The Eiffel compiler analyzes all the classes in the program and 
automatically decides exactly which methods need late binding, and which 
ones do not. (It also does dead code elimination; any methods not 
actually called from anywhere get totally removed.)

Post a reply to this message