One more comment:  I am pretty sure the error message said something about an
unexpected PRESENCE of a comma; my problem was ultimately the
unexpected ABSENCE of a comma. I think if I had seen a different message, I would have
fixed the problem in a matter of minutes.

Is the error message stream correct?

Greg M. Johnson wrote:

> I wish that the documentation better explained the syntax for #read and
> #write.
>
> I have created a file of the positions and velocities of a number of
> particles, (34 particles at 350 time periods).  I have pasted the first
> four records from my file.
>
> 0,0,2.82488,1.88872,1.28931,-0.528847,-0.0413402,-0.84771
> 0,1,4.52083,2,3.26511,0.180401,-0.87059,-0.457743
> 0,2,2.46931,-1.21869,-0.8285,-0.187654,-0.372504,-0.90886
> 0,3,-2.75538,0.609548,-1.23555,-0.440196,-0.39602,-0.805851
>
> The text file has the carriage returns already in it, as you can see. I
> successfully used the following command to write this file:
>
> #write
>
(MyFile2,tt,",",n,",",actorp[n][0].x,",",actorp[n][0].y,",",actorp[n][0].z,",",actorv[n][0].x,",",actorv[n][0].y,",",actorv[n][0].z,"\n"
>
> )
>
> But when I try to read the file, either superpatch for 3.1a crashes, or
> it says something about expecting a variable but seeing a comma
> instead.  I want to load this huge file into memory into two different
> arrays, each with two subscripts.
>
> According to my interpretation of the debug stream, when the program
> gets into the second line of variables, it hangs up on about the third
> variable. I am trying the following commands to read the file:
>
> #fopen MyFile2 "c:\pov31\include\traillist.txt" read
> #declare tt=0    ;
> #while (tt<350*clock+1)
> #declare n=0    ;
> #while (n<num)
> #debug "yeehah"
> #read (MyFile2,l,m,px,py,pz,vx,vy,vz)
>  #debug str(l,2,2)
>  #debug str(m,2,2)
>  #debug str(px,2,2)
>  #debug str(py,2,2)
>  #debug str(pz,2,2)
>  #debug str(vx,2,2)
>  #debug str(vy,2,2)
>  #debug str(vz,2,2)
> #declare actorp[tt][n]=<px,py,pz>;
> #declare actorv[tt][n]=<vx,vy,vz>;
> #declare n=n+1   ;
> #end
>
> #declare tt=tt+1;
> #end
>
> #fclose Myfile2
>
> Thanks for any possible help.   This "one hour" doofy project turned
> into a twelve hour battle with the software! I suspect the problem is
> in the use of two-dimensional arrays, as a much simpler,
> one-dimenstional array "reading" project works great.   If I may
> politely state so,  the 3.1a documentation preaches to the choir too
> often on syntax and rarely gives enough examples of how to actually use
> the terms. In this case, I don't know how to read my file.

Post a reply to this message

Nieminen Mika wrote:

> Matt Giwer <mgi### [at] giwersworldorg> wrote:
> :       A better question, why in the world would the interpreter
> : require a comma and CR/LF at the end of a line? I can't say I've
> : seen everything in my time but that is not a rational data set
> : requirement.

>   It doesn't require a comma and a CR/LF. It just requires a comma between
> values. It couldn't care less about CR/LF's. It just ingores them.

	That is the point. Absent the CR/LF any one corrupt data point
can currupt the entire result as everything is shifted only
point. Data number 23 replaces population value 290000 and
everything propagates in error from their on. But with CR/LF a
faulty data line is reported instantly. 

	As I said, rational data set. 	

> : begin:vcard

>   Please don't post this vcard crap here.

	When the POV-team post that rule, I will delate it. Until then,
take it up with Mozilla. 

> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

	Please don't post that! Or are requests one way? 

	If you have a problem, remember the Canadian Bacon grafitti. 

-- 
<blink>-------please--don't-----------------</blink>

http://www.giwersworld.org/artii/
http://www.giwersworld.org/artiii/

Finally up on 99/06/22 updated 07/13

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

On Mon, 09 Aug 1999 11:03:52 -0400, Matt Giwer wrote:
>> --
>> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
>
>	Please don't post that! Or are requests one way? 


