I was reading a CSV file successfully until povray ran into the next to  last
line below. (There were dozens of lines before it which were read successfully
as well, dozens after of similar format to the last line. )




-0.126,-2.53681E-06,49668.6783795397
-0.108,-2.14271E-06,50403.4610376579
-0.09,-1.77115E-06,50814.442593795
-0.072,-1.42709E-06,50452.3190548599
-0.054,-1.05761E-06,51058.5187356398
-0.036,-6.98572E-07,51533.7001769324
-0.018,-3.47316E-07,51826.0028331548
0,-1.8643E-09,0
0.018,3.49041E-07,51569.8728802634


Error message,
// "huhnomarks2.csv" line 52: Parse Error: Expected 'float, vector, or string
literal', ,  found instead
//  Render failed"



I'm not at all confident I have the code below in a concise or correct solution
to the problem.  I also have read in some doc or wiki that the CSV file quoted
above is not in the correct format.  Just sad that it got this far and then
bombed.


 #fopen MyFile "huhnomarks2.csv" read
 #debug "got to line  7 \n"

 #declare Vee=array[300]
 #declare I2=array[300]
 #declare I3=array[300]
 #declare I4=array[300]


 #declare n=0;
#while(n<300)
 #declare Vee[n]=0;
 #declare I2[n]=0;
 #declare I3[n]=0;
 #declare I4[n]=0;
 #declare n=n+1;
 #end

 #declare JunkText=""

#read(MyFile)
 #read(MyFile)


 #debug "got to line  18 \n"


 //#read(MyFile,JunkText,",")
 #debug "got to line  22 \n"

// #read(MyFile,JunkText,CurveTitle)



   #read (MyFile,Vkeed,Ik2d,Ik3d)

 //#read(MyFile,IsitV,IsitI2,IsitI3,IsitI4)

 #debug "got to line  25 \n"
 #declare n=0;
 #while (defined(MyFile))


   #read (MyFile,Veed,I2d,I3d)
   #declare Vee[n]=Veed;
   #declare I2[n]=I2d;
   #declare I3[n]=I3d;
   #declare n=n+1;

  #end

Post a reply to this message

On 28/01/14 14:45, gregjohn wrote:
> 
> I was reading a CSV file successfully until povray ran into the next to  last
> line below. (There were dozens of lines before it which were read successfully
> as well, dozens after of similar format to the last line. )
> 
> 
> 
> 
> -0.126,-2.53681E-06,49668.6783795397
> -0.108,-2.14271E-06,50403.4610376579
> -0.09,-1.77115E-06,50814.442593795
> -0.072,-1.42709E-06,50452.3190548599
> -0.054,-1.05761E-06,51058.5187356398
> -0.036,-6.98572E-07,51533.7001769324
> -0.018,-3.47316E-07,51826.0028331548
> 0,-1.8643E-09,0
> 0.018,3.49041E-07,51569.8728802634
> 
> 
> Error message,
> // "huhnomarks2.csv" line 52: Parse Error: Expected 'float, vector, or string
> literal', ,  found instead
> //  Render failed"
> 

I don't use #read very often so I might be wrong but shouldn't there be
commas after all the values even at the end of the lines?

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children

Post a reply to this message

Doctor John <j.g### [at] gmailcom> wrote:

>
> I don't use #read very often so I might be wrong but shouldn't there be
> commas after all the values even at the end of the lines?
>
> John
> --

Yes, I understand, ideally. Put this CSV is auto-generated by an electrical test
tool and I was hoping to get povray to auto-import the data, if I were to find
the correct povray syntax. The "mouse clicks" to fix the CSV are probably more
than would be required to just use Excel.

I was disappointed however that povray offered no complaint at
-0.018,-3.47316E-07,51826.0028331548

yet crashed with seeing
0,-1.8643E-09,0

I was hoping there were a small tweak to my code that could fix all this. (If
not a possible improvement to povray that could be suggested).

But you know, I guess I *do* have the power to just make sure there are no "0"
entries in the CSV. Will try that.

Post a reply to this message

With even more experimentation, I see that the code fails with the first
transition from negative to non-negative number, and not because of the "0".  It
was successfully reading all the values until then.

Post a reply to this message

