[jira] [Resolved] (CARBONDATA-3965) Adaptive encoding of Complex primitive float is using log value to store float (4 bytes) data

[Akash R Nilugal (Jira)]

     [ 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)