The difference: Warp's signature is 2 lines.  Way below the McQuary Limit.
Yours is six lines, which is already in excess of the limit, plus a mostly-
useless MIME attachment that eats up another 22 lines and incidentally adds
an extra step to reading your postings with text-mode newsreaders such as
slrn (which I use) that want to do the right thing with MIME-formatted 
postings.  Just because some idiot at Nutscrape doesn't understand USENET 
culture doesn't mean you have to meekly follow along.

Post a reply to this message

On 9 Aug 1999 11:28:19 -0400, par### [at] fwicom (Ron Parker) wrote:

>On Mon, 09 Aug 1999 11:03:52 -0400, Matt Giwer wrote:
>>> --
>>> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>>> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
>>
>>	Please don't post that! Or are requests one way? 
>
>
>The difference: Warp's signature is 2 lines.  Way below the McQuary Limit.
>Yours is six lines, which is already in excess of the limit, plus a mostly-
>useless MIME attachment that eats up another 22 lines and incidentally adds
>an extra step to reading your postings with text-mode newsreaders such as
>slrn (which I use) that want to do the right thing with MIME-formatted 
>postings.  Just because some idiot at Nutscrape doesn't understand USENET 
>culture doesn't mean you have to meekly follow along.

Ys, the vcf card is something of an annoyance.  I have Agent set up to save
attachments
and every now and again I have to delete all those dratted vcf cards.  There is a
temptation to filter out the offending users, but I have resisted this because this
would
mean missing some of Matt's more interesting postings :-)
David
------------
dav### [at] cwcomnet
http://www.hamiltonite.mcmail.com
------------

Post a reply to this message

Nieminen Mika wrote:
> 
> John VanSickle <van### [at] erolscom> wrote:
> : For instance, in my last IRTC entry, the insect parts were made of
> : bicubic patches, which I converted to meshes
> 
>   I wonder why.

Most of the bug parts had 12 bicubic patches in them, but others had
16, and I think one has 20.  There are 128 triangles per patch, and each
bug had roughly 30,000 triangles in it.  The use of meshes achieved a
memory savings of about 4.5 megs per bug.

They also parsed more quickly this way.

Regards,
John

Post a reply to this message

Mat

It's very annoying, and the information on both your own card and
that of SamuelT another offender could be put in text format
without taking up so much bandwidth.  

Most annoying is when I've got a render going and I'm reading
news groups and every time I open one of your messages, the
message comes up and then I see something else loading, scrole to
the bottom of the message and it's a bloody VCard.  

I havn't mentioned this before, because I feel that your
contributions to these groups are positive.  

