How to do Double to T conversion? about dsptools HOT 6 CLOSED

Ok, so seems like doing
val temp2 = implicitly[Real[Q]].fromDouble(9.333333)
can't possibly work correctly for FixedPoint #?'s

It uses FixedPoint.fromDouble(9.33333), which has default width = -1 and binaryPoint = 0. Default width = -1 gets translated to Width(), which gets properly inferred (assuming no fractional bits) down the line (i.e. 9.333 -> 5 bits, including 1 for sign), but the # of fractional bits = 0 if you don't specify binaryPoint, which you can't via the ConvertableTo from double.

Am I misunderstanding something wrt to the type classes? Or how is it possible that you guys previously passed any tests with constants? @chick @grebe @azidar @stevobailey

from dsptools.

So I think you're right that it is busted. What I think I used to do when writing the typeclasses would be to create my own typeclass instance (e.g. by extending this and override fromDouble to include specify and binary point and possibly width. I don't think this technique made it into the tests in this repo though. The tests in this repo don't exercise float/fixed generators much, that should definitely be rectified.

@stevobailey how are you getting constants into your fixed point fft currently?

I think the idea was to look at doing this with contexts and just never got around to it. I'm not sure if that's the best way, what do you think @shunshou?

from dsptools.

Will address with a pimp my library style PR. You guys can decide on a best way to proceed later. I just need something now.

from dsptools.

Thought I would add a couple of ideas that came up in conversation yesterday with @grebe and @stevobailey

• Automagically set the binary point for fixed point created in this scenario to where it would pass the nearlyEquals test. Basically match the epsilon defined there
• Based on a width, automatically place the binary point to the maximum value that still accommodates the MSB of the constant.

from dsptools.

That doesn't work. For a single constant, that's fine, but where you're more likely to see constants is for a LUT. All elements in a LUT need to have the same binary point. If elements had with = 16 butt one element was 5000 and another was 2, automagic would result in two very different binary pts.

from dsptools.

Also setting it to pass nearly equals doesn't make sense in the long run Bc you should be setting the epsilon at the nearly equals checking operation... When you're poking a real circuit, you need to build in epsilon margin Bc you aren't just doing a real to fixed conversion. All of the math in between can cause crazy amounts of numerical error that causes epsilon to need to be increased considerably...

from dsptools.