Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Name for the field element type in Cairo 1.0 #2468

AbdelStark started this conversation in Polls
Discussion options

Description

Dear Cairo builders, we need your opinion on the name of the field element type in Cairo 1.0. So far, we always have used the term felt to design the basic type in Cairo. With Cairo 1.0 and Sierra, we want to give more flexibility and adaptability to the language, hence we anticipate potential future changes to the basic field element type we use (i.e use goldilocks instead of the current prime). We also want to make explicit at a given time what field element is used, and we believe it should be reflected in the name of the type.

What should be the name of the field element type ?
f252
10%
fe252
18%
felt252
71%

60 votes

You must be logged in to vote

Replies: 8 comments 12 replies

Comment options

I would stay away from f252 as it can be mistaken for floating-point numbers.

You must be logged in to vote
0 replies
Comment options

I don't like having 252 in the name itself, because it cannot hold all the values that fit into 252 bits, i.e. 2**252 > 2**251 + 17 * 2**192 + 1

You must be logged in to vote
3 replies
Comment options

it can't?

Comment options

oh right there was some space reserved for something, no? i can't find it in the docs

Comment options

I think you're right, there was something related to addresses, but also can't remember or find the details.

However what I meant with the comment was that the max value that fits into 252 bits is greater than the prime so it would just wrap around ((2**252 - 1) % prime). So while we need 252 bits to store the prime, not all values are "available" which is in contrast with other primitive types like u128.

Comment options

Why not simply felt:
1_felt
42_felt
?

You must be logged in to vote
2 replies
Comment options

AbdelStark Mar 14, 2023
Maintainer Author

because as I explained in the description if at some point we change the prime to goldilocks for example it will be problematic

Comment options

To make sure I understand correctly, is it about changing the felt in variables:
fn some_fn(some_felt: felt, some_other_felt: felt252);
Or in creating a felt:

1_felt
42_felt

Or somewhere else?

Comment options

i feel as though usual types are characterized by the number of bits they fit,
u8, u32 etc.

here, we use bits for our usual felt type 251 or 252 for convenience, but the field itself characterizes the felt.

since fields have distinct names, they could be used as prefixes or suffixes.

e.g.

felt_gl for field element on goldilock

or simply felt, always, and you declare use goldilocks::felt at the top of your file.

You must be logged in to vote
2 replies
Comment options

The problem is that we don't have a "known" name for the field we currently use in Cairo.

Comment options

i guess you could name it the starkware field?
or it could be the felt_std as it was the first

felt_std, felt_gold or felt_gl , etc. but it does add an underscore in the type, which is quite ugly.
I guess namespacing the type feels okay to me

std::felt
goldilocks::felt, etc

Comment options

Rust convention is keeping things minimal (fn, u32, pub, etc...), that's why I like fe252 over felt252. Agree f252 seems confusing (f is used for float)

You must be logged in to vote
0 replies
Comment options

fe252 is my pick because it's a shorthand for felt/field element. Rust uses fX for floating-point so I agree we should avoid this.

You must be logged in to vote
1 reply
Comment options

is it possible that two fields both use a prime that is close to 252 bits? if so, then this name allows for "naming collision"

Comment options

We decided to go with felt252, as this is the winner option in the poll. In the future we will add aliasing capabilities so that the developer will have the freedom to choose what suits best. Thanks a lot for your contribution.

You must be logged in to vote
4 replies
Comment options

In the future we will add aliasing capabilities so that the developer will have the freedom to choose what suits best.

Please don't do that, people will start fighting over taste differences. I think it'd be better to enforce one convention 🤔

Comment options

AbdelStark Mar 14, 2023
Maintainer Author

Noted @mkaput thanks for the input

Comment options

Do I see correctly that the decision has been made 4h after voting started?
Kinda quick, no?

Comment options

AbdelStark Mar 14, 2023
Maintainer Author

Yeah sorry we were in a rush for StarkNet 0.11. Next time we will make sure to consult earlier

Comment options

#Linux
grep -rl --exclude-dir=.git --include \*.cairo felt . | xargs sed -i 's/felt/felt252/g'
# Mac OS
grep -rl --exclude-dir=.git --include \*.cairo felt . | xargs sed -i "" -e 's/felt/felt252/g'
You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

AltStyle によって変換されたページ (->オリジナル) /