Matt Giwer wrote:
> 
> Nieminen Mika wrote:
> 
> > Matt Giwer <mgi### [at] giwersworldorg> wrote:
> > :       A better question, why in the world would the interpreter
> > : require a comma and CR/LF at the end of a line? I can't say I've
> > : seen everything in my time but that is not a rational data set
> > : requirement.
> 
> >   It doesn't require a comma and a CR/LF. It just requires a comma between
> > values. It couldn't care less about CR/LF's. It just ingores them.
> 
>         That is the point. Absent the CR/LF any one corrupt data point
> can currupt the entire result as everything is shifted only
> point. Data number 23 replaces population value 290000 and
> everything propagates in error from their on. But with CR/LF a
> faulty data line is reported instantly.
> 
>         As I said, rational data set.
> 
> > : begin:vcard
> 
> >   Please don't post this vcard crap here.
> 
>         When the POV-team post that rule, I will delate it. Until then,
> take it up with Mozilla.
> 
> > --
> > main(i,_){for(_?--i,main(i,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> > ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
> 
>         Please don't post that! Or are requests one way?
> 
>         If you have a problem, remember the Canadian Bacon grafitti.
> 
> --
> <blink>-------please--don't-----------------</blink>
> 
> http://www.giwersworld.org/artii/
> http://www.giwersworld.org/artiii/
> 
> Finally up on 99/06/22 updated 07/13

-- 
Cheers
Steve

------------------------------------------------------------------------------------------------
%HAV-A-NICEDAY Error reading file mailto:sjl### [at] ndirectcouk

Post a reply to this message

Greg M. Johnson wrote:
> 
> John VanSickle wrote:
> 
> > Greg M. Johnson wrote:
> > >
> > > I wish that the documentation better explained the syntax for
> > > #read and #write.
> > >
> > > I have created a file of the positions and velocities of a number
> > > of particles, (34 particles at 350 time periods).  I have pasted
> > > the first four records from my file.
> >
> > Generally, when I have an outside program generate data for POV-Ray,
> > I have the same program output a standard .INC file, with all of the
> > #declares, #locals, etc., needed for POV-Ray to parse the file
> > directly. This requires very little extra effort in the program that
> > generates the data, and the results parse a lot faster.
> >
> > For instance, in my last IRTC entry, the insect parts were made of
> > bicubic patches, which I converted to meshes using a bit of macro
> > code.  I got tired of waiting for the macro to parse, so I modified
> > the macro to write the triangles to a file, in full POV syntax.
> > From then on I merely #included the generated files, in place of the
> > original generating code.  Things parsed much more quickly.

> So, like how would you make your inc if you had two variables which
> were [350][34] each?
> 
> Would your file generator literally say:
> 
> #declare position.x[1][1]=1;
> #declare position.y[1][1]=2;
> #declare position.z[1][1]=3;
> #declare position.x[1][2]=4;
> #declare position.y[1][2]=5;
> #declare position.z[1][2]=6;

No, the file generator can also dump out the following:

#declare position=array[350][34] = {
  { <1,2,3>,<4,5,6>, ... }, {... }, ...
}

The PovRay code would look like this:

// START OF SAMPLE BASIC CODE

#write(MyFile,"#declare position=array[", ROWS, "][", COLUMNS, "] = {\n")
#local iI=0; #while(iI<ROWS)
  #if (iI>0) #write(MyFile,",") #end
  #write(MyFile,"{ ")
  #local iJ=0; #while(iJ<COLUMNS)
    #if (iJ>0) #write(MyFile,",") #end
    #write(MyFile,MyDataArray[iI][iJ])
  #local iJ=iJ+1; #end
  #write(MyFile, " }\n" )
#local iI=iI+1; #end
#write(MyFile, "}\n" )

// END OF SAMPLE CODE

Your file generating program can print out the #declares, square
brackets, angle brackets, squiggly brackets, commas, and so forth.

The only difficulty is that if you want to have text data in there as
well, you have to explicitly print out the quotes with the CHR$()
function:

  #write(MyFile, "#declare MyString="; CHR$(34); "Stormbringer";
    CHR$(34); "\n")

which will create a line of text that looks like this:

  #declare MyString="Stormbringer"

You can feed a vector to the #write() directive as well; my example does.

  #write(MyFile,x-y+z*3)

will cause the string

  < 1,-1, 3>

to be written to MyFile.  There is no need to bust up the vectors into
scalars, only to build them back up later.

Of course, keeping track of the brackets and quotation marks can be
a bit of a trick. :-)

> I know how to write such a file, but wouldn't this make it a huge INC?

As you can see from my response, it will not be very much larger than
the file you already plan to use.  It might be twice as big, but that's
what we have hard drives for.

> Are you sure this is faster than reading with a #while loop the
> following data:
> 
>  1,2,3,4,5,6,

Yes, it is much faster.  The file is generated in a form the parser
already knows how to understand; the other method you discuss goes
through a #while-#end loop, which takes extra time in any interpreted
language.

Hope this helps,
John

Post a reply to this message

What can a vcard do that a sig can't, anyway?

Margus

Matt Giwer wrote:
> 
> 
>         When the POV-team post that rule, I will delate it. Until then,
> take it up with Mozilla.
> 
>

Post a reply to this message

Margus Ramst wrote:
> 
> What can a vcard do that a sig can't, anyway?
> 
> Margus

Irritate people ?

-- 
Ken Tyler

See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

On Tue, 10 Aug 1999 17:10:44 -0700, Ken <tyl### [at] pacbellnet> wrote:
>Margus Ramst wrote:
>> 
>> What can a vcard do that a sig can't, anyway?
>> 
>> Margus
>
>Irritate people ?

As a counterexample I offer Warp's sig. >:)

Post a reply to this message