You are of course right, but knowing that Mr. Tyler is using a Wintel
machine, I was just talking to him specifically, though I should have
said that in the email...Sorry for being Wintel myopic.

Steve


"John M. Dlugosz" wrote:
> 
> Stephen Lavedas wrote in message <36C### [at] virginiaedu>...
> > of course you realize that there are no
> >appreciable HD savings in this version since the minimum sector size is
> >4k and so any file less than 4K in size takes up 4K anyhow...
> 
> Maybe on =your= disk.
> 
> In NTFS, the MFT record which stores the demographics of the file can store
> the contents too, if it is short.  So there is =no= space allocated for the
> file besides the MFT record which holds the name(s), size, permissions,
> dates, etc.  On some UNIX file systems, data of a few hundred bytes can be
> stuffed in the iNode, which is the same principle.
> 
> So on NTFS, all files take exactly 1K for the MFT (master file table)
> record, plus consume a couple bytes in an index (how the directories are
> kept).  If the content is a few hundred bytes, it will go in the MFT too and
> the file only takes 1K.
> 
> After that, it allocates clusters, where the cluster size is fully
> configurable at format time.  I use fairly small clusters to prevent just
> this kind of waste.  Microsoft's documentation claims, in all its wisdom,
> that a smaller cluster size will increase fragmentation.  But on a fast SCSI
> drive it's never been a problem, and I can always defragment if needed.
> Anyway, a data drive could easily have clusters of 1K or 2K, not the
> wasteful 4K.  One could even use half a K per cluster.
> 
> --John

Post a reply to this message

Stephen Lavedas <swl### [at] virginiaedu> wrote:
: Take a look at my indented version.

  It could be better. Your indentation style has some lack of logic.
  The general rule is: every block is indented.

: #declare HalfDome_1 = 
: union {

  Here the entire union is a block so it should be indented with respect
to the #declare, ie:

#declare HalfDome_1 =
  union {
    ...
  }

: #declare aa = 0;

  The block inside the union is also a block, so it should be indented:

#declare HalfDome_1 =
  union {
    #declare aa = 0;
    ...
  }

:    #while  (aa < 90)

  This #while is not an independent block with respect to the #declare, so
it can't be indented. It's part of the same block.

#declare HalfDome_1 =
  union {
    #declare aa = 0;
    #while (aa < 90)
      ...
    #end
    ...
  }

:       #declare bb = 0;
:       #while  (bb < 45)

  Here you made it right. So sometimes you indent in one way and sometimes
in the other. There's no logic there.

:          box{
:               ...
:             }       

  A block closing parenthesis should be indented at the same depth as the
block itself, ie:

    box {
      ...
    }

  Another style of placing the opening parenthesis is:

    box
    { ...
      ...
    }

(I like this one more)

  So my version would be:

#declare HalfDome_1=
  union
  { #declare aa=0;
    #while(aa<90)
      #declare bb=0;
      #while(bb<45)
        box
        { -.5,.5
          scale<.05,1.5,1.5> translate z*-40 rotate z*-2*bb
          scale<1,1,1.6+pi/90*-bb> rotate y*2*aa translate y*.75
        }
        #declare bb=bb+1;
      #end
      #declare aa=aa+1;
    #end
  }

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/

Post a reply to this message

I would probably be able to help you with the maths but I didn't completely
understand the problem. Can you explain more detailedly what do you want to
calculate?

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:
> 
>   I would probably be able to help you with the maths but I didn't completely
> understand the problem. Can you explain more detailedly what do you want to
> calculate?
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/



As cleary as I might. The code I presented forms a quarter sphere shape
from flattend almost 2D boxes. After a little work I managed to come up with
a method that solves the problem you get when you rotate two different curves
into each other. A problem that is illustrated by the construction of a beach
ball. The sections are narrower on the ends an fat in the center. If they
were of equal width they would bunch up at the poles of the globe.

  Any way the code takes one box, rotates it from n*-x, y*0 to x*0, n*y
stopping at 90 degrees. As each box is placed by the first while loop action
there is a scaling function being performed the reduces the size of each
subsequent box until the loop times out. So now I have a curved wedge
shaped construct much like the shape of a beach ball section. This small
sliver is now rotated 180 degrees to form the quarter sphere. Finished done.

  For all of this to happen I had to calculate all of the values for each action
that took place to form this object. I would like to restructure the scene file so
that all I or another user has to do is input the size of box he/she wishes to use
and the radius of the sphere shape that needs to be created. The rest of equations
will be handled by the script from this point on.

  Therefore the question is:

  Can the file be converted to take 3 - scale values for the single box object
and one coordinate value, which by the way is also the radius value, then finish
the calcualtions and construction of the object by itself ?

 I believe it is rather straight foreward and should pose no real challenge.
I just lack the personal memory of the processes learned 25 years ago and don't
have the printed resources here to look up the equations I need to plug in to
the right places.

So that's where it stands.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Stephen Lavedas wrote:
> 
> Okay Ken... you have a couple of magic numbers in here (a magic number
> is a number that is just there for some reason and no logical
> explaination is known except by the author)  The most important one is
> 1.6*pi/90-bb where did you get this figure?  I am trying to figure it
> out, and my guess is that you just kept tweaking it until there weren't
> any gaps...Also, where did you come up with the origial scale for the
> box?
> 
> Steve

  I have finally figured out why it was necessary to add the extra .1 to
the object size. As the boxes are rotated and scaled the are rapidly
reduced in size for the y dimension. In fact the are reduced to zero
on the last loop of the counter. When the loop hits the last count
the object has reached a dimension where it is divisible by itself
and Pov notes a divide by zero error.
 The Pov team, in their own infinite wisdom, have built a trap into
the program to protect us from this kind of situation. Unfortunately
when Pov steps in to correct the error it automatically assigns a
scale of one to the offending object. I could not for the life of
me figure out why my dome was so distorted on the top most row.
I finally, probably by accident, found that adding the .1 value
kept the object within scalable limits before the count died and Pov
would be forced to rescue me from myself.

I wonder If I could save myself a lot of trouble by starting the first
rotation from the top of the dome downward opposite it's current
behavior. This way it would never reach zero because the object size
will be increasing instead of decreasing through the loop.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Actually, sitting through what may have been THE most boring lecture I
have ever attended... And I have attended quite a few, I came to a     
solution to your problem.  I have yet to implement it except on paper
since I have been extremely busy (though I can now claim the 7th fastest
ergometer score on my crew team since I covered 2000meters in 6:31.2
today after covering the same distance in 2.4 seconds more yesterday and
got perhaps that much sleep between them) So if you will forgive me, I
am going to nap, then go to a meeting, then lift, then do homework for
three classes and then tomorrow after my long day is over, I will
implement the code... The sad part is that it isn't so hard to
implement, but I just haven't sat down and typed it in (btw the radius
will and must be defined by the size of the box used...)  

