[
https://issues.apache.org/jira/browse/CARBONDATA-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ajantha Bhat resolved CARBONDATA-3965.
--------------------------------------
Fix Version/s: 2.1.0
Resolution: Fixed
> Adaptive encoding of Complex primitive float is using log value to store
> float (4 bytes) data
> ---------------------------------------------------------------------------------------------
>
> Key: CARBONDATA-3965
> URL: https://issues.apache.org/jira/browse/CARBONDATA-3965
> Project: CarbonData
> Issue Type: Bug
> Reporter: Ajantha Bhat
> Priority: Major
> Fix For: 2.1.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> I have tested, With current UT itself it is hitting. for [Null, 5.512] it is
> using long as storage for complex primitive adaptive. Base behavior needs to
> check. I guess it can be analyzed separately
>
> For this, I have checked
> If No complex type, (if it is just primitive type) same values goes to
> DirectCompress, not adaptive. But for complex primitive it goes to adaptive
> because of below code. And as min max is stored as double precision. Long is
> chosen for this.
> {{DefaultEncodingFactory#selectCodecByAlgorithmForFloating()}}
>
> {{} else if (decimalCount < 0 && !isComplexPrimitive) \{
> return new DirectCompressCodec(DataTypes.DOUBLE);
> } else \{
> return getColumnPageCodec(stats, isComplexPrimitive, columnSpec,
> srcDataType, maxValue,
> minValue, decimalCount, absMaxValue);
> }}}
> {{}}
> I don't know (remember) why complex primitive should not enter direct
> compress. why that check is explicitly added.{{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