Am 28.01.2014 15:45, schrieb gregjohn:
>
> I was reading a CSV file successfully until povray ran into the next to  last
> line below. (There were dozens of lines before it which were read successfully
> as well, dozens after of similar format to the last line. )
>
>
>
>
> -0.126,-2.53681E-06,49668.6783795397
> -0.108,-2.14271E-06,50403.4610376579
> -0.09,-1.77115E-06,50814.442593795
> -0.072,-1.42709E-06,50452.3190548599
> -0.054,-1.05761E-06,51058.5187356398
> -0.036,-6.98572E-07,51533.7001769324
> -0.018,-3.47316E-07,51826.0028331548
> 0,-1.8643E-09,0
> 0.018,3.49041E-07,51569.8728802634

Using #read, POV-Ray interprets this as:

...
   -1.42709E-06, 50452.3190548599 - 0.054,
   -1.05761E-06, 51058.5187356398 - 0.036,
   -6.98572E-07, 51533.7001769324 - 0.018,
   -3.47316E-07, 51826.0028331548   0,
   -1.8643E-09,                 0   0.018,
    3.49041E-07, 51569.8728802634

And yes, it /does/ compute the differences.

To my knowledge you could even use variable names in there, or functions.

Post a reply to this message

On 28/01/14 17:48, clipka wrote:
> Using #read, POV-Ray interprets this as:
> 
> ....
>   -1.42709E-06, 50452.3190548599 - 0.054,
>   -1.05761E-06, 51058.5187356398 - 0.036,
>   -6.98572E-07, 51533.7001769324 - 0.018,
>   -3.47316E-07, 51826.0028331548   0,
>   -1.8643E-09,                 0   0.018,
>    3.49041E-07, 51569.8728802634
> 
> And yes, it /does/ compute the differences.
> 
> To my knowledge you could even use variable names in there, or functions.
> 

... which is why you need the commas.

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> ...
>    -1.42709E-06, 50452.3190548599 - 0.054,
>    -1.05761E-06, 51058.5187356398 - 0.036,
>    -6.98572E-07, 51533.7001769324 - 0.018,
>    -3.47316E-07, 51826.0028331548   0,
>    -1.8643E-09,                 0   0.018,
>     3.49041E-07, 51569.8728802634
>
> And yes, it /does/ compute the differences.
>
> To my knowledge you could even use variable names in there, or functions.

Actually, it goes like this:

-------------------------------
Here's a block from my CSV
-------------------------------
-0.09,-1.77115E-06,50814.442593795
-0.072,-1.42709E-06,50452.3190548599
-0.054,-1.05761E-06,51058.5187356398
-0.036,-6.98572E-07,51533.7001769324
-0.018,-3.47316E-07,51826.0028331548
-0.001,-1.8643E-09,51877.
0.818,3.49041E-07,51569.8728802634
0.036,6.66051E-07,54049.9150965917
0.054,9.48796E-07,56914.236569294


-------------------------------
Here's what variable values actually made it into my scene.
-------------------------------

 0.0900  -1.7712E-06  50814.4426
 0.0720  -1.4271E-06  50452.3191
 0.0540  -1.0576E-06  51058.5187
 0.0360  -0.6986E-06  51533.7002
 0.0180  -0.3473E-06  51826.0028
 0.0010  -0.0019E-06  51877.0000


"huhnomarks3.csv" line 51: Parse Error: Expected 'float, vector, or string
literal', ,  found instead


I still might be attempting, to use a recent friend's analogy, to use a Ferrari
as a snowplow, but the fact that I'm so close that I'm hopeful I could just make
a few more tweaks.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> To my knowledge you could even use variable names in there, or functions.

You can put #declares, #macros and, in general, almost any # commands
in a file you are reading with #read, and those commands will be
processed normally.

-- 
                                                          - Warp

Post a reply to this message

Doctor John <j.g### [at] gmailcom> wrote:
> I don't use #read very often so I might be wrong but shouldn't there be
> commas after all the values even at the end of the lines?

POV-Ray will interpret "1 2" as two numbers, but "1 -2" as a subtraction,
resulting in one number. Thus the comma is not *strictly* necessary when
the next number has no binary operator in front of it, but it's
nevertheless a good idea.

This will work the same in normal .pov files as well. (In fact, the exact
same parser is used to interpret .pov files and input files read using
the #read command.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> POV-Ray will interpret "1 2" as two numbers, but "1 -2" as a subtraction,
> resulting in one number. Thus the comma is not *strictly* necessary when
> the next number has no binary operator in front of it, but it's
> nevertheless a good idea.
>

This is disproven by my example above.

Post a reply to this message