Steve 
(of course in the time it took me to write this...)

Ken wrote:
> 
> Stephen Lavedas wrote:
> >
> > Okay Ken... you have a couple of magic numbers in here (a magic number
> > is a number that is just there for some reason and no logical
> > explaination is known except by the author)  The most important one is
> > 1.6*pi/90-bb where did you get this figure?  I am trying to figure it
> > out, and my guess is that you just kept tweaking it until there weren't
> > any gaps...Also, where did you come up with the origial scale for the
> > box?
> >
> > Steve
> 
>   I have finally figured out why it was necessary to add the extra .1 to
> the object size. As the boxes are rotated and scaled the are rapidly
> reduced in size for the y dimension. In fact the are reduced to zero
> on the last loop of the counter. When the loop hits the last count
> the object has reached a dimension where it is divisible by itself
> and Pov notes a divide by zero error.
>  The Pov team, in their own infinite wisdom, have built a trap into
> the program to protect us from this kind of situation. Unfortunately
> when Pov steps in to correct the error it automatically assigns a
> scale of one to the offending object. I could not for the life of
> me figure out why my dome was so distorted on the top most row.
> I finally, probably by accident, found that adding the .1 value
> kept the object within scalable limits before the count died and Pov
> would be forced to rescue me from myself.
> 
> I wonder If I could save myself a lot of trouble by starting the first
> rotation from the top of the dome downward opposite it's current
> behavior. This way it would never reach zero because the object size
> will be increasing instead of decreasing through the loop.
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

Post a reply to this message

Stephen Lavedas wrote:
 So if you will forgive me, I
> am going to nap, then go to a meeting, then lift, then do homework for
> three classes and then tomorrow after my long day is over, I will
> implement the code... The sad part is that it isn't so hard to
> implement, but I just haven't sat down and typed it in (btw the radius
> will and must be defined by the size of the box used...)
> 
> Steve
> (of course in the time it took me to write this...)

Good night Steve,

I have at least another couple months to live so take all the time you
need. All kidding aside your efforts are appreciated and never have
I asked for extra effort or put time demands on someone who is doing
me a favor in the first place.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message