New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed point types #409

Open
chriseth opened this Issue Mar 3, 2016 · 16 comments

Comments

6 participants
@chriseth
Contributor

chriseth commented Mar 3, 2016

https://www.pivotaltracker.com/story/show/81779716

TODO:

  • assignment (lvalue and rvalue)
  • conversion (between different fixed types)
  • conversion (between other types)
  • comparison operators (< > =)
  • unary operators (-, --, ++)
  • binary operators (+ - / * )
  • do-we-need-these? binary operators (% **)

@chriseth chriseth added this to the bieti milestone Mar 3, 2016

@chriseth chriseth modified the milestones: colocolo, bieti Mar 29, 2016

@chriseth chriseth modified the milestones: domesticus, colocolo Apr 11, 2016

@chriseth chriseth changed the title from Fixed point types to Fixed point types - ConstantNumber part Apr 11, 2016

@chriseth chriseth changed the title from Fixed point types - ConstantNumber part to Fixed point types Apr 11, 2016

@chriseth chriseth added active and removed planned labels Apr 15, 2016

@chriseth chriseth added planned and removed active labels Apr 25, 2016

@chriseth

This comment has been minimized.

Contributor

chriseth commented May 12, 2016

Some notes:

IntegerType::binaryOperatorResult is too tight, this should work but seems not to: uint128(1) + ufixed(2), same with FixedPointType::binaryOperatorResult

also this should work: .5 * uint128(7)

what happens currently with uint(7) / 2? Is it identical to .5 * uint(7)?

add test about signed mod with rational constants (should behave identical to SMOD opcode)

@VoR0220

This comment has been minimized.

Contributor

VoR0220 commented May 12, 2016

signed mod as in a modulus operation with signed rational constants?

@chriseth

This comment has been minimized.

Contributor

chriseth commented May 12, 2016

yes - and fixed point

@VoR0220

This comment has been minimized.

Contributor

VoR0220 commented May 12, 2016

alright. I'll get on that. Crafting tests. Working on some fixes. And then it's onto the actual compilation.

@VoR0220 VoR0220 self-assigned this May 13, 2016

@VoR0220

This comment has been minimized.

Contributor

VoR0220 commented May 13, 2016

so couple of things. I got your first one working.

ufixed a = uint128(1) + ufixed(2);

The second two in the examples you laid out, based on how we defined implicit conversion are currently impossible.

0.5 currently converts to ufixed0x8 and that does not convert with a uint128.

uint(7) / 2 stays a uint256 after the division by 2 (it's truncating), and therefore cannot convert to ufixed128x128. And no... 0.5 * uint(7) is not the same as uint(7)/2....one is a ufixed0x8 and the other is dividing by an integer....kind of confusing....I'm thinking we may need to fix this up. Open to all suggestions....the only thing I can think up right now is to create a class atop integer type and fixed point and make it a super class of some kind...

@chriseth chriseth added in progress and removed active labels May 20, 2016

@chriseth chriseth modified the milestones: 2-functionality, domesticus Aug 5, 2016

@axic axic added the enhancement label Sep 6, 2016

@VoR0220 VoR0220 referenced this issue Sep 7, 2016

Closed

Fixed Point Type #619

7 of 9 tasks complete
@chriseth

This comment has been minimized.

Contributor

chriseth commented Dec 2, 2016

We decided to rather denote decimal places instead of "number of bits after the comma" to reduce confusion among users. This means that
fixed64x7 is a type of 64 bits and a value x of this type is interpreted as the number x / 10**7.

The type fixed is an alias for fixed128x19. The reason is that this type simplifies multiplication and also allows conversion from int64 without loss of precision / range.

@VoR0220

This comment has been minimized.

Contributor

VoR0220 commented Dec 2, 2016

@chriseth do we still want to allow users to fully extend the decimal range so that it can be fixed0x32 (I believe that's the full amount that it could take in but may be wrong).

@chriseth

This comment has been minimized.

Contributor

chriseth commented Dec 2, 2016

@VoR0220 note that the 0 is the total amount of bits in the type. The drawback of using decimals is that you cannot force the value to be between 0 and 1 anymore (because that does not fit the decimal range).

@VoR0220

This comment has been minimized.

Contributor

VoR0220 commented Dec 2, 2016

@chriseth so in other words it HAS to have an integer portion now...That's fine by me. The range and precisions seriously diminishes after 128 bits in fixed point either way.

@VoR0220

This comment has been minimized.

Contributor

VoR0220 commented Dec 4, 2016

@chriseth

This comment has been minimized.

Contributor

chriseth commented Mar 20, 2017

@VoR0220

This comment has been minimized.

Contributor

VoR0220 commented Mar 20, 2017

^Good find.

@axic

This comment has been minimized.

Member

axic commented Jul 19, 2017

Added a todo list above.

I think a good start could be making the below code compile:

contract C {
  fixed a = 3.14;
  function f(fixed b) {
     a = b;
  }
  function g() returns (fixed) {
    return a;
  }
}

@axic axic added feature and removed enhancement labels Oct 6, 2017

@meowingtwurtle

This comment has been minimized.

Contributor

meowingtwurtle commented Jan 10, 2018

Is this still planned for completion?

@axic

This comment has been minimized.

Member

axic commented Jan 30, 2018

A good question raised by @meowingtwurtle: should an explicit typecast from fixed point to integer be a reinterpretation of the bits or an actual integer conversion?

Currently typecasting is a mix between the two, but mostly it is an actual conversion and not reinterpretation. One example is function type to address (the address of the external contract) and to bytes4 (the signature of the external function).

I think we should always do an actual conversion, e.g. fixed point to integer is the integer only part. Reinterpretation can always be done via assembly if needed.

In the future it may make sense introducing a notation to separate the two.

@meowingtwurtle meowingtwurtle referenced a pull request that will close this issue Feb 14, 2018

Open

Add support for fixed points #3389

@fulldecent

This comment has been minimized.

Contributor

fulldecent commented Mar 1, 2018

The test case in this issue could be much improved to illustrate all features that are required to be implemented.

@axic axic added this to To discuss in Backlog (non-breaking) via automation Jul 30, 2018

@axic axic removed the in progress label Aug 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment