Invisible <voi### [at] devnull> wrote:
[tldr]

> and this is valid. Notice, however, that it is impossible to write an
> "unwrap" function. Because once you "wrap" something, its original type
> information is lost forever, so there's no way in hell to know what type
> to cast it back to.

what about in heaven?  In Lisp there's no such hellish troubles. :)

> Now a "shape" is simply an ordinary data structure, which contains some
> function pointers. And each sort of shape - a sphere, a cone, whatever -
> is an ordinary /function/ which fills out this data structure with the
> right function pointers. In particular, every type of shape now has the
> same type signature. There is no Sphere type, no Plane type, no Cone
> type, there is only a Shape type. So now we can write
>
>    [sphere 0 1, plane 1 0]
>
> and have it be well-typed. (It's [Shape].)

So your solution to get away from the complaints of the compiler is to have all
types be the same single type?  Yes, sounds like the Lisp solution too. ;)

> The short summary is that Haskell, the finest
> functional programming language in the land, is superior to Java, one of
> the more sucky OOP languages. Not exactly a revelation, is it? I think
> I'm going to go outside for a while...

you do good. :)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> > You can certainly do things this way. There is a snag, however. If you
> > stick to Haskell 2010 (the currently published official language
> > specification), you cannot easily make a list of shapes. Because all the
> > elements of a list have to be of identical types. And (for example)
> > Sphere is not the same type as Plane, even if they do both implement the
> > Shape class (and possibly other classes like Eq or Show). There is no
> > way to say "a list of everything that has these methods".

> Heh. So standard Haskell obviously sucks as much as Java without generics.

Why exactly would you need generics in order to make a list of different
shapes? (Being able to do such a thing is kind of the very definition of
object-oriented programming.)

-- 
                                                          - Warp

Post a reply to this message

>> Heh. So standard Haskell obviously sucks as much as Java without generics.
>
> Why exactly would you need generics in order to make a list of different
> shapes? (Being able to do such a thing is kind of the very definition of
> object-oriented programming.)

No, I think he means that I said Java sucks because of X, so he's saying 
Haskell sucks because of Y. There isn't any particular relationship 
between these things...

[At least, I /think/ that's what he meant...]

Post a reply to this message

On 28/06/2012 11:28 PM, nemesis wrote:
> [tldr]

That's the story of my life.

>> Notice, however, that it is impossible to write an
>> "unwrap" function. Because once you "wrap" something, its original type
>> information is lost forever, so there's no way in hell to know what type
>> to cast it back to.
>
> what about in heaven?  In Lisp there's no such hellish troubles. :)

No. In Lisp, there are no types at all. :-P

> So your solution to get away from the complaints of the compiler is to have all
> types be the same single type?  Yes, sounds like the Lisp solution too. ;)

Not all types, just all /shape/ types. There's the difference. In Lisp, 
you can put any value anywhere. Haskell (and Java) allow you to require 
that all the elements of the list have specific properties.

>> Not exactly a revelation, is it? I think
>> I'm going to go outside for a while...
>
> you do good. :)

Hmm.

Post a reply to this message

>>>> You already do it for AllIsect(). There's no additional work necessary.
>>>
>>> In Java, calling AllIsect() causes all intersections to be computed. In
>>> Haskell, calling the isect function does /not/ necessarily cause all
>>> intersections to be computed. Only the ones you actually "look at".
>>> That's the point I'm making.
>>
>> As Clipka pointed out, you need to calculate all intersections anyway to
>> find the nearest one.
>
> And as I pointed out, this is not the case for many objects. E.g., a
> sphere has two points of intersection. These are the solutions to a
> quadratic equation. And we all know that the way to solve that is
>
> x = -b +/- Sqrt(b^2 - 4ac) / 2a
>
> To find the "nearest" intersection, you merely pick the "-" rather than
> the "+". Done.

Assuming your sphere is to the "right" of your ray starting point.

>>
>> I was just pulling your leg. You can call your variables Fred, Pebbles
>> and Bambam if you want to. Just don't go about making readability
>> claims, if you do, though. :)
>
> Is it wrong that I actually know who those people are? o_O
>

