- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
static private Double getHashString(String string, Integer foundation){
Double hash = 0.0 ;
short [] charsToInteger = getCharArray(string);
double step = Double.MAX_VALUE / 256 - foundation;
for (int i = 0; i < charsToInteger.length ; i++ ){
hash += charsToInteger[i] * step;
step = step / 2 - 1;
}
return hash;
}
static private short [] getCharArray(String string){
char [] chars = string.toLowerCase().toCharArray();
short [] bytes = new short [chars.length];
for (int i = 0; i < chars.length; i++){
bytes [i] = (short) (chars[i] & 0x00FF);
//System.out.println("bytes [" + i + "] = " + bytes[i]);
}
return bytes;
}
ISO # 0
> Решать эту задачу обычным способом желания не было
> Я решил попробовать реализовать внезапно возникшую идею представления строки в виде числа, то бишь сигнатуры. Причем надо было реализовать эту идею таким образом, чтобы число зависело от символов и их порядка, находящихся в строке. Т.е. сделать так, чтобы сортировка этих чисел была эквивалентна сортировке строк в алфавитном порядке по всем символам этих строк.
Это охуенно!
Зато в репозитории есть «HashStringService.java», «HashStringController.java» и «public interface HashStringJpaRepo extends JpaRepository <HashString, Long>».
guest # 0 ⇈
Эквивалетно уже сразу не получится
ISO # 0 ⇈
P.S. Статью рекомендую прочитать, там просто эпического уровня анскилл.
guest # 0 ⇈
Чтобы решить задачу, нам нужно биекционно отражить множество строк на множество чисел.
Можно представить себе что строка это N-ичное число , N -- количество букв в алфавите.
То есть задача сводится к переводу из N-ричной системы в двоичную (для представления в памяти ПК) или в десятичную (с учетом локали).
Если я верно помню, то для перевода в десятичную каждый разряд умножают на A в степени B, где A это основание числа (в случае ASCII видимо 127) а B -- номер разряда.
Так что задача решается элементарно, правда для сортировки достаточно больших строк может и не хватить сверхбыстрой памяти.
Упомянутый выше hash это по-определеию сюръекция, и значит в общем случае не подходит
guest6_uebok # 0 ⇈
Fike # 0 ⇈
Достаточно инъекционно, нет? Можно добавить шаг с умножением числа на два и получить невозможность вывода нечетного числа, но сохранить контракт.
3.14159265 # 0 ⇈
Программист на «Лаже», даже «HelloWorld» не напишет без JPA, IoC и AbstractFactory.
[email protected] # 0
Неудобные строки, это когда у тебя 2 строки килобайт по 10, одна из которых нормальная, а во второй могут быть дефект[ы] OCR, а это вполне себе нормальные строки.
Fike # 0 ⇈
Fike # 0
ой бляджь просто идите нахуй
guest # 0 ⇈
Верхняя часть его состоит из монитора (телевизора) а нижняя из процессора (оперативной памяти)
Fike # 0 ⇈
guest # 0 ⇈
Я уже объяснил комптютер. Объясни теперь ты что нить
Fike # 0 ⇈
Внешний слой это просто честность (софт скиллы), а внутренний сонаправленность (мыслей программиста и потока байт)
Desktop # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
Верхняя часть его состоит из головы (пищеприёмника), а нижняя из ягодиц (точки опоры).
DaveMustAim # 0 ⇈
Это небо, плачущее небо под ногами.
guest # 0 ⇈
Это свиньи плещутся в канаве,
Рядом Чебуратор наблюдает за свиньями,
Что же будет с Родиной и с нами? ааа,
Рядом Чебуратор наблюдает за свиньями,
Что же будет с Родиной и с нами?
Осень, свиньи яблоки жрут,
Только пожрали - сразу насрут,
Только насрали - снова сожрут,
Вечный круговорот.
Что зима такое - это дубо,
Это с дуба помер Чебуратор,
Вместе с Чебуратором поймали дуба свиньи,
Весь колхоз и тётушка Аксинья, ааа,
Вместе с Чебуратором поймали дуба свиньи,
Весь колхоз и тётушка Аксинья.
Лето, осень, зима и весна,
Январь, февраль, март и апрель,
Вторник, среда, ёбаный в рот,
Вечный круговорот.
HoBorogHuu_nemyx # 0 ⇈
Это в хрюкни.
o6AMa_4MO # 0 ⇈
Сам знаешь, кому ответил
DaveMustAim # 0 ⇈
Desktop # 0 ⇈
Stallman # 0 ⇈
o6AMa_4MO # 0 ⇈
3.14159265 # 0 ⇈
>Что из этого возможно получить в виде выгоды? Ну, конечно же возможно! Вообще, старший байт , если мы сортируем список строк (слов) , описываемых одной страницей UTF-8 ASCII кодов, можно отбросить.
> Он является лишь маркером для выяснения страны происхождения данных строк.
Теперь мы знаем как отличать дешевые китайские подделки char.
guest # 0 ⇈
3.14159265 # 0
Пхахаха. Дальше можно быдло не читать.
>@SpringBootTest
>@ComponentScan("com.epam.brest")
>@EntityScan("com.epam.brest")
>@Transactional
>@EnableJpaRepositories
Зачем? Зачем?
guest # 0 ⇈
А вот спринг МВЦ
https://github.com/Helgi-cell/HashStringAlphabetical/blob/main/src/main/java/com/epam/brest/hashstring/controller/HashStringController.java
зы: он троллит, конечно
https://github.com/Helgi-cell/HashStringAlphabetical/blob/main/src/main/java/com/epam/brest/hashstring/jparepositories/HashStringJpaRepo.java
3.14159265 # 0 ⇈
guest # 0 ⇈
Додик знает, что любое приложение состоит из
* веб контроллера
* базы данных
ну и если тебе надо хеллоу ворлд написать -- он и пишет туда JPA, Spring MVC и прочий Spring.
Ну и конечно сервис ради DependencyInjeciton:
https://github.com/Helgi-cell/HashStringAlphabetical/blob/main/src/main/java/com/epam/brest/hashstring/service/HashStringService.java
guest # 0 ⇈
Гологубчик, перелогиниться забыл?
Я кстати, только что по путинскому мосту проехал.
Desktop # 0 ⇈
3.14159265 # 0
https://avatars.githubusercontent.com/u/71282399
Хоумворк.
https://github.com/Helgi-cell/HomeWork11October
guest # 0 ⇈
https://github.com/Helgi-cell/HomeWork11October/blob/main/src/main/java/DataModules/PriceShipping.java
3.14159265 # 0 ⇈
Там вот этих пиздушных геттеров, спрингов и JPA ещё нет, не научили ещё погромировать.
https://github.com/Helgi-cell/SteelJob/blob/main/src/steelworks/MyInterfaceHat.java
Статические массивы в интерфейсе, очень мило
guest # 0 ⇈
Ну есть же картинка известная, типа нуб
Мидл
Сеньйор
3.14159265 # 0 ⇈
...
guest # 0 ⇈
А как появились ``public BigDecimal getPriceLargeMore()`` так сразу стала какая-то хуйня там про строки
зы: хотя я бы наверное не рискнул пользоваться водосточным коленом, в расчете которого учавствовал дабл
3.14159265 # 0 ⇈
Не-не-не. Это слишком просто.
Эволюция Июнь, Мыдл, Синьор там всё должно только усложняться.
The Evolution of a Haskell Programmer.html
guest # 0
ГЦ-блядь никогда не думает, где лежит объект: она просто пишет new, и течет.
С++ блядь конечно думает: лежит ли объект у меня на стеке, или в векторе? Или может на стеке, а в векторе ссылка? Или я его мувнул в вектор, и больше не могу им пользоваться? А может, я его туда скопировал (что долго)?
Для джаваёба все эти вопросы не существенны.
И вот жаваёб пришел в Rust, где всё тоже самое, что и в плюсах (ну только ничего по умолчанию не копируется а мувается, и еще ссылку надо явно задавать).
У ГЦбляди пухнет маленький мозг, и ГЦ блядь начинает хуярить всё в кучу с RC (atomic он для передачи между тредами) а если что-то не компилируется (ибо всё мувается по умолчанию и оно мувнулось) то тупо клонирует
В итоге получает говнецо похлеще джавы, и скоро начнет ныть, что нифига это чото не быстро.
3.14159265 # 0 ⇈
Ну да.
Йажа она конечно тупая, но хотя бы реордеринг в OoO будет.
А тут атомики наделают фенсов и вообще перепитушня страшная.
ЗЫ, там растухи рекомендуют Rc.
Unlike Rc, Arc uses atomic operations for its reference counting. This means that it is thread-safe. The disadvantage is that atomic operations are more expensive than ordinary memory accesses. If you are not sharing reference-counted allocations between threads, consider using Rc for lower overhead.
Чем не зашло?
guest # 0 ⇈
В рустне есть:
* Box это некоторый аналог юника
* Rc это шарик, как ты понимаешь. Но шарик не потокобезопасный (потому что ты не можешь с двух потоков крутить счетчик) и потому его нельзя между тредами.
* Arc атомарный шарик, который можно между тредами (там трейт специальный реализуется, позволяющий между потоками копировать)
Если ты будешь всё хранить в куче и со всем работать через Arc то будет малость не так перформансно, как могло бы быть
JlAKOMKA # 0