[Qucs-devel] Re: ASCO

[Stefan J. <st...@gr...>]

On Mo, 30.01.2006, 14:47, asco developer wrote:

Hello!

>> I put the following things onto my TODO list:
>>
>>   yvalue (S[1,1], 12e9)
>>   xvalue (S[1,1], 1)
>>   max (S[1,1], 2e9: 5e9)
>>   min (S[1,1], 2e9: 5e9)
>>   avg (S[1,1], 2e9: 5e9)
>
> Creating a language, that is logical and simple at the same time can
> be a demanding task. All simulators that I have used to far have used
> the character comma as their separator symbol. Off course you can run
> away of this be specifying the column as the default separator
> character in Qucs. Maybe they have used comma because they use s(11)
> and not s(1,1).
>
> What I would like is that all simulators have agreed on a common
> format, at least for most of the common things. I know this is an
> utopia, but what a heck. So, my suggestion at this moment is for you
> to think on something that works well today and still allows Qucs to
> scale up quite well, without the need to reinvent a new extraction
> language in a near future. Revamping can be good, but it also takes
> time to implement and check!
>
>
>>
>> Whereas S[1,1] can be vectors, and matrix vectors with a single
>> dependency
>> only (in this case it is "frequency").  The range specification is
>> max(),
>> min() and avg() can be either:
>>
>>   xval1:xval2  OR  (values from xval1 to xval2)
>>   xval1:       OR  (values from xval1 to last)
>>   :xval2       OR  (values from first to xval2)
>>   :                (all values)
>>
>> The specified values are going to be inclusively.
>
> Kind off Matlab style, no?

Better: Octave-style. :-)

>> Each given x value *must* be in the dataset, otherwise the functions
>> return
>> an error.  When given a y value (as in e.g. xvalue()) then the nearest
>> x value will be returned.  Or should be an appropriate interpolation be
>> applied?
>
> Interpolation can in some case be a better option than just returning
> an error. If you have only the following data points:299.34MHz,
> 300.234 MHz, 304.123MHz ... why shouldn't the user be allowed to
> measure at 300 MHz?

Because the 300.234MHz is near enough?

But I see.  I'll think about it...

>> Any more suggestions, objectives, comments?
>
> Nope!

Cheers, Stefan.