[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuplot-info-beta
Subject:    Re: millisecond time format
From:       plotter () piments ! com
Date:       2008-02-23 18:19:55
Message-ID: op.t6zo7hkd6dbjys () linbox ! localdomain
[Download RAW message or body]

On Sat, 23 Feb 2008 19:12:09 +0100, Ethan A Merritt  
<merritt@u.washington.edu> wrote:

> On Saturday 23 February 2008 09:58, plotter@piments.com wrote:
>> This does however raise another question in my mind. I am mainly using
>> gnuplot in an embedded context using softfloat. If all x coords are
>> treated as double (although not using the fractional part) this mean a  
>> lot
>> of unnecessary float operations at every step of the plot process.
>>
>> Mightn't it be worthwhile my changing this locally to use integer on an
>> integer arch?
>
> On input, data values are stored in a variable of type "coordval",
> which is either float or double depending on the architecture and
> configuration options.   However when the data is used for plotting
> the program switches to using integer coordinates representing
> individual pixels to the precision of the current terminal.
>
> I doubt there is much room for switching to integers any earlier.
>
>

OK! So internal calculation is always float of some sort or another and  
the original question of support for sub-second time resolution once again  
becomes a "simple" question of defining an input specifier and parsing the  
input data.

Thus all plotting and fitting and other functions would account for the  
new precision.

Thanks for the explainations.

Peter.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gnuplot-beta mailing list
gnuplot-beta@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
[prev in list] [next in list] [prev in thread] [next in thread]