No.  It's not like the Flintstones is an obscure reference.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>>> As Clipka pointed out, you need to calculate all intersections anyway to
>>> find the nearest one.
>>
>> And as I pointed out, this is not the case for many objects. E.g., a
>> sphere has two points of intersection. These are the solutions to a
>> quadratic equation. And we all know that the way to solve that is
>>
>> x = -b +/- Sqrt(b^2 - 4ac) / 2a
>>
>> To find the "nearest" intersection, you merely pick the "-" rather than
>> the "+". Done.
>
> Assuming your sphere is to the "right" of your ray starting point.

No assumption.

The result of this equation is the distance along the ray that you need 
to travel to get to the intersection. Therefore, the lowest solution is 
guaranteed to be the one you want. (Unless the camera is /inside/ the 
sphere, which won't work for several other reasons besides this one.)

Post a reply to this message

>> Assuming your sphere is to the "right" of your ray starting point.
>
> No assumption.
>
> The result of this equation is the distance along the ray that you need
> to travel to get to the intersection. Therefore, the lowest solution is
> guaranteed to be the one you want. (Unless the camera is /inside/ the
> sphere, which won't work for several other reasons besides this one.)

No assumption, except for this one, that one, and these other ones, too...

:P

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 03/07/2012 02:35 PM, Francois Labreque wrote:

>>> Assuming your sphere is to the "right" of your ray starting point.
>>
>> No assumption.
>>
>> The result of this equation is the distance along the ray that you need
>> to travel to get to the intersection. Therefore, the lowest solution is
>> guaranteed to be the one you want. (Unless the camera is /inside/ the
>> sphere, which won't work for several other reasons besides this one.)
>
> No assumption, except for this one, that one, and these other ones, too...
>
> :P

No assumption, assuming the camera isn't inside a solid object.

If the camera /is/ inside a solid object, you need to adjust several 
things beyond just the ray intersection tests.

Post a reply to this message

> On 03/07/2012 02:35 PM, Francois Labreque wrote:

>>>> Assuming your sphere is to the "right" of your ray starting point.
>>>
>>> No assumption.
>>>
>>> The result of this equation is the distance along the ray that you need
>>> to travel to get to the intersection. Therefore, the lowest solution is
>>> guaranteed to be the one you want. (Unless the camera is /inside/ the
>>> sphere, which won't work for several other reasons besides this one.)
>>
>> No assumption, except for this one, that one, and these other ones,
>> too...
>>
>> :P
>
> No assumption, assuming the camera isn't inside a solid object.

Huh...

Ok, and even though you're building this just for your own amusement, is 
this limitation of the software fully documented?  Will you remember it 
when you get to version 13 and you decide to add CSG support or POV SDL 
parsing?  What if you mess up a rotation or translation and your camera 
inadvertantly ends up inside an object?

Call me paranoid, but I'd prefer to expect the unexpected and program 
for it right away, instead of simply assuming it won't ever happen.  At 
the very least, you should test for it and bail out gracefully rather 
than invoke undefined behaviour.

>
> If the camera /is/ inside a solid object, you need to adjust several
> things beyond just the ray intersection tests.

Agreed.  But that does not negate our original point that in order to 
find the nearest intersection, you need to find them all.
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

> Call me paranoid, but I'd prefer to expect the unexpected and program
> for it right away, instead of simply assuming it won't ever happen. At
> the very least, you should test for it and bail out gracefully rather
> than invoke undefined behaviour.

Sure. Who says I didn't write a test for that?

>> If the camera /is/ inside a solid object, you need to adjust several
>> things beyond just the ray intersection tests.
>
> Agreed. But that does not negate our original point that in order to
> find the nearest intersection, you need to find them all.

No, you just need to detect when the camera is inside a solid object and 
emit an error message rather than rendering the scene.

(If you /want/ the camera there, you sound turn the object in question 
inside-out, which takes care of /all/ of the necessary adjustments so 
the scene will render correctly. In that case, no error message.)

Post a reply to this message